Subject: [xmpp] PROTO review of draft-ietf-xmpp-posh

From: "Ben Campbell" <[email-masked]>
Date: Fri, 20 Feb 2015 18:30:37 -0600

Hi Peter and Matt,

I’m in the process of doing a PROTO writeup for POSH, and have one 
possibly material comment, and a few minor comments. Apologies for not 
turning these up during WLGC, and also if these rehash stuff we’ve 
already closed on. (The chairs should yell at me.)

— Material Comment: IANA Considerations

These seems a bit unusual, since we are registering a “fragment” 
that other protocols will use to register actual URIs.  This does not 
seem to have been contemplated by RFC5785. This also the side effect of 
establishing rules for certain entries in the well-known URI registry 
over and above those from RFC5785.

Does it make sense to actually register the prefix itself, since it’s 
not really a URI? It would seem reasonable to leave the actual 
registration to protocols that need to register posh URIs.

I see Mark Nottingham is the expert for the well-known URI registry. By 
any chance has anyone run this by him?

Editorial Comments:

— section 3, numbered steps:

Which server is the POSH server? Is that the hosting server, or the web 
server that serves the well-known URI? I can infer the answer, but it 
would be good to be explicit.

— section 3.2, 3rd paragraph from end: (starting with “Note: The 
JSON document…”)

There’s 2119 language in a “Note”. I tend to read indented notes 
as parenthetical. If it needs 2119 language it should probably be part 
of the mainstream text.

— Security Considerations:

“To protect against circular
    references, clients MUST NOT follow an infinite number of 
redirects.”

That’s a bit of a <ducking> circular reference. Or at least a 
tautology. Perhaps it could be non-normative, or reformulated as 
something to the effect of “… MUST limit the number of 
redirects…”

—References:

IDNits reports a few out-of-date references.

Thanks!

Ben.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Feb 2015 14:58:05 -0700

Hi Ben, thanks for the review.

On 2/20/15 5:30 PM, Ben Campbell wrote:
> These seems a bit unusual, since we are registering a “fragment” that
> other protocols will use to register actual URIs.  This does not seem to
> have been contemplated by RFC5785. This also the side effect of

You make a very good point. I think you're right that it makes more 
sense for the POSH spec to provide instructions to protocols that need 
to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - but 
not to register a URI prefix (instead, just say "please use the prefix").

> any chance has anyone run this by him?

