RE: VBWG official response to last call issue

Thank you for your response and I appreciate your consideration despite the
improper timing of my comments.  I agree with the disposition of items 1, 2,
6, and 7. The other items relate to the <data> element and although I
disagree with the approach I will agree with the disposition if you give the
last sentence of my item 3 ("At a minimum it should be optional ...")
additional consideration.  This suggestion was not addressed in your
response.

Rationale:
The implementation of the <data> element does not make sense for those in
the community that rely on an App Server based n-tier approach, in which
data access occurs prior to forming the VoiceXML document.  We are big
VoiceXML supporters and wish to implement 2.1 (and eventually be
"conforming" should the VoiceXML forum provide that service as they have
with 2.0) but spending a lot of time implementing a feature which we will
never use would be counterproductive.  I concede that this feature could be
of value to users in other environments, so its inclusion as an optional
feature allows its implementation in a standard way if desired, but allows
its exclusion in a conforming implementation.

Thanks again,
Ken

-----Original Message-----
From: MattO [mailto:matto@tellme.com] 
Sent: Monday, February 28, 2005 12:42 PM
To: Waln, Ken
Cc: www-voice@w3.org
Subject: VBWG official response to last call issue


Dear Ken,

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]. Although your feedback was based on the First Working
Draft, the specification did not change radically, and we have evaluated
your requests against the LCWD [1]. Our apologies that it has taken so long
to respond.

Please indicate before March 7th, 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 7th,
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
issue. 
  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
against 
  what a W3C reviewer would generally consider to be technically sound. 
  If a group believes that a reviewer's comments result from a
misunderstanding, 
  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/2004AprJun/0057.html you
raised the following issue which was registered as change request R104 Our
response is given inline:

"I'm a little behind on my reading, but I figure for a working draft
comments are still useful.

1)	In Section 2, I agree with the comments on this list that 'srcexpr'
is a better attribute name, both for consistency and in case someday it is
desired to use an expression to be the content of the element rather than
the source. I would not advlocate adding the "expr" attribute in addition as
I'd rather see a cleaner way of handling dynamic grammars than using script
to put the entire grammar into a variable.  How about allowing <value> in an
inline XML grammar (although I realize this is more of an SRGS problem at
that point or at least there would be an interaction)?"

VBWG Response: Accepted/Deferred

The working group has accepted the feedback from you and others in the
community that "srcexpr" is a more appropriate name for the dynamically
evaluated attribute. This feedback was incorporated into the Last Call
Working Draft [1]. The working group has, however, opted to defer further
discussion of the dynamic generation of grammars to a future version of
VoiceXML.

"2)	In section 3, I do not see the value of this construct.  The example
shows it being used to pass a parameter to the script being included, but
since the script functions by definition accept parameters, why pass in a
parameter to load different scripts? In general this smacks of
self-modifying code a little bit.  If you are going to call functions in a
script file, the function definitions should be included statically. Maybe
another example could convince me. The best example I can come up with would
be a set of language specific includes, but I think that can be handled
better in other ways as well."

VBWG Response: Accepted

The srcexpr attribute on script achieves parity with other tags including
audio, goto, submit, subdialog, and choice (and now grammar and data) that
support the dynamic resolution of the URI that they are to fetch. For all
these tags, a developer could use the dynamic URI attribute to her advantage
to dynamically configure the host from which the resource is fetched - for
example, a development server during the development phase and a production
server during the deployment phase. The script srcexpr example has been
updated in the forthcoming draft to illustrate this use case.

"3)	I agree with comments that the data element seems to encourage
designing far too much of an application as client-side script instead of
using an n-tier model.  I would prefer it not be added. At a minimum it
should be optional as it should not be encouraged as an appropriate design
pattern."

VBWG Response: Rejected

The data element allows a clean separation of dynamic data from static
presentation markup. A benefit of this approach is the ability for multiple
applications targeted at one or more modes of interaction to consume data
produced via a well-defined URL API. Another benefit is the ability for
browsers to cache the presentation markup. Irrespective of this position,
the VoiceXML 2.1 specification states the following:

'If an implementation does not support DOM, the name attribute must not be
set, 
and any retrieved content must be ignored by the interpreter.'

This implies that the data element can also be used purely for its
non-transitional "send" capabilities (HTTP GET or POST).

"4)	If the data element is needed, I think the VBWG should avoid
defining its own data access protocol like this.  The current design
encourages too much interdependency between the VoiceXML document and the
XML service.  Defining a new protocol like this opens up lots of work to be
done in the areas of versioning, security, etc.  I recommend replacing it
with a mechanism to call SOAP web service (if it is left in at all) with
clearly specified parameters and return values."

VBWG Response: Rejected

The purpose of the data security model is to assert that browsers should
support content sandboxing. 
In particular, because the data element is effectively a "file open" command

for arbitrary XML content at any URL accessible to the browser, it
represents a potential security risk.  

Without this security model, a browser running inside a corporate firewall
would 
permit an application running on that browser to access internal corporate
documents 
and to potentially submit that data back to another web server.  

The working group evaluated a number of solutions that would enable data
providers to secure their data against unauthorized access. The working
group decided to keep the description of the access-control PI in the spec
to inform browser implementors about one possible mechanism for enforcing
security on the data.

"5)	The access control on the data element does not seem to be very
secure.  It seems to assume the browser is a trusted entity (since the
credentials are fetched along with any sensitive data, the browser already
has  the sensitive data).  I suppose it is trying to protect against
malicious VoiceXML in a hosted environment, but that is only one deployment
option for a VoiceXML browser. I think any security needs to be removed from
the XML and moved into lower levels of the protocol.  Perhaps supplying
credentials for a web server level validation is enough."

VBWG Response: Rejected

The security model is not designed to enforce a trust relationship between
the server and the browser.  
The server-to-browser trust relationship should be enforced with existing
technologies such as SSL certificates, 
XML-SIG or XML-ENC, trusted VPNs, or exclusive network access.

While the hosted environment is only one deployment option, 
Web standards should be designed to support the most conservative security
environment.  
In particular, malicious VoiceXML content should not have arbitrary access
to any 
network-accessible XML resource.  

Web servers supplying credentials is insufficient because the trust
relationship 
is from application-to-application, not browser-to-server.  
The browser is the agent entrusted to preserve application-to-application
sandboxing.  

The working group evaluated a number of solutions that would enable data
providers to secure their data against unauthorized access. The working
group decided to keep the description of the access-control PI in the spec
to inform browser implementors about one possible mechanism for enforcing
security on the data.

6)	Section 9 - "consultation" implies that a dialog occurs on the
second call leg.  If we want to allow that feature, I would also add a
<connect> tag to complete the transfer.  I think "monitored" or
"monitoredblind" might describe it better. An alternative would be to drop
this proposal and instead add an "answermode" attribute with values
"immediate", "startvoice", "endvoice" etc.  There are a lot of variations on
single-line transfers and deciding when a call is complete. Far-end answer
is not well defined in general, depending on the protocol - our platform
currently offer these choices as configuration parameters but sometimes it
is necessary to  set on a call by call basis (e.g. an international number
might behave differently).

VBWG Response: Deferred

Using the type attribute, platform vendors are free to add additional
platform-specific transfer types.

7)	Could add more event values for completion: "SIT" (special
information tone), "answeringmachine", etc. Are these implicitly allowed as
platform specific return values or does it need to be explicit?

VBWG Response: Deferred

Standardization of these return values is beyond the scope of VoiceXML 2.1.

Received on Tuesday, 1 March 2005 00:36:24 UTC