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

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2020 15:08:49 +0000

Hi,

Based on Adam's AD review, I have created a pull request.

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" <[email-masked]> 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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Jan 2020 21:20:43 +0000

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.

What a subchannel specification must indicate is which language modality that the subchannel transports. I think we should be satisfied with telling that the T.140 data channel transports text modality and leave to other subchannel specifications to specify which modality they transport.

I made separate change proposals for two occurrences of the RFC 8373 update indication. I am afraid that these two change proposals might require some harmonization of language.

Regards

Gunnar

Den 2020-01-24 kl. 16:08, skrev Christer Holmberg:

Hi,

Regards,

Christer

On 24/01/2020, 15.10, "Christer Holmberg" <[email-masked]><mailto:[email-masked]> wrote:

    Hi,

    I suggest the following:

    OLD:

    NEW:

    Regards,

    Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

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

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288