Re: Registration of media type application/xhtml-voice+xml

Bruce Lilly <blilly@erols.com> Wed, 20 July 2005 13:27 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KDRwtI068340; Wed, 20 Jul 2005 06:27:58 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KDRwRj068339; Wed, 20 Jul 2005 06:27:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KDRumt068321 for <ietf-xml-mime@imc.org>; Wed, 20 Jul 2005 06:27:57 -0700 (PDT) (envelope-from blilly@erols.com)
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 0FFF5299BA; Wed, 20 Jul 2005 09:27:55 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KDRr07001114(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 09:27:53 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KDRqi9001113(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 09:27:53 -0400
From: Bruce Lilly <blilly@erols.com>
Reply-To: ietf-types@alvestrand.no
Organization: Bruce Lilly
To: ietf-types@alvestrand.no
Subject: Re: Registration of media type application/xhtml-voice+xml
Date: Wed, 20 Jul 2005 09:27:49 -0400
User-Agent: KMail/1.8.1
Cc: Martin Duerst <duerst@it.aoyama.ac.jp>, "ietf-xml-mime@imc.org" <ietf-xml-mime@imc.org>
References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> <OFE9D62E0C.63121448-ON8525703D.0057CB6D-8525703D.005AE95B@us.ibm.com> <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp>
In-Reply-To: <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507200927.50460@mail.blilly.com>
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>

[dropping IANA and duplicates from Ccs]

On Thu July 14 2005 02:49, Martin Duerst wrote:
> I agree with that reviewer that the type should not contain
> '+' characters except before 'xml'. All other subtypes have used '-'
> as a separator. The '+' separator was specifically introduced to
> express the fact that the '+xml' part is something more than
> a simple subtype.

Neither the MIME specifications nor draft-freed-media-type-reg-04.txt
define any "separator" (other than '/' between type and subtype).  The
syntax merely provides a set of acceptable characters.  A subtype name
of "!#$&.+-^_" is perfectly acceptable and contains no "separator".
The draft does mention "+xml" as a suffix convention as documented in
RFC 3023.  We need to bear in mind the difference between rules and
conventions, as well as the voluntary nature of RFC conformance.

> Although there is probably nothing in RFC 3023 explicitly
> disallowing the use of '+' for "arbitrary use", I think that
> the whole rationale for '+xml' in Appendix A of RFC 3023
> (in particular http://www.ietf.org/rfc/rfc3023.txt, A.12)
> seem to indicate that it shouldn't be done.

3023 defines a convention (3023 term) using a suffix (also the 3023
term).  There is nothing in the MIME specifications, the Freed draft,
or RFC 3023 that implies that '+' has any special status per se.

> >I believe this argument is not strong enough to prevent approval of the 
> >application/xhtml+voice+xml media type:

I concur.
 
> >2. The argument for having "+" in the subtype is unconvincing, given that 
> >the simplest method to determine if something is XML is also the safest, 
> >that is, if the last four characters are "+xml" or "/xml" then the 
> >document is XML, otherwise it is not.

I vehemently disagree.  The name and the content are different things --
sometimes content is mislabeled.  It is absolutely not "the safest" to
assume particular content based solely on the name.  Reasonable security
practice dictates examination of the content itself.  The practice of
assuming particular content based solely upon the name, coupled with
automatic execution, has led to the spread of many, probably most, MS
Windows "worms".