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

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Jan 2020 21:55:40 +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.

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.

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://github.com/cdh4u/draft-datachannel-t140/pull/55<https://protect2.fireeye.com/v1/url?k=2c2d5b3e-70f95c92-2c2d1ba5-8667c4afe13e-d27a5c8e10d59d11&q=1&e=d6e7256a-9e02-4443-bca5-69fb5eaa056c&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F55>

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]><mailto:[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

_______________________________________________

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Jan 2020 22:33:41 +0000

Hi,

Den 2020-01-26 kl. 22:55, skrev Christer Holmberg:
Hi,

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.

Regards

Gunnar

Regards,

Christer

Hi,

Regards,

Christer

    Hi,

    I suggest the following:

    OLD:

    NEW:

    Regards,

    Christer

mmusic mailing list

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Jan 2020 07:38:00 +0000

Hi,

>> 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

 
 
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

Regards,
 
Christer

 
On 24/01/2020, 15.10, "Christer Holmberg" mailto:[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:

    NEW:

     
    Regards,
    
    Christer

 
mailto:[email-masked]

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

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

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 27 Jan 2020 11:46:06 +0000

Christer, you are right, clear and fine.

No need for change.

Gunnar

-- 

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288