Subject: [rtcweb] draft-ietf-rtcweb-data-channel (Issue 5)

From: Adam Roach <[email-masked]>
Date: Mon, 24 Nov 2014 14:18:44 -0600

I promised to propose a minor fix to the RFC 2119 use for the Issue 5 
resolution discussed in Hawaii. The text on the slide was:

> The message orientation of SCTP is used to preserve the message 
> boundaries of
> user messages. Therefore, no more than one message MUST be put into an 
> SCTP
> user message. If the deprecated PPID-based fragmentation and 
> reassembly is not
> used, exactly one message MUST be put into an SCTP user message.

I propose reformulating as:

    The message-orientation of SCTP is used to preserve the message
    boundaries of user messages.  Therefore, senders MUST NOT put more
    than one application message into an SCTP message. Unless the
    deprecated PPID-based fragmentation and reassembly is used, the
    sender MUST include exactly one application message in each SCTP
    message.

One of the things that flummoxed me a bit here in trying to rework the 
language is that "message" in the original formulation meant two 
different things: (1) an SCTP message (as in RFC4960) and (2) an 
application message (as in http://w3c.github.io/webrtc-pc/). I suggest 
that the document should include a terminology section that clearly lays 
out these two concepts with clearly-defined terms, citing these two 
specifications, and that the remainder of the document is rigorously 
updated to reflect that terminology (i.e. the term "message" should 
never appear by itself, only prefixed with an adjective to make it clear 
which of these two messages is meant).

/a

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 26 Nov 2014 09:18:19 +0100

On 24 Nov 2014, at 21:18, Adam Roach <[email-masked]> wrote:

> I promised to propose a minor fix to the RFC 2119 use for the Issue 5 resolution discussed in Hawaii. The text on the slide was:
> 
>> The message orientation of SCTP is used to preserve the message boundaries of
>> user messages. Therefore, no more than one message MUST be put into an SCTP
>> user message. If the deprecated PPID-based fragmentation and reassembly is not
> The message-orientation of SCTP is used to preserve the message boundaries of user messages.  Therefore, senders MUST NOT put more than one application message into an SCTP message.  Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP message.
I don't know what an SCTP message is. Most likely I would guess that it is an SCTP packet. Using
that interpretation, your suggested text forbids bundling of data chunks and sending user messages
larger than the MTU minus headers.
That is why I used "user message", the entity which is transported by SCTP to the peer with preservation
of message boundaries. This is also used in RFC 4960. So what about:

The message-orientation of SCTP is used to preserve the message boundaries of user messages.  Therefore, senders MUST NOT put more than one application message into an SCTP user message.  Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP user message.

OK?
> 
> One of the things that flummoxed me a bit here in trying to rework the language is that "message" in the original formulation meant two different things: (1) an SCTP message (as in RFC4960) and (2) an application message (as in http://w3c.github.io/webrtc-pc/). I suggest that the document should include a terminology section that clearly lays 
It was intended to be an user message. Fix in the above suggested text.

Best regards
Michael
> out these two concepts with clearly-defined terms, citing these two specifications, and that the remainder of the document is rigorously updated to reflect that terminology (i.e. the term "message" should never appear by itself, only prefixed with an adjective to make it clear which of these two messages is meant).
> 
> /a
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb