headers
Internet-Drafts | 28 Sep 1999 12:58
Picon
Favicon

I-D ACTION:draft-ietf-urlreg-procedures-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Locator Registration Procedures Working Group of the IETF.

	Title		: Registration Procedures for URL Scheme Names
	Author(s)	: R. Petke, I. King
	Filename	: draft-ietf-urlreg-procedures-08.txt
	Pages		: 6
	Date		: 27-Sep-99
	
This document defines the process by which new URL scheme names are
registered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urlreg-procedures-08.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urlreg-procedures-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-urlreg-procedures-08.txt".
(Continue reading)

Permalink | Reply | 15 comments |
headers
The IESG | 27 Sep 1999 20:47
Picon
Favicon

Protocol Action: Registration Procedures for URL Scheme Names to BCP


The IESG has approved publication of the following Internet-Drafts:

o Registration Procedures for URL Scheme Names 
  <draft-ietf-urlreg-procedures-08.txt> as a BCP.

o Guidelines for new URL Schemes <draft-ietf-urlreg-guide-05.txt> as an
  Informational RFC.

These documents are the product of the Uniform Resource Locator
Registration Procedures Working Group.  The IESG contact persons are
Keith Moore and Patrik Faltstrom.

 
Technical Summary

The paper specifies how to register a new scheme for URL's, and more
especially how scheme names are allocated. A registration process is
needed to ensure that the names of all such new schemes are
guaranteed not to collide.  Further, the registration process ensures
that URL schemes intended for widespread, public use are developed in
an orderly, well-specified, and public manner.

Working Group Summary

There were some discussions about if this document should also
include definitions for other trees than the IETF one. The discussion
was long, and no consensus could be reached. A descision was then
made to only talk about the IETF tree, and then "Alternative trees",
and consensus was reached.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian King | 27 Sep 1999 07:03
Picon
Favicon

Update: draft-ietf-urlreg-procedures-08.txt

Based on recent mail threads, I have amended this draft to address concerns
raised by our Area Directors and members of the WG; this is in response to
some real life issues that recently arose relative to a proposed URL scheme.
In particular, I've amended paragraph 3.2 to more carefully describe when
one may or may not use an Informational RFC to accomplish registration of a
URL scheme name.  I've previously sent out mail to the list with the
suggested language, and had few comments, so here it is, folks.  

Comments?  Let me have 'em.  Thanks -- Ian 

Ian King <iking <at> microsoft.com>
Speech Product Group
MICROSOFT CORPORATION
Permalink | Reply | 1 comment |
headers
Ian King | 13 Sep 1999 08:24
Picon
Favicon

RE: Proposed amendment to language of draft-ietf-url-procedures

