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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 3 Aug 2015 17:31:15 -0600

Adding Mark to this thread, with pointers to get him up to speed...

On 7/31/15 7:50 PM, Barry Leiba wrote:
>>> If you like, it could even do POSH service names and POSH format
>>> names, and specify ".well-known/posh/<servicename>/<formatname>",
>>
>> Currently it's the <servicename> field that we're most interested in.
>
> Right... and that's what I'm suggesting an FCFS registry for.  You
> register "posh" in .well-known, and you create your own FCFS registry
> for service names, and if you don't care about the format as a
> separate thing, you just register "spice.json" (and so on) in your
> FCFS registry.  That way, Mark doesn't get involved in approving
> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to
> say about posh service names (or seedy ones, for that matter).
>
>> Perhaps it makes sense to talk about it again with Mark?
>
> Sounds like a plan.

Hi Mark,

During IESG review of draft-ietf-xmpp-posh, Barry raised a question 
about the .well-known registration, which you and Matt Miller and I 
talked about ages ago. Here are some relevant readings:

https://tools.ietf.org/html/draft-ietf-xmpp-posh-04#section-8

https://mailarchive.ietf.org/arch/msg/xmpp/Vcikwhh1Fln6Z7WfKlb0mCarFDw

https://mailarchive.ietf.org/arch/msg/xmpp/5bRV3Ob2ugDkL2E7XFrCL-eKLFE

https://mailarchive.ietf.org/arch/msg/xmpp/xw_-TOVxkQJWqquZe4UH2yDJKAg

Barry's proposed approach is more elegant. However, my feeling is that 
POSH is essentially a one-off workaround for use in XMPP until DNSSEC 
and DANE are more widely deployed. Although we've tried to design it in 
such a way that it *could* be used by other application protocols, I 
doubt that folks in those communities will use POSH unless Matt and I 
start actively promoting it (and even that is only a necessary 
condition, not a sufficent one). Because I don't think that we'll see 
additional .well-known registrations related to POSH, setting up a 
separate POSH registry to supplement a "posh" entry in the well-known 
URIs registry feels like overkill to me given the burden on IANA (I'm 
not a fan of one-entry registries).

That said, people have been wrong before about the popularity of 
technologies defined in RFCs and it's possible that POSH could become 
more popular, in which case I'd lean more strongly toward the approach 
that Barry has outlined.

As the designated expert for the well-known URIs registry, do you have 
any suggestions or preferences on how to proceed?

Thanks!

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 3 Aug 2015 21:17:19 -0600

Hi Mark, thanks for sharing your perspective. I'll give it more thought tomorrow. 

Peter

Sent from mobile, might be terse 

