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

["Mykyta Yevstifeyev (М. Євстіфеєв)" <[e-mail]>]

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<[e-mail]>  or
> <[e-mail]>, 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
>