Subject: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Jul 2014 13:00:17 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

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

Reviewer: Dan Romascanu

Review Date: 7/2/2014

IETF LC End Date: 7/4/2014

IESG Telechat date: 7/10/2014

Summary: ready with minor issues

Major issues:

None

Minor issues:

1.       In order to accommodate the Websocket binding this document describes several deviations from RFC6120. For example, in Section 3.3 it says:

The WebSocket XMPP sub-protocol deviates from the standard method of

   constructing and using XML streams as defined in [RFC6120] by

   adopting the message framing provided by WebSocket to delineate the

   stream open and close headers, stanzas, and other top-level stream

   elements.

              I am wondering whether it would not be appropriate to reflect this in the document header by adding Updates RFC6120

2.       In Section 3.6.1:

   If the server wishes at any point to instruct the client to move to a

   different WebSocket endpoint (e.g. for load balancing purposes), the

   server MAY send a <close/> element and set the "see-other-uri"

   attribute to the URI of the new connection endpoint (which MAY be for

   a different transport method, such as BOSH (see [XEP-0124] and

   [XEP-0206]).

        I do not understand the usage of MAY in this paragraph. Is there another method to move to a different Web socket endpoint that is described here or some other place? In not, why is not the first MAY at least a SHOULD? The second usage seems to describe a state of facts, so it needs not be capitalized at all.

Nits/editorial comments:

In Section 3.1 I believe that the example should be preceded by some text that indicates that this is an example, such as: 'An example of a successful handshake and start of session follows:'

---

From: Jari Arkko <[email-masked]>
Date: Tue, 8 Jul 2014 00:57:55 -0400

Thanks for the review, Dan.

I would like to see some thoughts from the editors regarding the two points that you raised.

Jari

On 02 Jul 2014, at 09:00, Romascanu, Dan (Dan) <[email-masked]> wrote:

> In Section 3.1 I believe that the example should be preceded by some text that indicates that this is an example, such as: ‘An example of a successful handshake and start of session follows:’
>  
>  
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Jul 2014 02:46:21 -0600

<hat type='shepherd'/>

On 7/8/14, 12:51 AM, Lance Stout wrote:
> Hrm, did my earlier response on the 3rd not make it through moderation to the gen-art list?
>
>
>
>> 1. In order to accommodate the Websocket binding this document describes several
>> deviations from RFC6120. For example, in Section 3.3 it says: The WebSocket
>> XMPP sub-protocol deviates from the standard method of constructing and using
>> XML streams as defined in [RFC6120] by adopting the message framing provided by
>> WebSocket to delineate the stream open and close headers, stanzas, and other
>> top-level stream elements. I am wondering whether it would not be appropriate to
>> reflect this in the document header by adding Updates RFC6120
>
> This is creating a new binding, separate from the TCP binding defined in RFC6120. While
> this document introduces framing (thus deviating from RFC6120) it does not actually
> modify anything in RFC6120.

That seems accurate to me (also with my RFC6120-author hat on).

>>    different WebSocket endpoint (e.g. for load balancing purposes), the server
>>    MAY send a <close/> element and set the "see-other-uri" attribute to the
>>    URI of the new connection endpoint (which MAY be for a different transport
>>    method, such as BOSH (see [XEP-0124] and [XEP-0206]).
>>
>>         I do not understand the usage of MAY in this paragraph. Is there another
>> method to move to a different Web socket endpoint that is described here or some
>> other place? In not, why is not the first MAY at least a SHOULD? The second
>> usage seems to describe a state of facts, so it needs not be capitalized at all.
>
> That is the only method, so I agree that can be a SHOULD, and also agree on the
> second point.
>
> After proposing changing this to SHOULD to the WG, some members have questioned if
> 2119 language is even needed here at all, as there is no alternative way to do this.

Right. I might change "the server MAY send a <close/> element and 
set..." to, simply, "the server sends a <close/> element and sets..." 
since, as you say, this is just how it's done. (These conditionally 
normative statements are always a bit confusing - "if X then MUST Y" and 
such.)

Peter

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Jul 2014 09:06:34 +0000

Hi Jari,

The authors actually responded - see http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html. 

They pushed back on my #1 - I am still not convinced by their argument (as the protocol does change by adding a different mapping) but I would not block the document for this purpose. 
The proposed changes for the rest are fine. 

Regards,

Dan

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2014 7:58 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
> 
> > 1.       In order to accommodate the Websocket binding this document
> describes several deviations from RFC6120. For example, in Section 3.3 it
> says:
> >               I am wondering whether it would not be appropriate to reflect this
> in the document header by adding Updates RFC6120
> >
> > 2.       In Section 3.6.1:
> >
> >         I do not understand the usage of MAY in this paragraph. Is there
> another method to move to a different Web socket endpoint that is
> described here or some other place? In not, why is not the first MAY at least
> a SHOULD? The second usage seems to describe a state of facts, so it needs
> not be capitalized at all.
> >
> >
> > Nits/editorial comments:
> >
> > In Section 3.1 I believe that the example should be preceded by some text
> that indicates that this is an example, such as: 'An example of a successful
> handshake and start of session follows:'
> >
> >

---

From: Lance Stout <[email-masked]>
Date: Mon, 7 Jul 2014 23:51:01 -0700

— Lance

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Jul 2014 09:22:41 -0600

Hi Dan,

As the document shepherd for this spec and the author of RFC 6120, I 
have one comment below.

> The proposed changes for the rest are fine.

Even at the time of RFC 3920 (precursor to RFC 6120), we had one other 
binding, namely the HTTP binding long-polling binding ("BOSH") defined 
at http://xmpp.org/extensions/xep-0124.html - this is why in RFC 3920 we 
explicitly stated that the spec defined only the TCP binding:

###

4.2. Binding to TCP

    Although there is no necessary coupling of an XML stream to a [TCP]
    connection (e.g., two entities could connect to each other via
    another mechanism such as polling over [HTTP]), this specification
    defines a binding of XMPP to TCP only.  In the context of
    client-to-server communications, a server MUST allow a client to
    share a single TCP connection for XML stanzas sent from client to
    server and from server to client.  In the context of server-to-server
    communications, a server MUST use one TCP connection for XML stanzas
    sent from the server to the peer and another TCP connection
    (initiated by the peer) for stanzas from the peer to the server, for
    a total of two TCP connections.

###

We repeated this qualification in RFC 6120:

###

3. TCP Binding

3.1. Scope

    As XMPP is defined in this specification, an initiating entity
    (client or server) MUST open a Transmission Control Protocol [TCP]
    connection to the receiving entity (server) before it negotiates XML
    streams with the receiving entity.  The parties then maintain that
    TCP connection for as long as the XML streams are in use.  The rules
    specified in the following sections apply to the TCP binding.

       Informational Note: There is no necessary coupling of XML streams
       to TCP, and other transports are possible.  For example, two
       entities could connect to each other by means of [HTTP] as
       specified in [XEP-0124] and [XEP-0206].  However, this
       specification defines only a binding of XMPP to TCP.

###

The WebSocket binding specified in this I-D is intended to eventually 
replace BOSH for reasons explained in RFC 6202.

In my opinion, the point of layering via bindings is to not modify or 
update one binding by defining another binding. Thus I continue to be of 
the opinion that the WebSocket binding does not update RFC 6120.

Peter

> xmpp mailing list
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Jul 2014 16:30:23 +0100

On 8 July 2014 10:06, Romascanu, Dan (Dan) <[email-masked]> wrote:

> Hi Jari,
>
> The authors actually responded - see
> http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html.
>
> They pushed back on my #1 - I am still not convinced by their argument (as
> the protocol does change by adding a different mapping) but I would not
> block the document for this purpose.

