Re: FW: VoiceXML 2.1 and PI issue

Oops, let me clarify.  I think the write up below is my best attept to 
date to explain the choice of the PI.  The PI seems the most appropriate 
feature of XML for our use case, so some understanding of why it is best 
not to use the PI would be valuable so I can articulate that to the 
working group.  I look forward to your full review. 

Also, is there an XML 1.1 deprecated or "not recommended" features 
list?  This would help us as we create new XML specifications to make 
sure we aren't using features that are considered out-of-style. 

Brad

Brad Porter wrote:

> 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).
>>
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: FW: VoiceXML 2.1 and PI issue
> From:
> Brad Porter <brad@tellme.com>
> Date:
> Mon, 11 Oct 2004 12:12:19 -0700
> To:
> MattO <matto@tellme.com>
>
> To:
> MattO <matto@tellme.com>
> CC:
> dsr@w3.org, 'Michael Bodell' <bodell@tellme.com>, connolly@w3.org
>
>
> 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-----
>>
>>
>>  
>>