Minutes of the URL Scheme Registration (URLREG) BOF
Reported by: Lisa Dussealt of Microsoft.
We will resist all discussion of the generic URL specification -- it's a separate topic under consideration by the IESG. We will avoid covering specific URL proposals-- we will only cover the process by which these become standards.
II. Discussion of Open Issues in Current Draft by Larry Masinter
Major open section of the draft is the URL scheme registration process. Open issue also internationalization. Section 2.1.1 -- conflicts with generic URL spec??
Issue: how 2.3.1 does not contradict the directive that new URL schemes be proposed only if things cannot be done another way
Discuss open URL schemas and how they would move forward (zigmond-media,
hoffman-ailto, callaghan...).
Q: Should this Working Group's charter include the task of moving existing schemes toward the standards track?A. (Harald): No. This group should only define the procedure by which new schemes move forward.
Q. Is there a separate group that will exist to look at these schemas and approve them?
A. There is an URN registration group fumbling with the same registration process issues. It is unclear what is the difference between URL and URN. As long as we don't have a procedure, we can't move proposed schemas to standards.
Q. Should there be a different procedure from the existing IETF procedure of moving from proposed to draft to standard?
A. (Harald) What you can do is different, so the procedure is different. It is not clear that every URL scheme should be standards track – doing that was just a stopgap procedure.
Decision made to revisit the charter at the end of the meeting.
IV. Discussion on Current URL Process I-D
Proposal: submit an I-D, move to proposed, then to draft standard. Create a process that is not too easy and not too cumbersome to encourage the right quantity and quality of standard URL schemes.
Q. Can we define a strategy to differentiate private URL schemes from standard schemes, i.e., "x-protocol" for private and "protocol" for standard?
A. (Larry) It's too hard to move from private name to the real name when it becomes widely used.
Q. What is the consequence of unregistered URL schemes? Are they bad?
A. (Harald) This topic should be abandoned. First decide what the
registration procedure should be then explore the ramifications.
Q. Have there been any known URL collisions? Has there been a problem? Perhaps there should be two tracks, one official, one unofficial – but maybe there isn't a collision problem.
A. Only collisions have been with extensions of names, such as extensions of the mailto syntax with extra information. There has been leakage of internal-only names such as AOL: with people expecting those schemes to work more widely than they do.
Issue: The end-user doesn't know our rules so we have to be careful to avoid failures.
First track should be first-come, first-serve -- people can reserve a name so that there is no collision, without needing to define a syntax. Second track (standard) should define the syntax so that it can be widely used. It matters a lot whether the process takes a month or a year -- if the standards track process is short, then we don't need a fast track.
Issue: what if there is a name on the unofficial track that we want to use on the official track?
Q. Have there been in recent times in some other area an example of a swift standards track?
Rich: I'm hearing that registration is an important component to avoid collisions. Also good syntax definition is required for wide use. Finally, I'm hearing that IETF’s standard track is too slow. We would like to keep all sanctioned URL schemes within the IETF.
Issue: I think the standards track is quite fine -- even putting dozens of new schemes through the existing standards track is fine.
Idea: We can allow private URL schemes to do whatever they like response: No, we do need to define even private URL schemes to avoid user confusion.
Larry: I don’t think it's good for private schemes to go standards track because it will clutter up the process for no good reason.
Q. Is there a procedure in the IANA for abandonment of registered items?
A. The IANA will operate any registry it is asked to operate according to the rules they are given. We can write the rules for IANA to add and delete items to their registry.
Proposal: First step - register with IANA. Second step - publish scheme/syntax as informational if it is private or put through standards track if it is to be widely used.
Counter-proposal: IANA scheme that everybody can participate in, can register a name provided they have defined a syntax/scheme and a contact. This process might have a form to complete, and if the form is in order, IANA accepts the entry and the name is registered.
Q. Is it too much work for the IETF to accept and look at <>20 Informational RFC's?
A. (Harald) No. What I'm more concerned about are conflicts like having Compuserve register a "aol://" scheme or Microsoft register a "java://" scheme.
We're getting into the fine points of mechanics in order to get around the problem of over-registration. How do we decide who gets "java://" ? Can we avoid that?
Note that the doc proposes a 2-person review panel appointed by the Area Directors, which would have advisory capacity only.
Issue: Review panel should have the community that implemented the related functionality also review the proposal. Any URL that covers a protocol should be reviewed by that protocol community.
Issue: Names in URLs should not be trademarks.
Rich: We will take this onto the list.
2. Internationalization IssuesLarry: We need consensus on internationalization, using character-encoding schemes. Transcription might not be as robust as the existing ASCII method. We don't want to encourage use of something that doesn't work just to gain internationalization. I'd like to hear from others than the few voices heard on the list. Currently in the syntax draft, characters come from a limited repertoire.
Consensus: We should not cover the character issue in this group – we need to define the process first. What's in the doc now is all right.
Will those implementing URL schemes use this encoding? (Larry) I have yet to hear that anybody will do anything with this!! We need implementation.
A. There is a major Japanese browser that uses Kanji characters but I don't know how they are doing this. It was a conversion from something else.
A. We are starting to use unicode.
Issue: There's a lot more than just web browsers....
More investigation into implementation is required. This may be a chicken-and-egg problem, to resolve we need to try implementing.
Decision: We will take this to the w3c mailing list to reach more browser implementors.
3. Conflict Between I-D's -- Section 2.1.1
Many people are putting :// into their URL schemes from the impression that every URL needs "://". We need to clarify the intent of the double-slash. Does it introduce a host name? Tim Berners-Lee says it's an indication of the top-level of a scheme and not necessarily an internet host name, and as such it can be used widely.
Decision: This will be fixed in the next draft.
4. Conflict between making proxies work and why have a URL if it can be done
with something else (Section 2.3.1)
Harald acknowledged having started this line of inquiry. LDAP has mappings into HTML/HTTP, which lose interesting information, but other schemes don't lose this. The document should say whether it's one kind or the other.... This was intended logically to say that URLs should have demonstrated utility. You can demonstrate utility by having a gateway to get at the information to show what the URL would get you. Decision: This should be worded more clearly, more strongly. Take out the reference to HTTP/HTML because you can gateway into anything to demonstrate usefulness.
New issue: We don't want to consider the difference between URLs and URNs in this draft.
A: Right. The URN group was still deciding whether all URNs start with URN. Now we have consensus that it starts with URN so no issue.
New issue: More verbiage around 2.2.5 -- URLs that are not related to data sources (i.e., mailto). We need to be more explicit about what they should do
Decision: Strike the reference to proxies and HTTP/HTML from the charter. Decision: Keep the goal of addressing security consideration in the charter.
We hope we can have a new I-D by June 1. This requires resolution from the Working Group or inclusion of alternatives for open issues in the I-D.
Should we strike the mention of I18N in the schedule? Isn't this somebody else's problem? Alter the June 1 milestone to state that it will contain discussion of all known open issues, one of which just happens to be internationalization. This milestone should be more general.
Change final milestone to "submit I-D to IESG as BCP"
Decision: should have two documents
Decision to change the charter as described; Rich will submit an amended charter to the list and, after discussion, to the Area Director.