Hi Joerg,
>>> Section 3.2.3 defines behaviour in a negative way, i.e., via MUST NOT
>>> statements, excluding all but one possibility. This could be problematic in
>>> the future if another option gets added to SCTP usage, which would then
>>> implicitly be allowed. It would be better if the behaviour was defined i
>>> a positive way, i.e., using MUST.
>>
>> In general I agree with you. But, in the case the base data channel spec mandates a set of SCTP extensions,
>> and the text says that a couple of them must not be used for CLUE. I think that is the clearest way.
>>
>> (And, if additional SCTP extensions are added to rtcweb-data-channel in the future, that could cause problems no matter
>> if we use MUST or MUST NOT, depending on whether such extensions can be used with CLUE or not.)
>
> Well, if you have 4 features A, B, C, D and you state that B and C MUST
> NOT be used, this leaves A and D. If somebody adds E to SCTP, then E is
> implicitly allowed. I think it is just easier to spell out what
> implementers are supposed to do.
The default is that implementers do whatever rtcweb-data-channel says, and then we only explicitly indicate the exceptions.
Also, if someone writes an RFC X that adds feature "E" to SCTP, "E" will not automatically be incorporated into rtcweb-data-channel and clue-datachannel. Those specs would have to be updated, with an explicit reference to RFC X in order to incorporate "E".
ANY technology we reference could be extended with new features.
----
>>> Sect. 3.2.5, 2nd para: use "MUST" instead of "must" since this appears to
>>> be normative, so RFC 2119 wording should be used.
>>
>> The reason I use "must" is because the text is referencing requirements in another specification, i.e., the
>> requirement is not defined or introduced by this draft. That is based on guidance I have received on earlier drafts.
>
> Ok. Maybe make this explicit in the text. "According to RFCxxxx, ..."
The text in the latest version (-17) now says:
"As defined in [I-D.ietf-rtcweb-data-channel], the dynamic address
reconfiguration extension ('Supported Extensions Parameter'
parameter) defined in [RFC5061] must be used to signal the support of
the stream reset extension defined in [RFC6525]. Other features of
[RFC5061] MUST NOT be used for CLUE data channels."
----
>>> Sect. 3.2.7, 1st para: this appears t be normative language and thus
>>> should use the RFC 2119 keywords.
>>
>> As for your comment on 3.2.5, the text is simply referencing requirements defined elsewhere.
>
> See above.
The text in version -17 says:
"As described in [I-D.ietf-rtcweb-data-channel], in order to close a
data channel, an entity sends an SCTP reset message [RFC6525] on its
outgoing SCTP stream associated with the data channel. When the
remote peer receives the reset message, it also sends (unless already
sent) a reset message on its outgoing SCTP stream associated with the
data channel. The SCTPoDTLS association, and other data channels
established on the same association, are not affected by the SCTP
reset messages."
----
>>> Sect. 3.3.1.1, table 1 + 2nd para after table 1: the text in the 2nd para
>>> defines the value for the "application usage"; this should also be reflected
>>> in table 1 since it seems that only one application usage is defined.
>>
>> I don't know how I would get it into the table, as it is a generic description of an m- line for SCTP over DTLS.
>>
>> I could of course copy/paste the table, indicate that it shows the m- line for CLUE, and replace "application usage"
>> with "webrtc-datachannel". But, I am not sure that would make things more clear.
>
>All I am saying is that all other table entries refer to explicit values
>while this one points indirectly to the text. There is nothing wrong
>technically, rather a matter of presentation.
I guess I could keep the generic text saying that mmusic-sctp-sdp defines how the m= line parts are set, and then say that the table shows the values for a CLUE data channel.
--------
>>> Editorial:
>>>
>>> Don't just copy the first paragraph(s) from the introduction to create an abstract.
>>
>> I will see if I can make the Abstract shorter.
>
> I want you to make it different. An abstract is _not_ the introduction
> even though the first bits may overlap.
I agree, but as this is a relatively simple draft, I see no reason in making it different just to make it different __
But, in version -17 I did remove stuff that I don't think need to be in the Abstract, and it now says:
"This document defines how to use the WebRTC data channel mechanism in
order to realize a data channel, referred to as a CLUE data channel,
for transporting CLUE protocol messages between two CLUE entities."
---
>>> Sect. 3.3.1: the ref to the clue-signalling draft is missing a link (all other refs have one).
>>
>> Not sure I understand. What do you mean by "missing a link"?
>
> It's missing a hyperlink. No idea why but all other citations seem to
> have hyperlinks.
Aaah... now I get it. I was reading the pure text version, without any links __
The XML code for this reference is identical to the code for same as references, where the link does exist, so I am not sure where the problem is.
----
>>> Fix the formatting of table 2 to avoid letter breaking from words.
>>
>> Will do.
>
> As you said in a different email, this may be hard. Hyphenation is the
> only thing that comes to mind. Or abbreviation. The present way looks
> just broken.
I was thinking about abbreviation, but I'd like to use the same terminology as in mmusic-data-channel-sdpneg.
But, I tried by using "sub-protocol" and "Appli-cation", and that makes it better.
Regards,
Christer
