Re: LC nits on draft-ietf-websec-origin-04, Re: Fwd: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15

On Thu, Aug 25, 2011 at 11:40 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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?

That could well be important if the Origin header is used in other
protocols, such as CORS.  Would you recommend requiring the first or
the last instance?

Adam

Received on Friday, 26 August 2011 07:59:07 UTC