[apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-historic-00.txt)
John C Klensin <john-ietf@jck.com> Fri, 19 November 2010 19:25 UTC
Return-Path: <john-ietf@jck.com>
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 13B193A6863; Fri, 19 Nov 2010 11:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 id0AzPvbm1HX; Fri, 19 Nov 2010 11:24:54 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4DECF3A67FF; Fri, 19 Nov 2010 11:24:50 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PJWaZ-000BIg-Jh; Fri, 19 Nov 2010 14:25:39 -0500
Date: Fri, 19 Nov 2010 14:25:38 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <A232FF7C06EE5B1C0F886130@PST.JCK.COM>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-historic-00.txt)
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: Fri, 19 Nov 2010 19:25:02 -0000
Alexey, It seems to me that the TN3270 discussion has started to conflate two separate issues and that we might derive something useful from that discussion: (1) Whether the URI scheme is properly specified and in use (2) Whether the underlying applications protocol is well-specified, in use, and still useful. For TN3270, the answer to "properly specified" is clearly "no" because, as several people have pointed out, there really is no spec, just a reservation. It may still be in use, and several people have made credible suggestions that is actually the case. Certainly the answer to (2) is "yes". Having a tn3270 URI in use without a spec is actually troubling because there is no way to tell whether all uses of the keyword are consistent. However, deprecating the keyword or dropping it from the registry is not a solution to that problem. Either getting a spec or warning people off would be a superior approach. That situation is very different from the "mailserver" case, where there really isn't an underlying application protocol in active use, at least as far as I know. Perhaps that difference is a useful differentiating factor. For some years, we had the implicit assumption that every application protocol deserved a URI. I've personally always felt that was a bad assumption because of mismatches between the operational model of some protocols and the URI model, but I lost that argument. Looking at the situation from the perspective of today's environment, I suggest that: (1) We move URI schemes to Historic only if we are justified and willing to move the underlying applications protocol specifications to Historic -or- if no such protocol spec exists and there is no reasonable prospect of getting one. I note that, using that criterion, "mailserver" would go to Historic and "tn3270" would not. I haven't done enough research to have an opinion about "afs", but see below. (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. 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. 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. 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
- [apps-discuss] Provisional URI registrations (was… John C Klensin
- Re: [apps-discuss] Provisional URI registrations Graham Klyne
- Re: [apps-discuss] Provisional URI registrations Martin J. Dürst
- Re: [apps-discuss] Provisional URI registrations John C Klensin
- Re: [apps-discuss] Provisional URI registrations Martin J. Dürst
- Re: [apps-discuss] Provisional URI registrations Graham Klyne
- Re: [apps-discuss] [Uri-review] Provisional URI r… Mykyta Yevstifeyev
- Re: [apps-discuss] [Uri-review] Provisional URI r… Graham Klyne