I have a vague recollection of having talked with him about it once, but 
I can find no evidence of that in my email folders. If we agree that 
what you suggest is the best approach, then I think it makes sense to 
update the document before reaching out to him (and in fact that might 
not be necessary since this document wouldn't be doing anything unusual).

> would be good to be explicit.

It is the server hosting the application service. I agree that this 
could be clearer in the text. The web server is called the "Source 
Domain HTTPS server" here (which is rather a mouthful).

> — section 3.2, 3rd paragraph from end: (starting with “Note: The JSON
> document…”)
>
> There’s 2119 language in a “Note”. I tend to read indented notes as
> parenthetical. If it needs 2119 language it should probably be part of
> the mainstream text.

Yeah, taking that out of a note seems best.

>     references, clients MUST NOT follow an infinite number of redirects.”
>
> That’s a bit of a <ducking> circular reference. Or at least a tautology.
> Perhaps it could be non-normative, or reformulated as something to the
> effect of “… MUST limit the number of redirects…”

Right, "less than infinite" isn't all that helpful. :-)

Going straight to the source, I find that RFC 7231 says:

    A client SHOULD detect and intervene in cyclical redirections (i.e.,
    "infinite" redirection loops).

       Note: An earlier version of this specification recommended a
       maximum of five redirections ([RFC2068], Section 10.3).  Content
       developers need to be aware that some clients might implement such
       a fixed limitation.

If it's good enough for HTTPBIS perhaps it's good enough for us, but 
even RFC 7231 only makes it a SHOULD (which I find slightly surprising).

> IDNits reports a few out-of-date references.

The authors will update our I-D caches.

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 Feb 2015 16:10:12 -0600

Hi Peter, further comments below. I removed sections that do not seem to 
need further discussion.

On 23 Feb 2015, at 15:58, Peter Saint-Andre - &yet wrote:

[...]

>> that
> to register POSH URIs - as, for instance, draft-ietf-xmpp-dna does - 
> but not to register a URI prefix (instead, just say "please use the 
> prefix").

So if I understand the implications of this path, it would mean we give 
guidance that any protocol that uses posh should register a “posh.*” 
URL. (I note that the well-known URI registry uses the specification 
required policy. Is that adequate for POSH use?). But this doc would not 
register anything. Would that guidance still go in the IANA 
considerations section? I suspect the answer is probably not.

Also, does anything implode if some protocol chooses not to use the POSH 
prefix? Do we actually care? I assume we don’t expect developers to 
try to guess well-known URIs.
> I have a vague recollection of having talked with him about it once, 
> but I can find no evidence of that in my email folders. If we agree 
> that what you suggest is the best approach, then I think it makes 
> sense to update the document before reaching out to him (and in fact 
> that might not be necessary since this document wouldn't be doing 
> anything unusual).

I agree that if we don’t register anything, and don’t try to change 
the well-known URI registration policy for posh purposes, it might not 
be necessary to involve Mark. (But for the record, if he were okay with 
the way things are currently documented, I would back off on this 
point.)

[...]

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 23 Feb 2015 15:19:45 -0700

On 2/23/15 3:10 PM, Ben Campbell wrote:
> Hi Peter, further comments below. I removed sections that do not
> seem to need further discussion.
> 
>>> These seems a bit unusual, since we are registering a
>>> “fragment” that other protocols will use to register actual
>>> URIs.  This does not seem to have been contemplated by RFC5785.
>>> This also the side effect of establishing rules for certain
>>> entries in the well-known URI registry over and above those
>>> from RFC5785.
>>> 
>>> Does it make sense to actually register the prefix itself,
>>> since it’s not really a URI? It would seem reasonable to leave
>>> the actual registration to protocols that need to register posh
>>> URIs.
>> 
>> You make a very good point. I think you're right that it makes
>> more sense for the POSH spec to provide instructions to protocols
>> that need to register POSH URIs - as, for instance,
>> draft-ietf-xmpp-dna does - but not to register a URI prefix
>> (instead, just say "please use the prefix").
> 
> So if I understand the implications of this path, it would mean we
> give guidance that any protocol that uses posh should register a
> “posh.*” URL. (I note that the well-known URI registry uses the
> specification required policy. Is that adequate for POSH use?). But
> this doc would not register anything. Would that guidance still go
> in the IANA considerations section? I suspect the answer is
> probably not.
> 
> Also, does anything implode if some protocol chooses not to use the
> POSH prefix? Do we actually care? I assume we don’t expect
> developers to try to guess well-known URIs.
>> 
>>> I see Mark Nottingham is the expert for the well-known URI
>>> registry. By any chance has anyone run this by him?
>> 
>> I have a vague recollection of having talked with him about it
>> once, but I can find no evidence of that in my email folders. If
>> we agree that what you suggest is the best approach, then I think
>> it makes sense to update the document before reaching out to him
>> (and in fact that might not be necessary since this document
>> wouldn't be doing anything unusual).
> 
> the well-known URI registration policy for posh purposes, it might
> not be necessary to involve Mark. (But for the record, if he were
> okay with the way things are currently documented, I would back off
> on this point.)
> 

I also recall discussing it with Mark, but I can't find any
documentation to back that up either.  As I recall, the intent was to
constrain the crazy stuff future people might do in the .well-known
namespace.

I'd rather change this to guidance on how to register an app-specific
POSH URI, than try to do something new-ish with the existing IANA
tables.  The authors will discuss it and come up with a proposed change.

- -- 
- - m&m

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Feb 2015 15:31:56 -0700

On 2/23/15 3:10 PM, Ben Campbell wrote:
> URL.

Yes but that's really just for a friendly consistency.

Matt and I chatted about it over IM and we both recalled that we were 
trying to prevent crazy registrations in .well-known (this was around 
the time that Mark Nottingham was starting to work on the evocatively 
named draft-nottingham-uri-get-off-my-lawn, now RFC 7320).

> (I note that the well-known URI registry uses the specification
> required policy. Is that adequate for POSH use?).

I think so. Over time we've tried to become more liberal about IANA 
registrations policies.

> But this doc would not
> register anything.

Correct.

> Would that guidance still go in the IANA

It would go in another section since we wouldn't be registering 
anything, nor would we be providing actionable guidance to IANA.

> prefix?

No imminent implosions to worry about.

> Do we actually care?

Not much, although as I said it provides a friendly consistency.

> I assume we don’t expect developers to try
> to guess well-known URIs.

That's true.

> I agree that if we don’t register anything, and don’t try to change the
> well-known URI registration policy for posh purposes, it might not be
> necessary to involve Mark. (But for the record, if he were okay with the
> way things are currently documented, I would back off on this point.)

Well, I think the way things are currently documented is misguided, so 
we might as well correct it.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Feb 2015 15:53:07 -0700

> we might as well correct it.

Here is proposed text:

###

8.  Guidelines for Protocols that Use POSH

    Protocols that use POSH will need to register well-known URIs wth the
    IANA in accordance with [RFC5785] (the IANA registration policy
    [RFC5226] for well-known URIs is Specification Required).

    For the sake of consistency, it would be best if the URIs registered
    by such protocols match the URI template [RFC6570] path "/.well-known
    /posh.{servicedesc}.json"; that is, begin with "posh." and end with
    ".json" (indicating a media type of application/json [RFC7159]).

    For POSH-using protocols that rely on DNS SRV records [RFC2782], it
    would be best if the "{servicedesc}" part of the well-known URI is
    "{service}.{proto}", where the "{service}" is the DNS SRV "Service"
    prepended by the underscore character "_" and the "{proto}" is the
    DNS SRV "Proto" also prepended by the underscore character "_".  As
    an example, the well-known URI for XMPP server-to-server connections
    would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
    a service name of "xmpp-server" and uses TCP as the underlying
    transport protocol.

    For other POSH-using protocols, the "{servicedesc}" part of the well-
    known URI can be any unique string or identifier for the protocol,
    which might be a service name registered with the IANA in accordance
    with [RFC6335] or which might be an unregistered name.  As an
    example, the well-known URI for a hypothetical "SPICE" application
    could be "posh.spice.json".

###

Peter

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 Feb 2015 17:02:09 -0600

>  could be "posh.spice.json".

That works for me. I would also not complain if the “it would be 
best” lines were replaced with SHOULDs [1], but I’m also okay like 
it is.

[1] based on the 2119 usage of normative text to avoid harm, even if 
it’s not needed for interoperability, said harm being the pollution of 
the well-known URI registry with “craziness.”