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

[Barry Leiba <[e-mail]>]

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

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

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

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.

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

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

>    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