Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 03 March 2014 12:46 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 2D8BD1A009E for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 04:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham
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 Z_b7NzNKIL5H for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 04:46:38 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 393C21A0090 for <rtcweb@ietf.org>; Mon, 3 Mar 2014 04:46:38 -0800 (PST)
Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CD6561C1042F2; Mon, 3 Mar 2014 13:46:34 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se>
Date: Mon, 03 Mar 2014 12:46:33 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B3CAD36-6C87-4FA6-B9A3-FFB0A181AE9F@lurchi.franken.de>
References: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@ESESSMB209.ericsson.se> <B112281E-4130-43C8-A051-7C4490BFF2C3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ri_pq6_Q8vZwLEZib4F7wcF24Ik
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 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: Mon, 03 Mar 2014 12:46:40 -0000

On 25 Feb 2014, at 10:48, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
>>> Q1:
>>> 
>>> Section 5 says:
>>> 
>>> 	"SCTP as specified in [RFC4960] MUST be used in
>>>  	combination with the extension defined in [RFC3758] and provides the
>>>  	following interesting features for transporting non-media data
>>>  	between browsers:"
>>> 
>>> I suggest to say:
>>> 
>>> 	"The SCTP extension defined in [RFC3758] MUST be supported, and
>>>    	provides the following features:
>>> 
>> But this implies that the listed features are provided by the extension defined in RFC 3758, which is not true. The features are provided by the combination of RFC 4960 and RFC 3758.
> 
> Correct. My mistake.
> 
> So, my suggestion would then be to remove "as specified in" and "interesting".
> 
> 	"SCTP [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and 
> 	provides the following features for transporting non-media data between browsers:"
> 
> The reference implicitly means "as specified in", in my opinon :)
Removed the 'interesting'.
The document use a 'as specified in' or similar text in several places. For consistency
it should be removed in all places. So I kept it for now to be consistent.

Best regards
Michael
> 
> ----------
> 
>>> Q3:
>>> 
>>> Section 5 says:
>>> 
>>> 	"This value can be used to multiplex multiple protocols
>>>  	over a single SCTP association.  The sender provides for each
>>>  	protocol a specific PPID and the receiver can demultiplex the
>>>  	messages based on the received PPID."
>>> 
>>> I think we discussed this earlier. The PPID value CAN NOT (at least not as used by WebRTC) be used to multiplex multiple protocols 
>>> over a single SCTP association. If you create multiple channels, for multiple protocols, the same PPID values may be used for each protocol.
>>> 
>>> The PPID CAN, however, be used within a data channel, e.g. to demultiplex the DCP from channel data.
>> 
>> I guess the problem is that I consider 'protocol' as something running on top of SCTP like DCEP, Binary of String data, you consider 'protocol' 
>> as something running on top of Binary of String data and the 'protocol' being identified in the JS protocol string.
>> 
>> What about using:
>> 
>> <t>Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side.
>> The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association.
>> In the WebRTP context, the PPID is used to distinguish between
>> UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in <xref target='I-D.ietf-rtcweb-data-protocol'/>.
>> Please note that the PPID is not accessable via the Javascript API.</t>
>> 
>> Does this address your issue?
> 
> Instead of talking about SCTP associations, could we talk about data channels? I.e. the PPID can be used to multiplex/demultiplex multiple upper layers within a single data channel?
> 
> Because, if you have multiple data channels on a single SCTP association, you will use the stream IDs  - not the PPIDs - to multiplex/demultiplex between the channels.
> 
> ----------
> 
>>> Q5:
>>> 
>>> Sometimes you say "SCTP" and sometimes "SCTP as defined in [RFC4960]".
>>> 
>>> I suggest to e.g. use the reference on the first occurrence, and then only use "SCTP".
>> 
>> I double checked:
>> SCTP as defined in [RFC4960] is used in
>> * In the Introduction (first occurrence) talking about SCTP / UDP
>> * In the Introduction to make sure which specifications are used: RFC 4960 and RFC 3758
> 
> In the 2nd paragraph of the Introduction, the text says:
> 
> 	"SCTP as specified in [RFC4960] with the partial reliability extension defined in [RFC3758]"
> 
> Could you remove "as specified in", and say?
> 
> 	"SCTP [RFC4960] with the partial reliability extension defined in [RFC3758]"
> 
> 
>> * In section 5 when used with RFC 2119 language.
> 
> I still think you could remove "as specified in", and say:
> 
> 	"SCTP [RFC4960] MUST be used in combination with the extension defined..."
> 
>> * In section 6 to make clear what relates to RFC 4960 and what to the NDATA extension.
>> 
>> All of these are intentional. Which one do you think is not necessary?
> 
> In section 6.6, I think you could remove "specified in", and say:
> 
> 	"The SCTP base protocol [RFC4960]..."
> 
> 
> I am not religious about these things, but again: in my opinion adding the reference means "as specified in", and makes the text easier to read :)
> 
> Regards,
> 
> Christer
> 
>