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

[Julian Reschke <[e-mail]>]

On 2012-04-10 10:54, Carsten Bormann wrote:
> 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

Thanks for the suggestions. I will consider these...

>>> 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.

I meant to say "does not need".

> 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.

Good point. Note it has been resolved for httpbis a long time ago.

> 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.
> ...

Understood.

I don't think we *are* rewriting history, though.

Best regards, Julian