Re: [Encoding] false statement [I18N-ACTION-328][I18N-ISSUE-374]

On Sun, Aug 31, 2014 at 8:38 PM, John C Klensin <john+w3c@jck.com> wrote:
> To the extent to which that is true, we get back to a variation
> on Larry's point about making changes where they belong: If we
> need to update the IANA registry by specifying the essential
> details that have been omitted, encouraging updating of relevant
> entries with those details, and then marking everything left as
> "dangerous" or "suspect" until they are updated, that would seem
> to me to be entirely reasonable.  I think the IETF community
> would require a persuasive case about those deviant
> implementations and evidence that they are really the result of
> definitional gaps or misunderstandings, but that should be easy
> if it were really the case.  Things like using a Windows code
> page in place of ASCII (the "us-ascii" charset registration)
> doesn't fit those criteria -- it is a simple decision to
> deviate, whether for good reasons or not.

Yeah, I've had that debate on the registry list a few times and it led
me to think that IETF's registry will never reflect running code.
(Also, note that the registry does not cover all labels from the
Encoding Standard, but also has other labels we do not want. And that
it does not actually define the encodings and the details thereof. It
provides pointers to other documents, sometimes RFCs, which in turn
are not up to date with IBM, NEC, or Microsoft extensions prevalent in
various places around the world. And definitely do not handle
important security details.)


> I think it also leads to a question that I consider legitimate,
> which is why we would expect conformance to the Encoding spec to
> be significantly better than conformance to the IANA Charset
> registry definitions.   It is not clear to me that either is
> less ambiguous than the other.

Well, we started out with something that was already much closer to
running code. In the meantime both Mozilla and Google have been making
strides to close their relative gaps. I'm confident this approach
works as we proved it many times over the years (with a revised
edition of CSS that defined error handling, HTML, the DOM, etc). The
IETF is notoriously bad at doing interoperability testing and then
when parties diverge over the years they act surprised and blame the
browsers which due to network effects do not have much power to
change.


-- 
http://annevankesteren.nl/

Received on Monday, 1 September 2014 09:35:21 UTC