W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: [AC] other issues

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 7 Aug 2006 10:28:24 -0400
Message-Id: <38052A4C-E0F6-454A-B6D2-67FD822EECB9@nokia.com>
Cc: public-appformats@w3.org
To: ext Anne van Kesteren <annevk@opera.com>

Hi Anne,

On Aug 4, 2006, at 4:07 PM, ext Anne van Kesteren wrote:

> * Do we need to say anything on when UAs have to check the access  
> control mechanisms (HTTP header and XML processing instruction)?  
> For example, for a typical safe request (same-domain) would the UA  
> still verify with the access control mechanism that it can indeed  
> request the resource?

It seems like the spec should be silent on the "when to check"  
question (e.g for optimizations) but I don't feel strongly here and  
would like to hear other opinions.

> * Error handling. This consists of two separate issues.
> - Currently it is not defined what happens when someone uses a  
> pseudo-attribute not defined to be valid in the processing  
> instruction.

Seems like ignoring unrecognized pseudo-attributes would provide some  
future proofing (e.g. if a new pseudo-attribute is added in a  
subsequent version of the spec an "old" processor would still process  
its supported set of pseudo-attributes).

> - Currently it is not defined what happens when someone uses  
> invalid syntax inside one of the psuedo-attributes. We could either  
> directly put the resource in default access state or even access  
> denied state (to be sure) or just say the particular attribute is  
> to be ignored or the whole processing instruction is to be ignored.  
> One reason for putting the resource into the access denied state is  
> that I might want to ban domain A explicitly, but typed AA.

Presumably syntax errors such as this could be found before  
deployment. Thus to facilitate future proofing, it seems like  
ignoring the invalid value would be best (for example in case the  
syntax and/or semantics of a pseudo-attribute's value changes in a  
subsequent version of the spec).

> * For ease of authoring I think we should allow whitespace at the  
> start and end of the pseudo-attribute values as well.


> For the HTTP header we should not allow new lines there by the way,  
> but I assume that's clear...

Seems like conformance with RFC2616 would dictate what is said or not  


Art Barstow
Received on Monday, 7 August 2006 14:29:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC