Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

[Peter Saint-Andre - &yet <[e-mail]>]

On 8/28/15 6:05 AM, Barry Leiba wrote:
>>> 1. Recommend URIs like https://example.com/.well-known/posh/spice.json
>>>
>>> 2. In draft-ietf-xmpp-posh, register "posh" in the well-known URIs
>>> registry
>>>
>>> 3. In draft-ietf-xmpp-posh, set up a registry for POSH protocols
>>>
>>> 4. In draft-ietf-xmpp-dna, register "xmpp-client" and "xmpp-server" in
>>> the POSH registry
>>>
>>> I offered to Matt that I can propose text for the IANA considerations
>>> sections since I've written such text before. I'll endeavor to draft
>>> something in the next few days.
>>
>> Here is proposed text for draft-ietf-xmpp-posh...
>
> Thanks, Peter; this looks good.  Two questions, inline.
>
>> 9.  IANA Considerations
>>
>> 9.1.  Well-Known URI
>>
>>     This specification registers "posh" in the Well-Known URI Registry as
>>     defined by [RFC5785].  The completed template follows.
>>
>>     URI suffix:  posh
>>
>>     Change controller:  IETF
>>
>>     Specification:  [[ this document ]]
>>
>>     Related information:  The suffix "posh" is expected to be followed by
>>        an additional path component consisting of a service name (say,
>>        "spice") and a file extension of ".json", resulting in a full path
>>        of, for instance, "/.well-known/posh/spice.json".  Registration of
>>        service names shall be requested by developers of the relevant
>>        application protocols.
>>
>> 9.2.  POSH Service Names
>>
>>     This document establishes a registry for POSH service names.
>
> It would help IANA if you suggested where to put the registry (in an
> existing group of registries, or in its own, new top-level group).

Ah, I thought that was up to the IANA. Given that POSH service names are 
used an additional path component in well-known URIs, placing this 
registry in the Uniform Resource Identifier (URI) Schemes registry would 
make sense.

>>     POSH service names are registered on the advice of one or more
>>     Designated Experts (appointed by the IESG or their delegate).  An
>>     IANA registration policy [RFC5226] of Expert Review was chosen
>>     instead of the more liberal First Come First Served to help ensure
>>     that POSH is used in appropriate ways within applications.
>
> Thanks for that explanation; it helps.
>
> 1. Are Peter Saint-Andre and Matt Miller willing and able to act as
> the designated experts?  If so, I'll put that in for IESG approval.

I can serve in that capacity.

> 2. Do you want expert review to also apply to IETF documents (such as
> xmpp-dna, which would then need expert review before final approval)?
> If not, you could use "Expert Review OR IETF Review", or "Expert
> Review OR Standards Action".

I think "Expert Review OR IETF Review" would be fine but I'm not sure 
what Matt thinks.

> 3. It would be good to have a short paragraph or a pointer to other
> text that gives some guidance of what "used in appropriate ways"
> means, so the DEs (should we eventually put in someone other than the
> authors) know what not to accept.

Matt and I will try to formulate some text. We had some more specific 
text but it wasn't quite right. The basic idea is that we don't want 
folks to be using POSH when other technologies are a better fit. The 
example we had was DNS SRV but that wasn't correct since the two are 
complementary.

>>     Registration requests are to be sent to the [e-mail] mailing
>>     list for review and comment, with an appropriate subject (e.g.,
>>     "Request for POSH service name: example").
>>
>>     Before a period of 14 days has passed, the Designated Expert(s) will
>>     either approve or deny the registration request, communicating this
>>     decision both to the review list and to IANA.  Denials should include
>>     an explanation and, if applicable, suggestions as to how to make the
>>     request successful.  Registration requests that are undetermined for
>>     a period longer than 21 days can be brought to the IESG's attention
>>     (using the [e-mail] mailing list) for resolution.
>>
>> 9.2.1.  Registration Template
>>
>>     Service name:  The name requested, relative to "/.well-known/posh/";
>>        e.g., a service name of "example" would result in a well-known URI
>>        such as "https://example.com/.well-known/posh/example.json".
>>
>>     Change controller:  For Standards-Track RFCs, state "IETF".  In all
>>        other cases, give the name of the responsible party.  Other
>>        details (e.g., postal address, e-mail address, home page URI) may
>>        also be included.
>
> Is there a reason not to make e-mail address mandatory?  IANA ought to
> have a recorded contact point.

True. I think that's better.

>>     Definition and usage:  A brief description that defines the service
>>        name and mentions where and how it is used (e.g., in the context
>>        of a particular application protocol).
>>
>>     Specification:  Optionally, reference to a document that specifies
>>        the service or application protocol that uses the service name,
>>        preferably including a URI that can be used to retrieve a copy of
>>        the document.  An indication of the relevant sections may also be
>>        included, but is not required.
>>
>> ###
>>
>> And we would need to make associated changes in draft-ietf-xmpp-dna, such
>> as...
>>
>> ###
>>
>> 9.  IANA Considerations
>>
>>     The POSH specification [I-D.ietf-xmpp-posh] establishes a registry
>>     for POSH service names to be used in well-known URIs [RFC5785].  This
>>     specification registers two such URIs for use in XMPP: "xmpp-client"
>>     and "xmpp-server".  The completed registration templates follow.
>>
>> 9.1.  POSH Service Name for xmpp-client Service
>>
>>     POSH service name: xmpp-client
>
> This should probably match the template in the other document, so
> either change this to "Service name" or change the template to "POSH
> service name".

Correct.

>>     Change controller: IETF
>>
>>     Definition and usage: Specifies the location of a POSH file
>>     containing verification material or a reference thereto that enables
>>     a client to verify the identity of a server for a client-to-server
>>     stream in XMPP
>>
>>     Specification: [[ this document ]]
>>
>> 9.2.  POSH Service Name for xmpp-server Service
>>
>>     POSH service name: xmpp-server
>>
>>     Change controller: IETF
>>
>>     Definition and usage: Specifies the location of a POSH file
>>     containing verification material or a reference thereto that enables
>>     a server to verify the identity of a peer server for a server-to-
>>     server stream in XMPP
>>
>>     Specification: [[ this document ]]
>>
>> ###
>>
>> Matt and I have checked this approach with a few implementers and potential
>> implementers; no one has objected yet, but if folks on the [e-mail]
>> list or elsewhere have significant concerns it would be great to hear from
>> you. :-)
>
> Barry

Thanks for the review!

Peter

-- 
Peter Saint-Andre
https://andyet.com/