- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 26 Aug 2011 08:40:50 +0200
- To: Adam Barth <w3c@adambarth.com>
- CC: Peter Saint-Andre <stpeter@stpeter.im>, public-web-security <public-web-security@w3.org>, Thomas Roessler <tlr@w3.org>
On 2011-08-26 04:35, Adam Barth wrote: > On Thu, Aug 25, 2011 at 8:35 AM, Julian Reschke<julian.reschke@gmx.de> wrote: >> On 2011-08-24 19:43, Peter Saint-Andre wrote: >>> >>> Thanks, Thomas. Just a quick note that this is in IETF Last Call now, >>> ending on 2011-09-06. This is your last chance for feedback. >>> ... >> >> Below a few late comments.. >> >> 6. Serializing Origins >> >> - It really really seems that the two algorithms need to be swapped (the >> first one converts to ASCII, but the second does not). > > I'm not sure I understand. Doesn't the IDNA ToUnicode algorithm > output Unicode (used in the first algorithm)? Why do you believe the > second algorithm does not produce ASCII (recall that "the host part of > the origin triple" is defined to use the idna-canonicalized host > name). You are right. Sorry. >> - Also, I'd prefer a declarative definition. >> >> 7. The HTTP Origin header >> >> - header *field* > > Fixed. > >> - the syntax doesn't allow multiple header fields, and the prose says >> clients MUST NOT generate them; what is the recipient supposed to do when it >> get's multiple instances anyway? Is the default approach (ignoring them all) >> good enough? Do we need to warn recipients so that they check? > > The document does not impose any conformance requirements on > recipients of the Origin header field. Indeed. Should it? I mean, it wouldn't be good if some recipients took the first instance, and others took the last, right? > ... Best regards, Julian
Received on Friday, 26 August 2011 06:41:27 UTC