> On Aug 3, 2015, at 6:10 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Peter,
> 
> As I discussed with Barry, I don't have any strong guidance here; I agree that his approach is probably the way I'd go with if I designed it myself, but I agree it's highly dependent on the situation. With my DE hat on, I'm neutral on this. 
> 
> Cheers,
> 
> 
>> On 4 Aug 2015, at 9:31 am, Peter Saint-Andre - &yet <[email-masked]> wrote:
>> 
>> During IESG review of draft-ietf-xmpp-posh, Barry raised a question about the .well-known registration, which you and Matt Miller and I talked about ages ago. Here are some relevant readings:
>> 
>> Barry's proposed approach is more elegant. However, my feeling is that POSH is essentially a one-off workaround for use in XMPP until DNSSEC and DANE are more widely deployed. Although we've tried to design it in such a way that it *could* be used by other application protocols, I doubt that folks in those communities will use POSH unless Matt and I start actively promoting it (and even that is only a necessary condition, not a sufficent one). Because I don't think that we'll see additional .well-known registrations related to POSH, setting up a separate POSH registry to supplement a "posh" entry in the well-known URIs registry feels like overkill to me given the burden on IANA (I'm not a fan of one-entry registries).
>> 
>> That said, people have been wrong before about the popularity of technologies defined in RFCs and it's possible that POSH could become more popular, in which case I'd lean more strongly toward the approach that Barry has outlined.
>> 
>> As the designated expert for the well-known URIs registry, do you have any suggestions or preferences on how to proceed?
>> 
>> Thanks!
>> 
>> Peter
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Aug 2015 10:10:46 +1000

Hi Peter,

Cheers,

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 11 Aug 2015 18:57:52 -0600

> say about posh service names (or seedy ones, for that matter).

I'm warming to this suggestion. Part of my hesitation was caused by the 
fact that I had misunderstood RFC 5785. I somehow had the impression 
that it discouraged path components beyond the registered name, but that 
impression was false:

    Typically, a registration will reference a specification that defines
    the format and associated media type to be obtained by dereferencing
    the well-known URI.

    It MAY also contain additional information, such as the syntax of
    additional path components, query strings and/or fragment identifiers
    to be appended to the well-known URI, or protocol-specific details
    (e.g., HTTP [RFC2616] method handling).

However, I haven't yet had an opportunity to discuss this in depth with 
my co-author. We'll be back in touch once we've talked about it and 
perhaps discussed it with implementers.

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 11 Aug 2015 18:28:40 -0700

> I'm warming to this suggestion.

:-)  Nice.

> However, I haven't yet had an opportunity to discuss this in depth with my
> co-author. We'll be back in touch once we've talked about it and perhaps
> discussed it with implementers.

Fair 'nough; thanks.

Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 11 Aug 2015 20:48:24 -0500

On 11 Aug 2015, at 19:57, Peter Saint-Andre - &yet wrote:

> I'm warming to this suggestion. Part of my hesitation was caused by 
> the fact that I had misunderstood RFC 5785. I somehow had the 
> impression that it discouraged path components beyond the registered 
> name, but that impression was false:
>
> However, I haven't yet had an opportunity to discuss this in depth 
> with my co-author. We'll be back in touch once we've talked about it 
> and perhaps discussed it with implementers.

For the record, I do not object to this change. I can even see the 
advantage. But let's keep in mind that there was working group consensus 
(such as it was) to do things as currently written. We can change that 
if there is good reason--but I want to make sure people think the reason 
is really good enough (with all due respect to Barry and Stephen).

If we do change it, we should probably consider an abbreviated WGLC on 
just this point. (Or perhaps the discussion with implementors would 
serve the same purpose.)

Thanks!

Ben.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 18 Aug 2015 16:25:28 -0600

> just this point. (Or perhaps the discussion with implementors would

Hi all,

A quick status update...

The authors have provisionally addressed all of the other issues from 
IESG review of draft-ietf-xmpp-posh and draft-ietf-xmpp-dna in our 
working copies. Matt and I are currently pinging implementers and we aim 
to finish gathering feedback from them by the end of this week. We'll 
report further once that is done.

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 24 Aug 2015 17:52:15 -0500

On 18 Aug 2015, at 17:25, Peter Saint-Andre - &yet wrote:

> working copies. Matt and I are currently pinging implementers and we 
> aim to finish gathering feedback from them by the end of this week. 
> We'll report further once that is done.

Hi,

Any updates?

Thanks!

Ben.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 24 Aug 2015 17:52:01 -0600

On 8/24/15 4:52 PM, Ben Campbell wrote:
>> The authors have provisionally addressed all of the other issues
>> from IESG review of draft-ietf-xmpp-posh and draft-ietf-xmpp-dna
>> in our working copies. Matt and I are currently pinging
>> implementers and we aim to finish gathering feedback from them by
>> the end of this week. We'll report further once that is done.
> 
> Hi,
> 
> Any updates?
> 
> Thanks!
> 
> Ben.

Peter and I have reached out to a number of implementers.  No one
we've talked to objects to changing the URI.  We still need to make
the appropriate changes to POSH and DNA; we are meeting later this
week to work out those details.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 24 Aug 2015 20:07:51 -0500

Thanks!

Ben.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 25 Aug 2015 20:29:46 -0600

>> week to work out those details.

Right, I think we need to do the following:

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.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 27 Aug 2015 21:51:16 -0700

> something in the next few days.

Here is proposed text for draft-ietf-xmpp-posh...

###

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.

    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.

    Registration requests are to be sent to the [email-masked] 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 [email-masked] 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.

    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

    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 
[email-masked] list or elsewhere have significant concerns it would be 
great to hear from you. :-)

