Re: [rtcweb] Call for comment on document split

[Igor Faynberg <[e-mail]>]

I share the concern, but yet no matter how humble the beginning was 
(e.g., SIP), things ended up with far too many specifications for anyone 
to grasp (e.g., ...SIP).  don't think we will get away with two 
specifications no matter what (but I am a registered pessimist).I

This is why I think that modularity thought through in the beginning 
(vs. ad-hoc additions) will ensure order in the future.  In addition, 
with the controlled break-up, we could know in advance whether (and how) 
change in one document would affect others.

It is true though that a short Informational describing the structure of 
the project and references to other documents would be helpful.

Igor

On 6/17/2011 1:21 AM, Dave CROCKER wrote:
>
>
> On 6/16/2011 9:30 PM, Ted Hardie wrote:
>> We'd like to have one document which describes the use cases.
>> We'd like to have one document that gives a system overview and 
>> outlines the
>> overall model.
>> We'd like to have one document that describes the privacy and 
>> security model.
>> We'd like to have one document that  describes the connectivity model 
>> (for NAT
>> traversal etc.).
>>
>> Later documents will be: signaling and negotiation methods, media 
>> transports,
>> datagram transport for non-media data, and one or more documents on 
>> media
>> processing and codecs.
>
>
> If someone wants to implement the simplest, core capability that is 
> useful within this context of service, how many docs are they going to 
> have to read?
>
> Which ones? How long before they will be written?
>
> For classic Web, I think it is still just 2.  Same for email.
>
> My question is motivated by the usual concern about barriers to 
> adoption that can stymie new services.
>
> d/