Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-sdp-ws-uri-01

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Paul,

Thanks for your feedback. Please see inline. See the attached diffs as
well with proposed changes

-----Original Message-----
From: bfcpbis <[e-mail]> on behalf of Paul Kyzivat
<[e-mail]>
Date: Wednesday, 16 March 2016 at 2:04 AM
To: "[e-mail]" <[e-mail]>
Subject: Re: [bfcpbis] WGLC on draft-ietf-bfcpbis-sdp-ws-uri-01

>Generally in good shape. A few comments:
>
>* Section 3.2 says:
>
>    This section defines a new SDP media-level attribute, 'ws-uri' which
>    can appear in any of the media lines.
>
>But this cannot appear in any media *line*. I think you mean it can
>appear in any media *section*.

Right. I will fix this text


NEW:
This section defines a new SDP media-level attribute, 'ws-uri' which
    can appear in any of the media sections.



>
>This also applies to section 3.3.

Yes. Will fix here as well with the above proposed text

>
>* Section 4.1:
>
>The text here says that the *answerer* "MUST add an "a=ws-uri" or
>"a=wss-uri" attribute". But Section 4.2 admits the possibility that the
>offerer might be the server. Clearly it is the *server* side that needs
>to include "a=ws-uri" or "a=wss-uri", regardless of whether that side is
>offerer or answerer.

Agree. I will reword the text to:

NEW:
Furthermore, the server side, which could be either
          the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-uri"
attribute in the media section
          depending on whether it wishes to use  WebSocket or secure
WebSocket



Is this better ?


>
>I can see how this might be important, such as in cases where a UAC
>sends an offerless invite to the server and the server wants to use
>BFCP. And the "client" might not be *able* to act as a web server. The
>possibility of this case should also be discussed elsewhere in the
>document.

Agree. This is a good point. I will add a new sub-section 4.6 with below
text 

Title: Offerless INVITE Scenarios

In some scenarios an endpoint (e.g., a browser) originating the call (UAC)
can send
an offerless INVITE to the server. The server will generate an offer
in response to the INVITE. In such cases the server MUST  send an offer
with
setup attribute as ³passive" so as to accept incoming connection and
MUST include "a=wss-uri" or "a=ws-uri" attribute in the media section
depending on whether the server wishes to use WebSocket or secureWebSocket.
The SDP offer sent by the server will look like the example in Section 4.3.


Is the above text ok ?


>
>Also, this section has some problems in use of terminology: The
>construct "add an ... attribute in the "m=" line of each media-line ..."
>makes no sense. Perhaps what you mean is: "add an ... attribute in the
>media-section".

Right will re-word the text at all places to indicate ... attribute in the
media-section...


>
>* Section 4.5:
>
>It would be good to mention the use of "a=connection:existing" for
>websocket reuse.

Sure will mention a=connection:existing and its reference to RFC4145. See
the attached diff.


Thanks,
Regards,
Ram

>
>	Thanks,
>	Paul
>
>
>On 3/13/16 12:55 PM, Charles Eckel (eckelcu) wrote:
>> This is to announce a 2 week WGLC on the draft:
>> https://tools.ietf.org/html/draft-ietf-bfcpbis-sdp-ws-uri-01
>>
>> Please review and provide any comments by Monday, March 28, 2016.
>> Comments should be sent to the authors and the BFCPBIS WG list.
>> If you review the draft but do not have any comments, please send a note
>> to that effect as well.
>>
>> Thanks,
>> Charles
>>
>>
>>
>> _______________________________________________
>> bfcpbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bfcpbis