next steps on draft-ietf-xmpp-websocket

Dear Authors and WG,

This morning, at Richard's invitation and as the document shepherd for 
draft-ietf-xmpp-websocket, I briefly joined the IESG telechat to talk 
through the DISCUSS positions lodged by Stephen Farrell and Ted Lemon:

https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/

As a result, I'd like to ask the authors to complete several tasks (and 
I will be happy to propose or help with text for these items, since I 
was present during the IESG discussion):

1. More clearly describe the delegation scenario outlined in the second 
paragraph of Section 6:

    Browser based applications are not able to inspect and verify at the
    application layer the certificate used for the WebSocket connection
    to ensure that it corresponds to the domain specified as the "to"
    address of the XMPP stream.  For hosts whose domain matches the
    origin for the WebSocket connection, that check is already performed
    by the browser.  However, in situations where the domain of the XMPP
    server might not match the origin for the WebSocket endpoint
    (especially multi-tenant hosting situations), the web host metadata
    method (see [RFC6415] and [XEP-0156]) MAY be used to delegate trust
    from the XMPP server domain to the WebSocket origin.

In particular, it would be very helpful to add two examples (one in 
which the WebSocket origin matches the domain of the XMPP service, and 
one in which it does not, e.g., delegation of foo.example to 
hosting.example.net) and to explain that the delegation model is 
conceptually the same as for the existing DNS SRV lookup methods 
described in RFC 6120, except using web linking in the WebSocket case. 
Extra credit for walking through the examples in enough depth that 
readers of this document can see all the key the steps involved (go to 
HTTPS URL at source domain for host-meta data, retrieve the appropriate 
web link, resolve that link to an IP address, connect there via wss: URI 
or HTTP upgrade, etc. - and what certificate to check at the end of that 
process, tying in with RFC 2818 for checking rules).

2. In Section 6.1, briefly describe why the choice of transport binding 
(WebSocket here vs. TCP as in RFC 6120), including the different message 
framing method used here, does not have an impact on the effectiveness 
of end-to-end stanza encryption methods.

3. There was a bit of confusion (reflected in Ted Lemon's DISCUSS) about 
the exact purpose of the WebSocket binding. To clear up this confusion, 
it would be good to explain that the WebSocket binding is an alternative 
way to interact with the same service that one might interact with using 
the TCP binding (in an IM context, one would be able to retrieve the 
same contact list, chat with the same people, etc.). That is, the point 
of the WebSocket binding is mainly to enable browser-based clients to 
connect to servers (in a more efficient way than BOSH), since such 
clients don't have access to facilities that would enable them to open 
TCP connections as in RFC 6120. It would be best if one aspect of this 
explanation would include a discussion of the security context for 
web-based interactions with XMPP services - e.g., the web origin concept 
(RFC 6454) applies, discovery occurs via host-meta and web linking, and 
browsers don't allow access to the application-layer certificates 
(perhaps there are other salient points to raise here, too, but those 
seem like the key ones to me).

Richard, does that accurately summarize the discussion?

Naturally, the authors also need to address the various other comments 
provided by IESG members (again, see 
<https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/>).

Let me know if you have any questions or comments.

Thanks!

Peter