Great.  I'm going to give it another day or two to see if I get feedback
(and I'm targeting specific known contributors), and I'll submit the
re-re-revised draft for publication.  -- isk 

-----Original Message-----
From: Keith Moore [mailto:moore <at> cs.utk.edu]
Sent: Saturday, September 11, 1999 8:57 AM
To: Ian King
Cc: 'Keith Moore'; 'ietf-url <at> imc.org'; 'urn-ietf <at> lists.internic.net';
'Rich Petke'; Patrik Fältström
Subject: Re: Proposed amendment to language of draft-ietf-url-procedures

> Keith, does this address your concerns?

yes, I think so.

Keith
Permalink | Reply | 0 comments |
headers
Ian King | 13 Sep 1999 07:36
Picon
Favicon

RE: Proposed amendment to language of draft-ietf-url-procedures

Then what do you suggest to provide collision management, identification and
interoperability in URL schemes?  I'd be thrilled if you have a viable
alternative to offer.  But a lot of very intelligent folks have discussed
this matter for a long time, and this is what they came up with.  I'd be
delighted if we did not need process around this, and these matters could
somehow "just work out".  But the consensus is that this just is not the
case, at least not today.  

If you feel you have a viable alternative, that would prevent namespace
collision, encourage development of interoperable standards, and provide
sensible management of this highly visible namespace -- I'm all ears.  

Ian King <iking <at> microsoft.com>
Speech Product Group/Intelligent Interface Technologies
MICROSOFT CORPORATION

-----Original Message-----
From: Masataka Ohta [mailto:mohta <at> necom830.hpcl.titech.ac.jp]
Sent: Sunday, September 12, 1999 2:26 AM
To: moore <at> cs.utk.edu
Cc: mohta <at> necom830.hpcl.titech.ac.jp; moore <at> cs.utk.edu; Ian King;
ietf-url <at> imc.org; urn-ietf <at> lists.internic.net; paf <at> swip.net;
RPetke <at> wcom.net
Subject: Re: Proposed amendment to language of draft-ietf-url-procedures

Keith;

> > Are you saying that IETF is infallible and has never published
> > any bad ideas of its own?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian King | 10 Sep 1999 23:30
Picon
Favicon

RE: Proposed amendment to language of draft-ietf-url-procedures

Keith, 

My concern about that is demonstrated by the example of about: (pun not
intended), which was implemented in different ways by Netscape and
Microsoft.  While I agree that it is not a good thing to have two
non-interoperable implementations of the same scheme, it IS a good thing to
document what exists.  As discussed elsewhere, cautionary language should be
required in such a document ("the IETF does not endorse this usage").  

I do agree that the IESG should have discretion to reject submissions that
have nothing to do with the Internet, although I would offer a
counterexample: the aol: scheme, for reasons that have been previously
discussed.  Nonetheless, I agree that IESG should have broad discretion in
limiting URL scheme registrations supported by Informational RFCs.  Perhaps
the following rewrite of my proposed language meets that:
---------------
Registration in the IETF tree requires publication of the URL scheme syntax
and semantics in either an Informational or Standards Track RFC. In general,
the creation of a new URL scheme requires a Standards Track RFC.  An
Informational RFC may be employed for registration only in the case of a URL
scheme which is already in wide usage and meets other standards set forth in
[RFC-GUIDELINES], such as "demonstrated utility" within the Internet
Architecture; the IESG shall have broad discretion in determining whether an
Informational RFC is suitable in any given case, and may either recommend
changes to such document prior to publication, or reject it for publication.
An Informational RFC purporting to describe a URL scheme shall not be
published without IESG approval.  This is a departure from practice for
Informational RFCs as set forth in RFC 2026, for the purpose of ensuring
that the registration of URL schemes shall serve the best interests of the
Internet community.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian King | 10 Sep 1999 20:43
Picon
Favicon

Proposed amendment to language of draft-ietf-url-procedures

Folks, 

In the recent discussion about a certain URL scheme, it became apparent that
we had left a hole in our document (draft-ietf-url-procedures-07.txt)
regarding Informational RFCs and URL scheme registrations.  From my notes,
we had agreed to include Informational as an allowed form of document for
submission, because it would be a less burdensome route for the "owner" of
an existing scheme to register, to the benefit of all.  However, that
purpose (and the restriction it implies) did not get translated into
language in the draft.  

Having exchanged email with several people on this, it appears we need to
amend the first paragraph of section 3.2 to read something like:

	Registration in the IETF tree requires publication of the URL scheme
syntax and semantics in either an Informational or Standards Track RFC. An
Informational RFC may be employed for registration only in the case of a URL
scheme which is already in wide usage; the creation of a new URL scheme
requires a Standards Track RFC.  The IESG shall determine whether a URL
scheme submitted by Informational RFC meets the "wide usage" standard.  As a
suggestion, a URL scheme may be considered to be in "wide usage" if there
exist multiple interoperable implementations that support the scheme, or if
the scheme can be shown to be in common use on the Internet.  Regardless, an
Informational RFC purporting to describe a URL scheme shall not be published
without IESG approval.  

I believe this to be the LAST (phew) such change we need to make to gain
acceptance for this document.  We were also "on hold" pending a re-review by
the Security ADs (which was the change incorporated in version -07 of this
draft), last I heard from our Area Director.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dan Connolly | 10 Sep 1999 19:09
Picon
Favicon

DAV: and opaquelocktoken: missing from URI scheme registry

IANA,

In the course of maintaining an informal list of URI schemes[1]
I noticed that the URI Scheme registry[2] is missing entries for
DAV: and opaquelocktoken: per [WEBDAV]. Please fix.

Also... the title of [2] should be
	"Uniform Resource Identifier (URI) Schemes"
no?

  "... . It excludes those
   portions of RFC 1738 that defined the specific syntax of individual
   URL schemes; those portions will be updated as separate documents, as
   will the process for registration of new URI schemes."
	-- http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt

[1] http://www.w3.org/Addressing/schemes

[2] Uniform Resource Locators (URL) Schemes
ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes
Last Modified: Thursday, 18 February, 1999 3:58:12 PM GMT

[WEBDAV] http://www.ietf.org/rfc/rfc2518.txt
"   This specification also defines a URI scheme for the encoding of
lock
   tokens, the opaquelocktoken URI scheme described in section 6.4.

   To ensure correct interoperation based on this specification, IANA
   must reserve the URI namespaces starting with "DAV:" and with
   "opaquelocktoken:" for use by this specification, its revisions, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Masinter | 25 Aug 1999 19:43
Picon
Favicon

IETF tree URL registration procedure incomplete

(Conversation redirected to URLREG):

The recent discussion on the 'ietf <at> ietf.org' list about the 'tv' URL
makes me believe that the process described in 
draft-ietf-urlreg-procedures-07.txt for IETF tree documents isn't
adequate to insure proper review of new top level URI schemes, and also
that it assumes more editorial control by IESG of Informational
RFCs than is currently documented by RFC 2026.

As Scott Bradner wrote on the ietf list:

> in the 30 years that the RFC series has run it has always been the case
> that an independent person could get an RFC published if the RFC Editor
> frlt it was a contribution to the Internet community - I think we
> have to think very hard if we want to change this.

In the particular case of "URL schemes", the URI working group
in 1994 and the URLREG group in its many years of existance have
relied on the ability of the IESG (and not merely the RFC editor)
to exert some judgement over URL registrations contained in Informational
RFCs.

In some ways, URL schemes bear some resemblance to top level domains
in their role as a root of a naming authority and in the desire of
some organizations to 'own' the 'short name'; the uproar over a private
use of 'tv' without apparent consensus of the TV community would not be
there if the name of the URL scheme were 'directtv-tune:', as 
draft-ietf-urlreg-procedures-07.txt might propose.

The URL registration procedure document has languished for a while;
(Continue reading)

Permalink | Reply | 14 comments |
headers
Amit Kapoor | 25 Aug 1999 00:10
Picon

Signed/Encrypted Mail URL


	While fiddling around with S/MIME and
	mailto:, it struck me that it would be
	nice to allow browsers to invoke the
	mail client to generate a signed and/or
	encrypted mail message (with appropriate
	warnings to the user).  This would be
	very useful for bill payment and delivery
	and do not force the browsers to create
	a SSL connection with the server.

	I thought of extending mailto: to do the
	same, and have already received objections
	on that..:).  I guess we can always create
	a new url for the same..

	Anyway, this message is to find out if
	anyone else is interested in this and
	what would be the best way to solve it.

	cheers-

Amit
Permalink | Reply | 3 comments |
headers
Internet-Drafts | 13 Aug 1999 13:01
Picon
Favicon

I-D ACTION:draft-ietf-urlreg-procedures-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Locator Registration Procedures Working Group of the IETF.

	Title		: Registration Procedures for URL Scheme Names
	Author(s)	: R. Petke, I. King
	Filename	: draft-ietf-urlreg-procedures-07.txt
	Pages		: 6
	Date		: 12-Aug-99
	
This document defines the process by which new URL scheme names are
registered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urlreg-procedures-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urlreg-procedures-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-urlreg-procedures-07.txt".
(Continue reading)

Permalink | Reply | 0 comments |

Gmane