Minutes, URL Registration Working Group, Munich IETF Meeting chaired by Dan Zigmond Minutes reported by Larry Masinter [Larry Masinter, 9/14/97: My deep apologies for being so late with these. Somehow I managed to forget that I was the minutes-taker until just a few days ago. The cutoff for minutes for the proceedings is 9/15, but please send any corrections as soon as possible, even if it is after today. My notes were sketchy and my memory has faded after a month.] The first part of the meeting discussed the guidelines for new schemes, draft-masinter-url-process-02.txt. The current draft is nearly a checklist or a form to fill out, and perhaps that could be extended. Is this just a set of 'guidelines', or is it more a set of questions each URL scheme must answer, to characterize what it is doing? We should try to separate out the difference between "public" and "private" URL schemes. The discussion centered around "What's reasonable to standardize?" Primarily, we don't want same name with different mechanisms. We discussed some common URL scheme design issues, e.g., when a given protocol should use a single scheme vs. a set of schemes. The example given was z39.50, which wound up defining two different schemes. There is a design choice, and no current guidelines for making the choice. We discussed the issue of trademarks in URL schemes, and more generally, the choice of the name of the scheme. Given a resource locator, "word:<...> ", in what cases is "word" bad? It is vendor proprietary? It is not really general enough? It is really a content-type? We need more examples. We discussed the question of whether there should be a clearer separation between "data location" and "service location" in URL schemes, e.g., whether new schemes should distinguish these syntactically. Or, more generally, whether we could use some syntatic mechanism to characterize better what kind of resource it is. We discussed the example of IPP. The IPP working group is using HTTP to send things to printers, but plan on using HTTP: URLs for printers. Maybe they want a different URL type? But maybe they should elaborate better what it is they can do with it. Yaron Goland proposed a couple of criteria for URL schemes: - What users are going to see? - What needs to be standardized? - What doesn't need to be standardized? - What users type in is called a "URI". What goes into the 'open location' box is a kind of URI. This is the global registry. In XML, every tag is a URI. We discussed establishing a glossary for URL scheme descriptions, e.g., "Get-like", "Put-like", "document-like", "evokes a service". We agreed to try to define a glossary; Erik Gutmann & Yaron Goland will send some terms to the list. URLs are a kind of registry. Our criteria should be: 1) The list of URLs are comprehensive and interoperable. 2) The definition is clear enough that people can figure out the mechanism useful to support it. Make sure that it is clear when a URL is globally scoped. It was suggested that the criteria document should have language of the form: "If the URL refers to a file, then it should have these characteristics, if it refers to a service procedure, then it should have these characteristics, and otherwise, it might have separate vetting procedures." [Note: a comment was made that perhaps URLs should look like acronyms: it's a good thing, because shouldn't be English.] ----- We discussed the "service:" URL scheme. service:____://location____ ^ type(protocol) ^ +--- location A question for the process document: can names be delegated? It was observed that the process for URL registration could be different for different categories. It was suggested that one criteria for "different schemes" vs "multiplexing a single scheme" is that different schemes should have different implementations, but that a single scheme could be handled with have a "single" implementation. We discussed the issue of the granularity of URL schemes with the example of "person:" vs "phone:" vs "fax:", of being generic about identifying an individual, a particular address (e.g., a telephone number) or a particular service (fax) at that telephone number. The ITU Study group 16 originally wanted "person:", but maybe they need both "person:" and "telephone:". Someone made a plea: "Please don't turn URIs into protocols." This was countered with the point of view that URLs describe a protocol interaction encoded in a terse string. We discussed the question of how to Deprecate/change/get rid of, migrate a URL scheme's syntax. The normal IETF standards track contains mechanisms for deprecating, changing and marking protocols historic. But perhaps the URL process guidelines should be explicit about changing & deprecated. An analogy: MIBs are standards-track documents, but have a separate set of processes for reviewing them. The process should not insist that all URLs be standardized. We need to lower the barrier so that anyone can get a private name. We talked about the 'usefulness' clause in the guidelines: there are some URL schemes for which it's not clear that they hurt anybody, but it's not clear they're useful. Question: What is the right process for deciding the right name? Keith will send a message he sent to ITU SG 16. What's the process for deciding how to name something? "tel:" vs "voice:" vs "phone:"? What's the way to handle the aesthetics? Keith suggests something like usenet group name bashing. Someone else suggested a committee that will have final say. Name bashing is done in public. We discussed a hybrid scheme: find out who cares? Find a group of people... nominating committee. The committee should have clear instructions. It should gather public comment, make sure it doesn't loop infinitely. The process will have to fit into the rest of the standards process. There was a warning about government involvement; URL scheme names are a 'high-rent' district, and that the issue of trademarks will arise, and we should watch out for the kinds of trademark issues that the WIPO is involved in. Yaron Goland presented a proposal, draft-goland-url-dns-00.txt for 'names that people don't want to see': URL schemes that are only meant for consumption by programs, but not meant to be standardized. The motivation was to avoid registration and public comment. The idea idea is: dns+netscape.com+blah: is a namespace that is owned by "netscape.com"; name space confict is reduce to avoiding DNS conflicts, and we don't have to worry about creating another IANA central registry. One alternative, adding random numbers to URL schemes, e.g., "MS1234:" was rejected on the grounds that programmers (who need these) will forget random numbers. To the question "how many private URL schemes are there?", the answer was given that there were perhaps 20-40 in use at Microsoft, with 2-3 being added a day; WebTV has 24, with 6/year added. Maybe others have similar number of schemes. We discussed the particular characters "DNS" and the use of "+" as the separator, and decided to continue the discussion on the list. ---- A question was raised on the issue of "how to embed URLs in URLs"? There is one proposal for embedding URLs inside other URLs which had the user change / to ! (after encoding !). What are the protocol elements that get embedded in URLs? For example, the ftp scheme tried to embody user & password, type=D, trying to make it consistent. In general that's hard. -------- Erik Gutman presented the "service:" URL scheme and the registration procedure the service location group was considering. The general syntax is: service:type:/servicetype/address________;_____ which defines the elements in the URL scheme. A service template is a document that defines it. It defines: type<->protocol path rules attributes version The service template registers the template to a group. The group is open. The group should solicit experts in the field. There is a time fuse for discussion, and rules. The scheme goes to the registry as version 0.X once it is accepted, the version changes to 1.x until it is changed (deleted/modified) when the version changes to 2.x. They require users to propose management mechanism for subschemes. Delegated management of registry... the registry should apply to things before the colon. The name space determines rules for how you get names. You can only delegate to a permanently standing group. --- Pete Cordell, BT presented "Conversational URLs" * Internet Telephony * POTS Issues: There are many ways to contact People, change expected. For more info: email: Pete.Cordell@bt-sys.bt.co.uk. A rough draft will be sent out to the list. ---- We discussed the process for gathering together the interested parties for deciding on URL schemes. In general, protocol groups are responsible for their own URLs. How to find like-minded folks to define a URL? ---- We ended the meeting with a review of commitments: Dan Zigmond will write up a vetting process. We will discuss the guidelines on the mailing list. Yaron Goland & Erik Gutmann will write a glossary.