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.
OK.
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
said.
Regards,
Art Barstow
---
