T.140 Real-Time Text Conversation over WebRTC Data Channels
draft-ietf-mmusic-t140-usage-data-channel-14

** I support Martin Duke’s DISCUSS position.

** Section 5.4  
Initially:
“As a T.140 data channel does not provide a mechanism for the receiver to identify retransmitted  T140blocks after channel reestablishment, the sending endpoint MUST NOT retransmit T140blocks unless it has strong indications  that a T140block has been lost during the data channel failure.”

Later:
“Different mechanisms used by sending and receiving endpoints to detect or suspect text loss are outside the scope of this specification.”

How is this normative MUST NOT supposed to be evaluated if the the explanation of “strong indications” is not explained in this document and no reference is provided?

¯\_(ツ)_/¯

Thank you for the document and some bonus point for using only IPv6 in your examples ;-)

-éric

Thanks for this document.  I have just one comment about BCP 14 key words that I don’t think has come up elsewhere:

— Section 5.3 —

   It is RECOMMENDED to use the
   default transmission interval of 300 milliseconds [RFC4103], for
   T.140 data channels.  Implementers MAY also use lower values, for
   specific applications requiring low latency, taking the increased
   overhead in consideration.

Given the “RECOMMENDED” in the first sentence, I don’t think the second sentence is really a BCP 10 “MAY”, but should be “may” (or “might”).  Actually, I think I would also remove the first comma, as, “Implementers might use lower values for specific applications requiring low latency, taking the increased overhead in consideration.”

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!).

Thanks for the changes. I believe this substantially addresses my DISCUSS.

However, we've created a couple of nits:
- In Section 5.3, the MAY was added to the first paragraph instead of the second. I don't object to having one in the first paragraph, but don't feel it to be necessary.
- In 5.4, "channels.As" needs a space in there.


Old comment (which has been addressed):
The Tsvarea review cites a few other places where the 2119 language is a little loose, e.g. MUSTs with vague and unenforceable criteria.