Re: [rtcweb] Call for comment on document split

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As a software developer myself, I believe that this approach is wrong.  The goal
of the IETF is to make the Internet work better, not to make the developers life
better.

Implementers should contribute running code to help the IETF make the Internet
work better, by having multiple implementations of the same protocol and find
any interoperability, security and extensibility issue as soon as possible.
Documenting one implementation as protocol creates monoculture, and everybody
should know better by now than encouraging this.

And BTW, I do not think that "scaring away" developers is a bad thing.

On 06/17/2011 12:47 PM, Kundan Singh wrote:
> 
> 
>>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 <igor.faynberg@alcatel-lucent.com>
>> To: rtcweb@ietf.org
>> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk37tP8ACgkQ9RoMZyVa61cgwgCeNPkF5g0Q99L6DTlKawxUv8s3
1vYAn1sUE+Q+LSX5JbHAMfU0jMi0hIO3
=snqx
-----END PGP SIGNATURE-----