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

[Peter Saint-Andre <[e-mail]>]

Hi Dan,

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

On 7/8/14, 3:06 AM, Romascanu, Dan (Dan) 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.
> 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


>
> Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: Jari Arkko [mailto:[e-mail]]
>> Sent: Tuesday, July 08, 2014 7:58 AM
>> To: Romascanu, Dan (Dan)
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
>>
>> 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) <[e-mail]>
>> wrote:
>>
>>> 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:'
>>>
>>>
>>> _______________________________________________
>>> Gen-art mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/gen-art
>
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp
>