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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 26 November 2014 08:18 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC30A1A0045 for <rtcweb@ietfa.amsl.com>; Wed, 26 Nov 2014 00:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIWQ3aFrhU6w for <rtcweb@ietfa.amsl.com>; Wed, 26 Nov 2014 00:18:24 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35371A0030 for <rtcweb@ietf.org>; Wed, 26 Nov 2014 00:18:23 -0800 (PST)
Received: from [192.168.1.200] (p548190F0.dip0.t-ipconnect.de [84.129.144.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A678C1C1622BD; Wed, 26 Nov 2014 09:18:20 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <547392A4.4080309@nostrum.com>
Date: Wed, 26 Nov 2014 09:18:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEA82CC2-9822-4D08-BCF5-1A90D767DB7D@lurchi.franken.de>
References: <547392A4.4080309@nostrum.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uiCqLEXqru9vyjb9ha0tYQy_xhs
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel (Issue 5)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Nov 2014 08:18:26 -0000

On 24 Nov 2014, at 21:18, Adam Roach <adam@nostrum.com> 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
>> 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.
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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb