URL Registration Proceedures WG Minutes

-- URL registration Procedures WG --
Meeting: Tuesday, Dec. 9, 1997, 1300-1400EST.

*** note, these minutes are incomplete and paraphrased, ***
*** apologies for inaccuracies, omissions ***

http://www.imc.org/ietf-url

[email protected]
[email protected] (to subscribe)

Chair: Rich Petke ([email protected])
       Ian King ([email protected])

Rich Presented information about the goals of group.
Talked about being behind on dates as per charter.



-- URL registration guide --

Larry has finished final mods on this.  This will be proposed
as last call.

draft-ietf-urlreg-guide-00.txt
editors: Larry Masinter ([email protected])
         Dan Zigmond ([email protected])


-- URL registration process --

options:
- everything standards track
- standing review committee
- mimic mime rfc 2048
- no reg option
- draft-iesg-iana-considerations-01.txt

someone:  there were two suggestions.  (1) standards track rfc, (2)
have a committee to review new schemes with appeals process to ADs.
Some question about how well the latter process fits into IESG.

Rich:  I don't know that in the past.

Leslie:  I think on the mailing list that there was the notion of 
treating this like the MIME media type registration mechanism.
RFC2048.

Don: There certainly have been no major objections to this.  There
is also Yaron Goland's proposal which ties uniqueness to DNS names.

Yaron (MS):  We needed a way to register arbitrairy schemas, and
these had two qualities (1) they did not need to be human readable
but should be pretty enough that a developer could look at it, and
(2) that they needed to prevent conflicts in namespace.  The
proposal basically has DNS, then is followed by a path.  There
is also recommendations for what happens if DNS name changes hands,
etc.  A solution for the DNS changing hands problem is to use GUIDs
which will be unique to the year 6000

Larry: IESG has approved a document that will affect us:
draft-iest-iana-considerations-01.txt.  It lays out in great detail
example policies that could be used.  Here is a basic outline:

1.  free-for-all.  For local use only.  Don't try to avoid conflicts.
	No need to be reviewed by IANA.
2.  hierarchical allocation.  Pretty much what Yaron was talking about
	IANA controlls a higher level of the namespace.  We could
	use DNS here, or another mechanism is fine.
3.  first-come-first-serve.  Anyone can obtain a value as long
	as they provide point of contact, and describe what it 
	will be used for.  Advantage
	is that you will get a short name (rather than using
	hierarchal allocation).  For example vnd- mime types.
4.  specification required.  There must be an RFC.
5.  IESG approved committee.  Extensions are approved by IESG.

These are just examples of policies.  We don't necessarily have
to use these, but these provide some examples of existing
schemes that we could use.  I think there is some value in 
allowing multiple mechanisms to be used here.

Patrick: I agree with Larry that we can not come up with only one
way of doing this because occasionally you'll need a URL scheme
that is used by several applications.

Dan Zigmond: I am wondering if there is value in making these
URLs short.  There is value to having short URLs for WebTV,
for example.

Yaron:  The reason we chose DNS in the draft is that they can
be short, and somewhat pretty.  One of the problems that comes up
is that of trademarked names.  There are a class of URLs that need
to not have any resembalance to something that could be
trademarked.  It seemed to us that using DNS meant that since DNS
alredy solved this, using their mechanism avoided this problem.

In addition, we had a big problem with filename extension
collisions.  I don't belive any kind of registration mechanism
will be effective because people will use them without registering.

Larry:  I was worried about the trademark issue when the mime
registration using vnd- was first proposed.  I don't think this
has actually turned out to be a problem.  The process by which
registration mechanism works ensures that it will be reviewed
by other people and those people will give feedback.

In addition, if people want to have hierarchal names as well that
makes sense since they require no registry mechanism.

I think then people would have a choice.  If they want a short
name, then they have to either go thru an IANA registration
mechanism, or publish it in a draft.  If they don't want to do
this, then they can use the hierarchal mechanism.

Patrick:  ? missed this one ?

Dan Zigmond:  I don't know how much we have to worry about the
trademark issue.  If someone had a trademark on HTTP, it hasn't
stopped that from going thru the IETF, etc.  Also there are
vanity names, and there is no reason to not be able to 
create a name like "webtv" url.

someone:  What I hear is that shortnames are very valuable like
"webtv" is valuable to users.  What I'm not sure about is if 
there is a real link between what is in the protocol and 
what is displayed to the user.

Leslie:  I'd like to get a handle.  Since DNS proposal has
managed to prevent collisions in the namespace, have you considered
how netscape and ie will interact with these.  My point is that 
potentially they will do something undesirable.

Yaron: ? missed this one ?

Larry:  I want to answer the question why people want short URL
schemes.  People using these authoring tools to enter these URLs.
Even though users may not see these, authors will, and it needs
to be clear for these.

someone:  It would be possible to not use friendly names for
filenames.

Josh:  I don't think there will be a big problem between Microsoft
and Netscape.  Having a short URL scheme where you can't distinguish
between MS and Netscape defeats the purpose of having this.

Henrik:  3 points.  Even if the browser starts with a short
name, the browser can return a big long name.  Also, you can
avoid namespace collisions by using short names.  Bringing up
the filename example, there often needs to be multiple names for
a single file.

Don:  I think we're drilling down too far on these points.  I want
to see if there is concensus that there is a need for a mechanism.

Dan:  Proposed that we use the three teir mechanism that Larry
described.

someone:  I think there should be a sliding scale.

Larry:  I'd like to get done in this working group, and I don't think
it needs to take a long time.  I'd like to be done in this working
group if possible.

Dan Zigmond:  I volunteered to edit the document from the last meeting.
Here is my understanding:

1. short names (vnd) by review.  The short description is sent to a 
mailing list and feedback is given in an advisory way.  There 
is no enforcement.  There is enough process to let people find 
conflicts.  This would be done by 'vnd.'

2. short-short names (rfc, standards track, iesg action)
 
3. long name - your review.

Henrick:  I don't like binding short names in a globally 
unique manner.  I object to the centralized mechanism.  some
discussion.  ? did not understand this enough to explain ?

Larry:  my experience is really the opposite.  x- never works.
If you ever release any sofware that has x-, you will be forced
to continue to ship that way.  My philosphy is that lots of
URL schemes is bad, and we should try to discourage this while
acknowleding that you can't prevent it.

Keith: x- was not bad.  When you pick a name for something,
you realize that you may pick one that is.  I talked to someone
from w3c about mime content type registration.  Harald and I, etc
felt there should be a way to pre-register a short name.

Larry: so what you're saying is that a draft would be required.

Keith: an internet draft would not be required.  There would be
a way to do this for example thru IANA.

Larry: so working group chair and IANA.

Keith: just have to make sure the right people sign off on it.

Rich:  we're running out of time.  Dan is going to publish the
draft.  We want to get rapid discussion of this and hopefully
close before the next IETF meeting.

------------------------------------------------------------------
Minutes by Alec Dun
Microsoft.