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

[Carsten Bormann <[e-mail]>]

On Apr 10, 2012, at 10:29, Julian Reschke wrote:

> On 2012-04-09 18:57, Carsten Bormann wrote:
>> * Technical summary
>> 
>> This is the right thing to do, and should have been done right after the end of the UTF wars.
>> 
>> * 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?
> 
> No. But it licenses future revisions of these specs to do the right thing.
> 
>> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.
> 
> We tried to clarify this in the latest draft. Can you suggest changes?

(such as "text/html" and "text/xml") 
->
(such as "text/html" and "text/xml" are able to) 

And in the start of that paragraph:

registrations
->
future registrations

> 
>> 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.
> 
> The media type definition will have to state the default.

Yes.

s/currently//

Again. maybe 

for text/* media types
->
for future registrations of text/* media types

in the same paragraph.

>> Even more generally:
>> Who is affected by (needs to read) this specification?
>> Who are the targets of the SHOULDs and MUSTs?
>> How do I find out whether an implementation complies?  interoperates?
> 
> The audience is people registering media types.
> 
> And yes, one could argue this spec needs to RFC2119 keywords.

I can't parse that last sentence.

The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and not for registrations either, but for "protocols".
They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict.
I know (the draft is mute about that) that we are fixing 2616, but this draft says nothing about how to handle that kind of conflict.

Again, adding little words such as "future" might help.
Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?).

> 
>> 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?  Which specification wins when such a meta-specification is neglected in a specific specification?
> 
> This document updates RFC 2046, I don't think more needs to be done here...

I'm fine with that, I'm just not fine with the ambiguity resulting from retroactively changing meta-specs that have conflicting specs in force.
I think with the above clarifications in place we might be reaching the point of diminishing returns in managing this specific conflict.
I'm just trying to make the more general point here that you have to be careful in how you rewrite history.

Grüße, Carsten