Hi,
VERY worth reading - detailed minutes from the URI BOF at
IETF 60th Plenary last week.
Almost everything discussed directly impacts printers
and network imaging devices.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: uri-request at w3.org [mailto:uri-request at w3.org]On Behalf Of Larry
Masinter
Sent: Sunday, August 08, 2004 11:56 PM
To: minutes at ietf.org
Cc: uri at w3.org
Subject: Minutes URIREV04 BOF, 8/6/2004 9-11:30 AM
Minutes were taken (using Jabber) by Ted Hardie, Paul Hoffman and
Lisa Dusseault (with some contributions from the net.) Larry Masinter
used log to create the minutes.
Ted = Ted Hardie, Larry = Larry Masinter, Roy = Roy Fielding,
Martin = Martin Duerst, John = John Klensin, James = James Seng,
Leslie = Leslie Daigle, Pete = Pete Resnik
Original agenda
===============
5 min Agenda review
15 min RFC 2396 revision
*** draft-fielding-uri-rfc2396bis-06.txt
IETF last call has been requested.
(Roy Fielding)
15 min Internationalized Resource Identifiers (IRI)
*** draft-duerst-iri-09.txt
Let's hear current state & try to get this one out.
(Martin Duerst)
15 min RFC 1738 scheme updates
*** draft-hoffman-rfc1738bis-02.txt
Finally updating/obsoleting old spec.
(Paul Hoffman)
100 min Registering URI schemes
The policy and process for registering new URI
schemes.
10 min Introduction to topic
"Guidelines for URI schemes",
*** RFC 2718, RFC 2717 registration procedure
"vnd and prs trees"
*** draft-king-vnd-urlscheme-03.txt
Some recent 'problematic schemes'
Request for IANA registry of 'proposed' schemes?
75 min Discussion
15 min Wrap-up: conclusions, next steps, action items
draft-fielding-uri-rfc2396bis
=============================
This is ready for IETF last call. It has had a very vigorous review
on uri at w3.org. Larry believes that it will be relatively clean
sailing through the rest of the process. Ted notes that it certainly
ready for IETF last call.
There were many remarks about how RFC2396bis is much better than
RFC2396, and a real service to the community. There was appreciation
and applause for Roy's work on the document.
We discussed Section 6.3 (Canonical Form):
The discussion started with questions: are the following normalized?
'http://www.w3.org/2000/01/rdf-schema#' (empty fragment identifier)
'http://example.com:80/' (port number = default port)
Roy noted there had been a normalization step which removed empty
fragment identifiers, but it was removed on request. The removal of a
default port was considered a 'protocol-specific' normalization. We
discussed other possible normalizations by invoking other equivalences
listed in section 6, e.g., '6.1' and '6.2', etc. It was noted that
different software uses different canonical forms, e.g., XML
namespaces vs. HTTP proxy.
Roy concluded that Section 6.3 says exactly what it was meant to say,
and nothing was left out on purpose. Larry suggested removing section
6.3 from the 'Standard' document and, if desired, having a separate
Proposed Standard for a URI canonical form.
The ATOMPub group needs URI canonical form, will review this section.
This discussion to be continued on the list.
This section will need some work, but it shouldn't hold up IETF last
call, instead these can be handled as last call comments. Roy says he
won't change this section until there is actual data.
draft-duerst-iri
================
A request to the IESG for publication has been sent. The mailing list
for disucssion is public-iri at w3.org; last call comments to IESG &
public-iri at w3.org. Larry was an original author, then it was handed
off to Martin; then Michel joined as co-editor.
There is an issues list which notes issues and closures at w3.org as
well. Nit: two of the names of the productions in RFC2396bis changed;
cosmetic change in IRI document are needed to track them, but IETF
last call need not wait for this. The W3C/IETF coordination call
discussed how to move forward on this. The current proposal is to move
the two documents (RFC2396bis and IRI) to Last Call at the same time.
If issues come up with URI spec it will either be orthogonal to the
IRI spec or they will need joint update. The big difference of course
is that IRI goes to Proposed.
Ted is concerned that we might need an informational document in the
future, on usage of URIs and IRIs -- when do you use one, when to use
the other, and other useful advice. For example, Larry talked to
someone who wondered if they should register a URI scheme or an IRI
scheme or both; perhaps it isn't clear there is just *one* namespace
for schemes.
Martin would be willing to help with a document that is aimed at
protocol developers, but might need help from someone with a more
"outside" view.
Martin notes that discussion of URIs vs. IRIs in ATOM has not
progressed in part due to limitations in the wiki. (???)
1738 scheme revision
====================
RFC 1738 contained not only the early URI syntax but also several
scheme definitions. Paul Hoffman did a draft which extracted the
definitions of those schemes: ftp, gopher, news, nntp, telnet, wais,
file, prospero.
Most of the discussion on the document has been on 'file:'. 'file:'
doesn't interoperate across platforms, and sometimes not even on the
same platform (e.g., one windows application will treat file: URIs
differently than another).
'File:' it deeply broken. Is it worth trying to fix, given how widely
deployed the broken implementations are?
Are we prposing new protocol work? It isn't worth doing new protocol
work if the people responsible for the deployed software aren't going
to participate in the process. Would having a spec be a forcing
function? Should we just describe the way in which current
implementations differ?
Larry thinks there's some common practice around UNC pathnamess &
drive letters. It would be useful to document what's there. And people
can use file: URIs interoperability as long as they're really relative
URIs based on files that are selected in some other manner.
Martin thinks it would be useful to give implementors something
they can converge on... perhaps within 5-10 years.
Larry suggests describing common practice and stopping there; if
convergence is desired, all of the implementors can pick, say,
"Section 2" and recommend it. We can even make that an editorial
suggestion in the specification.
Is this 'a description of what is out there', but 'not a description
of what people have to implement'?
There was a discussion about whether 'gopher' was going to be marked
'historic', and whether any of the old schemes might be either 'left
behind' or 'obsoleted' or 'marked historic' and what that might mean.
Marking something 'historic' might imply a different status than
intended; gopher:, prospero: and wais: aren't dangerous, just not
widely used.
There was a discussion back and forth about splitting this into
several documents, leaving some in one document, etc. Not splitting
now would just make someone else split it later. The discussion led
to the conclusion that Paul would split this into seven separate
documents; some people would be asked to take on some of the documents
(news & nntp to usefor, for example).
There was some question about whether this would block RFC
2396bis. The thought was not, the meta-data about whether 1738 was
'updated' or 'obsoleted' was independently maintained.
Registration process, guidelines
================================
(RFC 2717, 2718, draft-king-vnd-urlscheme)
We discussed the process for registering URI schemes.
* URI registration is broken:
The public perception of URI scheme registration is off from
reality. There are many schemes whose attempted registration has
languished for years without any deterministic process for either
registering them or saying 'no' definitively.
We originally made an exception to the guidelines for URI schemes
which allowed schemes to be registered even if they didn't quite meet
the guidelines if they were widely deployed. The result has been
people just use their scheme and hope that if they get widely
deployed, they will get a registration.
The original intent of the high bar was keep the number of registered
schemes down. But people just mint them, and plan to register later.
Now are seeing conflicts; e.g., 'mmms:' has diffenent interpretations
used by 3GPP and Microsoft. We need to fix this.
Ted suggests that we abandon the idea that registration will reduce
total number. Our only purpose should be to eliminate namespace
conflicts.
* What's in the registry? Is there a 'line'?
We discussed various forms of registries that might set some line --
schemes below the line not as good as schemes above the line. A
provisional registration followed by a permanent one after six months,
etc.
Ted suggests a provisional registration that provides a specification
or an implementation pointer, for six months. If someone already has
a provisional registration and a spec, they win, they get in.
James suggests that perhaps the rule is that the scheme has to have
two different implementations.
Leslie asks how one might make a URI processor that can handle a
zillion different schemes.
Leslie suggests that there are two classes: ones with published specs,
one without; we should discourage non-protocol schemes.
Requiring a 'definition' or a 'protocol' for a scheme might not be
enough; Paul gave an example of a scheme with a 'definition' which is
'just like http', i.e., it's well-defined, but useless as a URI
scheme.
John points out that if we set up barriers, people will do whatever
they do anyway.
Larry suggests registering implementations of URI schemes.
Larry says rather than setting a threshold ("must have at least 1
implementation") just document the values in the registry, and let
people come to their own conclusions.
Leslie says the criteria might be running code and/or specification is
enough to get above the line. Larry wants us to never draw a line.
Larry wants us just list pointers; people will game the line.
Leslie thinks that "community vote" is OK, as long as we clearly
define what is IETF (as in: on standards track). Larry agrees.
* Abuse:
Roy says that we might also need to worry about preventing abuse,
e.g., registering URI schemes with other people's trade names, etc.
John points out that there is an easy denial-of-service on other
people's names. With IANA and port numbers, the rule was 'you get one
for free' but for the second registration, you need to provide
something, e.g., a protocol definition.
Paul says there are big WIPO problems. John says that WIPO will
probably just let people sue each other. John says that ICANN just
defers to WIPO.
Paul talked about formal association with WIPO.
John points out (again) about insanity and WIPO.
James says we don't have a problem now because the bar is so high; if
we lower the bar, it's going to become a problem.
Geoff talks about WGs "preemting" registration. [[ed: ??]]
* Duplicates (and comparison to header registry)
Larry suggested that perhaps allowing multiple registrations for the
same scheme might be allowed. This caused wild disagreement in the
room ("that's nuts", "terrible, terrible", "if we allow collision,
let's just not do this").
Pete says we had the same fight about the header registry; points out
that we wanted a single place for people who didn't want to have a
conflict to look.
Pete thinks that we can have duplicates in the registry. Pete says
"document usage, allow people to see what isn't use". John says let
the bad guys duke it out.
Leslie asks "what happens when a bad guy wants to add a second
registation for urn:?".
Larry thought that allowing duplicates might reduce some DoS
values, because someone else registering 'roy:' wouldn't stop
Roy from using it.
Ted thinks the bar should be set above allowing multiple registration.
Martins says the Web just doesn't work with multiple schemes. Martin
wants each one clear, and wants to resolve the problem with the
current duplicates.
Leslie would have preferred a universe with just one, and a smaller
number of schemes. But she wants to acknowledge reality. We should
give the clearest picture possible of the universe.
Ted acknowledges that keeping the number of URI schemes low was not of
benefit to the user. Argues that trying to shape it to avoid collision
is paramount. Paul agrees with Leslie.
John points out that the header registry's purpose is to say "here's
the legitimate use of foo, but there is another use". The header
registry is used for security and user-defense warning (e.g.,
which systems might send headers which have different meanings).
Martin asks if the header registry works and what implementers think
of it; how do negative comments get into the registry?
John says the negative comments can get there through the standards
process.
Tony Hansen clarifies how the header registry works.
* scaling:
Roy ask about scaling for the IANA registration, and suggests that
maybe we use an issue-tracking system to help with the scaling.
* vnd and pers:
We have gotten enormous pushback from the vnd- and prs- trees.
Larry suggests abandoning them, and it is agreed.
* Guidelines
Someone unknown asks about getting on IANA pages. Larry clarifies
that we are talking about changing the way to get onto the IANA pages.
Martin points out that some people understand the current rules, but
others are clueless and then get grumpy.
Cyrus Daboo points out that there is only a single entry right now.
* Other orgs:
Martin points out that other standards organizations can pass in a
MIME type template in their own specs that must go through the IESG,
and asks that we think about that for URIs as well.
* summary:
Ted says that we have general agreement that we need a lower bar and
acknowledge what is happening now.
We have exposed many good issues, but there are still many
details to be worked out.
Tony Hansen agreed to co-author with Ted on a draft.
This will be a replacement for RFC 2717 and RFC 2718 (registration
procedures AND guidelines). Martin Duerst has offered to help.
Roy notes that RFC 2718 (Guidelines) are really about locators, and
non-locator schemes may need some additional, but different,
guidelines.
Non-IETF tree (vnd- or prs-) will be dropped.
wrap up
=======
We agreed to do everything on uri at w3.org. Possibly even scheme review
in the future.
Ted says that he wants to close down uri-review mailing list.
Martin says that URIs are important, and that the W3C may make the URI
Interest Group mailing list a public list.
* Postscript:
On the jabber log, but not in the meeting, Michael Mealling asked: Has
anyone actually gone to the authors of the non-registered schemes and
asked them what it would take to make them happy?