Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme

Barry Leiba <barryleiba@computer.org> Sat, 03 December 2011 14:28 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7012121F8531 for <apps-discuss@ietfa.amsl.com>; Sat, 3 Dec 2011 06:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.965
X-Spam-Level:
X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMkEfN50IzGk for <apps-discuss@ietfa.amsl.com>; Sat, 3 Dec 2011 06:28:44 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB7121F8514 for <apps-discuss@ietf.org>; Sat, 3 Dec 2011 06:28:44 -0800 (PST)
Received: by ywm13 with SMTP id 13so4139832ywm.31 for <apps-discuss@ietf.org>; Sat, 03 Dec 2011 06:28:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pYSxf0YgAaARPi36dOA3pEg/PTaEUOjFbzzX1KzwTA0=; b=XeRUwL5JNlekeLkbBgCuGh27Le8UhZ+XNHYGrO1/du/Eloc2zUS0YAHvoQHk8aeZe0 wmdIDAB9JR5lNwtN+xNnYjb+2IsqEKncpLz6d5++f6ERzFgEzTyjtHHG1jqF9xDrIs8I ZnkZltauOB+IQrDg1HzRwaT2nUUORWUdOHNlU=
MIME-Version: 1.0
Received: by 10.236.154.193 with SMTP id h41mr3003193yhk.15.1322922523058; Sat, 03 Dec 2011 06:28:43 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.236.110.49 with HTTP; Sat, 3 Dec 2011 06:28:42 -0800 (PST)
In-Reply-To: <4ED9B441.2020507@gmail.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <CAC4RtVB4Y2ozbBs=n1hwCMdvv-YinhLiGFGgwt4R=a7-8iyYmA@mail.gmail.com> <4ED9B441.2020507@gmail.com>
Date: Sat, 3 Dec 2011 09:28:42 -0500
X-Google-Sender-Auth: 3_3NyaMBorCiBy6zTpL90CIIElQ
Message-ID: <CALaySJLK3Qeoisair-C=TpT=RDh05WVroF5GCZ9w+jBiiQKqTA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: =?UTF-8?B?TXlreXRhIFlldnN0aWZleWV2ICjQnC4g0ITQstGB0YLRltGE0LXRlNCyKQ==?= <evnikita2@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps-discuss list <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 03 Dec 2011 14:28:45 -0000

I think there are only two minor things left to respond to here:

>> I don't think it's appropriate to specify the general IETF
>> discussion list as the contact point (Author/Change controller).
>> Put something "real" in there.
>
> For example?

Fair question.  The problem is that we usually use either the document
author/editor or the working group mailing list, and in this case the
former isn't appropriate, and I'm not sure about the latter.  Hm....

I suggest that we either use <apps-discuss@ietf.org> or
<uri-review@ietf.org>rg>, and I'm not sure which one is right.  Perhaps
others on apps-discuss, or perhaps the ADs, will comment.

>> NEW
>>   The registration procedures for this registry are "First Come First
>>   Served', described in RFC 5226 [RFC5226], with supporting
>>   documentation meeting the requirements below.  The registrant
>>   of the token MUST provide the following registration template,
>>   which will be made available on IANA web site:
>> ...
>>     Specification.  REQUIRED field.  This provides documentation
>>     at a level that could be used to create a compliant, interoperable
>>     implementation of the registered "about" URI.  The full
>>     specification SHOULD be included here, but it MAY be a
>>     reference to a document published elsewhere, if there is a
>>     reasonable expectation that the documentation will remain
>>     available.  IANA will consult with the IESG or its specified
>>     delegate if there is doubt about whether the specification is
>>     adequate for the purpose.
>>
>> This provides for a sort of "expert review" only to determine whether
>> the documentation is suitable, and does not have an expert at the gate
>> to block registrations.  I think this is a perfect example of a
>> registry where we'd rather have things registered and documented than
>> not, so encouraging that with minimal hassle and minimal risk for
>> rejection is best.
>
> I agree with such wording.  What I added is:
>
>>   o Specification.  This provides documentation at a level that could
>>     be used to create a compliant, interoperable implementation of the
>>     registered "about" URI.  The reference to a full specification MUST
>>     be provided here, and there should be a reasonable expectation that
>>     the documentation will remain available.  IANA will consult with
>>     the IESG or its specified delegate if there is doubt about whether
>>     the specification is adequate for the purpose.

I'm mostly fine with that.  In my suggested text, I put REQUIRED for
the field, and MAY for the separate documentation, because there will
likely be cases where the only specification needed is a couple of
sentences that can just be included here directly.  With "The
reference to a full specification MUST be provided here," we're
requiring that there always be a separate "full" specification, and I
think that'll just be excessive in many cases.

Note that when I said, "The full specification SHOULD be included
here," what I meant was that the full text of the specification SHOULD
be included right here in the field, rather than in a separate
document, but then added that there MAY be a separate document.  My
intent might not have been clear.

Do others have comments on this?

Barry