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

Julian Reschke <> Tue, 10 April 2012 08:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2FE621F8720 for <>; Tue, 10 Apr 2012 01:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rnYJ6F0BqpCc for <>; Tue, 10 Apr 2012 01:29:43 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 19C0221F84DA for <>; Tue, 10 Apr 2012 01:29:42 -0700 (PDT)
Received: (qmail invoked by alias); 10 Apr 2012 08:29:42 -0000
Received: from (EHLO []) [] by (mp012) with SMTP; 10 Apr 2012 10:29:42 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/Fy34WTR7Fr3cJdK6kI798wa9oweIb8BXBmPUfZi S+XY2fCY0+gJUj
Message-ID: <>
Date: Tue, 10 Apr 2012 10:29:42 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Carsten Bormann <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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:29:44 -0000

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?

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

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

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

Best regards, Julian