Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset

[Ned Freed <[e-mail]>]

> * Technical summary

> This is the right thing to do, and should have been done right after the end of the UTF wars.

Not entirely sure we had the necessary understanding of the issues at that
point, but it's water under the bridge in any case.

> * Editorial issues

> The document appears to spell out a SHOULD for "text/html" and "text/xml".
> Does it change the meaning of text/html and text/xml?
> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.

There are a total of three places where there are references to these media
types. There's no compliance language at all in the first two locations, and
the third location is inside of a parenthetical phrase that also contains no
compliance language. Unless you manage to miss th=ose parentheses there's
simply no way these references can be conflated with compliance language.

And if we're to the point where we're trying to write prose that's consistent
even when basic punctuation cues are missed, well, all I can say is that we've
got a lot of work ahead of us.

That said, if this really is a valid concern (I'm extremely skeptical myself),
one way to address is would be to omit the third reference entirely (maybe
mention  text/html in the second along with text/xml). If that isn't
sufficient, my only other suggestion would be to say something like "XML and
HTML based media types" instead of referring to those types specificaly. But
that last seems like serious overkill.

> More generally:
> When looking at a random media type three years from now, how do I find out
> whether this sentence does apply:

>    It does not change the
>    defaults for any currently registered media type.

Um, the absence of any sort change to a specific subset of the types
necessarily applies universally. More specifically, since this specification
doesn't change any default anywhere, it doesn't matter in the slightest when
the type was registered. New types are supposed to either make charset
mandatory or not allow it at all. And you can tell that the case by, well,
reading the registration and seeing whether or not they did that.

The only way there would be some sort of flag day problem here is if some sort
of default was changed. But this document does not do that, and Section 4 is
already quite explicit about this. (HTTPbis may do this for text/html, but
that's an issue for that set of documents to deal with.)

> Even more generally:
> Who is affected by (needs to read) this specification?

Since this document specifies how registrations for types that allow for
multiple characters and which might employ charset parameters, anyone creating
registrations subject to those issues should read it. This is why there's a
normative reference in the revised media type registrations procedures  to this
document.

> Who are the targets of the SHOULDs and MUSTs?

See above.

> How do I find out whether an implementation complies?  interoperates?

I assume this is intended to become a BCP. (The IESG makes the final
determination on that, and has from time to time had what I regard as screwy
notions about the correct track for some documents, but in this case BCP  seems
rather obvious.)

BCP aren't necessarily about implementations or interoperability. In this
particular case we're talking about registration compliance. This will become
part of the media type registration review process once it is approved.

> And meta^3:

> What is the IETF name for specifications that are exclusively intended to
> remind us not to make a certain class of mistake again when generating future
> specifications?

I have no idea. But since that's not what this specification is doing, I fail
to see the relevance.

>  Which specification wins when such a meta-specification is neglected in a
> specific specification?

This is tantamount to asking, "What happens if the IESG and/or media type
reviwer screw up and fail to properly apply these new rules to some
registration." The answer is we handle it like any other screwup using
processes we already have in place for such things.

				Ned