From owner-ietf-types@dokka.kvatro.no Fri Apr 3 18:41:41 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id SAA27824 for ietf-types-list; Fri, 3 Apr 1998 18:41:41 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id SAA27813 for ; Fri, 3 Apr 1998 18:41:19 +0200 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id SAA03851 for ; Fri, 3 Apr 1998 18:40:21 +0200 (METDST) Received: from dla (dla.ucop.edu [192.35.215.99]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id IAA29536 for ; Fri, 3 Apr 1998 08:40:14 -0800 (PST) Received: from localhost by dla (SMI-8.6/1.34) id QAA04150; Fri, 3 Apr 1998 16:58:16 GMT Date: Fri, 3 Apr 1998 08:58:16 -0800 (PST) From: Mark Needleman X-Sender: mhn@dla.ucop.edu To: ietf-types@ISI.EDU Subject: mime type Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk Awhile back I submitted a request to have a mime type of application/ber-apdu registered I have heard unoffically that there were some objections to this but I have never actually received any feedback or notification of the status of the request and would like to know officially its standing so I can determine what I need to do next if the mime type can not actually be registered thanks very much ----------------------------------------------------------- Mark H Needleman Coordinator Advanced Technology Development University of California California Digital Library Kaiser Center Room 854 300 Lakeside Drive Oakland, CA 94612-3550 510-987-0530 FAX: 510-763-2471 Internet: Mark.Needleman@ucop.edu From owner-ietf-types@dokka.kvatro.no Sun Apr 5 16:21:08 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id QAA04612 for ietf-types-list; Sun, 5 Apr 1998 16:21:08 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id QAA04599 for ; Sun, 5 Apr 1998 16:20:47 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id QAA08552 for ; Sun, 5 Apr 1998 16:19:51 +0200 (METDST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA15524 for ; Sun, 5 Apr 1998 07:19:49 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IVHDSJ5NWW984PEV@INNOSOFT.COM> for ietf-types@ISI.EDU; Sun, 5 Apr 1998 07:19:16 PST Date: Sat, 04 Apr 1998 19:30:00 -0800 (PST) From: Ned Freed Subject: Re: mime type In-reply-to: "Your message dated Fri, 03 Apr 1998 08:58:16 -0800 (PST)" To: Mark Needleman Cc: ietf-types@ISI.EDU Message-id: <01IVI2W0KS5U984PEV@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk > Awhile back I submitted a request to have a mime type of > application/ber-apdu > registered > I have heard unoffically that there were some objections to this but I > have never actually received any feedback or notification of the status of > the request and would like to know officially its standing so I can > determine what I need to do next if the mime type can not actually be > registered I'm not one of those who objected, but I do see this registration as more than a little problematic. Media types typically suffice to determine both object syntax _and_ semantics, that is, with a media type (and parameters) in hand an application knows how to process the associated object. This is not the case with application/ber-apdu. This media type doesn't even manage to cover syntax matters, let alone semantics. (It is an unfortunate fact that in practice multiple syntatic elements are sometimes encoded and stuffed into BER string elements. Sometimes the inner encoding is also BER and sometimes it is not. This makes it impossible to even do complete syntactic analysis of a BER stream without knowlege of its ASN.1 definition.) The simple fact of the matter is that given a generic application/ber-apdu object an application is pretty much in the dark as to what to do other than a limited syntax check. Now, you can argue that the protocol-oid and protocol-string fields provide the missing information to application. But even leaving aside whether or not switching on parameter values is a good idea, I'm not convinced that this is true. Since you give absolutely no rules for what to put in these parameters, any random user of this media type is free to put in whatever they please. For example, if I choose to send around X.400 P1 APDUs using this mechanism I could label them with any of the OIDs that happen to be on the various ASN.1 modules the X.400 standards specify. Or I could use a private OID of my own. I could use the string "X.400-P1" for the string label. Or I could use "X.400-1988-P1" to try and be specific about the version of X.400 I'm talking about. Or I could use "X.400 message" or something similar. The net result is that people use this mechanism at all it is almost guaranteed that they will label the same thing in different ways, and will not interoperate. Fixing this basically would require registering two new namespaces underneath application/ber-adpu. And this then begs the question of why not use the existing registration mechanism for media types instead. I also don't like the fact that this mechanism usurps the functions of the top-level media type namespace. Many BER APDUs belong under top level types such as text, image, or audio or model, not application. There are also some purely technical problems with what you propose in this area. For one thing, not all ASN.1-based PDU definitions have OIDs assigned to them. You would need to clarify what to do in such cases, since you say the OID label is required. And for another, OIDs of this sort are assigned to entire ASN.1 modules, which may in turn define a bunch of different PDUs. You would need to handle this issue as well. And yet another issue is that PDU definitions get revised without the ASN.1 module OID being updated. You also say that both fields are required, but later talk about what happens if both are present. It doesn't seem to me like there's an if involved if you require both fields. If this work is to move forward I would suggest that instead of registring a media type for BER APDUs that you write an informational document that explains how to register media types that happen to be BER APDUs. You could talk about how to name such types, how to include information about the ASN.1 definition of the type in the registration, and so on. I don't know if there really are enough common principles for registration of BER APDUs to make such a document worthwhile, but at least such a thing doesn't have the rather serious downside that appears to be present in the current proposal. Ned From owner-ietf-types@dokka.kvatro.no Tue Apr 7 18:20:48 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id SAA22895 for ietf-types-list; Tue, 7 Apr 1998 18:20:48 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id SAA22889 for ; Tue, 7 Apr 1998 18:20:13 +0200 From: iana@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id SAA28688 for ; Tue, 7 Apr 1998 18:19:14 +0200 (METDST) Received: from ode.isi.edu (ode.isi.edu [128.9.160.68]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA13224; Tue, 7 Apr 1998 09:19:11 -0700 (PDT) Date: Tue, 7 Apr 98 09:20:55 PDT Posted-Date: Tue, 7 Apr 98 09:20:55 PDT Message-Id: <9804071620.AA09704@ode.isi.edu> Received: by ode.isi.edu (4.1/4.0.3-6) id ; Tue, 7 Apr 98 09:20:55 PDT To: thomas@vinga.se Subject: Re: Registration of media types APPLICATION/ vnd.ecowin.chart, vnd.ecowin.series, vnd.ecowin.filerequest, vnd.ecowin.fileupdate, vnd.ecowin.seriesrequest, vnd.ecowin.seriesupdate Cc: iana@ISI.EDU, ietf-types@uninett.no Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk Thomas, We have registered the followin MIME Media Types with you as the point of contact: application/vnd.ecowin.chart application/vnd.ecowin.series application/vnd.ecowin.filerequest application/vnd.ecowin.fileupdate application/vnd.ecowin.seriesrequest application/vnd.ecowin.seriesupdate Thanks. Josh Elliott *************************************************************** Information Sciences Institute Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 USA Voice: (310) 822-1511 x302 FAX: (310) 823-6714 email: iana@iana.org *************************************************************** From owner-ietf-types@dokka.kvatro.no Mon Apr 13 22:51:23 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id WAA02895 for ietf-types-list; Mon, 13 Apr 1998 22:51:23 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id WAA02888 for ; Mon, 13 Apr 1998 22:51:06 +0200 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id WAA21520 for ; Mon, 13 Apr 1998 22:50:39 +0200 (METDST) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id NAA26262 for ; Mon, 13 Apr 1998 13:50:35 -0700 (PDT) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <0086QC@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.07 98/04/06] MIME-Version: 1.0 Content-Type: Text/Plain Date: Mon, 13 Apr 1998 16:50:12 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: New MIME Type: vnd.minisoft-hp3000-save To: ietf-types@ISI.EDU Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk MIME type name: application MIME subtype name: vnd.minisoft-hp3000-save Required parameters: none Optional parameters: none Encoding considerations: Since the encoded file may contain long lines or binary data, encoding should be BASE64 or QUOTED-PRINTABLE if necessary. Security considerations: Since the encoded file may be any supported HP3000 file type, including an executable file, appropriate caution should be excercised. Interoperability considerations: Since HP3000 files have specific attributes (separate from their contents) that must be preserved in transport, this encoding imbeds file attribute information at the beginning of the body part. Inclusion of these attributes makes the data essent- ially useless to other platforms, but is required in order to eventually reconstruct an identical file on a destination HP3000. This encoding should only be used for files which are intended to be transported only to another HP3000 system. Published specification: ftp://ftp.3k.com/DOC/ms92-save-format.txt Applications which use this media type: MS92 (various versions) [terminal emulator package] NetMail/3000 (various versions) [e-mail package for HP3000 systems] DeskLink (various versions) [HPDesk SMTP gateway] Contact for further information: Minisoft, Inc. 1024 First Street Snohomish, WA 98290 e-mail: support@minisoft.com Phone: +1(360)568-6602 Fax: +1(360)568-2923 3k Associates, Inc. 6901 Old Keene Mill Road, Suite 500 Springfield, VA 22150 e-mail: support@3k.com Phone: +1(703)569-9189 Fax: +1(703)451-3720 Author: Chris Bartram, 3k Associates, Inc. From owner-ietf-types@dokka.kvatro.no Mon Apr 13 22:50:21 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id WAA02870 for ietf-types-list; Mon, 13 Apr 1998 22:50:21 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id WAA02864 for ; Mon, 13 Apr 1998 22:50:11 +0200 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id WAA21517 for ; Mon, 13 Apr 1998 22:49:41 +0200 (METDST) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id NAA26252 for ; Mon, 13 Apr 1998 13:49:33 -0700 (PDT) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <0086QB@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.07 98/04/06] MIME-Version: 1.0 Content-Type: Text/Plain Date: Mon, 13 Apr 1998 16:49:06 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: New MIME type: vnd.wrq-hp3000-labelled To: ietf-types@ISI.EDU Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk MIME type name: application MIME subtype name: vnd.wrq-hp3000-labelled Required parameters: none Optional parameters: none Encoding considerations: Since the encoded file may contain long lines or binary data, encoding should be BASE64 or QUOTED-PRINTABLE if necessary. Security considerations: Since the encoded file may be any supported HP3000 file type, including an executable file, appropriate caution should be excercised. Interoperability considerations: Since HP3000 files have specific attributes (separate from their contents) that must be preserved in transport, this encoding imbeds file attribute information at the beginning of the body part. Inclusion of these attributes makes the data essent- ially useless to other platforms, but is required in order to eventually reconstruct an identical file on a destination HP3000. This encoding should only be used for files which are intended to be transported only to another HP3000 system. Published specification: Not available. Applications which use this media type: Reflection (various versions) [terminal emulator package] NetMail/3000 (various versions) [HP3000-based e-mail package] DeskLink (various versions) [HPDesk SMTP mail gateway] Person & email address to contact for further information: WRQ Inc. 1500 Dexter Avenue North Seattle, WA 98109 e-mail: support@wrq.com Phone: +1(206)217-7100 Fax: (206)217-0293 3k Associates, Inc. 6901 Old Keene Mill Road, Suite 500 Springfield, VA 22150 e-mail: support@3k.com Phone: +1(703)569-9189 Fax: +1(703)451-3720 Author: Chris Bartram, 3k Associates, Inc. From owner-ietf-types@dokka.kvatro.no Tue Apr 14 17:47:40 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id RAA21667 for ietf-types-list; Tue, 14 Apr 1998 17:47:40 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id RAA21660 for ; Tue, 14 Apr 1998 17:47:17 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id RAA05808 for ; Tue, 14 Apr 1998 17:46:52 +0200 (METDST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA16166 for ; Tue, 14 Apr 1998 08:46:50 -0700 (PDT) Received: from elwood.innosoft.com ("port 39951"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IVUQJS0VBU984VK0@INNOSOFT.COM> for ietf-types@ISI.EDU; Tue, 14 Apr 1998 08:46:06 PDT Date: Tue, 14 Apr 1998 08:47:49 -0700 (PDT) From: Chris Newman Subject: Re: New MIME type: vnd.wrq-hp3000-labelled In-reply-to: <0086QB@PICARD.3K.COM> To: Chris Bartram Cc: ietf-types@ISI.EDU Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk On Mon, 13 Apr 1998, Chris Bartram wrote: > Interoperability considerations: Since HP3000 files have specific attributes > (separate from their contents) that must be preserved in transport, > this encoding imbeds file attribute information at the beginning of > the body part. Inclusion of these attributes makes the data essent- > ially useless to other platforms, but is required in order to > eventually reconstruct an identical file on a destination HP3000. > This encoding should only be used for files which are intended to > be transported only to another HP3000 system. I'm not familiar with the exact problem you're trying to solve, but if you have both data and metadata, you might wish to consider the multipart/appledouble model from RFC 1740. It preserves the metadata, but the data itself can be trivially extracted by a MIME-aware agent even if it is unfamaliar with your media type. - Chris From owner-ietf-types@dokka.kvatro.no Tue Apr 14 18:41:54 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id SAA22592 for ietf-types-list; Tue, 14 Apr 1998 18:41:54 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id SAA22581 for ; Tue, 14 Apr 1998 18:41:31 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id SAA06277 for ; Tue, 14 Apr 1998 18:41:06 +0200 (METDST) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id JAA19909 for ; Tue, 14 Apr 1998 09:41:04 -0700 (PDT) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <0087HY@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.07 98/04/06] MIME-Version: 1.0 Content-Type: Text/Plain Date: Tue, 14 Apr 1998 12:40:10 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: New MIME type: vnd.wrq-hp3000-labelled To: CHRIS.NEWMAN@INNOSOFT.COM cc: ietf-types@ISI.EDU Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk In CHRIS.NEWMAN@INNOSOFT.COM writes: > On Mon, 13 Apr 1998, Chris Bartram wrote: > > Interoperability considerations: Since HP3000 files have specific attributes > s > > (separate from their contents) that must be preserved in transport, > > this encoding imbeds file attribute information at the beginning of > > the body part. Inclusion of these attributes makes the data essent- > > ially useless to other platforms, but is required in order to > > eventually reconstruct an identical file on a destination HP3000. > > This encoding should only be used for files which are intended to > > be transported only to another HP3000 system. > > I'm not familiar with the exact problem you're trying to solve, but if you > have both data and metadata, you might wish to consider the > multipart/appledouble model from RFC 1740. It preserves the metadata, but > the data itself can be trivially extracted by a MIME-aware agent even if > it is unfamaliar with your media type. We're defining a type to transport an already popular/standard (in the HP3000 world) method of encoding metadata. There are already many applications that use the format - we just thought it was time that we had a defined name for it in order to transport it via MIME (many apps have been using X-names for it for several years now). -Chris Bartram From owner-ietf-types@dokka.kvatro.no Sun Apr 26 23:57:10 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id XAA20106 for ietf-types-list; Sun, 26 Apr 1998 23:57:10 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id BAA09266 for ; Sat, 25 Apr 1998 01:53:36 +0200 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id BAA25912 for ; Sat, 25 Apr 1998 01:53:46 +0200 (METDST) Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id QAA29248 for ; Fri, 24 Apr 1998 16:53:42 -0700 (PDT) Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa06175; 24 Apr 98 16:45 PDT Received: by localhost with Microsoft MAPI; Fri, 24 Apr 1998 16:51:10 -0700 Message-ID: <01BD6FA1.2F44D5A0.ejw@ics.uci.edu> From: Jim Whitehead Reply-To: "ejw@ics.uci.edu" To: "'ietf-types@iana.org'" Subject: Registration of text/xml Date: Fri, 24 Apr 1998 16:51:09 -0700 Organization: U.C. Irvine X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk Hi, I have prepared an Internet Draft, draft-whitehead-mime-xml-00, which registers the media type text/xml. This draft will be available in the Internet-Drafts directory in 1-3 days, and can also be accessed from: http://www.ics.uci.edu/pub/ietf/webdav/xml/draft-whitehead-mime-xml-00.txt I accordance with the instructions in RFC 2048, I am sending my intention to register the text/xml media type to the "ietf-types@iana.org" mailing list. I look forward to your comments on this registration request. I have been experiencing some difficulty subscribing to the ietf-types mailing list, so please email your comments directly to . Thanks! - Jim Whitehead From owner-ietf-types@dokka.kvatro.no Tue Apr 28 00:54:25 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id AAA13023 for ietf-types-list; Tue, 28 Apr 1998 00:54:25 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id AAA13020 for ; Tue, 28 Apr 1998 00:54:11 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id AAA23580 for ; Tue, 28 Apr 1998 00:54:25 +0200 (METDST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28396 for ; Mon, 27 Apr 1998 15:54:22 -0700 (PDT) Received: from elwood.innosoft.com ("port 46361"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWDB97W9UE98541A@INNOSOFT.COM> for ietf-types@ISI.EDU; Mon, 27 Apr 1998 15:53:32 PDT Date: Mon, 27 Apr 1998 15:55:11 -0700 (PDT) From: Chris Newman Subject: Re: Registration of text/xml In-reply-to: <01BD6FA1.2F44D5A0.ejw@ics.uci.edu> To: Jim Whitehead Cc: "'ietf-types@iana.org'" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk On Fri, 24 Apr 1998, Jim Whitehead wrote: > I have prepared an Internet Draft, draft-whitehead-mime-xml-00, which > registers the media type text/xml. This draft will be available in the > Internet-Drafts directory in 1-3 days, and can also be accessed from: > > http://www.ics.uci.edu/pub/ietf/webdav/xml/draft-whitehead-mime-xml-00.txt A few comments on this registration: > Since the > default character set encoding for XML is UTF-8, it is appropriate > to make XML a subtype of the "text" media type, as "text/xml". I observe that the default character set for a text/* subtype is US-ASCII 7-bit (HTTP's profile of MIME defaults to ISO-8859-1). A charset parameter can be used on either a text/* subtype or an application/* subtype, so this is not a justification for using the "text" top level type. In fact, an application/* subtype is free to have any default charset, so this might be a justification to make XML a subtype of "application". > In an XML document, character set information can be encoded > within each XML element, and hence can vary across XML elements. The "text" top-level type effectively requires (RFC 2046 sec 4.1.2) that all the content of the media type use the same charset. In addition, it requires that linebreaks be represented as the two octets 0x0d 0x0a and that 0x0d and 0x0a not be used for other purposes. This suggests that the "text/xml" media type isn't capable of representing all objects considered "XML" by the XML specification. See section 11 of RFC 2110 for a more detailed discussion of line break issues with relation to web/email interactions. The right solution may be to register both "text/xml" and "application/xml". Then state that the former is used for data suitable to be displayed directly to a human without processing which uses a single charset with CRLF linebreaks, and the latter is used in other cases. Since XML documents can be aggregate in a similar fashion to HTML documents, I suggest a reference to RFC 2110 is in order. I like the security considerations section, but I suggest adding one more item which would be nice if it found its way back into the XML specification: Use of unsafe file operations or other system-level commands by specific XML DTDs is strongly discouraged. XML interpretors are strongly encouraged to include a "safe" mode which disables these commands in similar fashion to many display Postscript and Java interpretors. I'm not sure this is entirely correct, since I don't know what a DTD can specify, but I'm sure you get the gist of the idea. It seems worthwhile to ask implementors to do the right thing directly. - Chris (Permission is granted to forward this message to other interested parties). From owner-ietf-types@dokka.kvatro.no Tue Apr 28 03:42:49 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id DAA15637 for ietf-types-list; Tue, 28 Apr 1998 03:42:49 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id DAA15634 for ; Tue, 28 Apr 1998 03:42:36 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id DAA24026 for ; Tue, 28 Apr 1998 03:42:57 +0200 (METDST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA06244 for ; Mon, 27 Apr 1998 18:42:55 -0700 (PDT) Received: from enoshima.w3c.mag.keio.ac.jp (dhcp-100-233.mag.keio.ac.jp [133.27.195.233]) by sh.w3.mag.keio.ac.jp (8.8.8+2.7Wbeta7/3.6Wbeta7-W3C/Keio) with SMTP id KAA18957; Tue, 28 Apr 1998 10:42:39 +0900 (JST) Message-Id: <199804280142.KAA18957@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Tue, 28 Apr 1998 10:43:54 +0900 To: Chris Newman , Jim Whitehead , MURATA Makoto From: "Martin J. Duerst" Subject: Re: Registration of text/xml Cc: "'ietf-types@iana.org'" In-Reply-To: References: <01BD6FA1.2F44D5A0.ejw@ics.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk At 15:55 98/04/27 -0700, Chris Newman wrote: > On Fri, 24 Apr 1998, Jim Whitehead wrote: > > http://www.ics.uci.edu/pub/ietf/webdav/xml/draft-whitehead-mime-xml-00.txt > > A few comments on this registration: > > > Since the > > default character set encoding for XML is UTF-8, it is appropriate > > to make XML a subtype of the "text" media type, as "text/xml". > > I observe that the default character set for a text/* subtype is US-ASCII > 7-bit (HTTP's profile of MIME defaults to ISO-8859-1). A charset > parameter can be used on either a text/* subtype or an application/* > subtype, so this is not a justification for using the "text" top level > type. In fact, an application/* subtype is free to have any default > charset, so this might be a justification to make XML a subtype of > "application". This is a very valuable hint. Ideally, we would like to have the default of UTF-8 for both text/xml and application/xml, but of course for text/xml this is impossible. > > In an XML document, character set information can be encoded > > within each XML element, and hence can vary across XML elements. This is not true, and has already be pointed out to Jim (on a different mailing list). > The "text" top-level type effectively requires (RFC 2046 sec 4.1.2) that > all the content of the media type use the same charset. In addition, it > requires that linebreaks be represented as the two octets 0x0d 0x0a and > that 0x0d and 0x0a not be used for other purposes. This suggests that the > "text/xml" media type isn't capable of representing all objects considered > "XML" by the XML specification. This is true, but only because XML can use character encodings that do not conform to the CR/LF convention (e.g. UTF-16). That's why application/xml should also be registered. Regards, Martin. From owner-ietf-types@dokka.kvatro.no Thu Apr 30 05:17:22 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id FAA00520 for ietf-types-list; Thu, 30 Apr 1998 05:17:22 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id FAA00504 for ; Thu, 30 Apr 1998 05:16:42 +0200 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id FAA24968 for ; Thu, 30 Apr 1998 05:17:07 +0200 (METDST) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA26445 for ; Wed, 29 Apr 1998 20:17:05 -0700 (PDT) Received: from enoshima.w3c.mag.keio.ac.jp (dhcp-100-233.mag.keio.ac.jp [133.27.195.233]) by sh.w3.mag.keio.ac.jp (8.8.8+2.7Wbeta7/3.6Wbeta7-W3C/Keio) with SMTP id MAA17765; Thu, 30 Apr 1998 12:16:55 +0900 (JST) Message-Id: <199804300316.MAA17765@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Thu, 30 Apr 1998 12:16:08 +0900 To: MURATA Makoto , w3c-xml-sig@w3.org, "'ietf-types@iana.org'" From: "Martin J. Duerst" Subject: Re: Revised text for XML media types Cc: ejw@cloud.ics.uci.edu, masinter@parc.xerox.com In-Reply-To: <199804291114.AA00818@murata.apsdc.ksp.fujixerox.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk At 20:14 98/04/29 +0900, MURATA Makoto wrote: > I am a member of the XML WG and am co-authoring the RFC for > xml media types with Jim. A few comments below: > 2 The XML Media Types > As sometimes happens between two communities, both MIME and XML have > defined the term entity, with different meanings. Within the XML > specification, XML "entities" can be classified into four types. In > the XML terminology, they are called "document entities", "external > DTD subsets", "external parsed entities", and "external parameter > entities". Media types text/xml and application/xml can be used for > any of these four types. A short explanation about the different "defaults" for character encoding in the different communities, which motivates the requiredness of the "charset" parameter, might help here (see below). > 2.1 Text/xml > > MIME media type name: text > > MIME subtype name: xml > > Required parameters: charset > > This media type requires the charset parameter thus encouraging > good practice and avoiding default values established in the past. > > UTF-8 [RFC-2279] or UTF-16 (Appendix C.3 of [UNICODE] and > Amendment 1 of [10646]) is recommended. They are supported by any > conforming XML processors [REC-XML]. UTF-16 should be in network > byte order (big-endian), but recipients should be able to handle > little-endian. In 2.1, which is about text/xml, UTF-16 should not be recommended :-). > The omission of the charset parameter is non-conformant. In the > XML terminology, this omission is called a fatal error [REC-XML]. > The recipient XML processor must report this error and stop > normal parsing. (Alternative wording: "The omission of the > charset parameter is non-conformant. The recipient XML processor > must report this error. It may stop normal parsing or recover by > using heuristics shown in Annex F of [REC-XML].) I think that for purely practical reasons, I would prefer the alternative wording. Making it a fatal error is against the "be liberal in what you accept" principle of IETF. But it should maybe be better explained why it is important to have the parameter mandatory. Having the parameter mandatory allows to remove conflicts between MIME (where the default is US-ASCII for mail) and XML (where the default is UTF-8). Please note that the ommission of the parameter will result in different behaviour for different applications: Mail UAs that don't know text/xml will display it as US-ASCII, while XML applications will assume UTF-8 or whatever else the result of Annex F guessing is. This is clearly not desirable. > Magic number(s): none > > Although no byte sequences are always present, XML entities in > ASCII-compatible encodings (including UTF-8) often begin with 3C > 3F 78 6D 6C (" 00 3C 00 3F 00 78 00 6D or FF FE 3C 00 3F 00 78 00 6D 00 (BOM > followed by " XML]. For text/xml, the UTF-16 sequence is irrelevant :-). > 2.2 Application/xml > > MIME media type name: application > > MIME subtype name: xml > > Required parameters: charset > > This parameter is identical to the "charset" parameter of the > media type "text" [RFC-2046]. Note that the default value is > never used since this parameter is required. For application/*, there is no default for "charset", as far as I understand. > UTF-8 [RFC-2279] or UTF-16 (Appendix C.3 of [UNICODE] and > Amendment 1 of [10646]) is recommended. They are supported by any > conforming XML processors [REC-XML]. UTF-16 should be in network > byte order (big-endian), but recipients should be able to handle > little-endian. I would suggest to add "sent", so that it says "UTF-16 should be sent in network byte order...". > The omission of the charset parameter is non-conformant. In the > XML terminology, this omission is called a fatal error [REC-XML]. > The recipient XML processor must report this error and stop > normal parsing. (Alternative wording: "The omission of the > charset parameter is non-conformant. The recipient XML processor > must report this error. It may stop normal parsing or recover by > using heuristics shown in Annex F of [REC-XML].) Interestingly enough, because there is no MIME default that conflicts with the XML default, it is easier here to choose the alternative wording. But I guess we should choose the same for both cases, anyway. Regards, Martin. From owner-ietf-types@dokka.kvatro.no Thu Apr 30 07:34:16 1998 Received: (from majordomo@localhost) by dokka.kvatro.no (8.8.5/8.8.5) id HAA02954 for ietf-types-list; Thu, 30 Apr 1998 07:34:16 +0200 Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by dokka.kvatro.no (8.8.5/8.8.5) with ESMTP id HAA02951 for ; Thu, 30 Apr 1998 07:34:05 +0200 Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by tyholt.uninett.no (8.8.8/8.8.8) with ESMTP id HAA25230 for ; Thu, 30 Apr 1998 07:34:31 +0200 (METDST) Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by venera.isi.edu (8.8.7/8.8.6) with ESMTP id WAA03546 for ; Wed, 29 Apr 1998 22:34:27 -0700 (PDT) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA19573; Thu, 30 Apr 1998 15:33:21 +1000 (EST) Received: from [24.192.48.8] (UNKNOWN048008.rev.telstra-mm.net.au [24.192.48.8]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA29885; Thu, 30 Apr 1998 15:33:19 +1000 (EST) X-Sender: linkalarm@moreinfo.com.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Apr 1998 15:35:59 +1100 To: ietf-types@ISI.EDU From: George Bray Subject: Registration of MIME media type application/vnd.linkalarm Cc: geo@linkalarm.com Sender: owner-ietf-types@dokka.kvatro.no Precedence: bulk Commercial in Confidence To IETF MIME Type Registration >From George Bray, President Link Alarm, Inc. 30/APR/98 Dear IETF Types, Here is an application to register the MIME type application/vnd.linkalarm for use with our browser plug-in. LinkAlarm is a link checking service for web sites. The report for a site shows which pages and links are broken. If the end-user has our browser plug-in they can open their original HTML file directly from our report with a single click. The LinkAlarm plug-in comes with an administration application for MacOS and Win32. LinkAlarm Admin allows the user to maintain the information required by the plug-in. The plug-in requires the following information: URI of the site Default file of the Site Local Location of the source HTML files Local Location of the preferred HTML editor For a better understanding of our service and the way our plug-in provides its functionality, please see the LinkAlarm report on: The plug-in binary for MacOS PPC and Win32 is available at: When installed, the LinkAlarm report will show three icons on each page. The icon of a pencil on the page is the Plugin. You will also require the source HTML files for the site. The file is "avs.zip" for the Australian Vegetarian Society is also in the download area. We are still developing the site reports and the plug-ins. The most reliable version at present is the MacOS plug-in operating in Navigator 4 or IE 4. IE4 user should enable the plugin by checking the box on this page: http://reports.linkalarm.com/pref/ =============================================================================== MIME media type name: application MIME subtype name: vnd.linkalarm Required parameters: LINKALARMMODE = { BUTTON | POPUPMENU } -------------------------------------- LINKALARMMODE specifies how the plug-in draws itself on the LinkAlarm report, either as a "page" button or a triangle representing a popup menu. LINKALARMACTION = { EDIT | COPY | CONFIG } --------------------------------------- LINKALARMACTION specifies what action is to be taken by the plug-in. EDIT looks up the LinkAlarm Database for a corresponding URI. If found, the location of the source file is derived and passed to the HTML editor for opening. COPY copies the URI to the system clipboard. CONFIG opens the LinkAlarm Admin application. LINKALARMPARAM1 = URI ----------------------- LINKALARMPARAM1 contains a URI. Missing trailing slashes are accounted for. A typical implementation is made with the following HTML code. Optional parameters: LINKALARMPARAM1 (the URI) is optional when LINKALARMACTION is COPY or CONFIG Encoding considerations: The URI should not be escaped or encoded. Security considerations: As discussed above, the LinkAlarm plug-in and LinkAlarm Admin application provide additional functionality to the user of LinkAlarm reports. Specifically, they together allow the user to open their HTML source file in the HTML editor of their choice. The LinkAlarm plug-in operates on files available to the end user, either on the local computer or a filesystem available to it. The LinkAlarm Database is a tab delimited text file of the information required to calculate the local location of a URI. It can be stored anywhere on the local filesystem, but usually resides in the same directory as the LinkAlarm Admin application. The LinkAlarm Preferences file contains the file paths to a) the LinkAlarm Admin application and b) the preferred HTML editor. The LinkAlarm Database and Preferences files can only be modified by a user with physical access to the computer on which they reside. Presenting the functionality of opening a user-specified file with a user-specified application from a web page sounds to be a security threat. However, the opening action is only passed to the application if there exists a setting in the LinkAlarm Admin application for the corresponding URI. That setting may only be made by a human with physical access to the computer and security access to execute the LinkAlarm Admin application. A malicious perpetrator may be cunning enough to prepare and host an HTML page coded with an EMBED TAG that displays the LinkAlarm Plug-in. If an innocent person using the LinkAlarm Plug-in came to this page and pressed the button to edit the file, the following error message would be presented. "The LinkAlarm plug-in could not find the HTML file for this page." http://www.hacker.com/nasty.html The user has option to: Cancel - going back to the browser Go Browser Go Editor LinkAlarm Settings - go to the LinkAlarm Admin app. The LinkAlarm plug-in does not have the ability to write to the LinkAlarm Database file specifying the location of executable applications and HTML files, so it is impossible for a malicious perpetrator to change the operation of the LinkAlarm "open" execution to files and application of his desire. Interoperability considerations: This MIME Type will be used with the LinkAlarm plug-in in conjunction with reports provided online by Link Alarm Inc. The LinkAlarm Plug-in and Admin application are distributed in binary format only for operation on Macintosh PowerPC computers running MacOS and computers running Windows95 or Windows NT. Published specification: A publicly available specification for usage is not required, as Link Alarm Inc is the only entity providing functionality from it's published link checking reports. Applications which use this media type: LinkAlarm Plug-in, a Netscape compatible browser plug-in for use with compatible browsers. Additional information: Magic number(s): File extension(s): alr (Windows only) Macintosh File Type Code(s): LALM (registered 30/MAR/98) Person & email address to contact for further information: George Bray Link Alarm, Inc. Phone: +1 650 429 2144 Fax: +1 650 429 2144 Email: mailto:george.bray@linkalarm.com Web: http://www.linkalarm.com Intended usage: LIMITED USE Author/Change controller: George Bray -- George Bray Link Alarm, Inc. Suite 641, 2245 North Green Valley Parkway Henderson, NV 89014, U.S.A. Phone: +1 650 429 2144 Fax: +1 650 429 2144 Email: mailto:george.bray@linkalarm.com Web: http://www.linkalarm.com