Re: ACTION-96: Origin removal

On Jan 19, 2009, at 2:45 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Jan 19, 2009, at 7:19 AM, Simon Pieters wrote:
>>>
>>> On Mon, 19 Jan 2009 15:39:38 +0100, Sam Ruby <rubys@us.ibm.com>  
>>> wrote:
>>>
>>>> The issue we are trying to resolve is ISSUE-63[1]: "Origin  
>>>> header: in
>>>> scope? required for this release?"
>>>>
>>>> It sounds like either way the intent is to delegate this to the  
>>>> IETF.  Both
>>>> alternatives provide the same answers for the questions posed by  
>>>> the issue.
>>>>
>>>> Given that there is precedent for "commenting out" areas of the  
>>>> spec which
>>>> do not enjoy consensus, and that I have recently been informed that
>>>> sections can be removed from the HTMLWG draft and be retained in  
>>>> the WHATWG
>>>> draft, would a decision to remove the description of the Origin  
>>>> header from
>>>> the HTMLWG draft without prejudice (i.e. the door is left open  
>>>> for this to
>>>> be reopened in the future) be something everybody could live with?
>>>
>>> I don't see any reason to rush with removing it from the draft  
>>> until it's in another spec. Opera is interested in implementing it  
>>> so we'd rather have it specced somewhere than not specced.
>> Apple's position is the same. We are looking to implement it and  
>> would prefer to have some spec (even if it is not in its final  
>> location) than no spec.
>
> Somehow we are talking past one another, and I don't understand  
> where the confusion is.  I'm sure we all have a vested interest in  
> HTTPbis too, but there isn't any plans (I hope!) to duplicate that  
> effort here too, is there?  Heck, I'm kinda looking forward to the  
> inauguration tomorrow, let's make sure it happens by including it  
> too?  (caption for the humor impaired: that's a *JOKE*).

I don't think there is confusion, just disagreement. You have said  
that, since the work is starting on the process of moving to IETF, it  
should be removed from the HTML5 spec immediately. Simon and I have  
expressed the opinion that we'd rather see it temporarily in the HTML  
spec until the IETF work has progressed far enough. This has at least  
three benefits:

1) Vendors who are in the process of implementing the feature have a  
reference for the (hopefully brief) transitional period.

2) Even once the IETF draft is well down the path to progress, it is  
likely that the HTML5 spec will need to have some content related to  
Origin. The originating security context is a concept that cannot be  
fully defined at the HTTP level so the HTML5 spec will have to connect  
the dots. Thus, the likely final disposition for the Origin section is  
that it will be rewritten to normatively reference the IETF spec  
rather than outright removal. So let's correct it to the proper final  
text once we are ready.

3) In the very unlikely case that the IETF process fails, we still  
have a spec for the feature (even if possibly a suboptimal place)  
rather than an unspecified extension that has to be mutually reverse- 
engineered.

> If the right place to do the Origin header is here, let's make that  
> decision.  If the right place to do the Origin header is in the  
> IETF, lets not attempt to do an end-run around that process.  I have  
> some experience with the IETF, they are a nice and friendly bunch of  
> people.  Larry has considerably more experience than I, and has  
> offered to help.

In my opinion, either the HTML WG or the IETF is an appropriate place,  
with the IETF being a somewhat better place for anything directly  
related to the HTTP protocol itself. However, it is almost certain  
there will have to be some reference to a this spec in HTML5 as well  
as in the Cross-Origin Resource Sharing spec (formerly known as Access- 
Control).

Thus, starting the specification in the HTML WG and then migrating as  
much of it as possible smoothly to the IETF is not an "end-run" but  
rather a successful working of the standards process.

We have had examples of this before. HTML5 used to specify  
XMLHttpRequest, and also many details of how JavaScript DOM bindings  
work. These were things that were better specified in separate  
standards, and in a different Working Group. The former has now  
completely migrated to the Web Apps WG, and was removed entirely from  
the HTML5 spec. It has evolved in ways that are not controlled by the  
HTML5 Editor, and some of which he may well disagree with. Similarly,  
the HTML5 spec is converting to defining DOM interfaces in terms of  
the Web IDL spec, thus removing many JS-specific details from the  
spec. Both of these are cases where the gradual transition model  
worked very well, so I am not going to be convinced by arguments that  
this model is bad unless they have strong supporting evidence.

On the flip side, we have had proposals to separate out other parts of  
the HTML5 spec where there was insistence on removing the relevant  
part of the HTML5 spec right away, with the separate spec to come  
later. These requests have been refused, and I think that was wise.  
For example, it has been proposed that the <canvas> element, or at  
least its graphics API, should be put into a separate specification,  
and various individuals and groups proposed to start the work. But so  
far nothing has happened on this front, so I am glad we did not remove  
the feature from the spec. That would have led to no spec for the  
feature at all, a far worse outcome than the spec being in a  
suboptimal location.

> And both of us feel that pursing it there and keeping it here "just  
> in case" is a horribly bad idea.

Could you state some concrete benefits to removing the Origin-related  
text from the HTML5 draft immediately, or concrete harms of not doing  
so? I have stated some concrete benefits above for retaining it during  
the brief transition period.

> And it looks like work is progressing:
>
>  http://webblaze.cs.berkeley.edu/2009/origin/origin.txt
>
> If people insist, I can check with the IETF/W3C Liaison's, but I am  
> quite confident that they will agree.
>
>>> Also, having it included in the WHATWG version but not in the W3C  
>>> version could only lead to confusion, so I don't see that as  
>>> desirable either.
>> Likewise.
>
> That probably deserves a separate email with a separate subject  
> line, but we do have a real issue that needs to be addressed.
>
> Section 1.5.4 needs to be removed or replaced.  I'm paraphrasing  
> here, but Maciej's input is that it is unnecessary, Lachy's and  
> Chris's input is that this section doesn't set out what it is  
> intended to do.  Any of you three are welcome to correct me if I got  
> this wrong.  Ian's response:
>
>    if the HTMLWG has a strong desire to remove this section, I
>    can certainly remove it from the HTMLWG draft
>
> At this point I feel confident in saying that section 1.5.4 does not  
> enjoy consensus.

Ian also agreed to reword or alter the text. Hopefully with further  
feedback we can come to a widely agreeable text. That being said,  
differences between the two versions of the spec as to normative  
technical content would be *much worse* than differences in  
informative introductory material.

> As described above, Origin either belongs in the IETF or W3C: pick  
> one.

I reject this dichotomy. There are many times where any of several  
organizations could be a reasonable place to specify something. The  
goal for all of us should be to get the best technical outcome in a  
smooth way, not to fight over turf.

Regards,
Maciej

Received on Monday, 19 January 2009 23:51:04 UTC