Re: [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-histori-00)
Alfred Hönes <ah@TR-Sys.de> Sun, 21 November 2010 17:11 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681583A6A8B; Sun, 21 Nov 2010 09:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.397
X-Spam-Level:
X-Spam-Status: No, score=-98.397 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYxhC2qYhemM; Sun, 21 Nov 2010 09:11:06 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E8C6A3A6A94; Sun, 21 Nov 2010 09:11:03 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA262089486; Sun, 21 Nov 2010 18:11:26 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA19931; Sun, 21 Nov 2010 18:11:24 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201011211711.SAA19931@TR-Sys.de>
To: john-ietf@jck.com, alexey.melnikov@isode.com
Date: Sun, 21 Nov 2010 18:11:24 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-histori-00)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Nov 2010 17:11:08 -0000
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: ah@TR-Sys.de |
+------------------------+--------------------------------------------+
- Re: [apps-discuss] Provisional URI registrations … Alfred Hönes