Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Hi,

I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06<https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt> and find it to be in good shape, important and sufficient for its purpose. I see also that further separate work is desirable for the multi-party considerations and the gateway considerations.

I found some places where mainly editorial improvements can be made:

1. In 4.1, misspelling. "descripton" sb "description"

2. In 4.1 Note, misspelling "negotied" sb "negotiated"

3. In 1., line 4  the last informational reference in the paragraph should be to RFC 3550 instead of RFC 4103

4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.

5. In 4.2, first line: "an SDP 'dcsa' attribute" s.b. "one or more SDP 'dcsa' attributes"

6. At the end of 4.2, add "section 6.7" because it is hard to find in sdpneg where it is specified how to handle unknown attributes (and the wording in 6.7 is confusing, but that is another matter)

7. In 4.2.3 delete the last sentence "An offerer and answerer MUST mark the direction of the text by sending a direction attribute inside 'dcsa' attribute." This is superfluous information, and it can be misunderstood that the direction attribute always must be explicitly provided. (another solution could be to improve the sentence by including when the direction must be included)

8. In 4.2.3.1.1 "both send or receive" s.b. "both send and receive"

9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last paragraph of 4.2.3.1.1 says that the answerer might not support direction marking. It is then illogical to require that.

10. In 4.2.3.1.2 second paragraph. The wording about not indicating 'sendrecv' means implicit marking as sendrecv is a bit confusing and may cause implementers to believe that they must always provide explicit marking of direction. A remedy might be to swap order between the two sentences in the second paragraph and insert "(implicitly or explicitly)" after "sendrecv" to make the paragraph wording:

"If the answerer does not explicitly mark the data channel, a 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. If the offerer marked the data channel as sendrecv (implicitly or explicitly), the answerer SHOULD mark the data channel as sendrecv(implicitly or explicitly), sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "

11. In 4.3 Examples, some values are unusual and should be selected to be more natural:
The stream-id in the offer is very often even because it is most often the same party who takes the initiative to the SCTP association who also sends the initial offer. Thus, change all stream-id in the examples from the odd 1 to e.g. the even 2

Use different udp port numbers in the m-lines in the offers and corrsponding answers.

Use different sctp port numbers in offers and corresponding answers.

12. In 5.2 Change the header to "5.2 Data Encoding, Sending and Receiving"
and insert last this important hint for interoperability.

"The T.140 coding details contain information on optional control codes intended for controlling the presentation that may not be supported by the presentation level of the receiving application. The receiving application MUST handle reception of such T.140 control codes properly (e.g. ignore them) even if their effect on presentation is not supported."

13. In 6. Gateway considerations:

At the end of bullet point 4 add "in reception"

14. In 6. Gateway considerations:
After bullet point 4, add one more bullet point:
"If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1]<https://tools.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.html#T140ad1> in the data sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the T.140 data channel was lost during the failure. Data that may have been correctly transmitted and received MUST not be repeated."

15. In 6. Gateway considerations:
In the last bullet point, change MUST to SHOULD, because we say above that some implementations may not support the direction attributes.

16. In 7 Update to RFC 8373
Reference for RFC 8373 is missing

17. In 11.2 Informational references:
Add reference to RFC 3550 as indicated in point 3 above.

I intend to provide these comments also as change proposals in GitHub.

Regards

Gunnar Hellström

Den 2019-10-02 kl. 15:25, skrev Bo Burman:
Greetings MMUSIC ,

This is to announce a 2 week WGLC on the draft:

    https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt

as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, October 16, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks,

/Bo
(MMUSIC co-chair)

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic