W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03

From: Sam Ruby <rubys@intertwingly.net>
Date: Sat, 22 Aug 2009 06:21:37 -0400
Message-ID: <4A8FC6B1.9060604@intertwingly.net>
To: Maciej Stachowiak <mjs@apple.com>
CC: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>, Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org WG" <public-html@w3.org>
Maciej Stachowiak wrote:
> 
> Hi Sam,
> 
> On Aug 21, 2009, at 6:29 PM, Sam Ruby wrote:
> 
>> Ian Hickson wrote:
>>> On Fri, 21 Aug 2009, Maciej Stachowiak wrote:
>>>> That being said, it seems like we need to make a WG decision to go 
>>>> one way or the other, and time is of the essence, since it will take 
>>>> some time to draft an appropriate document once we have decided what 
>>>> to do.
>>> I can write a draft to do this in a few hours, if we decide it's the 
>>> thing to do. It doesn't seem like the thing to do, though.
>>
>> Given the following list:
>>
>> http://lists.w3.org/Archives/Public/public-html/2009Aug/1063.html
>>
>> ... at this point, I'm assuming that issues 14, 30, 35 are ones that 
>> you are intending to resolve by Last Call, and of the rest, issue 41 
>> is the only one that has a significant potential for taking 
>> significant time to integrate should it attract a proposal that we 
>> decide is the thing to do.
> 
> I'm not sure how you drew that assumption from my incomplete list of 
> issue statuses. That list was my personal attempt to classify the 
> current state of issues, based on my best guess. I did not directly 
> consult Ian or anyone else in making that list. Furthermore, the 
> classification was incomplete - I listed a number of issues where I 
> hadn't yet assessed the status.

I did not draw that assumption from your list, I took a look at your 
list, made my own assessment, and asked Ian for feedback on that 
assessment.  Ian did respond:

http://lists.w3.org/Archives/Public/public-html/2009Aug/1132.html

I am interpreting Ian's response as a positive affirmation that other 
than issue 41, all of the remaining could be incorporated into the draft 
in a matter of days should the Working Group decide that a change was 
needed.

> This issue, ISSUE-53, is one that I specifically listed as not yet 
> reviewed (at the time), in the email you cited. And Ian specifically 
> indicated his willingness to take either proposed route to resolve this 
> issue, while also stating his prefered outcome. So I'm not sure why you 
> listed those other issues as the only ones Ian is "intending to resolve 
> by Last Call".

My understanding is than Ian considers, for example, issue 8 as closed, 
though the Working Group does not.  In operational terms, that means 
that he plans no further action on that item until or unless he gets 
either new information or direction from the working group.  By 
contrast, the three I listed I was assuming that Ian was planning on 
working on, and indeed he confirmed that.

Issue 53, the subject of this email, is an example of an issue that Ian 
identified as only taking a few hours.  Again, I was simply asking Ian 
if the bulk of the remaining issues could also be done in an unspecified 
"few" hours each; and I am treating Ian's response as the closest I am 
likely to get to a "yes" from him at this time.

> To be more specific about my request to the Chairs, we need to decide at 
> least some of the following questions soon:
> 
> 1) Should HTML5's update to the text/html and application/xhtml+xml MIME 
> types be:
>     A) Inline in the HTML5 spec, as is the custom for other recent W3C 
> specifications?
>         OR
>     B) Posted as an separate IETF RFC, updating the previous RFC for 
> this purpose?
> 
> 2) Do we need to decide the answer to #1 by Last Call?

Please forgive the indirect answer, but what we need by Last Call is a 
draft that enjoys the consensus of the Working Group.  I personally have 
no opinion on question #1 (or more precisely: I can live with either), 
and indeed, I view the proper role of a chair to be to not to make such 
decisions, but rather to assess the consensus of the group.

> 3) If we need to decide the answer to #1 by Last Call, do we need to 
> start the relevant IETF action to either update or obsolete the old HTML 
> content-type RFC?
> 
> I think it is within the Chair's discretion to say that (2) and/or (3) 
> do not need to happen by Last Call; they are purely procedural/process 
> issues, and not technical issues. If the Chairs so rule, then we can 
> resolve ISSUE-53, or at least put it in a state where it doesn't block 
> LC but does block PR. If the Chairs feel that (1) needs needs to be 
> answered and action must be taken before Last Call, then the Chairs need 
> to assess consensus, or hold a poll to determine a decision, or 
> determine that the answer to (1) is within Chairs' discretion and then 
> tell us what the answer is. Since contacting the IESG, submitting an 
> Internet-Draft, and getting it on the right standards track are all 
> matters that, based on past experience, can take weeks or months to 
> accomplish, the time to make these decisions is now. Delaying these 
> decisions puts our Last Call target in jeopardy. This is the action I 
> need from the Chairs.

I'm not going to decide this by fiat, but I would be quite willing to do 
so via lazy consensus.  See below.

> If the Chairs are not ready to decide this now, may I put an action item 
> on you, Sam, to ensure these matters are decided, and if so, what due 
> date should I assign?
> 
> I do not believe this issue can progress further without some action or 
> decision from the Chairs. I believe your response here is kind of a non 
> sequitur and does not provide the needed action. Unless you mean to 
> imply that we don't need to resolve this one way or the other by Last 
> Call, in which case please make that clear so we can enter a decision.

Just to be clear:

1) The only identified issues that I am concerned about as potentially 
requiring significant editorial effort once a decision is made are 
issue-35 (aria-processing), issue-41 (distributed-extensibility), and 
issue-74 (canvas-accessibility).  Of course, one may never know what one 
might find when one turns over a rock, but of the issues I know of, 
issues 35 and 74 are the ones that I believe that the working group 
would find that the current draft does not adequately address, and that 
these three are the only ones where the mechanics of incorporating a 
decision of the Working Group into a Editors Draft is more than a few 
days worth of work each.

2) If you (or anybody) for that matter wishes to propose that any 
specific issue needs not be closed for Last Call, and were to propose a 
mechanism to track said issue that the Working Group in general were to 
agree with and the person who raised the issue in particular were 
comfortable with, then I am entirely OK with closing the issue.  I've 
seen you propose closing issues and tracking the continuing progress via 
bug reports before, and believe this to be a good outcome.

> Regards,
> Maciej

- Sam Ruby
Received on Saturday, 22 August 2009 10:22:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC