- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 1 Apr 2013 13:24:47 -0700
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
On 1 April 2013 12:58, Randell Jesup <randell-ietf@jesup.org> wrote: > I don't know that removing 'max' helps here or hurts. Also, sorta-acronyms > like rtx are obvious to networking people; not so much to JS app developers. > I see only minimal advantage here to brevity. Count might be an improvement > on Num. Yeah, 'rtx' is probably too aggressively short. >> 'preset' doesn't sound right, maybe you could have 'inlineOpen' >> (default: true) to convey what is really happening here. > > > externallyNegotiated (default: false)? Not great, but "inlineOpen" will be > pretty meaningless to most developers who probably could care less if > there's an in-band open message for a channel (whether externally negotiated > or not) - or even know there's an in-band message. Then again, 99% of > developers don't need to care about this anyways. Yes, I didn't get a warm fuzzy from my suggested name either, but you are right about the impact being relatively low. Other ideas: "announceSettings" (default: true), "prearranged" (default: false), "thisIsNotATest" (default: "yesItIs"). > Unsigned short has been the type in the protocol fields since the first > draft (like a year). Perhaps a silly optimization, though I think if you > want partial reliability with >64K resends, or >64 seconds of retry that you > *really* want reliable transmission (perhaps unordered, but reliable). If > we want to change it, now's the time, since we're breaking binary > compatibility in FF with my landing today anyways. Well, you'll be accepting a JS number, so it doesn't really matter what the spec says.
Received on Monday, 1 April 2013 20:25:14 UTC