Re: [rtcweb] Call for comment on document split

[Kundan Singh <[e-mail]>]

From a software developer's point of view, I feel the following will be most productive:

1. One or two complete document that are necessary and sufficient to implement RTC-Web/WebRTC. 
Everything else that is not covered by this document must be an existing popular standard with existing popular libraries/APIs.


2. Create the documents based on actual implementation, rather than the reverse. 

Perhaps include pseudo-code in Internet drafts to avoid ambiguity.

If interaction with external standards are needed, pseudo-code could show how it is done based on interfaces of existing popular libraries/APIs for that external standard.

Having to read and implement many documents to do one thing  is a recipe for disaster, e.g., (non) interoperability matrix, frustration, ...

If we manage to create tens of documents that cover all corner cases, all features, all authors, all existing extensions, but scare away actual developers, then we haven't learned from our mistakes...

Just a thought.

--
Kundan Singh



----- Original Message -----
> From: Igor Faynberg <[e-mail]>
> To: [e-mail]
> Cc: 
> Sent: Friday, June 17, 2011 10:24 AM
> Subject: Re: [rtcweb] Call for comment on document split
> 
> 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/
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>