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

Carsten Bormann <> Tue, 10 April 2012 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 194EE21F8745 for <>; Tue, 10 Apr 2012 01:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oy-88HhL3kfd for <>; Tue, 10 Apr 2012 01:54:26 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id CA16D21F872F for <>; Tue, 10 Apr 2012 01:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3A8s9tH002370; Tue, 10 Apr 2012 10:54:09 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6FDB8BE3; Tue, 10 Apr 2012 10:54:09 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 10 Apr 2012 10:54:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Julian Reschke <>
X-Mailer: Apple Mail (2.1257)
Cc: "" <>
Subject: Re: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 08:54:27 -0000

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:

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.



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