W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2004

Re: FW: VoiceXML 2.1 and PI issue

From: Brad Porter <brad@tellme.com>
Date: Tue, 12 Oct 2004 11:23:37 -0700
Message-ID: <416C2129.3070001@tellme.com>
To: Dan Connolly <connolly@w3.org>
Cc: Dave Raggett <dsr@w3.org>, MattO <matto@tellme.com>, 'Michael Bodell' <bodell@tellme.com>, www-voice@w3.org
Reforwarding to www-voice.  I'm doing my best to write up the 
explanation and look forward to your full review or a personal discussion.

Thank you!
Brad



Dan Connolly wrote:

>On Tue, 2004-10-12 at 12:34, Dave Raggett wrote:
>[...]
>  
>
>>I am interested to see what comments Dan Connolly may have on this,
>>    
>>
>
>I haven't seen anything that says why a PI should be used
>rather than an element or attribute.
>
>(but I've just been skimming; I prefer to discuss technical
>matters in public fora; in this case, www-voice).
>
>
>  
>


attached mail follows:


Hi Dave and Dan,

I'll give a brief write-up of the data security model and the use of the 
PI.  With respect to various alternatives and how to proceed, I 
personally find phone discussions to be more conducive to brainstorming 
possible resolutions. 

The <data/> tag allows for fetching and inspection of the contents of 
any XML document.  Being effectively a "file open" command on any XML, 
proper sandboxing needs to be enforced.  A VoiceXML application, like an 
HTML application or an untrusted Java applet should not have 
unrestricted "file open" access. 

There are a variety of sandboxing solutions to this: 

   1. Most common is to allow "file open" access only to XML files that
      reside in the same domain as the requesting document.  The browser
      must be trusted to perform the DNS/IP restrictions appropriately.

   2. Put the burden on the web server to validate HTTP_REFERER headers
      and not serve that XML content back to untrusted sites.  The
      browser must be trusted to provide proper HTTP_REFERER information. 

   3. Encode access rights as an X-Header of HTTP and have the browser
      enforce access only to the allowed domains.

   4. Encode access rights as a PI in the XML document and have the
      browser enforce access to that XML content only to the allowed
      domains.

   5. Encode access rights as a parent envelope around the enclosed XML
      data and have the browser enforce access to that XML content only
      to the allowed domains.

The VoiceXML 2.1 specification allows platforms to use any of these as 
they feel appropriate.  The PI is the commonly implemented technique 
today.   The PI allows for sandboxing while supporting the ability to 
share XML documents beyond just the same domain. 

To those not versed in internal discussions on the future of XML, the 
Processing Instruction appears the most appropriate place in an XML 
document for instructions to the processor about the security 
restrictions.  Enveloping the content in an XML security envelope may 
also prove valuable, but since there isn't a known security enveloping 
standard today and there isn't group bandwidth to create one, the group 
has not undertaken the effort to create one.

If this isn't sufficient explanation for 2.1, we would still like a call 
to be able to better articulate to our working group the perspectives on 
why the PI is including in XML 1.1 but out-of-favor for future 
standards, and also be able to report on any related efforts to define a 
secure envelope standard to support content sandboxing.

Thanks,
Brad



MattO wrote:

>-----Original Message-----
>From: Dave Raggett [mailto:dsr@w3.org] 
>Sent: Monday, October 11, 2004 10:54 AM
>To: matto@tellme.com
>Cc: jim@larson-tech.com; scott.mcglashan@hp.com
>Subject: VoiceXML 2.1 and PI issue
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Matt,
>
>I just had a quick chat with Dan Connolly about the PI issue. Dan and I
>would like to see either a justification of why a special PI (XML processing
>instruction) is needed for VoiceXML 2.1, or the adoption of of an
>alternative solution such as a new attribute or element. If this is the only
>issue before moving the CR, then things should be pretty quick.
>
>To move to CR, we will need an updated spec plus the implementation 
>report plan. We then have to schedule a meeting with W3C Management 
>to review the request to advance to CR. Would you be willing to attend the
>meeting to deal with any questions that come up? We will be asked to review
>the disposition of comments and it is important that all comments have been
>dealt with. Commentators need to have confirmed that their issues have been
>addressed even if the result isn't always what they wanted. This applies to
>Dan too.
>
>Regards,
>- -- 
> Dave Raggett <dsr@w3.org>  W3C lead for voice and multimodal.
>http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFBasjab3AdEmxAsUsRAiWBAKCWjuAIwdelaVXttv2/3RPV/BxT9QCbBKHa
>UdrFLm+nLn3M3o1adHMJFZU=
>=A/qU
>-----END PGP SIGNATURE-----
>
>
>  
>
Received on Tuesday, 12 October 2004 18:39:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:00 GMT