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

"Mykyta Yevstifeyev (М. Євстіфеєв)" <evnikita2@gmail.com> Sun, 04 December 2011 09:47 UTC

Return-Path: <evnikita2@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 9514E21F8801 for <apps-discuss@ietfa.amsl.com>; Sun, 4 Dec 2011 01:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.913
X-Spam-Level:
X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 G1diOrk5TPSM for <apps-discuss@ietfa.amsl.com>; Sun, 4 Dec 2011 01:47:29 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 831A821F87D9 for <apps-discuss@ietf.org>; Sun, 4 Dec 2011 01:47:28 -0800 (PST)
Received: by bkas6 with SMTP id s6so191257bka.31 for <apps-discuss@ietf.org>; Sun, 04 Dec 2011 01:47:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nVXKrC+x4bQOGGuyUbw7QA/K6mK6OG4PyxDf254Y52E=; b=E6cfgmpfd4YfSX5cIzmAKTYdUPiJHamNvFuCtZxRE3TvCvebuY6aNMwEseeS9UqeXr R3VX62KVywtO4PdG1r90r41U6dtVhW994fH8CMmfqR7xkU3ozT8E3Lg621Cg4JTxthXn VURkqPM5z1iJnJ+aNXS5isrcrQyUipjBi6RQI=
Received: by 10.205.121.20 with SMTP id ga20mr2440756bkc.94.1322992047434; Sun, 04 Dec 2011 01:47:27 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l5sm24873903bkv.9.2011.12.04.01.47.24 (version=SSLv3 cipher=OTHER); Sun, 04 Dec 2011 01:47:25 -0800 (PST)
Message-ID: <4EDB41E5.7080604@gmail.com>
Date: Sun, 04 Dec 2011 11:48:21 +0200
From: =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZTQsg==?= =?UTF-8?B?KSI=?= <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
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> <CALaySJLK3Qeoisair-C=TpT=RDh05WVroF5GCZ9w+jBiiQKqTA@mail.gmail.com>
In-Reply-To: <CALaySJLK3Qeoisair-C=TpT=RDh05WVroF5GCZ9w+jBiiQKqTA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Sun, 04 Dec 2011 09:47:29 -0000

03.12.2011 16:28, Barry Leiba wrote:
> 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.

I think we should choose APPSAWG as Author/Change controller and 
correspondingly supply apps-discuss list as contact point, as long as 
this doc is produced in APPSAWG and there are no plans to close it in 
the nearest future.

>
>>> 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.

This is intentional, in order to make somebody who wants to register the 
token think whether such registration will really be useful.  I don't 
think somebody wanting to register about:his-surname will undertake 
writing a spec; but some standards body will, and this will be a 
warranty of a registered token being really useful (in theory, of 
course).  That's why I was advocating Specification Required policy, and 
still hold such view.

Mykyta Yevstifeyev

>
> Do others have comments on this?
>
> Barry
>