Re: Re-registration of text/html

On 24.02.2010 14:20, Henri Sivonen wrote:
> ...
>>>> There are two ways to fix this
>>>> 1) let the MIME registration continue to allow serving HTML 4.01.
>>>> 2) make more of HTML 4.01 valid HTML5.
>>> I would like to make sure we don't do anything radical in our IANA
>>> registration here, so if there's anything I can do to bring it more in
>>> line with what RFC 2854 did, I would be happy to do so (except, of course,
>>> where the new text is an improvement or fixing known bugs). What specific
>>> text in RFC2854 allows HTML, HTML+, HTML2, and HTML3.2 to be used with
>>> text/html? I'd be happy to use the same text in our IANA registration (and
>>> of course adding HTML4).
>> Whether RFC 2854 allowed pre-HTML4 content is an interesting historical question, but not the primary one.
> I think the question is crucial when assessing whether the draft registration in HTML5 conforms to IANA precedent. Because if it does conform to the precedent, claims that the registration draft is somehow in violation of how the IANA does things are bunk.

I said that it would be interesting -- I note that RFC 2854 was written 
by Dan and Larry; maybe they can provide some insight.

But the registration requirements are the way they are, and if you 
believe they aren't, then please go ahead and ask the IESG for 

>> What's important is whether the new text/html will allow existing HTML4 content to stay valid;
> There are really multiple cases there:
>   1) Should pre-existing valid HTML4 continue to be valid HTML4? (I'd say yes.)

Of course.

>   2) Should pre-existing valid HTML4 be valid HTML5? (I'd say it doesn't need to as far as precedent goes. Valid HTML 3.2 is never valid HTML4.)

Not all of it, agreed.

>   3) Should pre-existing invalid content purporting to be HTML4 be valid HTML5? (I'd say it doesn't need to be, because it wasn't valid HTML4, to begin with.)

I don't care.

>   4) Should pre-existing valid HTML4 continue to be appropriate for serving as text/html? (Whatever we say, it'll continue to be so served.)


>   5) Should pre-existing invalid content purporting to be HTML4 be appropriate for serving as text/html? (Has it been previously?)

I don't care.

> Note that case #5 is by far more common than case #4!

It is, but I do not believe this is important for this question.

>> content including things like @profile, for instance. Right now it doesn't, and I believe that is a problem.
> What concrete badness do you expect to ensue if this "problem" remains?
> Do you believe in ever obsoleting specs? Does your concern about HTML4 extend to HTML 2.0? If not, why not?

I do believe in that, but it needs to be done carefully -- for instance, 
by only removing things that have been deprecated before, and by adding 
alternatives when something gets deprecated.

Best regards, Julian

Received on Wednesday, 24 February 2010 13:34:39 UTC