Re: [apps-discuss] Last Call: <draft-ietf-appsawg-mime-default-charset-03.txt> (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard

Barry Leiba <barryleiba@computer.org> Wed, 09 May 2012 01:18 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6E9E8015 for <apps-discuss@ietfa.amsl.com>; Tue, 8 May 2012 18:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.968
X-Spam-Level:
X-Spam-Status: No, score=-102.968 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC2dV7uSq12Z for <apps-discuss@ietfa.amsl.com>; Tue, 8 May 2012 18:18:21 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 310F69E8012 for <apps-discuss@ietf.org>; Tue, 8 May 2012 18:18:21 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so12538713obb.31 for <apps-discuss@ietf.org>; Tue, 08 May 2012 18:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YAuO4jWCl/4tlZ2dQ4hEhjpDdD3bWQ37dXNamvU4h3I=; b=dbh1EFtRRwURob8UKur6CAfRo9FuKG9XvWDDvEjYuq8pZfQFp/QGfNou5MCs92srgq abBfiFzqfrnUiTnt5gkvHrQuIUMxUxXaGsQutjS24iale3e5qWZKh7jQf5t2M3fu+ZTU QeI9RkjsAc2OdD3vZ14UwCLdCfPlIdY1VI2RehRimD6wGiX6CI7ZcLcVNaz5vUufS8sM EwcBXJDuzuio5EyIJJsNI1oZ4EX+Qtj7URIWTo8BC1p4sJosc0N2eF7yOD8nVVMG3EHj pgnIwcx9TwmqTBy0SghqmbaEXN09iSKvEExPtF1m3bgvhhEPIUPBmkUbP4MIlznMvFk4 3XSQ==
MIME-Version: 1.0
Received: by 10.182.172.100 with SMTP id bb4mr1647227obc.22.1336526300848; Tue, 08 May 2012 18:18:20 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.10.68 with HTTP; Tue, 8 May 2012 18:18:20 -0700 (PDT)
In-Reply-To: <01OF8RSPPS320006TF@mauve.mrochek.com>
References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <CAC4RtVDZfXi1JwGJLGwOVgsGuU-1dH-uj8bXTGCmjrva80mNhg@mail.gmail.com> <01OF8RSPPS320006TF@mauve.mrochek.com>
Date: Tue, 08 May 2012 21:18:20 -0400
X-Google-Sender-Auth: GxPxV4bZRZ9Xq9i_1ur4juzBrSQ
Message-ID: <CALaySJLFrKSF9JPBC54j0EaTQ6SNXM2+tag2uU2SmVjWxE7Erg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-mime-default-charset-03.txt> (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2012 01:18:21 -0000

> The new rules say that a media type either
>
> (1) Specifies that no charset parameter is used and that the charset is
>    determined from inspection of the content, or
>
> (2) Requires inclusion of a charset parameter specifying what the charset
>    is, or
>
> (3) Explicitly states what the default charset is. (Either with or without
>    allowing an optional charset parameter as a means of overriding the
>    default.)

The document makes all of those SHOULD.  From section 3:

   In order to improve interoperability with deployed agents, "text/*"
   media type registrations SHOULD either

   a.  specify that the "charset" parameter is not used for the defined
       subtype, because the charset information is transported inside
       the payload (such as in "text/xml"), or

   b.  require explicit unconditional inclusion of the "charset"
       parameter eliminating the need for a default value.

There's nothing that I read in this document that says that
registrations MUST do anything with regard to charset parameters.
Now, you may say that the designated expert would never accept a
registration that didn't (and well you might say that), but someone
looking at the registrations and their associated documentation won't
know that.

> As such, there is no possibility of confusion. An old text/* media type can get
> away without specifying charset information and relying on the language in RFC
> 2045; a new one cannot.

There is absolutely a possibility of confusion.  Someone who doesn't
know you and the process well may see something registered and be
completely uncertain whether it's old (and therefore gets US-ASCII as
its default) or whether it's new and doesn't comply with the SHOULDs
here (and therefore gets &deity only knows what as its default).

> the question is whether or not you can convince the reviewer you
> have sufficient cause to violate the SHOULD.

And if you do so convince the reviewer, what does the default value
wind up being?  And, again, how's an arbitrary person to know?

>>   To maintain compatibility with existing registrations, this fallback rule
>>   applies: any subtype of the "text" media type that does not comply with
>>   the rules above retains US-ASCII as its default, as originally specified
>>   in RFC 2046.
>
> That's a really bad idea for all sorts of reasons, including but not limited to
> it makes the document self-contradictory. You shouldn't remove a rule then say
> it's OK to fall back on it.

Well, I disagree with that.  No matter, see below.

> Now, if you want to add something that says:
>
>  Regardless of the approach chosen, all text/* registrations MUST clearly
>  specify how the charset of the content is determined and MUST NOT rely
>  on the RFC 2045 rule.

I'd change that to "all new text/* registrations", and I still want to
add a sentence that says that existing text/* registrations that don't
specify this retain the 2045 rule.

> I think this falls out of the existing text, but if you want to make it crystal
> clear I don't have a problem.

I think it does not fall out of the existing text at all.

Barry