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

[Gunnar Hellström <[e-mail]>]

Thanks for the comments,

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

Den 2020-04-08 kl. 03:53, skrev Benjamin Kaduk via Datatracker:
> 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?

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.

> 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?
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.
>
>     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?
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...
>
> 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".

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

>
> 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...
Explained in the beginning of this answer. It was only to define that 
the modality is "written" for this channel.
>
> 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!).
>
---------------------------

Over to Christer for more answers and conclusions.

Thanks,

Gunnar

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

-- 

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

Gunnar Hellström
Omnitor
[e-mail]
[phone]