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

Ram,

This all sounds good to me.

	Thanks,
	Paul

On 5/2/16 7:17 AM, Ram Mohan R (rmohanr) wrote:
> Hi Paul,
>
> Thanks for your feedback. Please see inline. See the attached diffs as
> well with proposed changes
>
> -----Original Message-----
> From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Paul Kyzivat
> <pkyzivat@alum.mit.edu>
> Date: Wednesday, 16 March 2016 at 2:04 AM
> To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
> 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
>>> bfcpbis@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>
>>
>> _______________________________________________
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>