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

From: Ian King <[email-masked]>
Date: Fri, 10 Sep 1999 11:43:01 -0700

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.  

Please get back to me with any feedback you have as soon as possible, so we
can get final approval for these important documents we have created.
Thanks -- Ian 

Madness takes its toll -- please have exact change.  
Ian King | Speech Product Group | Microsoft Corporation

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Sep 1999 15:01:01 -0400

Ian,

I'd actually push back a bit on the "wide usage" test, because I don't
believe that IETF should commit itself to publish bad ideas even if they
are in wide use.  The most we should commit ourselves to doing, IMHO, is
to avoid defining alternate meanings for URL prefixes in wide use, if
our doing so would cause interoperability problems.

So I would prefer that IESG be given more latitude to reject a URL
prefix registration than to say "it's not widely used".

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Sep 1999 15:05:10 -0400

> our doing so would cause interoperability problems.

(I should have added '...for our own protocols.') 

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Sep 99 10:32:28 JST

Keith;

> because I don't
> are in wide use.

Are you saying that IETF is infallible and has never published
any bad ideas of its own?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Sep 99 10:26:37 JST

Ian;

> In the recent discussion about a certain URL scheme, it became apparent that

attempt to restrict registration is proven to be silly.

> we had left a hole in our document (draft-ietf-url-procedures-07.txt)

So, abandon it and just let everyone freely register their favourite
URL names.

With such policy, the Internet has been working fine. Everyone can get
TCP/UDP port assigned with his favourite protocol name.

> can get final approval for these important documents we have created.

Which documents, do you think, important?

							Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 Sep 1999 02:55:35 -0400

> any bad ideas of its own?

of course not.  but just because IETF can make its own mistakes, 
doesn't mean it should lend its credibility to others' mistakes.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 12 Sep 99 18:26:14 JST

Keith;

> doesn't mean it should lend its credibility to others' mistakes.

OK. So, it's better if IETF is involved in less technical judgements.

No informational nor standard track RFCs should be required for
mere URL names.

					‘¾“c�@�¹�F
					[email-masked]