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

Julian Reschke wrote:
> Sam Ruby wrote:
>> ...
>>> 1) The IETF AFAIK hasn't made a recommendation; and I don't think it 
>>> can or will. Change control for these media types is in the W3C.
>>>
>>> 2) I made the recommendation *because* the editor added the 
>>> registration and I feel that this is not the best way to do it.
>>
>> OK, so lets open bug reports or issues on what the Working Draft 
>> currently states.
>> ...
> 
> OK.
> 
>>>> I guess what I am asking here is:
>>>>
>>>>   1) Is there some significant technical issue with the approach
>>>>      that has been taken, or is this simply a matter of bug reports
>>>>      that have yet to be written?
>>>
>>> The significant issue (IMHO) is that the media types apply to all 
>>> HTML languages, and the current RFC (2854) describing those takes 
>>> these into account. HTML5 does not.
>>
>> Just so that I'm clear, from your perspective the core issue isn't 
>> "Need to update media type registrations", but rather that you believe 
>> that HTML 4.01 (as a concrete example) is a separate and distinct 
>> language from HTML 5.  If I am understanding correctly, I believe 
>> that's fundamentally different issue than than the issue that was 
>> raised.  If so, I would prefer that this issue be closed and a 
>> separate issue be raised.
> 
> OK.
> 
>> [I feel compelled to disclose that I favor an approach of viewing 
>> HTML5 as superseding prior versions of HTML, and treating as bugs any 
>> places where it doesn't adequately do so; but this in no way precludes 
>> opening of new issues]
> 
> I would prefer that as well, but it's not the case for HTML5 as of now.
> 
>>> There is an existing document describing the media types, so the 
>>> simplest approach would be just to update it.
>>>
>>> The editor has decided not to do that, but to in-line the 
>>> registration. This will work as well, as long as we do not lose 
>>> significant information.
>>>
>>>> If there are no technical issues (modulo a few bug reports, and from 
>>>> what I can see, there is an agreement that these are bugs), and what 
>>>> currently exists is workable, I'm inclined to recommend closing this 
>>>> issue.
>>>> ...
>>>
>>> I'm not sure what bugs you refer to. The main issue is that if the 
>>> media type registration moves from RFC 2854 to HTML5, it should 
>>> preserve information about earlier versions of the language -- see 
>>> <http://tools.ietf.org/html/rfc2854#section-1>.
>>
>> The bugs I was referring to was the comments that you made that Ian 
>> has missed a few places, specifically meta/@scheme, and 
>> head/@profile.  Ian indicated that he would get to them.  I'm just 
>> suggesting that if this is important to you, perhaps bugzilla would be 
>> a reasonable way to track the changes needed.
> 
> head/@profile has it's issue already 
> (<http://www.w3.org/html/wg/tracker/issues/55>). I can add an issue or 
> bug for meta/@scheme, but these are only the ones I happen to be aware 
> of right now. Producing a complete list would be good, but is more work.
> 
> Before we do that, we probably should decide whether HTML5 is supposed 
> to describe all elements/attributes of previous specs or not.

That should be simple.  Is there anybody who is *opposed* to HTML5 
describing all elements/attributes of previous specs?

Ian indicated that he believes that it does.  You have pointed out that 
it does not currently.  If we treat these differences as bugs (and add a 
history section, as you and Anne discussed), is this issue resolved?

> If the answer is "yes", it needs to incorporate references to past 
> specs, optimally lists of elements/attributes describer over there. It 
> then can take over the media type registration, and we'll also have to 
> figure out how to change the status of RFC 2854 in the RFC Index.
> 
> If the answer is "no", then the media type registration should live in a 
> separate document. That could be either a W3C document, or just an 
> update to RFC 2854. (Which, as Larry pointed out, doesn't need to be 
> done right away and wouldn't block LC).
> 
> BR, Julian
>

Received on Monday, 24 August 2009 13:19:28 UTC