I genuinely don't understand why adding an additional binding should
require an Updates.

I understand "Updates" to be an indicator that implementors of (in this
case) RFC 6120 would need to read this document as well, and I don't
believe that to be the case.

In particular, implementors of RFC 6120 don't need to care about this
document unless they *also* want to do XMPP over Websockets, in the same
way that implementors of Websockets don't need to care about this document
unless they *also* want to send XMPP over them.

Of course, readers of this document are required to read both RFC 6120 and
the Websockets spec, but that's what Normative References are for.

Dave.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Jul 2014 15:49:19 +0000

Hi Dave,

An implementor of RFC 6120 does not know that the XMPP over Websockets binding option exists at all. It did not exist by the time 6120 was written, so of course, they can do without it. Now that the binding exist, the option should be visible IMO.

The language you use in the I-D actually seems to support this:

> The WebSocket
> top-level stream elements.

Regards,

Dan

From: Dave Cridland [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 6:30 PM
To: Romascanu, Dan (Dan)
Cc: Jari Arkko; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

On 8 July 2014 10:06, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jari,

I genuinely don't understand why adding an additional binding should require an Updates.

I understand "Updates" to be an indicator that implementors of (in this case) RFC 6120 would need to read this document as well, and I don't believe that to be the case.

In particular, implementors of RFC 6120 don't need to care about this document unless they *also* want to do XMPP over Websockets, in the same way that implementors of Websockets don't need to care about this document unless they *also* want to send XMPP over them.

Of course, readers of this document are required to read both RFC 6120 and the Websockets spec, but that's what Normative References are for.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Jul 2014 17:20:57 +0100

On 8 July 2014 16:49, Romascanu, Dan (Dan) <[email-masked]> wrote:

>  Hi Dave,
>
>
>
> An implementor of RFC 6120 does not know that the XMPP over Websockets
> binding option exists at all. It did not exist by the time 6120 was
> written, so of course, they can do without it. Now that the binding exist,
> the option should be visible IMO.
>
>
>
OK, but why is this case different to, for example, an IMAP extension,
where we don't say "Updates: 3501" every time - indeed, qresync got serious
push-back over the Updates there.

Dave.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 8 Jul 2014 11:05:31 -0700

Extension specifications, in my opinion, should not Update the base specification.   To those who think they should, consider what that means when the base specification is an IETF full standard and the extension specification is an independent submission experimental RFC.

Making base specification implementors aware of an extension is NOT the purpose of Updates.

-- Kurt

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Jul 2014 14:58:44 -0400

> push-back over the Updates there.

I agree.  This document does not update RFC 6120.  If an implementation of
RFC 6120 does not support this transport, then it will never need to know
about the framing changes.  If it does, then it will.  The two are
separate.

"Updates" is not a mechanism for advertising additional features.

--Richard

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Jul 2014 13:16:36 +0000

> >    elements.

‘deviates’ IMO suggests a change to the base specification, not just an optional new binding.

Regards,

Dan

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 9:59 PM
To: Dave Cridland
Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]; Jari Arkko; [email-masked]
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

