URL schemes

I don't have comments on the minutes per se (I wasn't at the meeting),
but I'd like to launch into some of the issues raised, especially the
top-level name space of URL schemes.

Ian King writes:
 > Minutes of April URLREG BOF for review

 > Scope of the BOF
 > ----------------
 > 
 > 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.

I think there are plenty of opportunities for discussion about the
standardization process to inform the discussions on the other related
issues, and vice versa.  For example, it is very useful to consider
the examples of particular URL schemes to understand the general
standardization process.  To some extent, resistance is futile, but
gentle reminders should be sufficient when divergence has gone far
enough.

 > Discussion on current URL process I-D
 > -------------------------------------
 > 
 > 1.  Registration process
 > 
 > 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.

I don't know of any application where the "x-" prefix idea makes sense.
But that is not the only way to define private schemes.

Note that the "x-" prefix essentially throws all experimental or
private schemes in the same name space, under "x".  So this simply
means there is no guarantee of non-conflict.  This does not mean that
there is a privately controlled non-conflicting name space.

I think that the correct way to get private name spaces with no
conflict is to use a hierarchical name space.  The top levels must be
agreed on publically, so there is potential for conflict at this
level.  But the idea is to minimize this conflict and to delegate any
conflict to other organizations that are designed to deal with it.

I seem to be suggesting that URL scheme names could be hierarchical.
But this is not strictly necessary as long as there is hierarchy
somewhere at the top of the URL, and that new syntax and semantics can
be associated with any subspace.

 > 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 dont' think it's good for private schemes to go standards track
 > because it will clutter up the process for no good reason.

I agree with Larry.  But we can avoid most of the clutter if we
delegate most of the process.  

 > 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
 > 
 > Issue: review panel should have the community that implemented the
 > related functionality also review the proposal.  Any URL which covers a
 > protocol should be reviewed by that protocol community.
 > 
 > Issue: Names in URLs should not be trademarks.  

An alternative: URLs scheme names and other top-level registered names
*should* be trademarks.  Let the trademarking infrastructure deal with
the conflicts.  But U.S. trademarks are not international.  But if we
are essentially doing the same thing as the trademark offices of many
govermnents but we are doing it internationally, are we not moving one
step closer to an international government?  Not that that is a bad
thing, of course.

 > 3. Conflict between I-D's -- section 2.1.1
 > 
 > Many people are putting :// into there 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.  

Correction: By Tim B.L.'s conception, '://' does not mean top level of
a scheme; rather, ':' means top level of a scheme, and '//' means a
just one level *higher* than '/'.  It is also possible to have '///'
which is higher still.  I'm not sure about the ramifications of this
scheme.  For one thing, we can add higher levels but not lower levels.
All this has more to do with the generic URI syntax than with the
registration process, so I'll stop, except to mention the following.

The URL scheme name is only one thing that may need to be registered.
Depending on the URL scheme, the identifiers used within a URL may
need to be registered.  E.g. DNS names for most URL schemes.  One
requirement for registration of a new URL scheme name might be that
there exist plausible policies for registering these other
identifiers.

 > 4. Conflict between making proxies work and why have a URL if it can be
 > done with something else (section 2.3.1)

The main reasons are syntactic convenience and new associated
semantics for new URL schemes.  A general enough scheme, such as http
maybe almost is, could be used to discover new semantics for subspaces
of existing URL schemes and for new URL schemes.

 > 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.  
 > Decision: omit section 2.6.1

Umm, the URN group was *founded* with the assumption that there is a
difference between URLs and URNs.  And recently they concluded that
(all?) URNs will start with "urn:".  But that decision by the URN
group should not necessarily impact any other working groups' decisions
until agreed on by the IESG.  Am I correct?

Nevertheless, I don't think we need to consider the difference between
URLs and URNs in this draft.  Several people in the URL group (I
expect) are with me in believing that the reason we don't need to consider
the difference is not because there *is* a difference but because
there *isn't* a difference.

Why does it matter (for this group) why we drop the URL-URN
discussion? It matters when considering who gets to decide whether the
URL scheme called "urn" gets assigned and on what basis.  Is it a
special case or is it just another URL scheme?  If it is a special
case, what other special cases will there be?  Who decides that
something is a special case?

--
Daniel LaLiberte ([email protected])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/