Re: Internet draft for sbml+xml media type
Ben Kovitz <bkovitz@caltech.edu> Tue, 14 October 2003 20:50 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9EKosI7064535 for <ietf-xml-mime-bks@above.proper.com>; Tue, 14 Oct 2003 13:50:54 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9EKos5E064534 for ietf-xml-mime-bks; Tue, 14 Oct 2003 13:50:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from mail-3.nethere.net (mail-3.nethere.net [66.63.128.72]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9EKorI7064529 for <ietf-xml-mime@imc.org>; Tue, 14 Oct 2003 13:50:53 -0700 (PDT) (envelope-from bkovitz@caltech.edu)
Received: (qmail 6458 invoked from network); 14 Oct 2003 20:50:55 -0000
Received: from webmail-1.nethere.net (localhost [66.63.128.78]) by mail-3.nethere.net with SMTP; 14 Oct 2003 20:50:55 -0000 (envelope-sender <bkovitz@caltech.edu>)
Received: from dhcp-193.cds.caltech.edu (dhcp-193.cds.caltech.edu [131.215.42.193]) by webmail.nethere.net (IMP) with HTTP for <bkovitz@66.63.128.69>; Tue, 14 Oct 2003 13:50:55 -0700
Message-ID: <1066164655.3f8c61af68aa6@webmail.nethere.net>
Date: Tue, 14 Oct 2003 13:50:55 -0700
From: Ben Kovitz <bkovitz@caltech.edu>
To: ietf-types@iana.org, ietf-xml-mime@imc.org
Subject: Re: Internet draft for sbml+xml media type
References: <1065642124.3f84688c56dd2@webmail.nethere.net> <18718895059.20031009210457@w3.org>
In-Reply-To: <18718895059.20031009210457@w3.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 131.215.42.193
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>
Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Chris Lilley wrote: > Do the existing SBML-consuming tools honor the charset > parameter when SBML is sent over HTTP or email? And where the > charset parameter disagrees with the encoding in the XMl > encoding declaration, do these tools rewrite the XML when > saving it to disk? > > Note that, although charset is optional in this registration, > RFC 3023 still imposes requirements on software in the > *absence* of a charset. > > If not, I suggest removing this optional parameter as follows: > > There is no charset parameter. Character handling has > identical semantics to the case where the charset parameter > of the "application/xml" media type is omitted, as > described in [RFC3023]. My understanding is that most current SBML-consuming tools do not honor the charset parameter, but that's only because most don't get involved with MIME. Thanks for pointing out the RFC 3023 statements regarding the absence of a parameter! Indeed us-ascii seems unnecessarily limiting. Andrew Finney on sbml-discuss at caltech.edu responded: The SBML Level 2 document states in section 4.1: "The character encoding for SBML is UTF-8. SBML documents should include the encoding attribute with the value UTF-8 in the XML prologue." SBML Level 1 doesn't have this text as far as I remember. I don't know if that helps. My vote would be to specify that SBML is always encoded in UTF-8 and follow through with that in the MIME registration. Would that make SBML unusual for an XML format? Do MIME processors need the flexibility to transform UTF-8 into us-ASCII? i.e. what are the concrete implications? if we do this are we imposing an unrealistic restriction on transmission that would probably not happen in practice? Can we make the char set non-optional and restricted to UFT-8? If yes this would then avoid the issue with rewriting to disk. If we restrict the car set does that make interpreting the incoming stream because the its in only char set? Any thoughts? Restricting sbml+xml to a UTF-8 encoding would certainly be simple, imposing no new requirements on SBML-consuming tools. But would this go against the grain of the relevant RFCs and future evolvability? Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org
- Re: Internet draft for sbml+xml media type MURATA Makoto
- Re: Internet draft for sbml+xml media type Ben Kovitz
- Re: Internet draft for sbml+xml media type Tim Bray
- Re: Internet draft for sbml+xml media type Ben Kovitz
- Re: Internet draft for sbml+xml media type Ben Kovitz
- Re: Internet draft for sbml+xml media type Chris Lilley
- Internet draft for sbml+xml media type Ben Kovitz