Subject: Re: [Uri-review] [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-histori-00)

From: Alfred Hönes <[email-masked]>
Date: Sun, 21 Nov 2010 18:11:24 +0100 (MEZ)

At Fri, 19 Nov 2010 14:25:38 -0500, John C Klensin wrote:

> ...
>
> (2) We instruct IANA to separate the "Provisional" category of
> the URI Scheme registry into two categories:
>
>       * Provisional (defined more or less as work in progress)
>         and
>       * Reserved keyword
>
> and move any of the now-provisional keywords for which there are
> adequate protocol specs but no adequate URI spec (existing or in
> active progress) into it.  ...

Good idea.   Hence: +1 !

>                       ...  I note that RFC 1738 describes the
> keywords it lists as "proposed at various times" with
> "...suggested that IANA reserve...", not "Provisional".  After a
> quick search, I haven't been able to discover any instructions
> to IANA to identify them as Provisional.  Unless such
> instructions exist, one could sensibly interpret the separation
> suggested here as correcting an error.

True.

> It seems to me that, until and unless the IETF takes a strong
> position against the "all application protocols can reasonably
> be associated with a URI" model, having a facility to reserve
> application-associated keywords for applications that are
> well-defined and URI schemes that might be developed in the
> future would promote interoperability by providing a warning
> that the keyword should not be generally used until (and unless)
> a spec is produced.
>
> If we took that approach, we could safely put both tn3270 and
> afs into "Reserved" if only because it is not clear to me that
> making a more careful decision about the latter would be worth
> the effort it would take.   We could similarly move anything
> else in the Provisional list that is associated with an expired
> I-D to Reserved.

Agreed.

> If there is sympathy for this approach and an I-D is needed to
> establish rules for adding new entries to the "Reserved"
> category, I guess I'm willing to quickly turn out a first draft.
> That draft could also formally create the category if needed
> but, as noted above, I think its absence is an error on IANA's
> part.
>
>     john

If the latter assumption holds (and the lack of explicit instructions
in RFC 4395 seems to indicate that), couldn't we do that in a more
lightweight manner?

I propose that the IANA Considerations section of Alexey's draft be
amended by a short statement that causes IANA to do the above during
the publication process of the 'mailserver to Historic" draft.

Stawman proposal (please feel free to improve):

   IANA is asked to revert the state of the entries in the URI scheme
   registry that originally have only been "reserved for use in future
   specification" and for which no registration document has been
   submitted ever that would qualify these entries for their current
   state (as defined in RFC 4395) back to their state prior to the
   publication of RFC 4395.  The related changes performed those days
   are deemed as not intended by RFC 4395 and hence inadvertant.

   Therefore, IANA is asked to create a new subheading and move two
   entries from the "provisional" category into this new category:

        Reserved URI Scheme Names
        -------------------------

        afs                                         [RFC1738]
        tn3270                                      [RFC1738]

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+