On Tue, Jul 8, 2014 at 12:20 PM, Dave Cridland <[email-masked]<mailto:[email-masked]>> wrote:
On 8 July 2014 16:49, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dave,

OK, but why is this case different to, for example, an IMAP extension, where we don't say "Updates: 3501" every time - indeed, qresync got serious push-back over the Updates there.

I agree.  This document does not update RFC 6120.  If an implementation of RFC 6120 does not support this transport, then it will never need to know about the framing changes.  If it does, then it will.  The two are separate.

Dave.

_______________________________________________
xmpp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jul 2014 08:38:30 -0600

> ‘deviates’ IMO suggests a change to the base specification, not just an

How about this:

OLD

NEW
    The framing method for the binding of XMPP to WebSocket differs
    from the framing method for the TCP binding as defined in [RFC6120];
    in particular, the WebSocket binding adopts the message framing
    provided by WebSocket to delineate the stream open and close
    headers, stanzas, and other top-level stream elements.

Peter

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Jul 2014 14:45:13 +0000

wfm

Thanks and Regards,

Dan

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2014 5:39 PM
> To: Romascanu, Dan (Dan); Richard Barnes; Dave Cridland
> Cc: [email-masked]; [email-masked]; Jari
> Arkko; [email-masked]
> >  > > The WebSocket XMPP sub-protocol deviates from the standard
> method
> > of
> >
> > 'deviates' IMO suggests a change to the base specification, not just
> > an optional new binding.
> 
> How about this:
> 
> OLD