Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel - the pull request - language modality

[Gunnar Hellström <[e-mail]>]

Christer, you are right, clear and fine.

No need for change.

Gunnar

Den 2020-01-27 kl. 08:38, skrev Christer Holmberg:
> Hi,
>
>>>> I have proposed new wording for the sentences about updating RFC 8373 in Github.
>>>>
>>>> We do not update RFC 8373 for all WebRTC data channels. We only do it for 't140' subchannels.
>>> We update 8373 for WebRTC data channels (the application/webrtc-datachannel) media type.
>>>
>>> We do NOT say that each subprotocol has to use the same language modality – we say that each
>>> subprotocol (e.g., t140) will have to specify the language modality for that subprotocol.
>> Right, sorry, I did not find that general update statement when I made my comment. I only found the two places that were
>> modified. So, I withdraw my comments, but please check if it is sufficiently easy to find the actual update text for RFC 8373.
> We have a dedicated section (Section 7) for the 8373 update, and it contains the statement I referred to earlier (saying that subprotocols
> must define the language modality), so I don't see how it could be made more clear than that :)
>
> Regards,
>
> Christer
>
>   
>   
>
>
>
> Den 2020-01-24 kl. 16:08, skrev Christer Holmberg:
> Hi,
>   
> Based on Adam's AD review, I have created a pull request.
>   
> https://protect2.fireeye.com/v1/url?k=2c2d5b3e-70f95c92-2c2d1ba5-8667c4afe13e-d27a5c8e10d59d11&q=1&e=d6e7256a-9e02-4443-bca5-69fb5eaa056c&u=https://github.com/cdh4u/draft-datachannel-t140/pull/55
>   
> Adam indicated that I could implement the changes together with the changes based on the IETF last-call comments. But, assuming people are ok with the changes, I'd like to merge the PR and submit a new version for the IESG to review.
>   
> Regards,
>   
> Christer
>   
>   
>   
>   
> On 24/01/2020, 15.10, "Christer Holmberg" mailto:[e-mail] wrote:
>   
>      Hi,
>      
>          ---------------------------------------------------------------------------
>                
>          >>      §4.1:
>          >>
>          >>      The offerer and answerer MUST NOT include the max-retr and max-time
>          >>      attribute parameters in the 'dcmap' attribute.
>          >>
>          >>      Ideally, this would include text that indicates what a recipient of such
>          >>      messages would do (with the obvious choices being ignoring them or treating
>          >>      them as an error). I suggest the easiest thing to specify is that recipients
>          >>      of either attribute for a T.140 section MUST ignore them.
>          >>
>          >> Just to note:
>          >>
>          >> - The draft defines that the T.140 data channel is reliable.
>          >> - max-retr and max-time are used to indicate that a data channel is partially reliable, so there would be a conflict.
>          >>
>          >> So, the question is whether it is ok to just ignore, or whether it is a protocol error and the m- line therefore should be rejected.
>          >>
>          >> If *both* attribute parameters are included in an offer (which would also create a conflict), draft-channel-sdpneg says that the offer must be rejected.
>          >
>          > Given this last fact, it seems that the best approach would be to treat
>          > the presence of either parameter in this context as an error. The key
>          > here is that the behavior should be spelled out.
>      
>      I suggest the following:
>      
>      OLD:
>      
>         The offerer and answerer MUST NOT include the max-retr and max-time
>         attribute parameters in the 'dcmap' attribute.
>      
>      
>      NEW:
>      
>         The offerer and answerer MUST NOT include the max-retr and max-time
>         attribute parameters in the 'dcmap' attribute. If any of the
>         attribute parameters are included in an offer or answer, the receiver
>         MUST take the proper actions to reject the SDP.
>      
>       ---------------------------------------------------------------------------
>       
>      Regards,
>      
>      Christer
>       
>      
>      
>   
> _______________________________________________
> mmusic mailing list
> mailto:[e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]
[phone]