Re: PROTO review of draft-ietf-xmpp-posh

Hi Ben, thanks for the review.

On 2/20/15 5:30 PM, Ben Campbell wrote:
> 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.

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

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

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

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.

> — 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…”

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

> —References:
>
> IDNits reports a few out-of-date references.

The authors will update our I-D caches.

Peter

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp