Subject: [Ietf-message-headers] HTTP header registration question

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 27 Sep 2007 13:53:40 +0200

Hi,

For a W3C specification "Enabling Read Access for Web Resources" the W3C  
WAF WG would like to register three HTTP headers: Access-Control,  
If-Method-Allowed, and Referer-Root (sic). Can I do that as attached or is  
it preferable to have three separate templates? Also, does the  
specification itself need to include anything that points back to the  
header registry, does it need to include the template, etc.? This did not  
became clear from reading RFC 	3864. Thanks for the information!

Kind regards,

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

_______________________________________________
Ietf-message-headers mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Sep 2007 00:37:35 +0200

Anne van Kesteren wrote:
  
> three HTTP headers: Access-Control, If-Method-Allowed, and 
> Referer-Root (sic). Can I do that as attached or is it 
> preferable to have three separate templates?

The given specification apparently only covers Access-Control
in an "Editor Draft".  Do you plan to add the other two later
in your draft ?

Maybe use three separate templates for the submission to IANA,
after the two weeks review here, less chances that something
goes wrong.  

For status: standard you have to wait until the specification
actually is a W3C standard.  You could use status: provisional
before, and later send an update to IANA when it's a standard.

> Also, does the specification itself need to include anything
> that points back to the header registry

No.

> does it need to include the template, etc.?

Of course it can, but that's more interesting for IETF RFCs:

IANA has a seat in the IESG, and can so check what they're
supposed to do before an IETF RFC is approved by the IESG.

BTW, your draft uses the ugly RFC 2616 "LWS" construct.
Maybe check with the 2616bis folks what they intend to do
with "LWS".  The 2616bis list is ietf-http-wg @ w3.org 

 Frank 

(I like your text/xml flame, Olivier hit me with it on the
 validator list ;-)

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 28 Sep 2007 11:58:54 +0200

> in an "Editor Draft".  Do you plan to add the other two later

The other two are both mentioned and it's defined what they are to  
contain. (They are request headers.) Maybe they should have syntax  
definitions as well just to make it complete.

> with "LWS".  The 2616bis list is ietf-http-wg @ w3.org

Once they publish something new, the specification can be revised I  
suppose.

> (I like your text/xml flame, Olivier hit me with it on the

More recently I've become of the opinion that a much more pragmatic  
solution would be to simply treat text/xml identical to application/xml as  
all browsers already do.

(I'll use "provisional" by the way, thanks.)

---

From: Martin Duerst <[email-masked]>
Date: Fri, 28 Sep 2007 19:52:45 +0900

Hello Anne,

I have some comments about the document at
http://dev.w3.org/2006/waf/access-control/Overview.html.

First, the title is not easy to understand for people who
aren't totally immersed in the Ajax business. Most Web
Resources are, almost by definition, read accessible.

I'd suggest a title like "Enabling Cross-Domain Read
Access for Web Resources".

I don't understand the sentence:
XML resources may include an <?access-control?> processing instruction within the XML Prolog to indicate in cases where the access control read policy applies from which domains they can be fetched. [XML]

First, the [XML] reference at the end looks totally out of context.
I know that some style guides say that references should be at the
end of a sentence, but this one is really unreadable. More important,
"in cases where" doesn't make sense.

The only way for me to understand this sentence is that the PI is
interpreted on the server side, before the document is (or actually
is not) sent, but experience with in-document information for server
side has been detrimental (nobody wants to take that performance hit),
so I highly advise against this. If the PI is supposed to apply
client-side, the the above sentence needs heavy rewriting.
Checking whether a document can be downloaded once it's already
downloaded is of course nonsense.

Another point that I don't understand is that the TO-ASCII algorithm
of RFC 3490 is mentioned several times, but the syntax only allows
RFC 3986 URIs or RFC 1034 labels. TO-ASCII only makes sense if you
start with an Unicode string, but RFC 3986 and RFC 1034 are pure
ASCII already. I think it would be good to allow IDNs, but you actually
have to say so.

Regards,    Martin.

>became clear from reading RFC  3864. Thanks for the information!

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 28 Sep 2007 13:15:22 +0200

> Access for Web Resources".

I think this would cause conflicts for people who want to use it in other  
contexts, but I personally agree with this. Maybe raise this on  
[email-masked] so other people can give input?

> XML resources may include an <?access-control?> processing instruction  
> within the XML Prolog to indicate in cases where the access control read  
> policy applies from which domains they can be fetched. [XML]
>>>>>
>

That should be replaced with "if" probably. And some punctation around it.  
I just made that change.

> downloaded is of course nonsense.

Good point. Replaced "they can be fetched" with "their content can be  
accessed".

> ASCII already. I think it would be good to allow IDNs, but you actually

I couldn't find definitions of "subdomain" and "label" elsewhere. And it  
seems that RFC 1034 doesn't actually restrict IDN usage, but I could be  
mistaken. If you have suggestions on how to improve this they are most  
welcome (on any list).

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Sep 2007 17:00:01 +0200

Anne van Kesteren wrote:

> I couldn't find definitions of "subdomain" and "label" elsewhere.

http://tools.ietf.org/html/rfc3696 (+ errata) is a nice intro, what
you want are "LDH" (letter-digit-hyphen) labels permitted in "host"
names, not labels containing arbitrary octets.

 Frank

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 29 Sep 2007 11:58:25 +0200

> names, not labels containing arbitrary octets.

I'm not sure that RFC helps as it's informational only. Would using  
ireg-name be appropriate? (We do not want to allow IP addresses for now.)

---

From: Martin Duerst <[email-masked]>
Date: Sat, 29 Sep 2007 19:31:54 +0900

>ireg-name be appropriate? (We do not want to allow IP addresses for now.)

ireg-name doesn't cut up the name into labels, because it is intended
(similar to reg-name in RFC 3986) to cover other registries than just
the DNS, if and when these would be used in new schemes.

I suggest that you look at the IDNA RFCs if you want to get a definition
of a label including non-ASCII characters. IDNA definitely deals with
individual labels, because that's where punicode and the xn-- prefix
and all that stuff happen.

Regards,    Martin.s

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 29 Sep 2007 12:49:17 +0200

Anne van Kesteren wrote:
 
> Would using ireg-name be appropriate?

If you'd want IRIs excluding domain-literals.

But your draft is about HTTP, isn't it ?
For HTTP you need URIs, or RFC 3986 reg-name,
not RFC 3987 ireg-name.  

An HTTP header uses Latin-1.  You could say
that clients are supposed to translate an
ireg-name into a reg-name as explained in
RFC 3987 3.1, that would be IDNA punycode,
not simply percent-encoded UTF-8.

 Frank