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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 25 February 2014 10:49 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 298B01A00DC for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 02:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 RTdolZJtZcUw for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 02:49:02 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAAA1A02DF for <rtcweb@ietf.org>; Tue, 25 Feb 2014 02:49:01 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-f5-530c751cabfe
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 98.BF.04853.C157C035; Tue, 25 Feb 2014 11:49:00 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 11:49:00 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-07.txt - Some editorial comments on section 5
Thread-Index: Ac8nU+WsE4W5K/avTLyRu1AtQ1+x3gKnELsAAAk8zFA=
Date: Tue, 25 Feb 2014 10:48:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1B89F8@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D16D2A3@ESESSMB209.ericsson.se> <B112281E-4130-43C8-A051-7C4490BFF2C3@lurchi.franken.de>
In-Reply-To: <B112281E-4130-43C8-A051-7C4490BFF2C3@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja5MKU+wwc3TGhYXm5YwWqz9187u wOSxZMlPJo8NLTuYApiiuGxSUnMyy1KL9O0SuDJm79vPVrBJqeLx2rlsDYzTpLsYOTkkBEwk /r86xwphi0lcuLeerYuRi0NI4ASjxMVtH1ggnCWMEqsmbAOq4uBgE7CQ6P6nDdIgImAqcXD5 PBYQm1lAXeLO4nPsILawQIHEyrsf2EHKRQQKJZ7MDoQot5Jo+XCQGcRmEVCV+Hz8JBOIzSvg K3G7ZQlYXEigg1Hi1342EJtTwFXi7IntYHFGoNu+n1rDBLFKXOLWk/lMEDcLSCzZc54ZwhaV ePn4H9QvihIfX+1jhKjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwCg6uOW30Q7Gk3vsDzFKc7AoifNe Z60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4KC+WJ/XEnqboN11WMoK1UxQ3vGwpLMgV +qAacHebkeE8deeEOQ5f5fkne77abxppseC7T7xmgcO5PXNXmigo+4mZciWuqLn5+bCOUfhk EZ2vouWqrXNSjvtdPb5WIuKL5NGgxqu7jnyv7511evHEnxpnm3/nfeSdPvWV1bNHX++rBYq5 JkxXYinOSDTUYi4qTgQA7q2aynACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6HQWJE6pwpzqQwdiRFz3Sa2L4Aw
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: Tue, 25 Feb 2014 10:49:04 -0000

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 :)

----------

>> 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