NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Rich Petke <email@example.com>
Ian King <firstname.lastname@example.org>
Applications Area Director(s):
Keith Moore <email@example.com>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: subscribe in message body
Description of Working Group:
This working group exists for the purpose of creating two documents: The first document, a BCP RFC, will be the process for registering new URL schemes. The second document, an Informational RFC, will be a guideline for the creators of new URL schemes. The purpose of this guideline will be to help ensure that new URL schemes:
· Consistently implement the general syntax of URLs as specified in the URL Generic Syntax and Semantics RFC.
· Are compatible with existing URL schemes.
· Have clearly specified character encoding rules.
· Have a well defined set of operations specified for them. Properly address security considerations.
The following issues are considered beyond the scope of this working group and shall not be addressed by it:
· Modifications to the URL Generic Syntax and Semantics RFC.
· Specific URL schemes, previously proposed or not, except as test cases for the guidelines document. - UR* schemes other than URLs.
Justification for working group:
RFC 1738 defined URL schemes for a number of protocols popular at the time that it was written. Many URL schemes for protocols not addressed in RFC 1738 have been proposed since the publication of that RFC.
Due to the absence of guidelines for the development of new URL schemes, some of these recently proposed schemes lack completeness. Further, while some of these schemes are now on the standards track, no mechanism for the registration of these new schemes has yet been specified.
The output of this working group is needed in order to help ensure the overall integrity and consistency of URLs in the future.
Goals and Milestones:
Publish drafts of the registration and guideline documents that capture all open issues and propose possible resolutions for each.
Submit guidelines document to IESG as an Informational RFC.
Submit registration document to IESG as BCP RFC.
No Current Internet-Drafts
No Request For Comments
Minutes of the URL Registration Working Group
Chaired by Dan Zigmond
Reported by Larry Masinter
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 on "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 syntactic 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 is 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.
^ type(protocol) ^
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 and 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 be 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 is: dns+netscape.com+blah: is a namespace that is owned by "netscape.com," name space conflict 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 / too ! (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________;_____ that defines the elements in the URL scheme. A service template is a document that defines it. It defines:
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
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
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 and Erik Gutmann will write a glossary.
go to list