W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2005

VBWG official response to last call issue

From: MattO <matto@tellme.com>
Date: Thu, 10 Mar 2005 16:56:50 -0800
To: <connolly@w3.org>
Cc: <www-voice@w3.org>
Message-ID: <001901c525d5$359cd6e0$f59c9dd1@sea.tellme.com>

Dear Dan,

The Voice Browser Working Group (VBWG) has almost finished resolving the
issues raised during the last call review of the 28 July 2004 working draft
of VoiceXML 2.1 [1]. Our apologies that it has taken so long to respond.

Please indicate before March 14th, 2005 if you are satisfied with the VBWG's
resolutions, if you think there has been a misunderstanding, or if you wish
to register an objection. If you will be unable to respond before March
14th, please let me know. The Director will appreciate a response whether or
not you agree with the resolutions.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's response to your issues.

Thank you,

Matt Oshry
Chief Editor, VoiceXML 2.1

1) Process requirement to address last call issues

Per section 7.2 [2] of the 5th February 2004 Process Document, in order for
the VoiceXML 2.1 specification to advance to the next state (Candidate
Recommendation), the Working Group must "Formally address all issues raised
about the document since the previous step." 
Section 3.3.3 of the Process Document [3] sets expectations about what
constitutes a formal response:

  "In the context of this document, a group has formally addressed an issue 
  when it has sent a substantive response to the reviewer who raised the
  A substantive response is expected to include rationale for decisions 
  (e.g., a technical explanation, a pointer to charter scope, or a pointer 
  to a requirements document). The adequacy of a response is measured
  what a W3C reviewer would generally consider to be technically sound. 
  If a group believes that a reviewer's comments result from a
  the group SHOULD seek clarification before reaching a decision."

If you feel that the response is based on a misunderstanding of the original
issue, you are encouraged to restate and clarify the issue until there is
agreement about the issue, so that the Working Group may prepare its
substantive response.

If the response shows understanding of the original issue but does not
satisfy the reviewer, you may register a formal objection with the Working
Group that will be carried forward with the relevant deliverables. 

[1] http://www.w3.org/TR/2004/WD-voicexml21-20040728/
[2] http://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs
[3] http://www.w3.org/2004/02/Process-20040205/policies.html#formal-address

2) Issues you raised and responses
In http://lists.w3.org/Archives/Public/www-voice/2004JulSep/0024.html you
raised the following issue which was registered as change requests R85. Our
response is given inline:

"I'm surprised by...

'If the XML document specifies an <?access-control?> processing instruction,
access to the data is allowed based on the following
algorithm: ...'
  -- http://www.w3.org/TR/2004/WD-voicexml21-20040728/#sec-data-security

Last time a processing instruction was used in a W3C spec,
it was allowed only after considerable debate...

'The use of XML processing instructions in this specification should not be
taken as a precedent. The W3C does not anticipate recommending the use of
processing instructions in any future specification.'
  -- http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/

I suggest using a namespace-qualified element or attribute instead."

VBWG Response: Rejected

The VBWG evaluated a number of mechanisms that would enforce the security of
the data retrieved by the <data/> element including domain-based
restrictions, HTTP_REFERER, HTTP X-Header, XML security envelope, and
XML-ENC. The use of a processing instruction to enforce security of the data
is a lightweight mechanism that is straightforward for data providers and
platform vendors to understand and to implement. The VBWG considered the
specification and practical implementation limitations of processing
instructions and determined that these did not interfere with the intended
behavior of this mechanism.

Upon further review, the VBWG acknowledged that specifying how security
policy and resource sandboxing must be implemented went beyond the scope of
the working group and therefore chose not to mandate one particular
mechanism.  However, because resource sandboxing is an important principle
for VoiceXML interpreters in certain deployment contexts, and
interoperability among implementations should be encouraged, the group chose
to document this mechanism in an informative appendix.
Received on Friday, 11 March 2005 00:57:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:50 UTC