Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 18:53:39 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-t140-usage-data-channel-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I eagerly await further discussion of the TSV(-art/-AD) comments but
have nothing to contribute to such discussion.

It's kind of interesting that we negotiate the human language to be used
for the ... human-entered text.  Are we expecting the user-agents to
enforce the result of that negotiation, or just send whatever the users
type, even if it is in some other language?

Section 4.1

   The offerer and answerer MUST NOT include the max-retr or the max-
   time attribute parameters in the 'dcmap' attribute.  If any of the
   attribute parameters is received in an offer, the answerer MUST
   reject the offer.  If any of the attribute parameters is received in

s/any of the/either of those/? (twice)

Section 4.2.3.3

   If the answerer has not marked the direction of a T.140 data channel
   in accordance with the procedures above, it is RECOMMENDED that the
   offerer does not process that as an error situation, but rather
   assume that the answerer might both send and receive T.140 data on
   the data channel.

My SDP O/A is a bit rusty, but isn't that a divergence from the default
behavior of "treat it as an error"?  Perhaps we could say something
about why diverging from the default is deemed best.

Section 5.2

   Each T140block is sent on the SCTP stream [RFC4960] used to realize
   the T.140 data channel using standard T.140 transmission procedures
   [T140].  [...]

I'm not really sure what is meant by "standard T.140 transmission
procedures" -- is that supposed to cover the process by which the webrtc
stack receives the T.140 input or something done within webrtc?

   Data sending and reporting procedures conform to [T140].

I don't see any instance of the string "report" in
file:///home/bkaduk/Downloads/T-REC-T.140-199802-I!!PDF-E.pdf; am I
missing something?

Section 5.4

   might have been lost.  Different mechanisms used by sending and
   receiving endpoints to detect or suspect text loss are outside the
   scope of this specification.

I think I can accept that, but do we have reason to believe that any
such mechanisms are possible?

Section 6

   o  During a normal text flow, T140blocks received from one network
      are forwarded towards the other network.  Keep-alive traffic is
      implicit on the T.140 data channel.  A gateway might have to

I'm not sure what reference I should look at to understand what is meant
by "keep-alive traffic is implicit".

Section 7

I confess I don't really understand what part of RFC 8373 was media-type
specific and needed updating for use by this document.
I guess I could see a need for some new specification regarding the
attributes' usage, since we need something to point to for translating
them from media-level attributes to data-channel-level attributes, but
that doesn't seem to be what this is claiming to do.
draft-ietf-mmusic-data-channel-sdpneg seems to already cover the
general behavior that when data channels are used, they get
data-channel-level attributes for things that would be media attributes
of the corresponding subprotocol as a media type.  Maybe I'm more rusty
on SDP O/A than I thought...

Section 8

   The generic security considerations for WebRTC data channels are
   defined in [I-D.ietf-rtcweb-data-channel].  As data channels are

Perhaps it is worth pre-dereferencing the reference chain to
rtcweb-security and rtcweb-security-arch directly?

It also seems appropriate to reiterate the note from earlier in the
document that "no mechanism to provide end-to-end encryption of T.140
data is defined at the time of this writing" and the consequences
thereof when the channel itself is not end-to-end.

Section 11.1

We should maybe sprinkle a couple more RFC 3264 refs; the current one
doesn't seem to be in a normative manner (though I don't dispute the
status of 3264 as a normative reference!).

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 8 Apr 2020 08:54:36 +0200

Thanks for the comments,

I will clarify a few inline and hand over to Christer to respond to all.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/

This relates to section 4.2.2 where the use of the hlang-send and 
hlang-recv attributes from RFC 8373 is specified. These attributes 
provide information about both language and modality preferences and 
capabilities of the parties.

In traditional calling between humans, the answering part is expected to 
start the conversation with a greeting phrase. It saves a lot of initial 
time to get to the topic of the call if the called party starts in a 
language and modality (spoken, written or signed) that the caller is 
confident with.

So, in calls between humans, the negotiation should result in a hint to 
the human user in which language and modality it is most suitable to 
express the greeting phrase.

The calling and answering users are not forced to use the indicated 
language and modality. It is specified that the attributes express 
languages that the users are willing to use.

In automatic answering devices, the attributes can be used to select the 
language and modality of the answer.

Section 5.3 in RFC 8373 says: " This document does not define the use of 
language tags in media other than interactive streams of audio, video, 
and text (such as "message" or "application"). Such use could be 
supported by future work or by application agreement."

Since the T140 data channel is not transported in any audio or video or 
text media, it was neccesarry to say that the present draft updates RFC 
8373 and that the modality is written.

This may have been a long explanation of a minor thing. The only thing 
this draft needs to bother about is just that:  to tell that these 
language attributes may be used and that they then represent written 
language.

> stack receives the T.140 input or something done within webrtc?
This is esseentially chapter 7 of T.140. It is at least to use UTF-8 
coding as specified in T.140. And start after channel establishment by 
sending UTF-8 BOM. It is also to not buffer longer than 500 ms, even if 
that is also said in another place.
> file:///home/bkaduk/Downloads/T-REC-T.140-199802-I!!PDF-E.pdf; am I
Right. There is only one response specified in T.140. It is the 
"Unsupported request" in section 8.7. But that cannot really be called a 
report.  Maybe another reference was intended here. 
draft-ietf-rtcweb-data-channel could be intended for the sending, but it 
has nothing on reporting. W3C webrtc has requirements on reporting for 
statistics, but I doubt that that was intended.   Over to Christer...
> by "keep-alive traffic is implicit".

Implicit means here that keep-alive is handled somewhere in the 
underlying stack. It seems to me that it is in SCTP, RFC 4960, sections 
1.5.7 Path management and 8.3 Heartbeat  even if I cannot find it 
expressed that the Heartbeat interval should be tuned so that they also 
serve as keep-alive on the connection through routers etc.

But also ICE, RFC 5245 section 10 also has specification for how ICE 
usually takes care of keepalive.

Maybe "implicit" could be changed to "handled by lower layers".

> on SDP O/A than I thought...
Explained in the beginning of this answer. It was only to define that 
the modality is "written" for this channel.
> status of 3264 as a normative reference!).
---------------------------

Over to Christer for more answers and conclusions.

Thanks,

Gunnar

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

-- 

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

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