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

[Christer Holmberg <[e-mail]>]

Hi,

Based on Gunnar's comments, I have updated the pull request.

Regards,

Christer

On 27/01/2020, 13.46, "Gunnar Hellström" <[e-mail]> wrote:

    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]