Minutes, URL Registration Working Group, Munich IETF
Meeting chaired by Dan Zigmond
Minutes reported by Larry Masinter
[Larry Masinter, 9/14/97: My deep apologies for being so late with
these. Somehow I managed to forget that I was the minutes-taker until
just a few days ago. The cutoff for minutes for the proceedings is
9/15, but please send any corrections as soon as possible, even if
it is after today. My notes were sketchy and my memory has faded
after a month.]
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 around "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 syntatic
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 are 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.
service:____://location____
^ type(protocol) ^
+--- location
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 & 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 he 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
idea is:
dns+netscape.com+blah:
is a namespace that is owned by "netscape.com"; name space confict 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 / to ! (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________;_____
which defines the elements in the URL scheme. A service template is a
document that defines it. It defines:
type<->protocol
path rules
attributes
version
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
2.x.
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
* POTS
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 & Erik Gutmann will write a glossary.