Re: [apps-discuss] Provisional URI registrations

Alfred Hönes <ah@TR-Sys.de> Mon, 22 November 2010 20:34 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 2DE4C3A6AFC; Mon, 22 Nov 2010 12:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.422
X-Spam-Level:
X-Spam-Status: No, score=-98.422 tagged_above=-999 required=5 tests=[AWL=0.327, 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 lNKnK6BdQImi; Mon, 22 Nov 2010 12:34:03 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 82F033A6AF9; Mon, 22 Nov 2010 12:34:01 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271188077; Mon, 22 Nov 2010 21:34:37 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA22485; Mon, 22 Nov 2010 21:34:33 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201011222034.VAA22485@TR-Sys.de>
To: gk@ninebynine.org, duerst@it.aoyama.ac.jp
Date: Mon, 22 Nov 2010 21:34:33 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
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: Mon, 22 Nov 2010 20:34:04 -0000

Graham Klyne wrote:

> Having made a very quick review of that discussion (w.r.t. tn3270),
> I feel there is a consensus that the appropriate response to to say
> "that's fine, it has a definition, let's leave it there".

Well, that's been one of the points where opinions seem to differ.
I could not find a definition, only RFC 1738 "reserving the name for
future definition".  The users of TN3270 service so far have claimed
there would be a definition, but nobody has shown it so far, and
some indications have been reported of different, non-interoperable
definitions as well.  I don't want to take a position on that now.


> There is no explicit provision for time-out of provisional
> registrations - the general idea (at least in the formulation
> of the header registry, from which I believe this registry was
> derived) was to provide a place where schemes could be documented
> for the community without having to meet the properly high standards
> of IETF consensus.

I would not have challenged "tn3270" as a provisional URI scheme
if there had been evidence that the procedures of RFC 4395 for such
scheme had been followed.


> One option in this case would be to move the tn3270 scheme to
> historic - I'm not sure if that's been suggested.

Exactly that was the starting point of the discussion.   :-)

I had suggested to add this status change to Alexey's draft that
aims at making 'mailserver' Historic, simply for the sake of
saving resources in drafting, draft approval, and RFC publication.
But i'm fine with defering that, doing that later, if still no spec
has be provided by that time.


> That's something I would support in this case.

Thanks.  I'll count on you when (and if) it turns sensical to retry.


John said:

>>   (2) Not having a Reserved category from the beginning appears to
>>   be an error on IANA's part, not something the IETF specified in
>>   any way.   If that is correct, it should be possible to deal
>>   with it as correcting an error, which is (or should be) an
>>   extremely lightweight procedure.

and you responded:

> Well, as Martin says, if it's an error it's not one on IANA's part.
> In this case, they follow what we (the IETF) asked of them.
> So I suppose we should be careful what we ask for :)

I disagree on the first two statements.

Actually, before the change of the URI Scheme registry triggered
by RFC 4395, 'afs', 'mailserver', and 'tn3270' had been listed
as "reserved".  I could not find instructions in RFC 4395 telling
IANA to convert these entries to "provisional" URI schemes,
and I observe that neither of these previously "reserved" keywords
would have qualified under the criteria for such registration in
RFC 4395.
So, since there apparently haven't been conversion rules; arguably,
something went wrong; achieving at consensus *now* that it likely
was a clerical error would allow us to perform a very lightweight
procedure to restore the 'status quo ante' (with three reserved
keywords), before Alexey's draft is published, or during that
process (but logically before 'mailserver' is made Historic).

Kind regards,
  Alfred.