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

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 01 Oct 2007 12:09:57 +0200

On Sat, 29 Sep 2007 12:31:54 +0200, Martin Duerst <[email-masked]>  
wrote:
> At 18:58 07/09/29, Anne van Kesteren wrote:
> 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.

Ah, it seems RFC 3490 defines "internationalized domain name" which can  
replace "subdomain" above. "internationalized label" can replace "label".  
Not sure why I didn't use those from the start. However, for HTTP it seems  
the ToASCII variant should be required (not just allowed) as HTTP doesn't  
do Unicode.

Thanks. Also thanks to Frank Ellerman for pointing out the limitation of  
HTTP that has escaped me (and the rest of the people reviewing; I begin to  
wonder how many there are...).

-- 
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: Graham Klyne <[email-masked]>
Date: Tue, 09 Oct 2007 23:01:45 +0100

Anne van Kesteren wrote:
> 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!

My comments concern procedural matters - I make no judgement here about the
technical content of the proposal...

The registration would probably have to be provisional until such time as the
specification documents achieve some kind of standard-equivalent status (e.g.
W3C REC).  The status information is generally "provisional"  for headers in the
provisional registry.  If this is W3C WG activity for which there is general
consensus on the direction if not the final details, then I's suggest that
provisional registration should be progressed sooner rather than later
(including a note of the venue for ongoing development of the specification).

Three separate templates may be preferable - they will lead to separate entries
in the registry.

With reference to other discussion, in which you said: "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."

... I think it may help if:
(a) they had syntax definitions (or reference to some existing definition), and
(b) if it's not obvious, that there be some indication to where in the document
the headers are defined (section number of suchlike).

The standard of definition required will be higher for permanent registration.

#g
--

(Although I'm currently a designated reviewer for registrations, my comments
here are personal, and carry no formal import.)

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 10 Oct 2007 19:05:05 +0200

On Wed, 10 Oct 2007 00:01:45 +0200, Graham Klyne <[email-masked]>  
wrote:
> My comments concern procedural matters - I make no judgement here about  
> the technical content of the proposal...

Feel free to make comments on the technical content though!

> The registration would probably have to be provisional until such time  
> as the specification documents achieve some kind of standard-equivalent  
> status (e.g. W3C REC).  The status information is generally  
> "provisional"  for headers in the provisional registry.  If this is W3C  
> WG activity for which there is general consensus on the direction if not  
> the final details, then I's suggest that provisional registration should  
> be progressed sooner rather than later

Ok. I believe that I can do that tomorrow as the two review weeks have  
passed then. (I initially e-mailed it on Thu 27 Sep 2007.)

> Three separate templates may be preferable - they will lead to separate  
> entries in the registry.

Ok.

> With reference to other discussion, in which you said: "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."
>
> (b) if it's not obvious, that there be some indication to where in the  
> document the headers are defined (section number of suchlike).

http://dev.w3.org/2006/waf/access-control/ now includes the syntax  
definitions.

> The standard of definition required will be higher for permanent  

What are the requirements exactly?

Thanks a lot by the way!

---

From: Martin Duerst <[email-masked]>
Date: Fri, 12 Oct 2007 09:57:04 +0900

I have just realized that I haven't seen any security issues
for this proposal described or discussed, although I think
that there may be quite some security issues connected to
phishing, which should be carefully analysed and described.

The scenario I'm thinking about is that a phishing site,
rather than as currently having to get the passwords from
the user to its server, and then from there contact the
real server, may be able to list the real server in
an Access-Control header and therewith may be able to
correspond directly between client and real server,
potentially circumventing some security checks that
were in place until now (e.g. a plausability check
for the IP address of the user,...).

Regards,   Martin.s

>What are the requirements exactly?

#-#-#  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, 12 Oct 2007 11:41:24 +0200

> phishing, which should be carefully analysed and described.

Actually, security considerations are discussed in  
http://dev.w3.org/2006/waf/access-control/#security

> for the IP address of the user,...).

How would this work exactly? I don't understand the scenario.