Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

[Adam Roach <[e-mail]>]

On 12/18/15 13:54, Bernard Aboba wrote:
> The DTMF language will aligned with the W3C specification and 
> clarified that A-D are not supported (as they will not be supported in 
> the JavaScript).
>
> [BA] I am not sure what "aligning the text" means. The W3C WEBRTC 
> specification does not dictate that A-D be supported - it only 
> describes how implementations should behave for supported tones, 
> referencing the Audio document for DTMF requirements. If a tone is 
> unsupported it is considered "unrecognized" in the API.

I'm a little confused about where this leaves the state of play. You're 
proposing the the W3C spec leave it open as to whether sending an "A" 
through the API will work or throw an exception? That seems to be 
begging for unnecessary pain. And, in this case, it's pushing the pain 
down to the authors, who will likely (accidentally) pass that along to 
users. It goes pretty well against the W3 priority of constituencies: 
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies


> It is the Audio document that provides the requirements, and as long 
> as A-D aren't a MUST NOT, the API needs to allow implementations to 
> send A-D if they choose to do so.

Does this rationale apply to RFC5244 tones also? If so, we have a bit 
more work to do on the W3C API.

If the rationale does not apply to RFC5244 tones, I'd be curious to hear 
about the criteria you're using to draw this line.

To be clear, what we need is to have a list of events that are mandatory 
to implement in both W3C and IETF, and none that are optional (at least, 
with the current, exception-throwing API). And we need this list to be 
identical. I personally have absolutely zero interest in whether A-D are 
included, but we need the list to be the same.

/a