Thanks!

Peter

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 09:05:09 -0400

> Here is proposed text for draft-ietf-xmpp-posh...

Thanks, Peter; this looks good.  Two questions, inline.

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

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

>       details (e.g., postal address, e-mail address, home page URI) may

Is there a reason not to make e-mail address mandatory?  IANA ought to
have a recorded contact point.

> And we would need to make associated changes in draft-ietf-xmpp-dna, such
> as...
>
> ###
>
> 9.  IANA Considerations
>

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

> Matt and I have checked this approach with a few implementers and potential
> implementers; no one has objected yet, but if folks on the [email-masked]
> list or elsewhere have significant concerns it would be great to hear from
> you. :-)

Barry

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 28 Aug 2015 06:49:04 -0700

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

> the designated experts?  If so, I'll put that in for IESG approval.

I can serve in that capacity.

> Review OR Standards Action".

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

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

> have a recorded contact point.

True. I think that's better.

> either change this to "Service name" or change the template to "POSH

Correct.

>> list or elsewhere have significant concerns it would be great to hear from

Thanks for the review!

Peter

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

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 28 Aug 2015 09:26:06 -0500

>> (using the [email-masked] mailing list) for resolution.

Do you expect to have a (perhaps rotating) panel of experts? I think if 
we have one or two designated (to IANA) experts, IANA will automatically 
do the right thing for any registration attempt, including bugging the 
ADs if the experts are non-responsive.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 10:59:59 -0400

> Do you expect to have a (perhaps rotating) panel of experts? I think if we
> have one or two designated (to IANA) experts, IANA will automatically do the
> right thing for any registration attempt, including bugging the ADs if the
> experts are non-responsive.

That's true, and it's not necessary to have time periods in there.  On
the other hand, putting in recommended times does seem to me to be
useful for setting expectations.

Maybe IANA can comment about whether they like such things, or prefer
not to be constrained by them.

Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 28 Aug 2015 10:16:26 -0500

> not to be constrained by them.

For what it's worth, the comment also applied to the prior paragraph (to 
the effect that registration requests should be sent to a designated 
mailing list.).

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 11:22:03 -0400

> For what it's worth, the comment also applied to the prior paragraph (to the
> effect that registration requests should be sent to a designated mailing
> list.).

That's been a common thing in many app-related registries, to allow
the community to participate in the process and comment.  It's been a
useful way for people making requests to get feedback, not just from
the DEs.

Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 28 Aug 2015 10:38:29 -0500

> useful way for people making requests to get feedback, not just from

I'm happy with that in principle, but do we expect _IANA_ to send to the 
mailing list vs directly to designated experts? Will that list be 
limited to approved designated experts? Is the list for people to get 
early advice on registrations before they go to IANA?

(I'm sure this has all been worked out for other app-related registries. 
I just don't know the answers.)

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Aug 2015 13:58:20 -0400

> mailing list vs directly to designated experts? Will that list be limited to
> approved designated experts? Is the list for people to get early advice on
> registrations before they go to IANA?

Ah, no: IANA does what IANA does, which is contacting the DE(s).  When
people have tried to say otherwise in their documents, I've pushed
them not to tell IANA how to run their process, and instead to give
advice to those making the requests.

For the mailing lists discussions, it's always the intent that
requestors are asked to post to the mailing list, and that DEs should
use any discussion on the mailing list to advise their review.

Barry