Re: [ietf-types] Registration of media type application/vcard+xml

Chris Lilley <> Fri, 08 April 2011 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3514C3A695A for <>; Thu, 7 Apr 2011 18:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6UkEkefS+KHa for <>; Thu, 7 Apr 2011 18:34:43 -0700 (PDT)
Received: from ( [IPv6:2620:0:2830:201::1:73]) by (Postfix) with ESMTP id EB7173A68D2 for <>; Thu, 7 Apr 2011 18:34:42 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p381a7AY003079 for <>; Thu, 7 Apr 2011 21:36:27 -0400
Received: from localhost ([]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1Q808f-0005rB-Ll; Thu, 07 Apr 2011 21:05:29 -0400
Date: Fri, 08 Apr 2011 03:02:28 +0200
From: Chris Lilley <>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <>
To: Bjoern Hoehrmann <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 ( []); Thu, 07 Apr 2011 21:36:27 -0400 (EDT)
Cc: Simon Perreault <>, "" <>
Subject: Re: [ietf-types] Registration of media type application/vcard+xml
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <>
List-Id: "Media \(MIME\) type review" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Apr 2011 01:34:44 -0000

On Thursday, April 7, 2011, 10:12:00 PM, Bjoern wrote:

BH> * Simon Perreault wrote:
>>   Type name:  application

>>   Subtype name:  vcard+xml

>>   Required parameters:  none

>>   Optional parameters:  none

BH> If you do not specify an optional 'charset' parameter, it is ambiguous
BH> what the encoding of `application/vcard+xml;charset=...` is; 

Or not; the XML specification amply covers how to determine the encoding of an XML document.

BH> if you only
BH> read the registration you are likely to ignore the parameter, 

The registration says there is no such parameter. Nor is it required for the application/* tree.

BH> while, if
BH> you read RFC 3023 you expect the 'charset' parameter to specify the en-
BH> coding, which has interoperability and security implications.

Considerations which don't arise if there is no such parameter, such as in this registration request.

Which is why the Technical Architecture group recommends against such use:
  "a receiving application can, with very high reliability, determine the encoding of an XML document by reading it, without reference to any external headers "


  "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction to use the charset is misplaced for application/xml and for non-text "+xml" types."

BH> If this omission of the parameter is not an oversight, I would expect a
BH> rationale for its omission as part of the review request and expect the
BH> interoperability and security issues that arise from this to be noted in
BH> the specification.

Perhaps you can point to which part of the Internet Media types registration process *requires* a charset parameter for the application/* tree and why adding one would be a good idea when, as you point out, adding a charset parameter and expecting it to overide the encoding declared in the XML instance has poor interoperability and raises security worries as well.

In other words, I strongly suspect that the 'omission' of this problematic parameter is not an oversight but a rational technical decision.

(Omitting comments with which I agree).

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups