Subject: [rtcweb] Consistent WebRTC Descriptions in WebRTC RFC Abstracts

From: Barry Dingle <[email-masked]>
Date: Tue, 13 Jan 2015 16:27:29 +1100

The recently proposed Standards *WebRTC Data Channel RFC* and *WebRTC Data
Channel Establishment Protocol RFC* have a consistent single sentence
describing what WebRTC is in their Abstracts. They both say:

The WebRTC framework specifies protocol support for direct interactive
rich communication using audio,
video, and data between two peers' web-browsers.

I notice that several other WebRTC proposed RFCs have single sentence
WebRTC descriptions in their Abstract *but they are differen*t e.g. WebRTC
Overview RFC; Media Transport + Use of RTP; Security; Security Architecture

All the others have *NO WebRTC description*.

*Do we need a consistent single sentence in the Abstract of all WebRTC
RFCs?*

If so, what should the wording be?

Should the wording be in the Abstract of ALL WebRTC RFCs?

Barry Dingle

Fellow of University of Melbourne, Australia

On Fri, Jan 9, 2015 at 1:38 AM, The IESG <[email-masked]> wrote:

> The IESG has approved the following document:
> - 'WebRTC Data Channels'
>   (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard
>
> This document is the product of the Real-Time Communication in
> WEB-browsers Working Group.
>
> The IESG contact persons are Richard Barnes and Alissa Cooper.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/
>
>
>
>
> Technical Summary:
>
> This document specifies the nonmedia data transport aspects of the WebRTC
> framework. It provides an architectural overview of how the Stream Control
> Transmission
> Protocol (SCTP) is used in the WebRTC context as a generic transport
> service.
>
> Working Group Summary:
>
> There was early discussion of the stacking order, but there has been no
> significant
> controversy since that was fixed. There have been a number of discussion
> on how to manage
> particular aspects of the larger context (e.g. WebRTClevel congestion
> control, since SCTP
> manages congestion control at the association level) and this has played a
> part in those, but
> not in any way that mde it the focus of controversy.
>
> Document Quality:
>
> There are implmentations of previous versions of this document, and we
> expect updates to
> them to the final version. Vendor support seems solid. This document did
> not require
> expert review of the types noted.
>
> Personnel:
>
> The document shepherd is Ted Hardie; the responsible Area Director is
> Richard Barnes.
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 13 Jan 2015 08:00:57 +0100

A good timely observation.
Similar problem in a couple of other protocol environments have caused 
me unnecessary waste of time. I have picked up one such definition from 
a central source document, while others have been used to other 
definitions, causing long discussions about which one to use. Time that 
would have been better spent on the technical content.

So, I recommend harmonization, and use of the same term in the 
documents. That will save time in the future.

Gunnar Hellström
Omnitor

------------------------------------------------------------------------------------

Barry Dingle skrev den 2015-01-13 06:27:
>
> The recently proposed Standards /WebRTC Data Channel RFC/ and /WebRTC 
> Data Channel Establishment Protocol RFC/ have a consistent single 
> sentence describing what WebRTC is in their Abstracts. They both say:
> The WebRTC framework specifies protocol support for direct interactive rich communication using audio,
> WebRTC descriptions in their Abstract _but they are differen_t e.g. 
> WebRTC Overview RFC; Media Transport + Use of RTP; Security; Security 
> Architecture
>
> All the others have _NO WebRTC description_.
>
> _Do we need a consistent single sentence in the Abstract of all WebRTC 
> RFCs?_
>
> On Fri, Jan 9, 2015 at 1:38 AM, The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     framework. It provides an architectural overview of how the Stream
>     Control Transmission
>     Protocol (SCTP) is used in the WebRTC context as a generic
>     transport service.
>
>     Working Group Summary:
>
>     There was early discussion of the stacking order, but there has
>     been no significant
>     controversy since that was fixed. There have been a number of
>     discussion on how to manage
>     particular aspects of the larger context (e.g. WebRTClevel
>     congestion control, since SCTP
>     manages congestion control at the association level) and this has
>     played a part in those, but
>     There are implmentations of previous versions of this document,
>     and we expect updates to
>     them to the final version. Vendor support seems solid. This
>     document did not require
>     The document shepherd is Ted Hardie; the responsible Area Director
>     is Richard Barnes.
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288