From owner-ietf-xml-mime Sun Apr 4 20:04:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA11753 for ietf-xml-mime-bks; Sun, 4 Apr 1999 20:04:05 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11746 for ; Sun, 4 Apr 1999 20:04:04 -0700 (PDT) Message-Id: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Sun, 04 Apr 1999 20:04:32 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: OK, we've got about 30 people who signed up for the list. I think the first order of business is for someone to say what is incorrect and/or lacking in RFC 2376. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Sun Apr 4 20:33:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA14446 for ietf-xml-mime-bks; Sun, 4 Apr 1999 20:33:27 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA14439 for ; Sun, 4 Apr 1999 20:33:26 -0700 (PDT) Received: by mx.fujixerox.co.jp; id MAA20657; Mon, 5 Apr 1999 12:33:54 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma020502; Mon, 5 Apr 99 12:33:17 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id MAA17304; Mon, 5 Apr 1999 12:31:10 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id MAA14263; Mon, 5 Apr 1999 12:33:15 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id MAA26949; Mon, 5 Apr 1999 12:31:17 +0900 Message-Id: <199904050333.AA00171@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 05 Apr 1999 12:33:03 +0900 To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Hoffman / IMC wrote: > OK, we've got about 30 people who signed up for the list. I think the first > order of business is for someone to say what is incorrect and/or lacking in > RFC 2376. Here it is. I will also post my summary of the discussion at the xml-dev mailing list very soon. Makoto ------------------------------------------------------------- Needs more information in the MIME header! (DRAFT) MURATA Makoto, Paul Hoffman, Frank Dawson, Jim Whitehead 1. Problem statement We would like the MIME parser to be able to dispatch different sorts of XML documents to different applications, such as specialized programs that handle just one type of XML document. Because MIME parsers do not look inside the MIME parts, identifiying the sort of documents must be done in the MIME headers. However, neither text/xml nor application/xml allow such information. 2. Possible solutions Three approaches have been proposed. They are (1) specialized media types such as text/calendar, (2) a top-level media type xml and its subtypes such as xml/calendar, and (3) a new parameter "externalid" of text/xml and applcation/xml. (1) Specialized mime types For each specialized applications of XML, we introduce a new subtype. It may introduce more parameters and might even have some added security consideration. This is the approach that has been assumed by the authors of RFC2376. Pros: Each application will be documented by some RFC. Cons: When the MIME parser does not know of such a subtype, the only available fallback is text/plain or application/octet-stream. That is, the MIME parser cannot invoke generic XML parsers/viewers, but has to display the document as a plain text file or save the document in a file. Each specialized application will require a new subtype registration, which takes a lot of time and therefore can have long delays. (2) New top-level media type xml and its subtypes Pros: Fallback to "xml/plain" allows the use of generic XML parsers/viewers. We can also lift the line termination rule of the top-level media type "text". Cons: It is extremely difficult to register a new top-level media type and therefore can have long delays (practically, who wants to do this?). The default behavior is probably not a good enough reason. Each specialized application will require a new subtype registration, which takes a lot of time and therefore can have long delays. (3) A new parameter "externalid" for text/xml and application/xml This parameter specifies the externalID from the DOCTYPE of the XML document (if the DOCTYPE is present). Examples would be: Content-type: text/xml; externalid="http://www.foo.com/whizzy.dtd" or Content-type: application/xml; charset="utf-16be"; externalid="-//IETF//DTD vCard v3.0//EN" Pros: This is probably the easiest solution which also provides XML-specific fallback. Requires no registration with a central authority. Other parameters can be added in the future when we have new schemata or when we find new usage patterns for DTDs. The definitions for those parameters can define which sets of parameters can appear together. Cons: DTD's do not necessarily exist. For example, RFD metadata do not have DTD's. The use of DTD's to choose applications might be an abuse of DTD's. Moreover, some DTD's might be handled by many different programs on a system, such as by a specialized processor and one or more XML browsers. On the other hand, some applications (such as XML browsers) handle a variety of DTD's. There will be new schemata that will probably overshadow DTD's, and these schemata may not use externalIDs the same way they are used in today's DTDs. (4) Yet another parameter "optinfo" or "ADD-PARAM" On top of (3), provide yet another parameter "optinfo" (list of name-value pairs) or "ADD-PARAM" (plain text) for additional information. Pros: Some applications of XML require even more appliction-specfic information so as to launch appropriate software tools. For example, if iCalendar information is captured by an XML DTD, the text/xml or application/xml MIME header has to mimick "method", "component", and "optinfo" of text/icalendar. (The latest internet draft for text/icalendar is available at: ftp://ftp.isi.edu/internet-drafts/draft-ietf-calsch-ical-12.txt) If this parameter is not available, people will abuse the parameter "externalid" by providing different names for the same DTD so as to express more information. This parameter stops such abuse. Cons: The "optinfo" parameter makes it difficult for a simple MIME parser to know what to expect in the parameter. The "ADD-PARAM" parameter does not have this problem, but does not have enough expressiveness. Note: None of the above proposals handle non-monolithic XML documents very well, since different islands of non-monolithic XML documents belong to different namespaces and thus different schemata. For example, the MIME parser cannot invoke vCard applications if the vCard is embeded by the namespace mechanism. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Sun Apr 4 20:38:29 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA14789 for ietf-xml-mime-bks; Sun, 4 Apr 1999 20:38:29 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA14784; Sun, 4 Apr 1999 20:38:28 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id EAA09623; Mon, 5 Apr 1999 04:37:16 -0700 Message-Id: <3.0.32.19990404203656.00c71cc0@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 04 Apr 1999 20:38:54 -0700 To: Paul Hoffman / IMC , ietf-xml-mime@imc.org From: Tim Bray Subject: Re: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 08:04 PM 4/4/99 -0700, Paul Hoffman / IMC wrote: >OK, we've got about 30 people who signed up for the list. I think the first >order of business is for someone to say what is incorrect and/or lacking in >RFC 2376. And just to save folks a couple of keyclicks, that's at http://www.cis.ohio-state.edu/htbin/rfc/rfc2376.html -Tim From owner-ietf-xml-mime Sun Apr 4 23:09:25 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA17385 for ietf-xml-mime-bks; Sun, 4 Apr 1999 23:09:25 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA17380 for ; Sun, 4 Apr 1999 23:09:20 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52150(1)>; Sun, 4 Apr 1999 23:09:43 PDT Received: from copper.parc.xerox.com ([13.0.211.121]) by thelma.parc.xerox.com with SMTP id <98053>; Sun, 4 Apr 1999 23:09:32 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Starting the ietf-xml-mime mailing list Date: Sun, 4 Apr 1999 23:09:03 PDT Message-ID: <000b01be7f2a$cdef0420$79d3000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199904050333.AA00171@archlute.apsdc.ksp.fujixerox.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > 1. Problem statement > > We would like the MIME parser to be able to dispatch different sorts > of XML documents to different applications, such as specialized > programs that handle just one type of XML document. Because MIME > parsers do not look inside the MIME parts, identifiying the sort of > documents must be done in the MIME headers. However, neither text/xml > nor application/xml allow such information. > > 2. Possible solutions > > Three approaches have been proposed. They are (1) specialized media > types such as text/calendar, (2) a top-level media type xml and its > subtypes such as xml/calendar, and (3) a new parameter "externalid" of > text/xml and applcation/xml. You left out the obvious one: for some kinds of media, it is necessary for the handler of the MIME media type to actually dispatch to one of several possible media type handlers. Rather than fixing MIME, which does the job of labelling data adequately, why not fix the software? In general, you cannot solve the problem of "dispatch to the appropriate handler" by modifying MIME, since finding the appropriate handler is platform and installation dependent. Some elements of this argument were taking place in a discussion with the W3C HTML working group, which was considering registering "text/xhtml" as a way of representing the XMLified version of HTML. MIME types are also used in some instances in "content negotiation" (prospectively telling a recipient what something would be if it were to be subsequently retrieved), as well as in "content labelling". New media types and media parameters don't help much with either, unfortunately. Many current implementations of content dispatch don't allow dispatch based on media type parameters, in any case. E.g., you can't select one handler for "text/plain;charset=us-ascii" and a different one for "text/plain;charset=utf8", even though you might have a more desirable ascii-only editor and a slower or fuller Unicode-based editor installed. So adding more parameters doesn't really help for content-dispatch with current implementations. And adding more MIME types for each kind of combination of XML seems like a recipe for disaster. If we have html, xhtml, html-netscape, html-microsoft, html-optimized-for-msie-on-windows-nt50, each with slightly different definitions, would they get separate MIME types? The same arguments apply for profiles of TIFF, and probably apply to profiles of Postscript. Postscript-2-laserwriter-fonts isn't a separate MIME type from Postscript-1, even though in situations, you might have the capability of displaying one but only printing the other. From owner-ietf-xml-mime Sun Apr 4 23:12:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA17411 for ietf-xml-mime-bks; Sun, 4 Apr 1999 23:12:09 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA17407 for ; Sun, 4 Apr 1999 23:12:07 -0700 (PDT) Received: from enoshima (dhcp-100-206.mag.keio.ac.jp [133.27.195.206]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id PAA02575; Mon, 5 Apr 1999 15:12:19 +0900 (JST) Message-Id: <199904050612.PAA02575@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: Mon, 05 Apr 1999 14:35:56 +0900 To: MURATA Makoto From: "Martin J. Duerst" Subject: Re: Starting the ietf-xml-mime mailing list Cc: ietf-xml-mime@imc.org In-Reply-To: <199904050333.AA00171@archlute.apsdc.ksp.fujixerox.co.jp> References: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:33 99/04/05 +0900, MURATA Makoto wrote: > Paul Hoffman / IMC wrote: > > OK, we've got about 30 people who signed up for the list. I think the first > > order of business is for someone to say what is incorrect and/or lacking in > > RFC 2376. > > Here it is. I will also post my summary of the discussion at the xml-dev > mailing list very soon. > (3) A new parameter "externalid" for text/xml and application/xml > > This parameter specifies the externalID from the DOCTYPE of the XML > document (if the DOCTYPE is present). Examples would be: > > Content-type: text/xml; > externalid="http://www.foo.com/whizzy.dtd" > or > Content-type: application/xml; charset="utf-16be"; > externalid="-//IETF//DTD vCard v3.0//EN" > Note: None of the above proposals handle non-monolithic XML documents very well, > since different islands of non-monolithic XML documents belong to different > namespaces and thus different schemata. For example, the MIME parser cannot > invoke vCard applications if the vCard is embeded by the namespace mechanism. I think this will become more and more important, and we should try to find a solution that doesn't exclude it. On first sight, it doesn't look so difficult: Define one parameter, maybe named "namespaces", that lists, comma-separated, all the namespaces used in the document. The DOCTYPE, if present, counts as one. The DOCTYPE, or the namespace of the root element, is listed first. If other description mechanisms (schemas,...) are defined, the URIs used for them can also be used. If I'm overlooking something, please tell me. Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-xml-mime Sun Apr 4 23:16:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA17453 for ietf-xml-mime-bks; Sun, 4 Apr 1999 23:16:46 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA17449 for ; Sun, 4 Apr 1999 23:16:46 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id HAA09706; Mon, 5 Apr 1999 07:15:23 -0700 Message-Id: <3.0.32.19990404231404.00c716a0@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 04 Apr 1999 23:17:02 -0700 To: "Larry Masinter" , "MURATA Makoto" , From: Tim Bray Subject: RE: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:09 PM 4/4/99 PDT, Larry Masinter wrote: >In general, you cannot solve the problem of "dispatch to the appropriate >handler" by modifying MIME, since finding the appropriate handler is >platform and installation dependent. Although you don't say so, I believe you are arguing against the desirability of an additional media type parameter. Right? -T. From owner-ietf-xml-mime Sun Apr 4 23:21:54 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA17485 for ietf-xml-mime-bks; Sun, 4 Apr 1999 23:21:54 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA17481 for ; Sun, 4 Apr 1999 23:21:53 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9MVRHLZTC8WWH73@INNOSOFT.COM> for ietf-xml-mime@imc.org; Sun, 4 Apr 1999 23:21:22 PDT Date: Sun, 04 Apr 1999 23:05:23 -0700 (PDT) From: Ned Freed Subject: Re: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Mon, 05 Apr 1999 12:33:03 +0900" <199904050333.AA00171@archlute.apsdc.ksp.fujixerox.co.jp> To: MURATA Makoto Cc: ietf-xml-mime@imc.org Message-id: <01J9NIKKFTKO8WWH73@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > (1) Specialized mime types > For each specialized applications of XML, we introduce a new subtype. > It may introduce more parameters and might even have some added > security consideration. This is the approach that has been assumed by > the authors of RFC2376. And it is what is already happening. We've registered several dozen of these already. > Pros: > Each application will be documented by some RFC. This isn't true. The standards say that RFC documentation is only required for registration in the IETF tree, and in practice none of the many registered XML-based types have been backed up with RFCs. > Cons: > When the MIME parser does not know of such a subtype, the only > available fallback is text/plain or application/octet-stream. That > is, the MIME parser cannot invoke generic XML parsers/viewers, but has > to display the document as a plain text file or save the document in a > file. This is a legitimate concern, although in practice what happens is that applications let you assign a viewer to an unknown type in fairly flexible ways. In other words, in practice this isn't all that much of a problem. > Each specialized application will require a new subtype registration, > which takes a lot of time and therefore can have long delays. This isn't true. Registrations now routinely take only a few days if they don't contain egregious errors. And we've been known to get them done in less than a day in some cases. Registrations containing errors take longer, of course. But feedback is quick, typically taking only a day or two, so the burden is on the person doing the registration to turn the thing around in a timely way. > (2) New top-level media type xml and its subtypes > Pros: > Fallback to "xml/plain" allows the use of generic XML parsers/viewers. > We can also lift the line termination rule of the top-level media type > "text". Most XML objects have no business being registered under text anyhow, so this isn't much of an advantage. > Cons: > It is extremely difficult to register a new top-level media type and > therefore can have long delays (practically, who wants to do this?). > The default behavior is probably not a good enough reason. It isn't a question of difficulty, it is a question of legitimacy. To do this you have to write a document that justifies the creation of such a thing. Do so and you likely won't have much of a problem, fail to do so and this approach isn't viable. > Each specialized application will require a new subtype registration, > which takes a lot of time and therefore can have long delays. Again, this just isn't true. > (3) A new parameter "externalid" for text/xml and application/xml > This parameter specifies the externalID from the DOCTYPE of the XML > document (if the DOCTYPE is present). Examples would be: > Content-type: text/xml; > externalid="http://www.foo.com/whizzy.dtd" > or > Content-type: application/xml; charset="utf-16be"; > externalid="-//IETF//DTD vCard v3.0//EN" > Pros: > This is probably the easiest solution which also provides XML-specific > fallback. > Requires no registration with a central authority. > Other parameters can be added in the future when we have new schemata > or when we find new usage patterns for DTDs. The definitions for those > parameters can define which sets of parameters can appear together. > Cons: > ... I'm afraid you've missed the biggest problem with this approach -- one that makes it almost a complete nonstarter: The lack of ability to dispatch on parameters in most applications that support MIME. Not only do applications lack this ability, there are also quite a few contexts where MIME labelling is used that don't support parameters, period. So in all these cases you end up being reduced to a single dispatch path for everything that's based on XML. As I say, its a total nonstarter. > (4) Yet another parameter "optinfo" or "ADD-PARAM" This has all the problems of (3). Ned From owner-ietf-xml-mime Sun Apr 4 23:36:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA17578 for ietf-xml-mime-bks; Sun, 4 Apr 1999 23:36:27 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA17574 for ; Sun, 4 Apr 1999 23:36:26 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52198(5)>; Sun, 4 Apr 1999 23:36:52 PDT Received: from copper.parc.xerox.com ([13.0.211.121]) by thelma.parc.xerox.com with SMTP id <98068>; Sun, 4 Apr 1999 23:36:43 PDT From: "Larry Masinter" To: "Tim Bray" , "MURATA Makoto" , Subject: RE: Starting the ietf-xml-mime mailing list Date: Sun, 4 Apr 1999 23:36:22 PDT Message-ID: <000d01be7f2e$9f23cfa0$79d3000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <3.0.32.19990404231404.00c716a0@pop.intergate.bc.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > At 11:09 PM 4/4/99 PDT, Larry Masinter wrote: > >In general, you cannot solve the problem of "dispatch to the appropriate > >handler" by modifying MIME, since finding the appropriate handler is > >platform and installation dependent. > > Although you don't say so, I believe you are arguing against the > desirability of an additional media type parameter. Right? -T. As far as I can tell, adding parameters doesn't solve the problem, and introduces other, possibly more severe, problems. So yes, I'm arguing against it. Larry From owner-ietf-xml-mime Mon Apr 5 01:30:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18288 for ietf-xml-mime-bks; Mon, 5 Apr 1999 01:30:38 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18284 for ; Mon, 5 Apr 1999 01:30:36 -0700 (PDT) Received: by mx.fujixerox.co.jp; id RAA03231; Mon, 5 Apr 1999 17:31:07 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma003107; Mon, 5 Apr 99 17:30:35 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id RAA17660 for ; Mon, 5 Apr 1999 17:28:29 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id RAA26182 for ; Mon, 5 Apr 1999 17:30:34 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id RAA01715 for ; Mon, 5 Apr 1999 17:28:36 +0900 Message-Id: <199904050830.AA00181@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 05 Apr 1999 17:30:22 +0900 To: ietf-xml-mime@imc.org Subject: List of issues MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I compiled a list of issues raised in the past. Although there are seven issues in this list, I would like to concentrate on the first issue for a while. Issue 1: Proposals for additional parameters in the past Namespace URI: It specifies the URI of the top-level namespace of the XML document Schema URI It specifies the URI of the top-level schema of the XML document DTD URI: It specifies the URI of the DTD of the XML document Class URI: It specifies the class of the XML document which will be handled by the same application programs (Note: RDF metadata are XML documents without DTD's, but every RDF metadata can be handled by the same program. XML documents with CSS stylesheets can be displayed by WWW browsers, evenif they do not have DTDs.) Conformance Profile URI: It specifies an XHTML conformance profile. Application URI: It speficies the URI of application programs Root element type: This was suggested as an addition to the namespace/schema/DTD/class URI. Issue 2: Type of XML mime entities There are four types of XML MIME entities. In the XML terminology, they are called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". The media types text/xml and application/xml can be used for any of these four types. Do we need some parameter to distinguish these four types? (Note that a MIME entity can be an external parsed entity AND a document entity at the same time. Some external DTD subsets can also be used as external parameter entities.) Issue 3: UTF-16 RFC 2376 should be revised when charsets for UTF-16 are registered. Currently, there is an internet draft for UTF-16 registration. Issue 4: Characters .vs. bytes An XML MIME entity is a sequence of characters as opposed to a sequence of bytes. RFC 2376 is not really clear about this. Issue 5: Packaging There should be a mechanism for packaging an XML document together with its stylesheet, catalog, and referenced resources (e.g., links, external entities). One possibility is MHTML. ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-11.txt ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-rev-07.txt Issue 6: Ambiguity of CCS conversion If an XML document is encoded in some charset whose CCS is not Unicode, XML processors will map the CCS to Unicode. For example, in the case of Shift_JIS, we need a mapping from JIS X 0201 + JIS X0208 to Unicode. Unfortunately, there are more than one mapping in the world. For example, the XML parser of IBM uses Javasoft mapping and that of Javasoft uses Microsoft mapping. I heard that many other charsets have such ambiguities. If this is the case, it might make sense to introduce a parameter "map" to precisely specify which mapping should be used. Issue 7: The default of the charset parameter Chris Lilley's recent proposal to revised RFC2376 is as below: > 1) Require explicit charset for overriding the internal encoding > declaration, so if one really wants to re-label a document as US-ASCII > one actually has to send it out as text/xml; charset="US-ASCII" > > 2) Define the absence of an explicit charset encoding in the MIME > header not as "US-ASCII" but as "use encoding in XML instance" in > accordance with the XML 1.0 Recommendation. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 6 05:47:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16258 for ietf-xml-mime-bks; Tue, 6 Apr 1999 05:47:49 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16253; Tue, 6 Apr 1999 05:47:48 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA25909; Tue, 6 Apr 1999 08:48:22 -0400 Message-ID: <370A020B.8CE866F2@w3.org> Date: Tue, 06 Apr 1999 14:46:03 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Hoffman / IMC wrote: > > OK, we've got about 30 people who signed up for the list. I think the first > order of business is for someone to say what is incorrect and/or lacking in > RFC 2376. Given the host of the list (Internet Mail Consortium) I would like to first ask for a clarification; is the topic of discussion *just* the use of MIME with XML for email, or does it also include the use of MIME with XML for HTTP and any other protocols. -- Chris From owner-ietf-xml-mime Tue Apr 6 09:47:30 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19302 for ietf-xml-mime-bks; Tue, 6 Apr 1999 09:47:30 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19298; Tue, 6 Apr 1999 09:47:28 -0700 (PDT) Message-Id: <4.2.0.32.19990406094521.00bf9800@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Tue, 06 Apr 1999 09:47:36 -0700 To: Chris Lilley From: Paul Hoffman / IMC Subject: Re: Starting the ietf-xml-mime mailing list Cc: ietf-xml-mime@imc.org In-Reply-To: <370A020B.8CE866F2@w3.org> References: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:46 PM 4/6/99 +0200, Chris Lilley wrote: >Given the host of the list (Internet Mail Consortium) Hey, we host lists that have little or nothing to do with email (not that I try to do that too often...) > I would like to >first ask for a clarification; is the topic of discussion *just* the use >of MIME with XML for email, or does it also include the use of MIME with >XML for HTTP and any other protocols. The latter. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Tue Apr 6 13:50:16 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21989 for ietf-xml-mime-bks; Tue, 6 Apr 1999 13:50:16 -0700 (PDT) Received: from torque.pothole.com ([209.94.126.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21985 for ; Tue, 6 Apr 1999 13:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id QAA02470 for ietf-xml-mime@imc.org; Tue, 6 Apr 1999 16:50:52 -0400 (EDT) Message-Id: <199904062050.QAA02470@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-reply-to: Your message of "Tue, 06 Apr 1999 09:47:36 PDT." <4.2.0.32.19990406094521.00bf9800@mail.imc.org> Date: Tue, 06 Apr 1999 16:50:52 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I consider the original question to have been pretty insulting. There is only one set of MIME types for all uses. The name of the list is ietf-xml-mime, not email-xml-mime. If it had been hosted at the W3C, would non-web uses have been ignored? Donald From: Paul Hoffman / IMC Message-Id: <4.2.0.32.19990406094521.00bf9800@mail.imc.org> X-Sender: phoffman@mail.imc.org Date: Tue, 06 Apr 1999 09:47:36 -0700 To: Chris Lilley Cc: ietf-xml-mime@imc.org In-Reply-To: <370A020B.8CE866F2@w3.org> References: <4.2.0.32.19990404200153.00c6a820@mail.imc.org> List-Archive: List-Unsubscribe: >At 02:46 PM 4/6/99 +0200, Chris Lilley wrote: >>Given the host of the list (Internet Mail Consortium) > >Hey, we host lists that have little or nothing to do with email (not that I >try to do that too often...) > >> I would like to >>first ask for a clarification; is the topic of discussion *just* the use >>of MIME with XML for email, or does it also include the use of MIME with >>XML for HTTP and any other protocols. > >The latter. > > >--Paul Hoffman, Director >--Internet Mail Consortium From owner-ietf-xml-mime Tue Apr 6 23:31:16 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA15376 for ietf-xml-mime-bks; Tue, 6 Apr 1999 23:31:16 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA15371 for ; Tue, 6 Apr 1999 23:31:14 -0700 (PDT) Received: by mx.fujixerox.co.jp; id PAA05667; Wed, 7 Apr 1999 15:31:54 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma005472; Wed, 7 Apr 99 15:31:33 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id PAA10067 for ; Wed, 7 Apr 1999 15:29:27 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id PAA10011 for ; Wed, 7 Apr 1999 15:31:30 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id PAA07356 for ; Wed, 7 Apr 1999 15:29:28 +0900 Message-Id: <199904070631.AA00213@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 07 Apr 1999 15:31:09 +0900 To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <199904050612.PAA02575@sh.w3.mag.keio.ac.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Martin J. Duerst wrote: I wrote: > > Note: None of the above proposals handle non-monolithic XML documents very well, > > since different islands of non-monolithic XML documents belong to different > > namespaces and thus different schemata. For example, the MIME parser cannot > > invoke vCard applications if the vCard is embeded by the namespace mechanism. > > I think this will become more and more important, and we should try to find > a solution that doesn't exclude it. On first sight, it doesn't look so difficult: > > Define one parameter, maybe named "namespaces", that lists, comma-separated, > all the namespaces used in the document. The DOCTYPE, if present, counts as > one. The DOCTYPE, or the namespace of the root element, is listed first. > If other description mechanisms (schemas,...) are defined, the URIs used > for them can also be used. I am wondering if it is really a good idea to put every information in the MIME header. How can a MIME processor or vCard application extract a vCard fragment from the XML document? To do so, somebody has to parse the document. But if somebody has to parse it anyway, it should be really easy to find which namespace appears in the document. Thus, there is not much point in having namespace information in the MIME header. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 6 23:37:30 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA15686 for ietf-xml-mime-bks; Tue, 6 Apr 1999 23:37:30 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA15682 for ; Tue, 6 Apr 1999 23:37:29 -0700 (PDT) Received: by mx.fujixerox.co.jp; id PAA07668; Wed, 7 Apr 1999 15:38:07 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma007438; Wed, 7 Apr 99 15:37:23 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id PAA13074 for ; Wed, 7 Apr 1999 15:35:17 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id PAA10443 for ; Wed, 7 Apr 1999 15:37:22 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id PAA07512 for ; Wed, 7 Apr 1999 15:35:19 +0900 Message-Id: <199904070637.AA00214@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 07 Apr 1999 15:37:03 +0900 To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <01J9NIKKFTKO8WWH73@INNOSOFT.COM> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned, Thank you for your comments. Freed wrote: > > Each application will be documented by some RFC. > > This isn't true. The standards say that RFC documentation is only required for > registration in the IETF tree, and in practice none of the many registered > XML-based types have been backed up with RFCs. I will revise the summary accordingly. Registration in the IETF tree and that in the vendor tree are quite different. > > Each specialized application will require a new subtype registration, > > which takes a lot of time and therefore can have long delays. > > This isn't true. Registrations now routinely take only a few days if > they don't contain egregious errors. And we've been known to get them done > in less than a day in some cases. Is this in the vendor tree? > > (3) A new parameter "externalid" for text/xml and application/xml ... > I'm afraid you've missed the biggest problem with this approach -- one > that makes it almost a complete nonstarter: The lack of ability to dispatch > on parameters in most applications that support MIME. I will add this fact to the summary. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 6 23:39:48 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA15796 for ietf-xml-mime-bks; Tue, 6 Apr 1999 23:39:48 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA15792 for ; Tue, 6 Apr 1999 23:39:47 -0700 (PDT) Received: by mx.fujixerox.co.jp; id PAA08580; Wed, 7 Apr 1999 15:40:27 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma008232; Wed, 7 Apr 99 15:39:37 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id PAA13779 for ; Wed, 7 Apr 1999 15:37:31 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id PAA10575 for ; Wed, 7 Apr 1999 15:39:36 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id PAA07528 for ; Wed, 7 Apr 1999 15:37:36 +0900 Message-Id: <199904070639.AA00215@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 07 Apr 1999 15:39:19 +0900 To: Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <000b01be7f2a$cdef0420$79d3000d@copper.parc.xerox.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > > You left out the obvious one: for some kinds of media, it is necessary > for the handler of the MIME media type to actually dispatch to one > of several possible media type handlers. Rather than fixing MIME, > which does the job of labelling data adequately, why not fix the software? Yes, the summary (which was compiled long time ago) dos not have this obvious one. I will add this option. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 6 23:41:36 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA15933 for ietf-xml-mime-bks; Tue, 6 Apr 1999 23:41:36 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA15927 for ; Tue, 6 Apr 1999 23:41:35 -0700 (PDT) Received: by mx.fujixerox.co.jp; id PAA09370; Wed, 7 Apr 1999 15:42:15 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma009182; Wed, 7 Apr 99 15:41:55 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id PAA14760 for ; Wed, 7 Apr 1999 15:39:50 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id PAA10815 for ; Wed, 7 Apr 1999 15:41:52 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id PAA07538 for ; Wed, 7 Apr 1999 15:39:51 +0900 Message-Id: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 07 Apr 1999 15:41:37 +0900 To: Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <000d01be7f2e$9f23cfa0$79d3000d@copper.parc.xerox.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > As far as I can tell, adding parameters doesn't solve the problem, > and introduces other, possibly more severe, problems. So yes, I'm > arguing against it. Are you also against specialized media types? Or, you would like to make clear that specialized media types do not solve all problems? Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 6 23:58:20 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA16501 for ietf-xml-mime-bks; Tue, 6 Apr 1999 23:58:20 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA16495 for ; Tue, 6 Apr 1999 23:58:19 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <56003(4)>; Tue, 6 Apr 1999 23:58:57 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <104002>; Tue, 6 Apr 1999 23:58:56 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Starting the ietf-xml-mime mailing list Date: Tue, 6 Apr 1999 23:58:49 PDT Message-ID: <001d01be80c4$1681c020$79d3000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Are you also against specialized media types? Or, you would like > to make clear that specialized media types do not solve all problems? It's not clear that specialized media types solve any problem at all, in the case of XML that already contains a document declaration. For other situations, specialized media types should be introduced with caution, since a world in which every kind of document has its own media types is one in which there is little interoperability. Larry -- http://www.parc.xerox.com/masinter From owner-ietf-xml-mime Wed Apr 7 04:53:20 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27383 for ietf-xml-mime-bks; Wed, 7 Apr 1999 04:53:20 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27371 for ; Wed, 7 Apr 1999 04:53:17 -0700 (PDT) Received: from enoshima (ppp0ppp51.sfc.keio.ac.jp [133.27.13.72]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id UAA00140; Wed, 7 Apr 1999 20:53:29 +0900 (JST) Message-Id: <199904071153.UAA00140@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: Wed, 07 Apr 1999 16:33:23 +0900 To: MURATA Makoto From: "Martin J. Duerst" Subject: Re: Starting the ietf-xml-mime mailing list Cc: ietf-xml-mime@imc.org In-Reply-To: <199904070631.AA00213@archlute.apsdc.ksp.fujixerox.co.jp> References: <199904050612.PAA02575@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 15:31 99/04/07 +0900, MURATA Makoto wrote: > Martin J. Duerst wrote: > > Define one parameter, maybe named "namespaces", that lists, comma-separated, > > all the namespaces used in the document. The DOCTYPE, if present, counts as > > one. The DOCTYPE, or the namespace of the root element, is listed first. > > If other description mechanisms (schemas,...) are defined, the URIs used > > for them can also be used. > > I am wondering if it is really a good idea to put every information in > the MIME header. Definitely not. > How can a MIME processor or vCard application extract a vCard fragment > from the XML document? To do so, somebody has to parse the document. But > if somebody has to parse it anyway, it should be really easy to find > which namespace appears in the document. Thus, there is not much point > in having namespace information in the MIME header. If we apply this argument fully, then the doctype is also not necessary. I think that, in order to decide which application(s) handle the document, what we have to think about is things such as: - What namespaces are included in the document. - Which of these namespaces have to be understood completely in order to process the document reasonably. - Which of these namespaces can be processed partially, or just ignored. There may be applications that can e.g. only process pure XHTML, or XHTML with some other namespaces, or XHTML with any additional namespaces, and so on. Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-xml-mime Wed Apr 7 05:25:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27629 for ietf-xml-mime-bks; Wed, 7 Apr 1999 05:25:12 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27625 for ; Wed, 7 Apr 1999 05:25:10 -0700 (PDT) Received: by mx.fujixerox.co.jp; id VAA21878; Wed, 7 Apr 1999 21:25:52 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma021828; Wed, 7 Apr 99 21:25:35 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99033010) with ESMTP id VAA18456 for ; Wed, 7 Apr 1999 21:23:29 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id VAA23737 for ; Wed, 7 Apr 1999 21:25:34 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id VAA12481 for ; Wed, 7 Apr 1999 21:23:35 +0900 Message-Id: <199904071225.AA00227@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Wed, 07 Apr 1999 21:25:24 +0900 To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <199904071153.UAA00140@sh.w3.mag.keio.ac.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Martin J. Duerst wrote: > > > How can a MIME processor or vCard application extract a vCard fragment > > from the XML document? To do so, somebody has to parse the document. But > > if somebody has to parse it anyway, it should be really easy to find > > which namespace appears in the document. Thus, there is not much point > > in having namespace information in the MIME header. > > If we apply this argument fully, then the doctype is also not necessary. Exactly. I would like to know advantages and disadvantages of Larry's obvious solution (i.e., dispatch to the general-purpose XML parser which further dispatch to appropriate applictions). Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Wed Apr 7 06:45:08 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28397 for ietf-xml-mime-bks; Wed, 7 Apr 1999 06:45:08 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28392 for ; Wed, 7 Apr 1999 06:45:07 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id OAA10527; Wed, 7 Apr 1999 14:43:18 -0700 Message-Id: <3.0.32.19990407064311.00cc6a10@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Apr 1999 06:45:13 -0700 To: "Larry Masinter" , "MURATA Makoto" , From: Tim Bray Subject: RE: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:58 PM 4/6/99 PDT, Larry Masinter wrote: >It's not clear that specialized media types solve any problem at all, >in the case of XML that already contains a document declaration. Whereas I may well agree with Larry, I have to raise a red flag in connection with the term "document declaration". XML has something called a "document type declaration" which despite its name essentially gives no useful information about the type of the document or what software ought to be invoked to process it. The new namespace declarations should turn out to be more useful in software dispatching. -Tim From owner-ietf-xml-mime Wed Apr 7 07:52:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28974 for ietf-xml-mime-bks; Wed, 7 Apr 1999 07:52:34 -0700 (PDT) Received: from sprouts.arbortext.com (root@sprouts.arbortext.com [198.108.59.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28970 for ; Wed, 7 Apr 1999 07:52:32 -0700 (PDT) Message-Id: <3.0.32.19990407095211.0102b910@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Apr 1999 09:53:13 -0500 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 14:35 1999 04 05 +0900, Martin J. Duerst wrote: >Define one parameter, maybe named "namespaces", that lists, comma-separated, >all the namespaces used in the document. The DOCTYPE, if present, counts as >one. The DOCTYPE, or the namespace of the root element, is listed first. >If other description mechanisms (schemas,...) are defined, the URIs used >for them can also be used. This is extremely ironic given that the original namespace proposal developed by the XML WG was to have namespace declarations only in the prolog (at the top) of an XML document. This would have made lots of things easier, but higher authorities decided that it was necessary to completely revamp the namespace proposal at the last minute to give locally scoped namespace declarations. Now there is this suggestion to collect all declared namespaces at the top of the document again. Isn't this going around in circles? Whatever the reasons for going with locally scoped declarations, aren't most of them also reasons against listing all such decls at the top? From owner-ietf-xml-mime Wed Apr 7 09:02:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29570 for ietf-xml-mime-bks; Wed, 7 Apr 1999 09:02:51 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29566 for ; Wed, 7 Apr 1999 09:02:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27281; Wed, 7 Apr 1999 09:03:32 -0700 (PDT) Received: from mehitabel.eng.sun.com (mehitabel.Eng.Sun.COM [129.146.82.247]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id JAA07915; Wed, 7 Apr 1999 09:03:28 -0700 (PDT) Received: from mehitabel by mehitabel.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15189; Wed, 7 Apr 1999 09:03:08 -0700 Message-Id: <199904071603.JAA15189@mehitabel.eng.sun.com> Date: Wed, 7 Apr 1999 09:03:08 -0700 (PDT) From: Murray Altheim Reply-To: Murray Altheim Subject: XHTML Schemas, Namespace Ids, and Profiles To: ietf-xml-mime@imc.org, pgrosso@arbortext.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3XW0TK+3SzgClCJO79tTFA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: [time for a new thread...] Paul Grosso writes: > At 14:35 1999 04 05 +0900, Martin J. Duerst wrote: > >Define one parameter, maybe named "namespaces", that lists, comma-separated, > >all the namespaces used in the document. The DOCTYPE, if present, counts as > >one. The DOCTYPE, or the namespace of the root element, is listed first. > >If other description mechanisms (schemas,...) are defined, the URIs used > >for them can also be used. > > This is extremely ironic given that the original namespace proposal > developed by the XML WG was to have namespace declarations only in > the prolog (at the top) of an XML document. This would have made > lots of things easier, but higher authorities decided that it was > necessary to completely revamp the namespace proposal at the last > minute to give locally scoped namespace declarations. I've long argued that the truly broken part of the current namespace proposal is that the namespace 'declaration' occurs in the instance, and that any sort of multiple-document type schema processing must occur in the prolog, potentially even before the schema/DTD is encountered. For example, if I were to write an application that colonized several DTDs before attempting validation of an instance containing colonized names, I'd need to see the declarations *before* the DTDs. Apparently some do not see the prolog-instance separation as valuable. One of the things I've also been trying to assert in the HTML WG is the separation between the document type definition and the document [instance's] namespace. In documents containing a DOCTYPE the former is provided, and the namespace 'declaration' (damn, I can never quite remove those quotes) provides the namespace identifier. For XHTML, there is essentially one namespace, as regardless of which of the three DTDs (Strict, Transitional, or Frameset) the semantics for understanding and processing a specific element type are identical. One of the HTML WG work items is 'document profiles', some sort of extensible metadata container for information about the document type or instance. This might contain MIME information, further links to schema documentation, author contact info, interoperability data, etc. My thinking is that it would be hierarchical and potentially full of external links, so that applications can dig as deep as necessary for further information. Or simply use either the profile identifier or some node-level sub-identifier as a cookie. We'd for awhile discussed using the existing 'profile' attribute on , but for some reason which I can't recall now have moved away from that (either some people thought that we might not require in all XHTML 'family' doctypes, or that it was overloading the attribute). I do think it better as a separate element type, as this allows containment (and therefore inlining of a profile within a document). My current favorite syntax for linking a profile would borrow ideas from existing HTML stylesheet syntax, allowing for either an inline profile, or a link to an external profile. I think most people would find this intuitively obvious (given experience with stylesheets). Simple processors could use the profile URI as a cookie, or retrieve it to obtain further data. The Cruise of the Jasper B. ... or expanded: The Cruise of the Jasper B. ...TBD... ... The second example still includes the href, to point out the need to create a way to maintain a named identifier for profiles, if such an identifier is ever to be used as a cookie. Perhaps the 'title' attribute or some other means would be better -- just some ideas anyway. Above we see declarations for: (a) the XML declaration (potentially the encoding, etc.) (b) the DTD's name (publicId/FPI/URN) (c) the DTD's location (systemId/URI) (d) the document namespace identifier (as URI) (e) the document stylesheet type and location (URI) (f) the document profile location (URI) and while obviously not all are needed all the time, I can certainly see the ability to maintain this separation being quite valuable. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 An SGML declaration does not an i18n make. From owner-ietf-xml-mime Wed Apr 7 09:31:00 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29762 for ietf-xml-mime-bks; Wed, 7 Apr 1999 09:31:00 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29758 for ; Wed, 7 Apr 1999 09:30:59 -0700 (PDT) Message-Id: <4.2.0.32.19990407092004.00b50c00@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Wed, 07 Apr 1999 09:28:31 -0700 To: From: Paul Hoffman / IMC Subject: RE: Starting the ietf-xml-mime mailing list In-Reply-To: <001d01be80c4$1681c020$79d3000d@copper.parc.xerox.com> References: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dispatching based on media types raises a few important issues that are somewhat unique to XML. If we say "every application gets a new media type" then there is no clean way for a MIME-handling application to fall back to handing an unknown media type to an XML parser. An unclean way for such an application to handle an unknown media type is to look inside the first few octets of the body and, if it looks like XML, hand it off to the XML parser instead of treating it as application/octet-stream or text/plain. If we say "stick everything XMLish under a media type that is XML-specific with some parameter for the kind of XML" then we assume that handing off unknown body types to an XML parser is useful. I question this assumption. What's the XML parser going to do with this block of data? Display it? Not terribly valuable. Get some namespace information from the inside and then dispatch based on the namespace? Possibly valuable, but this begs the question of why wasn't that information out in the MIME headers. I tend to lean towards "every application gets a new media type". --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Wed Apr 7 09:44:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29855 for ietf-xml-mime-bks; Wed, 7 Apr 1999 09:44:35 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29850; Wed, 7 Apr 1999 09:44:34 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id RAA10561; Wed, 7 Apr 1999 17:43:29 -0700 Message-Id: <3.0.32.19990407094512.00cee720@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Apr 1999 09:45:16 -0700 To: Paul Hoffman / IMC , From: Tim Bray Subject: RE: Starting the ietf-xml-mime mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:28 AM 4/7/99 -0700, Paul Hoffman / IMC wrote: >Dispatching based on media types raises a few important issues that are >somewhat unique to XML. While I still haven't thought all this through 100%, Paul has a good point. There are two models we're going to see in the real world. 1. something generic gets the XML and parses it 1.a the generic something displays the XML to a human using a stylesheet, possibly with help from other logic for embedded chunks from different namespaces. 1.b the generic something invokes some application. The 1.a example is of course Web browsers (although it seems there are some nasty architectural holes in how you dispatch control for embedded chunks of XML). I have a hard time thinking of a 1.b example. 2. An app gets invoked to deal with a resource that happens to be encoded in XML, and the app uses its built-in XML parser. This case probably wants its own media type; the fact that the encoding is XML is hardly material. Which of these will be more common? I don't think anyone knows. But they are both very plausible and we need to make sure there's a good coherent story either way. -Tim From owner-ietf-xml-mime Wed Apr 7 09:53:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29910 for ietf-xml-mime-bks; Wed, 7 Apr 1999 09:53:14 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29906 for ; Wed, 7 Apr 1999 09:53:13 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9OPMH0SDC8WW98O@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 7 Apr 1999 09:53:41 PDT Date: Wed, 07 Apr 1999 09:49:44 -0700 (PDT) From: Ned Freed Subject: Re: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Wed, 07 Apr 1999 15:37:03 +0900" <199904070637.AA00214@archlute.apsdc.ksp.fujixerox.co.jp> To: MURATA Makoto Cc: ietf-xml-mime@imc.org Message-id: <01J9QX87YFAE8WW98O@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01J9NIKKFTKO8WWH73@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > Each application will be documented by some RFC. > > > > This isn't true. The standards say that RFC documentation is only required for > > registration in the IETF tree, and in practice none of the many registered > > XML-based types have been backed up with RFCs. > I will revise the summary accordingly. Registration in the IETF tree and > that in the vendor tree are quite different. Moreover, relatively few types belong in the IETF tree. > > > Each specialized application will require a new subtype registration, > > > which takes a lot of time and therefore can have long delays. > > > > This isn't true. Registrations now routinely take only a few days if > > they don't contain egregious errors. And we've been known to get them done > > in less than a day in some cases. > Is this in the vendor tree? The registration process is the same (i.e. fast) in *any* tree that currently exists. The slowness associated with the IETF tree has to do with RFC review, which is an entirely separate process from type registration. The only case where I could imagine the registration process being slow is if we delegate registration trees to some other organization that doesn't do it as quickly as we do. However, thus far no such delegation has taken place, so this is an entirely academic point. Ned From owner-ietf-xml-mime Wed Apr 7 10:37:11 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00506 for ietf-xml-mime-bks; Wed, 7 Apr 1999 10:37:11 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00501; Wed, 7 Apr 1999 10:37:09 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9OPMH0SDC8WW98O@INNOSOFT.COM>; Wed, 7 Apr 1999 10:37:41 PDT Date: Wed, 07 Apr 1999 10:27:54 -0700 (PDT) From: Ned Freed Subject: RE: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Wed, 07 Apr 1999 09:28:31 -0700" <4.2.0.32.19990407092004.00b50c00@mail.imc.org> To: Paul Hoffman / IMC Cc: ietf-xml-mime@imc.org Message-id: <01J9QYRR52GS8WW98O@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> <001d01be80c4$1681c020$79d3000d@copper.parc.xerox.com> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Dispatching based on media types raises a few important issues that are > somewhat unique to XML. > If we say "every application gets a new media type" then there is no clean > way for a MIME-handling application to fall back to handing an unknown > media type to an XML parser. An unclean way for such an application to > handle an unknown media type is to look inside the first few octets of the > body and, if it looks like XML, hand it off to the XML parser instead of > treating it as application/octet-stream or text/plain. > If we say "stick everything XMLish under a media type that is XML-specific > with some parameter for the kind of XML" then we assume that handing off > unknown body types to an XML parser is useful. I question this assumption. And I agree. While I have no strong objection to creating a special top-level type for XML-based things, what experience has shown is that fallback strategies of *any* sort tend to be overrated. In almost every case something has messed it up. Either we got the granularity wrong (and I see a very good chance of this happening here given the emergence of alternative forms of XML), or it didn't prove to offer useful functionality, or it simply didn't deploy in the manner in which we envisioned. About the only success story we have, actually, are the image/audio/video top-level types, and while these have worked out tolerably well, their actual value to end users isn't that great. > What's the XML parser going to do with this block of data? Display it? Not > terribly valuable. Get some namespace information from the inside and then > dispatch based on the namespace? Possibly valuable, but this begs the > question of why wasn't that information out in the MIME headers. It is valuable in the case of a developer who wants to fire up an XML editing tool. But let's be real here -- such a person had better be perfectly capable of assigning types to their editor. If they cannot they had best look for a new line of work. > I tend to lean towards "every application gets a new media type". In case it isn't obvious by now, so do I. Ned From owner-ietf-xml-mime Wed Apr 7 10:44:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00583 for ietf-xml-mime-bks; Wed, 7 Apr 1999 10:44:33 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA00578; Wed, 7 Apr 1999 10:44:33 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <56792(2)>; Wed, 7 Apr 1999 10:45:15 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <98986>; Wed, 7 Apr 1999 10:45:05 PDT From: "Larry Masinter" To: "Ned Freed" , "Paul Hoffman / IMC" Cc: Subject: RE: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 10:44:57 PDT Message-ID: <001301be811e$5a2308c0$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-to: <01J9QYRR52GS8WW98O@INNOSOFT.COM> Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > I tend to lean towards "every application gets a new media type". > > In case it isn't obvious by now, so do I. This is a fine maxim, but it begs the question: what constitutes a separate, distinct application, vs a modification, profile, extension, or varation of an old one? In the case where you're allowed to have a document that mixes traditional HTML, MathML, Vector Graphics ML, etc., are these separate "applications" or are they one "application" ("renderable XML document")? Larry From owner-ietf-xml-mime Wed Apr 7 11:42:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01200 for ietf-xml-mime-bks; Wed, 7 Apr 1999 11:42:27 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01191; Wed, 7 Apr 1999 11:42:25 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id NAA13160; Wed, 7 Apr 1999 13:42:58 -0500 Message-ID: <370BA739.C588519D@themacs.com> Date: Wed, 07 Apr 1999 13:43:05 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: Ned Freed , Paul Hoffman / IMC , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <001301be811e$5a2308c0$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > > > I tend to lean towards "every application gets a new media type". > > > > In case it isn't obvious by now, so do I. > > This is a fine maxim, but it begs the question: what constitutes > a separate, distinct application, vs a modification, profile, > extension, or varation of an old one? > > In the case where you're allowed to have a document that mixes > traditional HTML, MathML, Vector Graphics ML, etc., are these > separate "applications" or are they one "application" ("renderable > XML document")? Well... The issue is certainly complex. In the XHTML world, we envision a plethora of derivative document types based upon the defined XHTML modules and their semantics, other standard modules and THEIR semantics, and privately defined modules and THEIR semantics. While we are still actively debating the definition of "XHTML Family", it is clear to me that this family includes a significant subset of these derivative document types. So, if there is a type for XHTML (text/xhtml), then that type has to be flexible enough in definition to accommodate all documents with a type that falls within the XHTML family. A Conforming Client would be required to handle any XHTML family document in some sensible manner. So, in answer to your question, I think it is up to the developer of the Media Type to define the rules for inclusion within that type, and to do so carefully. If they do it wrong (as we did in text/html), then they will be forced to live with their error forever. If they do it right, then future documents will forever be compatible in some manner. Viola. Too simple? Perhaps. Too much magic? Perhaps again. However, we are not in a position to dictate what every possible application might do in the future. Better to tell the application developers to be circumspect, and let the market decide who did it right in the end. In case it isn't obvious, I too lean toward each application "family" having their own media type. This is the only broadly recognized announcement mechanism we have, after all. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Wed Apr 7 11:48:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01236 for ietf-xml-mime-bks; Wed, 7 Apr 1999 11:48:44 -0700 (PDT) Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01231; Wed, 7 Apr 1999 11:48:41 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9R0MO501S8WWG0C@INNOSOFT.COM>; Wed, 7 Apr 1999 11:47:26 PDT Date: Wed, 07 Apr 1999 11:38:51 -0700 (PDT) From: Ned Freed Subject: RE: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Wed, 07 Apr 1999 10:44:57 -0700 (PDT)" <001301be811e$5a2308c0$aa66010d@copper.parc.xerox.com> To: Larry Masinter Cc: Ned Freed , Paul Hoffman / IMC , ietf-xml-mime@imc.org Message-id: <01J9R178PHF88WWG0C@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <01J9QYRR52GS8WW98O@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > I tend to lean towards "every application gets a new media type". > > > > In case it isn't obvious by now, so do I. > This is a fine maxim, but it begs the question: what constitutes > a separate, distinct application, vs a modification, profile, > extension, or varation of an old one? > In the case where you're allowed to have a document that mixes > traditional HTML, MathML, Vector Graphics ML, etc., are these > separate "applications" or are they one "application" ("renderable > XML document")? But this then begs the more general question of whether there is to be an attempt to "design" the XML usage space, and if there is, whether such an attempt has any chance of succeeding. If the answer to this is "no, we don't want to try and control the development, direction, and use of XML" then your question is basically out of scope. People will design whatever they want and register whatever they want. The resulting mixtures and granularity will be whatever developers decide is appropriate. And in such a world I see little value in having an XML top level type. (Perhaps no real harm, but little value.) However, if the answer to this is "yes", then the task at hand becomes one of coming up with an appropriate set of rules that people think will actually do the job and will be followed. And in such a world a top-level XML type might have some value, if only as a place to attach the ruleset. (Delegation of XML registration would also be something to consider.) I basically don't have an opinion on which way this should go. My one observation is that the IETF at least has typically opted to try and stay out of areas like this in the past. Ned From owner-ietf-xml-mime Wed Apr 7 12:12:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01417 for ietf-xml-mime-bks; Wed, 7 Apr 1999 12:12:12 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01413 for ; Wed, 7 Apr 1999 12:12:10 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9R0MO501S8WWG0C@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 7 Apr 1999 12:11:46 PDT Date: Wed, 07 Apr 1999 12:07:42 -0700 (PDT) From: Ned Freed Subject: RE: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Tue, 06 Apr 1999 23:58:49 -0700 (PDT)" <001d01be80c4$1681c020$79d3000d@copper.parc.xerox.com> To: Larry Masinter Cc: MURATA Makoto , ietf-xml-mime@imc.org Message-id: <01J9R22E9EKC8WWG0C@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Are you also against specialized media types? Or, you would like > > to make clear that specialized media types do not solve all problems? > It's not clear that specialized media types solve any problem at all, > in the case of XML that already contains a document declaration. On the contrary, it is very clear that they do solve at least some set of problems. There is no explanation for the large numbers of people happily registering these things otherwise. We have ample experience to tell us that people won't bother with this sort of administration unless they see some possible advantage to doing it, and won't continue to do it unless those advantages turn out to be real. Ned From owner-ietf-xml-mime Wed Apr 7 12:21:37 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01506 for ietf-xml-mime-bks; Wed, 7 Apr 1999 12:21:37 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01502 for ; Wed, 7 Apr 1999 12:21:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01590; Wed, 7 Apr 1999 12:22:18 -0700 (PDT) Received: from mehitabel.eng.sun.com (mehitabel.Eng.Sun.COM [129.146.82.247]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id MAA18545; Wed, 7 Apr 1999 12:22:15 -0700 (PDT) Received: from mehitabel by mehitabel.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA15409; Wed, 7 Apr 1999 12:21:56 -0700 Message-Id: <199904071921.MAA15409@mehitabel.eng.sun.com> Date: Wed, 7 Apr 1999 12:21:56 -0700 (PDT) From: Murray Altheim Reply-To: Murray Altheim Subject: Re: Starting the ietf-xml-mime mailing list To: shane@themacs.com Cc: ietf-xml-mime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qvvvvt5gfmBJt1skw6QDkA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Shane P. McCarron writes: [...] > In case it isn't obvious, I too lean toward each application "family" > having their own media type. This is the only broadly recognized > announcement mechanism we have, after all. In thinking about this more, I can see the value in defining a new media type 'text/xhtml' for the family iff we see that all applications within that space using the same infrastructure and mechanisms for extensibility, so that any application within that space can predict how to read what has been extended and the implications of the extension. We *may* be able to solve that with document profiles. But if it's still open season within 'text/xhtml' then we've only put off the problem until later, and also compounded it by meaninglessly fragmented the 'text/xml' space. If there is a solution for XML it should be the same as for XHTML, and so my sense is that either the HTML WG's concept of document profiles is more usable generally in XML or we're duplicating what must also be done for XML. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 An SGML declaration does not an i18n make. From owner-ietf-xml-mime Wed Apr 7 12:37:52 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01660 for ietf-xml-mime-bks; Wed, 7 Apr 1999 12:37:52 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01656 for ; Wed, 7 Apr 1999 12:37:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09046; Wed, 7 Apr 1999 12:38:17 -0700 (PDT) Received: from mehitabel.eng.sun.com (mehitabel.Eng.Sun.COM [129.146.82.247]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id MAA21713; Wed, 7 Apr 1999 12:38:13 -0700 (PDT) Received: from mehitabel by mehitabel.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA15419; Wed, 7 Apr 1999 12:37:53 -0700 Message-Id: <199904071937.MAA15419@mehitabel.eng.sun.com> Date: Wed, 7 Apr 1999 12:37:52 -0700 (PDT) From: Murray Altheim Reply-To: Murray Altheim Subject: RE: Starting the ietf-xml-mime mailing list To: masinter@parc.xerox.com, Ned.Freed@INNOSOFT.COM Cc: murata@apsdc.ksp.fujixerox.co.jp, ietf-xml-mime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hFcbeW7n+Sv4FmQE4dMaFw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed writes: > Larry Masinter writes: > > MURATA Makoto wrote: > > > > > Are you also against specialized media types? Or, you would like > > > to make clear that specialized media types do not solve all problems? > > > It's not clear that specialized media types solve any problem at all, > > in the case of XML that already contains a document declaration. > > On the contrary, it is very clear that they do solve at least some set of > problems. There is no explanation for the large numbers of people happily > registering these things otherwise. We have ample experience to tell us that > people won't bother with this sort of administration unless they see some > possible advantage to doing it, and won't continue to do it unless those > advantages turn out to be real. On the contrary, there may be a very plausible reason why 'large numbers of people' are registering specialized media types: there is no suitable alternative that is supported by the browser vendors at large. There may be very real advantages in an organized content negotiation scheme, but they can't be realized if there is no vendor support. I don't believe that resorting to file extensions can possibly be the way of the future. We all need a better alternative. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 An SGML declaration does not an i18n make. From owner-ietf-xml-mime Wed Apr 7 12:55:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01775 for ietf-xml-mime-bks; Wed, 7 Apr 1999 12:55:10 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01767 for ; Wed, 7 Apr 1999 12:55:08 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id OAA13654; Wed, 7 Apr 1999 14:55:50 -0500 Message-ID: <370BB84E.E0D9F051@themacs.com> Date: Wed, 07 Apr 1999 14:55:58 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Murray Altheim CC: shane@themacs.com, ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <199904071921.MAA15409@mehitabel.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Murray Altheim wrote: > > Shane P. McCarron writes: > [...] > > In case it isn't obvious, I too lean toward each application "family" > > having their own media type. This is the only broadly recognized > > announcement mechanism we have, after all. > > In thinking about this more, I can see the value in defining a new > media type 'text/xhtml' for the family iff we see that all applications > within that space using the same infrastructure and mechanisms for > extensibility, so that any application within that space can predict > how to read what has been extended and the implications of the > extension. We *may* be able to solve that with document profiles. > > But if it's still open season within 'text/xhtml' then we've only put > off the problem until later, and also compounded it by meaninglessly > fragmented the 'text/xml' space. If there is a solution for XML it > should be the same as for XHTML, and so my sense is that either the > HTML WG's concept of document profiles is more usable generally in > XML or we're duplicating what must also be done for XML. Maybe the way to look at it is that the HTML WG is working in a space and developing a solution that MAY scale to be a general solution. However, the HTML space needs the solution now and we are in a good position to define the solution for the generic HTML-oriented client space. I realize that it would be great if we could define a generic solution for all XML documents, but I just don't see it happening quickly. I think that we can get an HTML-oriented solution ready in uni time (before the end of the year), and I think that it will be a solution that is readily implementable by our constituents (the wireless, television, and desktop client manufacturers). This would be a good thing. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Wed Apr 7 14:03:40 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02339 for ietf-xml-mime-bks; Wed, 7 Apr 1999 14:03:40 -0700 (PDT) Received: from robin.prod.itd.earthlink.net (robin.prod.itd.earthlink.net [207.217.120.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02335 for ; Wed, 7 Apr 1999 14:03:39 -0700 (PDT) Received: from fdawson (1Cust149.tnt2.durham.nc.da.uu.net [153.37.238.149]) by robin.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id OAA10209; Wed, 7 Apr 1999 14:04:15 -0700 (PDT) Message-ID: <013b01be8139$f7056f00$f95472c6@fdawson.lotus.com> From: "Earthlink" To: "Larry Masinter" , Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 17:02:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Massinter wrote, in part: >In general, you cannot solve the problem of "dispatch to the appropriate >handler" by modifying MIME, since finding the appropriate handler is >platform and installation dependent. I don't think that MIME is broken. What was poorly thought out was the content-type definition for XML. - - Frank From owner-ietf-xml-mime Wed Apr 7 14:07:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02391 for ietf-xml-mime-bks; Wed, 7 Apr 1999 14:07:49 -0700 (PDT) Received: from robin.prod.itd.earthlink.net (robin.prod.itd.earthlink.net [207.217.120.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02382 for ; Wed, 7 Apr 1999 14:07:48 -0700 (PDT) Received: from fdawson (1Cust149.tnt2.durham.nc.da.uu.net [153.37.238.149]) by robin.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id OAA16154; Wed, 7 Apr 1999 14:08:28 -0700 (PDT) Message-ID: <014001be813a$8dea9580$f95472c6@fdawson.lotus.com> From: "Earthlink" To: "Larry Masinter" , Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 17:06:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: >Many current implementations of content dispatch don't allow dispatch >based on media type parameters, in any case. E.g., you can't select >one handler for "text/plain;charset=us-ascii" and a different one >for "text/plain;charset=utf8", even though you might have a more >desirable ascii-only editor and a slower or fuller Unicode-based >editor installed. So adding more parameters doesn't really help >for content-dispatch with current implementations. I think you may be thinking about HTTP? Certainly with a mail protocol like IMAP you can look through your inbox for entries based on values of the MIME header fields. The example mentioned was a "mail-enabled" application. For this application, the implementors on the IETF CALSCH WG felt very much that the MIME header field parameters were of importance. If your implementation doesn't want to make use of them, fine. But other applications of this MIME content-type need it. That is the point. - - Frank From owner-ietf-xml-mime Wed Apr 7 14:41:11 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02717 for ietf-xml-mime-bks; Wed, 7 Apr 1999 14:41:11 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02713 for ; Wed, 7 Apr 1999 14:41:11 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9R3FOYCR48WWG0C@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 7 Apr 1999 14:40:06 PDT Date: Wed, 07 Apr 1999 14:36:03 -0700 (PDT) From: Ned Freed Subject: RE: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Wed, 07 Apr 1999 12:37:52 -0700 (PDT)" <199904071937.MAA15419@mehitabel.eng.sun.com> To: Murray Altheim Cc: masinter@parc.xerox.com, Ned.Freed@INNOSOFT.COM, murata@apsdc.ksp.fujixerox.co.jp, ietf-xml-mime@imc.org Message-id: <01J9R78BH7ZS8WWG0C@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > It's not clear that specialized media types solve any problem at all, > > > in the case of XML that already contains a document declaration. > > > > On the contrary, it is very clear that they do solve at least some set of > > problems. There is no explanation for the large numbers of people happily > > registering these things otherwise. We have ample experience to tell us that > > people won't bother with this sort of administration unless they see some > > possible advantage to doing it, and won't continue to do it unless those > > advantages turn out to be real. > On the contrary, there may be a very plausible reason why 'large numbers of > people' are registering specialized media types: there is no suitable > alternative that is supported by the browser vendors at large. There may > be very real advantages in an organized content negotiation scheme, but > they can't be realized if there is no vendor support. I don't believe that > resorting to file extensions can possibly be the way of the future. We > all need a better alternative. Murray, it sounds to me like you are agreeing with me, not disagreeing. All I ever claimed was that contrary to Larry's assertion, it is clear that a real problem is being solved by registering various XML-derived types. I never claimed that this is the correct solution to the problem, or that this is the only problem around that needs a solution, or that this wasn't a solution forced by the current characteristics of browsers. And nowhere did I say that file extensions are being used. These are MIME types, not file extensions. Ned From owner-ietf-xml-mime Wed Apr 7 14:44:21 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02742 for ietf-xml-mime-bks; Wed, 7 Apr 1999 14:44:21 -0700 (PDT) Received: from robin.prod.itd.earthlink.net (robin.prod.itd.earthlink.net [207.217.120.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02738 for ; Wed, 7 Apr 1999 14:44:20 -0700 (PDT) Received: from fdawson (1Cust149.tnt2.durham.nc.da.uu.net [153.37.238.149]) by robin.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id OAA04526; Wed, 7 Apr 1999 14:45:02 -0700 (PDT) Message-ID: <033901be813f$a7ace040$f95472c6@fdawson.lotus.com> From: "Earthlink" To: "Larry Masinter" , Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 17:43:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >It's not clear that specialized media types solve any problem at all, >in the case of XML that already contains a document declaration. The overhead of having to open up every XML document to find out what document type it is is not practical. As in the case of email, all I should have to do is ask for a particular type of object from the store and get it. In addition, though, we also want to get at subtypes of objects. Or in the case of MIME type/subtypes, this would be the "sub-sub type". For example, for a calendar object (text/calendar) we want to pull to the client just the "event invitations". This would be the "sub sub type" of type=text, subtype=calendar. - - Frank From owner-ietf-xml-mime Wed Apr 7 14:55:50 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02847 for ietf-xml-mime-bks; Wed, 7 Apr 1999 14:55:50 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA02843 for ; Wed, 7 Apr 1999 14:55:49 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <61525(2)>; Wed, 7 Apr 1999 14:56:26 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <101260>; Wed, 7 Apr 1999 14:56:15 PDT From: "Larry Masinter" To: "Earthlink" , Subject: RE: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 14:56:06 PDT Message-ID: <002401be8141$6fe9c040$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-to: <033901be813f$a7ace040$f95472c6@fdawson.lotus.com> Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > >It's not clear that specialized media types solve any problem at all, > >in the case of XML that already contains a document declaration. > Ned corrected me. There are *some* problems that might be solved by specialized media types. > The overhead of having to open up every XML document to find out what > document type it is is not practical. As in the case of email, all I should > have to do is ask for a particular type of object from the store and get it. > > In addition, though, we also want to get at subtypes of objects. Or in the > case of MIME type/subtypes, this would be the "sub-sub type". For example, > for a calendar object (text/calendar) we want to pull to the client just the > "event invitations". This would be the "sub sub type" of type=text, > subtype=calendar. This is a good example of a problem that specialized media types won't solve. You might also want to scan your email for "event invitations from my boss", and you can't solve that problem with specialized MIME media types. So the question is: are there any realistic cases where having a "text/calendar" distinction in the email header actually helps substantially in deciding which email bodies to retrieve? Larry From owner-ietf-xml-mime Wed Apr 7 15:11:20 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03021 for ietf-xml-mime-bks; Wed, 7 Apr 1999 15:11:20 -0700 (PDT) Received: from robin.prod.itd.earthlink.net (robin.prod.itd.earthlink.net [207.217.120.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03016; Wed, 7 Apr 1999 15:11:19 -0700 (PDT) Received: from fdawson (1Cust149.tnt2.durham.nc.da.uu.net [153.37.238.149]) by robin.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id PAA19792; Wed, 7 Apr 1999 15:11:56 -0700 (PDT) Message-ID: <039d01be8143$694257a0$f95472c6@fdawson.lotus.com> From: "Earthlink" To: , "Paul Hoffman / IMC" Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 18:10:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I think that this argument needs a realworld application to give it some bite. I really don't think that there is appreciation for the problem facing application developers who are looking at possibly using a XML representation for their object, but are frustrated with the current MIME definition for the XML content type. Paul Hoffman wrote: >I tend to lean towards "every application gets a new media type". Paul understand the calendaring and scheduling application about as well as any outsider to this application domain. I agree with his note that argues that the MIME header needs to provide cues to application-specific client agents (e.g., Calendar User Agent) that periodically peeks into the MIME entity bucket (e.g., inbox) to look for it's application specific messages. This is the paradigm that mail-enabled CUAs use today. However, just having a "calendar" media type won't cut it. The CUA needs to be able to search the MIME entity bucket for particular types of "calendar" media types. Some of the ones that the Internet community has standardized in RFC 2447 include: EVENT PUBLISH (publish some arbitrary calendar data) EVENT REQUEST (initial invitation, reschedule, delegate the invitation, response to a counter-proposal) EVENT REPLY (response to an invitation) EVENT CANCEL (cancel the meeting or uninvite a single individual) EVENT ADD (add a set of additional instances to an already scheduled event) EVENT COUNTER (proposal an alternate time/place) EVENT DECLINECOUNTER (decline a counter) EVENT REFRESH (now, tell me the latest details for this meeting I am invited to) TODO PUBLISH (publish an arbitrary set of action items) TODO REQUEST TODO REPLY TODO CANCEL TODO ADD TODO COUNTER TODO DECLINE COUNTER TODO REFRESH JOURNAL PUBLISH JOURNAL REQUEST JOURNAL REPLY JOURNAL CANCEL JOURNAL ADD JOURNAL REFRESH A typical CUA action is to look into the MIME entity bucket for new invitations. All of these scheduling messages "sub-sub types" are represented in the same single calendar media type. Tell me again, how you are going a scalable way for a "calendar portal" site that has 100s of thousands of calendar users wanting this info each day to service requests from CUAs for "new invitations" or "invitation responses"? You can't expect the calendar service to be able to parse ALL of the thousands of XML entities that are in the MIME entity bucket to first find the calendar ones and then the "new invitations" or "invitation responses". If calendaring doesn't provide a real enough example, think about electronic commerce and the millions of transactions a site may be handling a day. We can't expect an EDI client to have to parse each of the XML entities in the MIME bucket to find the "purchase orders". - - Frank From owner-ietf-xml-mime Wed Apr 7 15:19:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03109 for ietf-xml-mime-bks; Wed, 7 Apr 1999 15:19:05 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03105 for ; Wed, 7 Apr 1999 15:19:04 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01J9R3FOYCR48WWG0C@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 7 Apr 1999 15:17:37 PDT Date: Wed, 07 Apr 1999 15:10:31 -0700 (PDT) From: Ned Freed Subject: RE: Starting the ietf-xml-mime mailing list In-reply-to: "Your message dated Wed, 07 Apr 1999 14:56:06 -0700 (PDT)" <002401be8141$6fe9c040$aa66010d@copper.parc.xerox.com> To: Larry Masinter Cc: Earthlink , ietf-xml-mime@imc.org Message-id: <01J9R8JTQTIK8WWG0C@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <033901be813f$a7ace040$f95472c6@fdawson.lotus.com> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > In addition, though, we also want to get at subtypes of objects. Or in the > > case of MIME type/subtypes, this would be the "sub-sub type". For example, > > for a calendar object (text/calendar) we want to pull to the client just the > > "event invitations". This would be the "sub sub type" of type=text, > > subtype=calendar. > This is a good example of a problem that specialized media types won't solve. Agreed. My quick and dirty way of thinking of this is that the media type/subtype should to be sufficient to get you the right application, but the parameters then can tell that application what to do, or when to do it, or various other sorts of things that for whatever reason are best not stored in or derived from the actual content. > You might also want to scan your email for "event invitations from my boss", > and you can't solve that problem with specialized MIME media types. So the > question is: are there any realistic cases where having a "text/calendar" > distinction in the email header actually helps substantially in deciding > which email bodies to retrieve? Of course the general case of this problem may in fact be intractable, even with full access to message content. (Define "boss". Figure out how to relate the origin of a given event invitation to this definition of "boss". Etc.) However, in the general problem space surrounding these sorts of applications, I see value in using parameters. For example, I may wish to have certain sorts of calendar operations handled silently and automatically, whereas others need to be done manually. In short, I agree with Frank that parameters have their uses in this context. Ned From owner-ietf-xml-mime Wed Apr 7 15:51:29 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03410 for ietf-xml-mime-bks; Wed, 7 Apr 1999 15:51:29 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA03405; Wed, 7 Apr 1999 15:51:28 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <61701(5)>; Wed, 7 Apr 1999 15:52:10 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <101331>; Wed, 7 Apr 1999 15:52:03 PDT From: "Larry Masinter" To: "Earthlink" , , "Paul Hoffman / IMC" Subject: RE: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 15:51:59 PDT Message-ID: <000401be8149$3e82ae60$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-reply-to: <039d01be8143$694257a0$f95472c6@fdawson.lotus.com> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'm saying you definitely have a problem: you have a complex space of possible objects: "all possible calendaring events, with indication as to the applicable users, the nature of the event, whether it's a request, a response, the dates involved, urgent" You need to query this space, find those that match a particular set of criteria, and then retrieve the objects that match your criteria. Neither adding parameters to text/calendar nor inventing new MIME subtypes for text/calendar-request text/calendar-response etc. will help implement the query capabilities that you need. Since it doesn't work, stop trying. You need some other kind of query protocol than keying off content-type. > However, just having a "calendar" media type won't cut it. The CUA needs to > be able to search the MIME entity bucket for particular types of "calendar" > media types. No, I think this is a poor characterization. The CUA needs to be able to search the MIME entity bucket for particular calendar events that match a particular query, "all repeating events that do not occur on Thursday". Trying to cram this into the type space is just poor engineering. Yes, it needs to search the MIME entity bucket. No, the search is not characterized by "type". > All of these scheduling messages "sub-sub types" are represented in the same > single calendar media type. You may want to characterize them as "sub-sub types", but it is a misuse of the type space. > Tell me again, how you are going a scalable way > for a "calendar portal" site that has 100s of thousands of calendar users > wanting this info each day to service requests from CUAs for "new > invitations" or "invitation responses"? You can't expect the calendar > service to be able to parse ALL of the thousands of XML entities that are in > the MIME entity bucket to first find the calendar ones and then the "new > invitations" or "invitation responses". Someone has to parse them. Certainly if a search engine can parse web pages to find the words and their lexical equivalences, an event search engine can parse the XML documents and index them in the multiple ways that searching the calendar-event database needs to be searched. > If calendaring doesn't provide a real enough example, Yes, the example is real, and shows that this problem can't be solved by overloading the MIME type space. > think about electronic > commerce and the millions of transactions a site may be handling a day. We > can't expect an EDI client to have to parse each of the XML entities in the > MIME bucket to find the "purchase orders". Purchase orders that are applicable to the particular division, purchase orders that haven't already been processed, purchase orders that are assigned to a particular account rep, etc. These are all database search problems, not type-indexing problems. Larry From owner-ietf-xml-mime Wed Apr 7 16:16:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03689 for ietf-xml-mime-bks; Wed, 7 Apr 1999 16:16:03 -0700 (PDT) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03681 for ; Wed, 7 Apr 1999 16:16:02 -0700 (PDT) Received: from fdawson (1Cust85.tnt3.durham.nc.da.uu.net [153.37.239.85]) by snipe.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id QAA15197; Wed, 7 Apr 1999 16:16:41 -0700 (PDT) Message-ID: <04a601be814c$73738240$f95472c6@fdawson.lotus.com> From: "Frank Dawson" To: "Larry Masinter" , Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 19:14:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote, in part: >I'm saying you definitely have a problem: you have a complex space >of possible objects: NO, this is not a complex problem. This is an existing 20+ year old mail enabled application. This nut has already been cracked for Internet developers using the "text/calendar" content definition. I queried Kurita-san and Paul Hoffman because I was interested in utilizing XML representation of iCalendar. We have a DTD defined. It is an isomer of the iCalendar standard format, but the MIME content type defintiion for text/xml and application/xml stinks. It doesn't provide us (and soon other XML application developers too) the right tools to do our job. Tools that are already in place for the iCalendar content type. This is not a problem with MIME. This is not a problem with calendaring. This is a problem with the current definition for the XML content type. This mailing list is to air our discussion on how to best fix this, right? >Yes, the example is real, and shows that this problem can't be solved >by overloading the MIME type space. Well, I personally don't think that we have "overloaded" the calendar content type in the iCalendar content type definition. There needs to be some balance between an infinite number of media types/subtypes for each transaction type and a smaller, managable number of media types for each logical application object type. As Ned has pointed out, this example and other show that leaving "hooks" on the outside of the object wrapper is very useful in providing a scalable, practical Internet solution using XML. - - Frank From owner-ietf-xml-mime Wed Apr 7 16:16:01 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03679 for ietf-xml-mime-bks; Wed, 7 Apr 1999 16:16:01 -0700 (PDT) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03675 for ; Wed, 7 Apr 1999 16:15:59 -0700 (PDT) Received: from fdawson (1Cust85.tnt3.durham.nc.da.uu.net [153.37.239.85]) by snipe.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id QAA15147; Wed, 7 Apr 1999 16:16:38 -0700 (PDT) Message-ID: <04a501be814c$7203c5a0$f95472c6@fdawson.lotus.com> From: "Frank Dawson" To: "Larry Masinter" , Subject: Re: Starting the ietf-xml-mime mailing list Date: Wed, 7 Apr 1999 19:04:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: >You might also want to scan your email for "event invitations from my boss", >and you can't solve that problem with specialized MIME media types. So the >question is: are there any realistic cases where having a "text/calendar" >distinction in the email header actually helps substantially in deciding >which email bodies to retrieve? Actually, the current MIME content type definition for "text/calendar" provides for MIME header parameter that CUAs are using to scan the inbox for the "new invitations". This is what gave me concern when I read the content type definition for text/xml and application/xml. It doesn't allow an application to detect what kind of XML object is in the email. For our application area, it is disfunctional. It is imparing the use of XML for representing iCalendar objects (and certainly other application objects too). - - Frank From owner-ietf-xml-mime Wed Apr 7 19:10:50 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA05355 for ietf-xml-mime-bks; Wed, 7 Apr 1999 19:10:50 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA05351 for ; Wed, 7 Apr 1999 19:10:47 -0700 (PDT) Received: from enoshima (ppp0ppp66.sfc.keio.ac.jp [133.27.13.87]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id LAA07387; Thu, 8 Apr 1999 11:11:21 +0900 (JST) Message-Id: <199904080211.LAA07387@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, 08 Apr 1999 08:37:00 +0900 To: Paul Grosso From: "Martin J. Duerst" Subject: Re: Starting the ietf-xml-mime mailing list Cc: ietf-xml-mime@imc.org In-Reply-To: <3.0.32.19990407095211.0102b910@pophost.arbortext.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:53 99/04/07 -0500, Paul Grosso wrote: > the original namespace proposal > developed by the XML WG was to have namespace declarations only in > the prolog (at the top) of an XML document. > Now there is this suggestion to collect all declared namespaces at > the top of the document again. Isn't this going around in circles? > Whatever the reasons for going with locally scoped declarations, aren't > most of them also reasons against listing all such decls at the top? As the discussion about callendars has just shown, there can be huge differences between having things inside the document (even at the top) and outside ("higher up than the top"). Also, requiring that all used namespaces be listed may definitely be too much in certain scenarios. It could be only the "main" namespace(s), only the "mandatory" namespaces, and so on. That would then of course lead to the question of how to distinguish these cases. Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-xml-mime Thu Apr 8 04:23:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA13970 for ietf-xml-mime-bks; Thu, 8 Apr 1999 04:23:34 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA13966 for ; Thu, 8 Apr 1999 04:23:33 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id HAA12250; Thu, 8 Apr 1999 07:24:15 -0400 Message-ID: <370A8FB6.64B32EEB@w3.org> Date: Wed, 07 Apr 1999 00:50:30 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Donald E. Eastlake 3rd" CC: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <199904062050.QAA02470@torque.pothole.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Donald E. Eastlake 3rd" wrote: > > I consider the original question to have been pretty insulting. OK, I accept that you consider it so; it wasn't intended to be, and Paul Hoffman seemed to treat it like a simple request for information and responded with that information. > There > is only one set of MIME types for all uses. That is also my understanding; I was checking that this is shared and agreed upon context for this discussion. I have heard other opinions voice the contrary. > The name of the list is > ietf-xml-mime, not email-xml-mime. Right, so we are clear it is about MIME; and if we read the MIME RFCs we are clear that that MIME is about email, and not necessarily clear that it is about any other protocol. So it seemed better to ask at first than to risk misunderstandings because of a lack of shared assumptions. > If it had been hosted at the W3C, > would non-web uses have been ignored? Yes, unless they could be shown to follow naturally and pretty much for free from the Web uses. The Web is the universe of network-accessible information. So, that includes mail, ftp, and so on. It struck me as an entirely reasonable question, in particular since the RFC that defines text/xml and application/xml refers to "MIME-like protocols" which seems to imply that HTTP is not MIME (something I have heard asserted in the past). So, if everyone agrees that the scope is, at minimum, both email and HTTP, then we can move on. It never hurts, I find, to state exactly what problem is being solved before attempting to solve it. -- Chris From owner-ietf-xml-mime Thu Apr 8 04:46:29 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA14176 for ietf-xml-mime-bks; Thu, 8 Apr 1999 04:46:29 -0700 (PDT) Received: from vortex.uplanet.com (host-165-3.uplanet.com [204.163.165.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14172 for ; Thu, 8 Apr 1999 04:46:29 -0700 (PDT) Received: from sluk (t6o49p17.telia.com [195.198.195.77]) by vortex.uplanet.com (8.9.2/8.9.2) with SMTP id EAA11212 for ; Thu, 8 Apr 1999 04:47:11 -0700 (PDT) From: "Peter Stark" To: Subject: Specialised media types (was RE: Starting the ietf-xml-mime mailing list) Date: Thu, 8 Apr 1999 04:47:16 -0700 Message-ID: <000801be81b5$8cda8f30$4dc3c6c3@uplanet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 In-Reply-To: <01J9R8JTQTIK8WWG0C@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I think that using specialized media types - one for every XML app - can be a potential scalability problem. Even if the media type registration is impressively fast today (one day!), I anyway doubt that it's appropriate to have a central authoritive for this purpose. One particular problem is the naming of media types in the Vendor tree: text/vnd.* You can put whatever you like after 'vnd', and that's what people do. I wonder why media types can't use similar naming rules as, for example, java classes (domain names) or XML names (URIs). Wouldn't it be possible to, in some way, join the MIME Media type tree with the domain names. For example, text/xml.org.w3.html, would be XHTML and text/xml.com.anyCo.myXmlApplication, would be someone's XML application. but text/html, would still be HTML That way, the browser can, even if it doesn't recognize the type, at least see that it's an XML document (and perhaps display it). It also means that I can create my own media types without having to contact a central naming authority (except for getting the domain name). I can also further sub-type my own media type. Perhaps some sort of new URN should be used instead, I don't know. Anything would be better than "vnd.whatever.."-names. PS > -----Original Message----- > From: owner-ietf-xml-mime@imc.org [mailto:owner-ietf-xml-mime@imc.org]On > Behalf Of Ned Freed > Sent: Wednesday, April 07, 1999 3:11 PM > To: Larry Masinter > Cc: Earthlink; ietf-xml-mime@imc.org > Subject: RE: Starting the ietf-xml-mime mailing list > > > > > In addition, though, we also want to get at subtypes of > objects. Or in the > > > case of MIME type/subtypes, this would be the "sub-sub type". > For example, > > > for a calendar object (text/calendar) we want to pull to the > client just the > > > "event invitations". This would be the "sub sub type" of type=text, > > > subtype=calendar. > > > This is a good example of a problem that specialized media > types won't solve. > > Agreed. > > My quick and dirty way of thinking of this is that the media type/subtype > should to be sufficient to get you the right application, but the > parameters > then can tell that application what to do, or when to do it, or > various other > sorts of things that for whatever reason are best not stored in > or derived from > the actual content. > > > You might also want to scan your email for "event invitations > from my boss", > > and you can't solve that problem with specialized MIME media > types. So the > > question is: are there any realistic cases where having a > "text/calendar" > > distinction in the email header actually helps substantially in deciding > > which email bodies to retrieve? > > Of course the general case of this problem may in fact be > intractable, even > with full access to message content. (Define "boss". Figure out > how to relate > the origin of a given event invitation to this definition of "boss". Etc.) > However, in the general problem space surrounding these sorts of > applications, > I see value in using parameters. For example, I may wish to have certain > sorts of calendar operations handled silently and automatically, whereas > others need to be done manually. > > In short, I agree with Frank that parameters have their uses in > this context. > > Ned > > From owner-ietf-xml-mime Thu Apr 8 05:01:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14303 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:01:46 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14298; Thu, 8 Apr 1999 05:01:44 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA14889; Thu, 8 Apr 1999 08:02:28 -0400 Message-ID: <370C9A49.6B08A7AD@w3.org> Date: Thu, 08 Apr 1999 14:00:09 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <199904070641.AA00216@archlute.apsdc.ksp.fujixerox.co.jp> <4.2.0.32.19990407092004.00b50c00@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Hoffman / IMC wrote: > > Dispatching based on media types raises a few important issues that are > somewhat unique to XML. > > If we say "every application gets a new media type" then there is no clean > way for a MIME-handling application to fall back to handing an unknown > media type to an XML parser. Although that is the right thing to do in some circumstances, and not in others. > An unclean way for such an application to > handle an unknown media type is to look inside the first few octets of the > body and, if it looks like XML, hand it off to the XML parser instead of > treating it as application/octet-stream or text/plain. Increasingly, many programs contain an XML parser. XML is being used for a very wide variety of different things. There is unlikely to be "a" single XML parser - its a component of some other application program. > If we say "stick everything XMLish under a media type that is XML-specific > with some parameter for the kind of XML" then we assume that handing off > unknown body types to an XML parser is useful. Right. In some cases, it may be. The thing to avoid, though, it to havce to parse the document once to find out what sort of thing it is, dispatch it somewhere else, and then have that "somewhere else" start parsing again from scratch. If that can be avoided by better labelling up front, that is a win. > I question this assumption. Right. > What's the XML parser going to do with this block of data? Display it? Not > terribly valuable. Not even possible, in some cases. XML is being used for all sorts of things from serialising Java Beans to Web server configuration files to interprocess communication - a lot of these uses are not especially "displayable". In some cases, the fact that they are written in XML is the least important thing about them. These are likely to need specialised registrations, too. Further, if the specification for any such case is not controlled by a single vendor, then registration in the vendor tree does not seem appropriate. This would be the case for situations ranging from a small vendor group (such as the Flashpix group) through groups such as W3C to bodies such as ISO, ITU, IEE and so on. Then there is a second class of uses which are essentially textual, where the XML markup is being used to structure headings, footnotes, chapters and suchlike document-like things. These things do indeed benefit, if not recognised, from being "displayed" and may even contain an internal link to a stylesheet which can be used to display them. I think that dispatching this 'marked up text' class of uses to a single parser/viewer, such as a browser, make sense (not in all cases of course, and editing should be distinguished from viewing, but full mailcap files can do that) and thus, a MIME labelling of text/xml would make sense. The third class of uses which are intended to be displayed but which requitre specialised display processors. Examples of these are markup for chemical structures, X3D for xml-ised vrml, PDB (protein database) format, BSML (bioinformatics sequence markup language), SVG (scalable vector graphics) and so on. These are likely to benefit from specialised registrations, which might be in the image, application, model, or other top level types. So far I havewn't seens a good case made for application/xml, sinc ehte re isn't a single XML application; the arguments around its use have centered around concerns for the lowest common denominator fallback to text/plain if text/xml is not recognised (and the possibility of bit 8 mangling, if sent over email rather than http or binary ftp) > Get some namespace information from the inside and then > dispatch based on the namespace? Possibly valuable, but this begs the > question of why wasn't that information out in the MIME headers. > > I tend to lean towards "every application gets a new media type". I think that is reasonable in many cases, but not all. There still seems to be a place for text/xml, for textlike or documentlike applications. -- Chris From owner-ietf-xml-mime Thu Apr 8 05:16:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14398 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:16:33 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14392; Thu, 8 Apr 1999 05:16:32 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA15811; Thu, 8 Apr 1999 08:17:11 -0400 Message-ID: <370C9DB9.CDF2DEED@w3.org> Date: Thu, 08 Apr 1999 14:14:49 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Larry Masinter CC: Ned Freed , Paul Hoffman / IMC , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <001301be811e$5a2308c0$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > > > I tend to lean towards "every application gets a new media type". > > > > In case it isn't obvious by now, so do I. > > This is a fine maxim, but it begs the question: what constitutes > a separate, distinct application, vs a modification, profile, > extension, or varation of an old one? Thats a good question, but part of it comes down to monolighic versus granular compound documents. > In the case where you're allowed to have a document that mixes > traditional HTML, (I'm assuming you mean XHTML here, ie HTML written in XML. Sop, all the things you citer are written in XML, and constitute one large XML instance using multiple namespaces). > MathML, Vector Graphics ML, etc., are these > separate "applications" or are they one "application" ("renderable > XML document")? If sens as separate bodyparts, which is possible, then they would all be separate "applications". If sent as one big XML instance, then in this case I would ay it would be text/xml. Once XLink and XPointer get more widely deployed, we are likely (IMHO) to see people moving away from this class of monolithic document and instead using small skeleton documents, written in XML and using XPointer transclusion to reference different media pieces (graphics, math, audio, etc) some (many) orf which are writen in XML , but each with their own label. This granularity allows finer control by mail user agents (they can figure out which bodyparts they understand) and allows the benefits of cacheing over HTTP as different compound documents reuse different component pieces. So (to get back to Larrys point) while we may see monolithic multimnamespace documents which can only really be labelled as text/xml, we will also alongside that see smaller more granular compound documents, where a correspondingly finer grained labelling of each component is more appropriate. Since it doesn't seem to have come up yet, I will also note the concept of content negotiation, as used by HTTP; where MIME labelling is used in negotiations between client and server. I guess this could also apply to email in the case of external bodyparts, but am not sure so will leave that to someone else. Content negotiation can be initiated by the document author (in the case that multiple alternatives are explicitly offered in the link to the resource), by the client (in the case of accept headers) or by the HTTP server (in the case of 'multiple choices' response code). Discussion of different MIME types for things written in XML should bear these considerations in mind, as well as the case where the content is already sent and one is trying to dispatch it appropriately. -- Chris > > Larry From owner-ietf-xml-mime Thu Apr 8 05:29:41 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14530 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:29:41 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14525; Thu, 8 Apr 1999 05:29:40 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA16623; Thu, 8 Apr 1999 08:30:20 -0400 Message-ID: <370CA0D2.2056CC54@w3.org> Date: Thu, 08 Apr 1999 14:28:02 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ned Freed CC: Larry Masinter , Paul Hoffman / IMC , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <01J9QYRR52GS8WW98O@INNOSOFT.COM> <01J9R178PHF88WWG0C@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed wrote: > But this then begs the more general question of whether there is to be an > attempt to "design" the XML usage space, and if there is, whether such an > attempt has any chance of succeeding. > > If the answer to this is "no, we don't want to try and control the development, > direction, and use of XML" This is the position of W3C; certain building blocks are made available (foundational blocks such as XML itself, XLink, XPointer, namespaces, etc; useful common things like styleshets, SVG for images, RDF for metadata which can be used or not as appropriate) but the way in which people combine these building blocks is up to them, and the element names that they use (when not using a building block that defines names for them, like XHTML and SVG do) is entirely their own affair. > The resulting > mixtures and granularity will be whatever developers decide is appropriate. Not just developers; increasingly, vertical markets. An XML namespace for real-estate listings, for example. One for dental records. So forth. > And > in such a world I see little value in having an XML top level type. (Perhaps no > real harm, but little value.) The only value I would see is if the fallbacks and other behaviours of the text/* tree were seen to be unavoidable and made the use of XML too fragile there. XML element names and element content can use all sorts of Unicode characters. Fallbacks to text/plain are not useful in general, and fallbacks to 7-bit US-ASCII risk manglng the data. On the other hand, as you said in another post: > About the only success story we have, > actually, are the image/audio/video top-level types, and while these have > worked out tolerably well, their actual value to end users isn't that great. If it can be assumed that a program which falls back to text/plain has already lost significant semantics anyway, and if it can be assumed that such fallback is rarely of value and rarely happens, then the use of text/xml is useful. If on the other hand the fallback is seen asa n unavoidable problem, then an xml/* tree would, indeed, have value simply by lifting such restrictions. > And in such a world a top-level XML type might > have some value, if only as a place to attach the ruleset. Right, that was what I was trying to say. > (Delegation of XML > registration would also be something to consider.) Perhaps, but who would own it? Oasis, perhaps? My sense is that W3C is not interessted in being a central repository for all possible uses of XML, many of which are not Web related in any way. -- Chris > > I basically don't have an opinion on which way this should go. My one > observation is that the IETF at least has typically opted to try and stay out > of areas like this in the past. > > Ned From owner-ietf-xml-mime Thu Apr 8 05:36:28 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14614 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:36:28 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14610 for ; Thu, 8 Apr 1999 05:36:27 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA17023; Thu, 8 Apr 1999 08:37:00 -0400 Message-ID: <370CA261.E15E3A09@w3.org> Date: Thu, 08 Apr 1999 14:34:41 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Murray Altheim CC: masinter@parc.xerox.com, Ned.Freed@INNOSOFT.COM, murata@apsdc.ksp.fujixerox.co.jp, ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <199904071937.MAA15419@mehitabel.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Murray Altheim wrote: > I don't believe that > resorting to file extensions can possibly be the way of the future. I agree that it should not be the way of the future, but there is some evidence that implementors are moving in this direction. Try serving up a PNG file labelled as image/png but with a .gif extension to a popular browser and see what happens ;-( Similarly, try serving up an XML file with a .txt extension as text/plain and some browsers will still complain "unable to display XML file with stylesheet" and faiul to display it as text - they are sniffing in the content. This is, apparently, because of the amount of unlabelled or mislabelled content which already exists. > We all need a better alternative. Yes. We also need one fairly quickly (all done and dusted in, lets say, three months tops) otherwise whatever solution is proposed will merely be a good idea, but too late. -- Chris From owner-ietf-xml-mime Thu Apr 8 05:45:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14716 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:45:14 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14712 for ; Thu, 8 Apr 1999 05:45:13 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA17493; Thu, 8 Apr 1999 08:45:54 -0400 Message-ID: <370CA477.C6DFAD6E@w3.org> Date: Thu, 08 Apr 1999 14:43:35 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Earthlink CC: Larry Masinter , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <033901be813f$a7ace040$f95472c6@fdawson.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Earthlink wrote: > > >It's not clear that specialized media types solve any problem at all, > >in the case of XML that already contains a document declaration. > > The overhead of having to open up every XML document to find out what > document type it is is not practical. As in the case of email, all I should > have to do is ask for a particular type of object from the store and get it. Yes. Thanks for bringing to our attention the fact that IMAP uses servers, as well as HTTP; since I use POP I tend to forget about what IMAP does. Is it possible to request the "best" of several multipart/alternate message bodyparts over IMAP, where "best" means the preferences of MIME type that the user has? > In addition, though, we also want to get at subtypes of objects. Or in the > case of MIME type/subtypes, this would be the "sub-sub type". For example, > for a calendar object (text/calendar) we want to pull to the client just the > "event invitations". This would be the "sub sub type" of type=text, > subtype=calendar. What about parameters, can these be handled? For example the CGM registration (image/cgm) defined two mandatory parameters; this was a problem at the time because parameters were not well handled by current implementations. But recently, W3C made WebCGM (a particuklar profile) a Recommendation, and were able to use those parameters to indicate thata particular CGM used the WebCGM profile. This was handy, no additional registration was necessary and the general semantics of imege/cgm still apply to WebCGM, but specific semantics are also added. Would IMAP be able to fetch image/cgm;Version=4;ProfileId=WebCGM bodyparts specifically? This use of parameters for profiles of a registered type/subtype combination sounds to me much like the possibilities with registering text/xhtml and then declaring the various HTML profiles for mobile, TV etc. -- Chris From owner-ietf-xml-mime Thu Apr 8 05:51:42 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA14767 for ietf-xml-mime-bks; Thu, 8 Apr 1999 05:51:42 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14763 for ; Thu, 8 Apr 1999 05:51:41 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id IAA17870; Thu, 8 Apr 1999 08:52:23 -0400 Message-ID: <370CA5FC.46F75563@w3.org> Date: Thu, 08 Apr 1999 14:50:04 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Larry Masinter CC: Earthlink , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <002401be8141$6fe9c040$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > [Frank wrote] > > In addition, though, we also want to get at subtypes of objects. Or in the > > case of MIME type/subtypes, this would be the "sub-sub type". For example, > > for a calendar object (text/calendar) we want to pull to the client just the > > "event invitations". This would be the "sub sub type" of type=text, > > subtype=calendar. > > This is a good example of a problem that specialized media types won't solve. But it sure cuts down the class of data to be further processed. Instead of searching through the entire mailbox/the entire server, just search in the text/calendar resources. > You might also want to scan your email for "event invitations from my boss", > and you can't solve that problem with specialized MIME media types. You can't solve that problem in its entirety with specialised MIME media types, but you can go a good part of the way and have a better start than, for example, sending all calendar events as text/plain. text/calendar;category=work;recurring=monthly (to take a suggestive but doubtles invalid example) would help even more - the parameters could be used to cut down on the search spoace even further. > So the > question is: are there any realistic cases where having a "text/calendar" > distinction in the email header actually helps substantially in deciding > which email bodies to retrieve? Yes; especially in the case of IMAP where the initial selection of bodis is done on the server and likely ones are sent to the client for the calendar program to further process. -- Chris From owner-ietf-xml-mime Thu Apr 8 06:16:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA15052 for ietf-xml-mime-bks; Thu, 8 Apr 1999 06:16:19 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA15048 for ; Thu, 8 Apr 1999 06:16:18 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52287(3)>; Thu, 8 Apr 1999 06:17:03 PDT Received: from copper.parc.xerox.com ([13.0.211.121]) by thelma.parc.xerox.com with SMTP id <99260>; Thu, 8 Apr 1999 06:17:00 PDT From: "Larry Masinter" To: Subject: RE: Starting the ietf-xml-mime mailing list Date: Thu, 8 Apr 1999 06:16:45 PDT Message-ID: <000201be81c2$0cedc460$d111020d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <370CA5FC.46F75563@w3.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'm not sure about this group. Here we have a bunch of people arguing about labelling things on the outside and not requiring processors to go inside the body to determine the actual content, yet everyone seems to be content with having the entire discussion with a "Subject" line of "RE: Starting the ietf-xml-mime mailing list". Regards, Larry From owner-ietf-xml-mime Thu Apr 8 10:21:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17643 for ietf-xml-mime-bks; Thu, 8 Apr 1999 10:21:49 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17639 for ; Thu, 8 Apr 1999 10:21:48 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id NAA03571; Thu, 8 Apr 1999 13:22:29 -0400 Message-ID: <370CAAC5.B38E4A1@w3.org> Date: Thu, 08 Apr 1999 15:10:29 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frank Dawson CC: Larry Masinter , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <04a601be814c$73738240$f95472c6@fdawson.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Frank Dawson wrote: > > Larry Masinter wrote, in part: > > >I'm saying you definitely have a problem: you have a complex space > >of possible objects: > > NO, this is not a complex problem. This is an existing 20+ year old mail > enabled application. This nut has already been cracked for Internet > developers using the "text/calendar" content definition. I queried > Kurita-san and Paul Hoffman because I was interested in utilizing XML > representation of iCalendar. We have a DTD defined. It is an isomer of the > iCalendar standard format, So, the mechanics and all the semantics of text/calendar are retained but it merely uses a different syntax? In that case, it would seem that something like text/xcalendar would meet your needs, and that apart from the syntactic portion, the defining specification would see "see text/calendar" in a great many places (or have the same text copied, whatever). > There needs to be > some balance between an infinite number of media types/subtypes for each > transaction type and a smaller, managable number of media types for each > logical application object type. Yes. This is the hierarchical model, as opposed to the flat model. Parameters provide a third level of hierarchy below the content type and content subtype levels. > As Ned has pointed out, this example and > other show that leaving "hooks" on the outside of the object wrapper is very > useful in providing a scalable, practical Internet solution using XML. The hooks are particularly useful for specialised types such as calendaring. For a more generic "this is a textual document marked up in XML" type, the difficulty is finding hooks of suitable generality. -- Chris From owner-ietf-xml-mime Thu Apr 8 10:21:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17653 for ietf-xml-mime-bks; Thu, 8 Apr 1999 10:21:55 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17649 for ; Thu, 8 Apr 1999 10:21:54 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id NAA03579; Thu, 8 Apr 1999 13:22:37 -0400 Message-ID: <370CAACA.282F3F93@w3.org> Date: Thu, 08 Apr 1999 15:10:34 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Frank Dawson CC: Larry Masinter , ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list References: <04a501be814c$7203c5a0$f95472c6@fdawson.lotus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Frank Dawson wrote: > Actually, the current MIME content type definition for "text/calendar" > provides for MIME header parameter that CUAs are using to scan the inbox for > the "new invitations". Okay, > This is what gave me concern when I read the content > type definition for text/xml and application/xml. It doesn't allow an > application to detect what kind of XML object is in the email. If you are pointing out the utility of parameters for finer granularity of labelling in general, then I agrree it can help. > For our > application area, it is disfunctional. It is imparing the use of XML for > representing iCalendar objects (and certainly other application objects > too). I sense from this a worry that existing registered uses of XML would need to re-register to use text/xml. If that is your worry, then I would say that I do not believe that this is the intention. -- Chris From owner-ietf-xml-mime Thu Apr 8 20:35:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00143 for ietf-xml-mime-bks; Thu, 8 Apr 1999 20:35:10 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00138 for ; Thu, 8 Apr 1999 20:35:05 -0700 (PDT) Received: by mx.fujixerox.co.jp; id MAA08018; Fri, 9 Apr 1999 12:35:00 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma007992; Fri, 9 Apr 99 12:34:47 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id MAA04138 for ; Fri, 9 Apr 1999 12:32:41 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id MAA23912 for ; Fri, 9 Apr 1999 12:34:46 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id MAA13097 for ; Fri, 9 Apr 1999 12:32:47 +0900 Message-Id: <199904090334.AA00252@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 09 Apr 1999 12:34:37 +0900 To: ietf-xml-mime@imc.org Subject: Re: Starting the ietf-xml-mime mailing list In-Reply-To: <370A8FB6.64B32EEB@w3.org> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Chris Lilley wrote: > It struck me as an entirely reasonable question, in particular since the > RFC that defines text/xml and application/xml refers to "MIME-like > protocols" which seems to imply that HTTP is not MIME (something I have > heard asserted in the past). RFC 2068(Hypertext Transfer Protocol -- HTTP/1.1) says: ---------------------------------------------------- 19.4 Differences Between HTTP Entities and MIME Entities HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, MIME [7] discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Sat Apr 10 13:50:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13799 for ietf-xml-mime-bks; Sat, 10 Apr 1999 13:50:10 -0700 (PDT) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA13795 for ; Sat, 10 Apr 1999 13:50:08 -0700 (PDT) Received: (qmail 21038 invoked from network); 10 Apr 1999 20:50:14 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 10 Apr 1999 20:50:14 -0000 Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id NAA05543 for ; Sat, 10 Apr 1999 13:50:14 -0700 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id NAA15702 for ietf-xml-mime@imc.org; Sat, 10 Apr 1999 13:50:14 -0700 Date: Sat, 10 Apr 1999 13:50:14 -0700 From: Terry Allen Message-Id: <199904102050.NAA15702@bolt.sonic.net> To: ietf-xml-mime@imc.org Subject: Mixed-format and Unpacking Expectations Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'd like to add remarks on topics I haven't seen dealt with at any length yet: mixed format compound documents and expectations for MIME unpacking. Here are some quotes of what has been said: | MURATA Makoto, Paul Hoffman, Frank Dawson, Jim Whitehead | 1. Problem statement | | We would like the MIME parser to be able to dispatch different sorts | of XML documents to different applications, such as specialized | programs that handle just one type of XML document. Because MIME | parsers do not look inside the MIME parts, identifiying the sort of | documents must be done in the MIME headers. However, neither text/xml | nor application/xml allow such information. | ... | (3) A new parameter "externalid" for text/xml and application/xml | | This parameter specifies the externalID from the DOCTYPE of the XML | document (if the DOCTYPE is present). Examples would be: | ... | Note: None of the above proposals handle non-monolithic XML documents | very well, | since different islands of non-monolithic XML documents belong to different | namespaces and thus different schemata. | =================== | Later, Murata Makoto wrote: | Issue 5: Packaging | | There should be a mechanism for packaging an XML document together | with its stylesheet, catalog, and referenced resources (e.g., links, | external entities). One possibility is MHTML. | =================== | Larry asked: | In the case where you're allowed to have a document that mixes | traditional HTML, MathML, Vector Graphics ML, etc., are these | separate "applications" or are they one "application" ("renderable | XML document")? | ==================== Mixed-format compound documents. I have imagined complex documents that are not pure XML. Such a document would have a root entity (cover page, table of contents) that gives access to others (which is why it's a document rather merely a web). That root entity could be PDF, XML, Word, plain text, CGM, you name it. Other entities could be XML, Word, PDF, etc. and on and on. I want to be able to package up such a document in MIME, and I think of "nonmonolithic" XML documents as a special case of this format-generic complex document. I'd like to solve the general problem AND solve the XML problem together. I've made several proposals for doing so: "Package or Perish", an SGML '97 paper, and "MIME Multipart/Related for CBL", possibly accessible s.v. "Related Documents" at http://www.veosystems.com/xml/cbl/cbl-1.1/doc/index.html In both cases I used the basis of the MHTML work, but tried to avoid putting information about relations of parts in the MIME headers, so that you could discard the MIME packaging without loss of information. I don't have any attachment to the details of either of those proposals: the week before the SGML '97 conference my colleagues and I worked up half a dozen combinations of MIME semantics to do the job, and any proposal that works is fine by me. I invented a text/x-compounddoc subtype for mixed-format compound documents, perhaps pointlessly: is it the opinion of this group that the root entity's MIME type is what should be used to label the whole (which is related to what Larry was asking)? or maybe the MIME type of the manifest (see next)? Expectations for MIME unpacking. There may be XML documents composed of very many pieces: My-enormous-catalogue-container Catalogue-entry-1 Catalogue-entry-2 Catalogue-entry-3 ... Catalogue-entry-100,000 Each of these catalogue entries may have an identifier, which could be listed in a manifest (in XML, say) that is the first body part of a multipart MIME message. The recipient may know he is interested only in Catalogue-entry-98,256. It seems to me that it might be more efficient to obtain that part by extracting and parsing the manifest and then searching for the MIME header of the wanted body part (thus making recursive use of the MIME packaging) rather than having the MIME unpacker unpack all of the MIME message first. I'm no MIME expert, so I don't know if that's reasonable, but I am uneasy about assuming that unpacking should be done before any subsequent processing. (Perhaps no such assumption has been made ...) regards, Terry Terry Allen Commerce One, Inc. Business Language Designer 1600 Riviera Ave., Suite 200 Advanced Technology Group Walnut Creek, Calif., 94596 tallen[at]sonic.net From owner-ietf-xml-mime Sun Apr 11 00:58:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17633 for ietf-xml-mime-bks; Sun, 11 Apr 1999 00:58:45 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17629 for ; Sun, 11 Apr 1999 00:58:43 -0700 (PDT) Received: by mx.fujixerox.co.jp; id QAA14834; Sun, 11 Apr 1999 16:58:51 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma014830; Sun, 11 Apr 99 16:58:33 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id QAA17298 for ; Sun, 11 Apr 1999 16:56:27 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id QAA05223 for ; Sun, 11 Apr 1999 16:58:31 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id QAA21660 for ; Sun, 11 Apr 1999 16:56:33 +0900 Message-Id: <199904110758.AA00259@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Sun, 11 Apr 1999 16:58:24 +0900 To: ietf-xml-mime@imc.org Subject: DTD media type? MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In the xml-dev mailing list, some people requested a media type for DTD (to be precise, an external DTD subset), since browsers should be able to launch a DTD viewer for DTDs. One could also argue that an additional parameter of text/xml and application/xml is enough for that purpose. Other than external DTD subsets and XML documents, there are two types of XML network entities. They are external parsed entities and external parameter entities. At present, RFC 2376 says that text/xml and application/xml can be used for all of the four types. No mechanisms for distinguishing the four types are present. Can we use XML processors to distinguish these four types? The answer is No. A DTD does not parse as an XML document. An external parsed entity does not typically parse as an XML document. (Note: it is possible to create an external parsed entity which also parses as an XML document.) An external parameter entity does not parse as an XML document. (Note: an external parameter entity can also become an external DTD subset.) Then, can we develop some other program to distinguish the four types? It is possible, but not likely. To do such autodetection, programs have to understand the charset parameter, handle the specified charset, and then compare the text against the BNFs for the four types. People will not implement such complicated autodetection, in my humble opinion. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Sun Apr 11 11:35:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22891 for ietf-xml-mime-bks; Sun, 11 Apr 1999 11:35:46 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA22887 for ; Sun, 11 Apr 1999 11:35:45 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52347(2)>; Sun, 11 Apr 1999 11:35:48 PDT Received: from copper.parc.xerox.com ([13.2.17.216]) by thelma.parc.xerox.com with SMTP id <97663>; Sun, 11 Apr 1999 11:35:36 PDT From: "Larry Masinter" To: "Terry Allen" , Subject: RE: Mixed-format and Unpacking Expectations Date: Sun, 11 Apr 1999 11:35:31 PDT Message-ID: <000e01be844a$1403eb00$d811020d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199904102050.NAA15702@bolt.sonic.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: When I asked | In the case where you're allowed to have a document that mixes | traditional HTML, MathML, Vector Graphics ML, etc., are these | separate "applications" or are they one "application" ("renderable | XML document")? I was thinking of an XML application which allowed, in a single body part, all of those namespaces. In the case where you have separate body parts, MHTML is probably the best you can do. > In both cases I used the basis of the MHTML work, but tried to avoid > putting information about relations of parts in the MIME headers, so > that you could discard the MIME packaging without loss of information. MHTML doesn't put "information about the relations of parts" in the MIME headers. It just puts the identity of each part in the wrapper. If you have body parts that are self-identifying (they contain their own uri/cid or whatever) then you can reassemble. Larry From owner-ietf-xml-mime Sun Apr 11 13:27:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23392 for ietf-xml-mime-bks; Sun, 11 Apr 1999 13:27:03 -0700 (PDT) Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA23388 for ; Sun, 11 Apr 1999 13:27:02 -0700 (PDT) Received: (qmail 31480 invoked from network); 11 Apr 1999 20:27:13 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 11 Apr 1999 20:27:13 -0000 Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id NAA28565; Sun, 11 Apr 1999 13:27:12 -0700 X-envelope-info: Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id NAA28609; Sun, 11 Apr 1999 13:27:12 -0700 Date: Sun, 11 Apr 1999 13:27:12 -0700 From: Terry Allen Message-Id: <199904112027.NAA28609@bolt.sonic.net> To: ietf-xml-mime@imc.org, masinter@parc.xerox.com, tallen@sonic.net Subject: RE: Mixed-format and Unpacking Expectations Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry wrote: | When I asked | | In the case where you're allowed to have a document that mixes | | traditional HTML, MathML, Vector Graphics ML, etc., are these | | separate "applications" or are they one "application" ("renderable | | XML document")? | | I was thinking of an XML application which allowed, in a single | body part, all of those namespaces. In the case where you have | separate body parts, MHTML is probably the best you can do. Ah. My answer would be that the use of "XML namespaces" does not imply separate applications (although you could figure out how to specify that an "XML namespace" should be mapped to an application, as NOTATION was used to do). | > In both cases I used the basis of the MHTML work, but tried to avoid | > putting information about relations of parts in the MIME headers, so | > that you could discard the MIME packaging without loss of information. | | MHTML doesn't put "information about the relations of parts" in the | MIME headers. It just puts the identity of each part in the wrapper. | If you have body parts that are self-identifying (they contain their | own uri/cid or whatever) then you can reassemble. Yes, I was thinking of RFC 2387 (Multipart/related), which uses Content-Disposition, possibly encoding structural information not borne elsewhere. I see now that RFC 2557 (MHTML) doesn't (and the bibliographic reference to RFC 2183 (Content-Disposition), CONDISP, is apparently dangling). But then, I was ignoring relative URLs. regards, Terry Terry Allen Commerce One, Inc. Business Language Designer 1600 Riviera Ave., Suite 200 Advanced Technology Group Walnut Creek, Calif., 94596 tallen[at]sonic.net From owner-ietf-xml-mime Sun Apr 11 19:49:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA03417 for ietf-xml-mime-bks; Sun, 11 Apr 1999 19:49:19 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA03408 for ; Sun, 11 Apr 1999 19:49:17 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA00863; Mon, 12 Apr 1999 11:49:28 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma000716; Mon, 12 Apr 99 11:48:52 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA09441 for ; Mon, 12 Apr 1999 11:46:47 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id LAA21003 for ; Mon, 12 Apr 1999 11:48:50 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id LAA05594 for ; Mon, 12 Apr 1999 11:46:51 +0900 Message-Id: <199904120248.AA00265@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Mon, 12 Apr 1999 11:48:44 +0900 To: ietf-xml-mime@imc.org Subject: What we have agreed on MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Having read the disussion so far, I believe that we have agreed on a few things and would like to know if somebody disgarees. 1. Registration of media subtypes is easy. 2. Dispatch based on parameters are not widely supported. 3. Fallback to general-purpose XML applications is not useful. 4. Document-like XML documents can be handled by general-purpose XML viewers If these are agreed on, we can eliminate some options and concentrate on the rest. If you disagree with these four points, please speak up now. Cheers, Makoto ---------------------------------------------------------- 1. Registration of media subtypes is easy. "Registrations now routinely take only a few days if they don't contain egregious errors." (Ned) "Registrations containing errors take longer, of course. But feedback is quick, typically taking only a day or two, so the burden is on the person doing the registration to turn the thing around in a timely way." (Ned) "The registration process is the same (i.e. fast) in *any* tree that currently exists. The slowness associated with the IETF tree has to do with RFC review, which is an entirely separate process from type registration." (Ned) "The standards say that RFC documentation is only required for registration in the IETF tree, and in practice none of the many registered XML-based types have been backed up with RFCs." (Ned) "Moreover, relatively few types belong in the IETF tree." (Ned) 2. Dispatch based on parameters are not widely supported. "The lack of ability to dispatch on parameters in most applications that support MIME. Not only do applications lack this ability, there are also quite a few contexts where MIME labelling is used that don't support parameters, period." (Ned) "Many current implementations of content dispatch don't allow dispatch based on media type parameters, in any case." (Larry) 3. Fallback to general-purpose XML applications is not useful. "What's the XML parser going to do with this block of data? Display it? Not terribly valuable. Get some namespace information from the inside and then dispatch based on the namespace? Possibly valuable, but this begs the question of why wasn't that information out in the MIME headers." (Paul) "what experience has shown is that fallback strategies of *any* sort tend to be overrated. In almost every case something has messed it up. Either we got the granularity wrong (and I see a very good chance of this happening here given the emergence of alternative forms of XML), or it didn't prove to offer useful functionality, or it simply didn't deploy in the manner in which we envisioned. About the only success story we have, actually, are the image/audio/video top-level types, and while these have worked out tolerably well, their actual value to end users isn't that great." (Ned) "Not even possible, in some cases. XML is being used for all sorts of things from serialising Java Beans to Web server configuration files to interprocess communication - a lot of these uses are not especially "displayable". In some cases, the fact that they are written in XML is the least important thing about them. These are likely to need specialised registrations, too. Further, if the specification for any such case is not controlled by a single vendor, then registration in the vendor tree does not seem appropriate. This would be the case for situations ranging from a small vendor group (such as the Flashpix group) through groups such as W3C to bodies such as ISO, ITU, IEE and so on." (Chris) 4. Document-like XML documents can be handled by general-purpose XML viewers "1.a the generic something displays the XML to a human using a stylesheet, possibly with help from other logic for embedded chunks from different namespaces." (Tim) "Then there is a second class of uses which are essentially textual, where the XML markup is being used to structure headings, footnotes, chapters and suchlike document-like things. These things do indeed benefit, if not recognised, from being "displayed" and may even contain an internal link to a stylesheet which can be used to display them. I think that dispatching this 'marked up text' class of uses to a single parser/viewer, such as a browser, make sense (not in all cases of course, and editing should be distinguished from viewing, but full mailcap files can do that) and thus, a MIME labelling of text/xml would make sense." (Chris) From owner-ietf-xml-mime Mon Apr 12 21:07:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA12189 for ietf-xml-mime-bks; Mon, 12 Apr 1999 21:07:33 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA12185 for ; Mon, 12 Apr 1999 21:07:28 -0700 (PDT) Received: from endymion (modem_f [199.93.212.248]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id AAA24656 for ; Tue, 13 Apr 1999 00:03:56 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: Subject: RE: Starting the ietf-xml-mime mailing list Date: Mon, 12 Apr 1999 23:25:22 -0400 Message-ID: <003601be8563$9dae87b0$0100007f@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0) In-Reply-To: <3.0.32.19990407094512.00cee720@pop.intergate.bc.ca> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > 1. something generic gets the XML and parses it > 1.a the generic something displays the XML to a human using a > stylesheet, possibly with help from other logic for > embedded chunks > from different namespaces. > 1.b the generic something invokes some application. > > The 1.a example is of course Web browsers (although it seems there > are some nasty architectural holes in how you dispatch control for > embedded chunks of XML). I have a hard time thinking of a 1.b > example. > > 2. An app gets invoked to deal with a resource that happens to > be encoded in XML, and the app uses its built-in XML parser. > This case probably wants its own media type; the fact that > the encoding is XML is hardly material. I would say that 1b is roughly equivalent to 2, except for an additional level of abstraction. I actually prototyped, a while ago now, 1b using the standard set of mail tools on Unix. I basically specified a compound document/application object in a TR9401 catalog (a poxy medium it turns out, that needed a lot of fixing, and a number of extensions). That catalog could be transmitted to a generical application that then invoked whatever else was appropriate (in this case, DynaText, Panorama, and Web browsers). I think we need to clearly seperate the issue of packaging a single XML instance/entity, and a compound document. I would argue that the former is almost entirely devoid of any application semantics (being either simple text/xml or application/xml), but the latter *intrinsically* has *some* semantics associated with it. I guess this is basically supporting the notion that application specific uses of XML should have application defined media types, but there is a slight difference in the *mechanism* that I am talking about. We could have something like xml/processing-specification or something suchlike, with an associated handler, and that handler could be reponsible for the dispatch (not part of the MIME world at all). Again, I prototyped something like this some time ago, and it did work well, even on top of *existing* (this was '95) MIME infrastructure. I should note that both Simon St. Laurent and Chris Lilley have been making noise about such "catalogs" recently as well. From owner-ietf-xml-mime Tue Apr 13 02:25:37 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA01607 for ietf-xml-mime-bks; Tue, 13 Apr 1999 02:25:37 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA01601 for ; Tue, 13 Apr 1999 02:25:34 -0700 (PDT) Received: from enoshima (pv24.mag.keio.ac.jp [133.27.195.124]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id SAA23471; Tue, 13 Apr 1999 18:25:39 +0900 (JST) Message-Id: <199904130925.SAA23471@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, 13 Apr 1999 18:05:43 +0900 To: MURATA Makoto From: "Martin J. Duerst" Subject: Re: DTD media type? Cc: ietf-xml-mime@imc.org In-Reply-To: <199904110758.AA00259@archlute.apsdc.ksp.fujixerox.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 16:58 99/04/11 +0900, MURATA Makoto wrote: > In the xml-dev mailing list, some people requested a media type for DTD (to > be precise, an external DTD subset), since browsers should be able to launch > a DTD viewer for DTDs. One could also argue that an additional parameter of > text/xml and application/xml is enough for that purpose. [rest deleted] Makoto, I think the things you have mentioned in your mail are quite important. But my guess is that many of the participants in this discussion don't have the necessary background. Is there somewhere a web page where all these terms are defined and explained with simple examples, or something similar? Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-xml-mime Tue Apr 13 03:34:04 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA06178 for ietf-xml-mime-bks; Tue, 13 Apr 1999 03:34:04 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA06174 for ; Tue, 13 Apr 1999 03:34:02 -0700 (PDT) Received: by mx.fujixerox.co.jp; id TAA04750; Tue, 13 Apr 1999 19:34:19 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma004625; Tue, 13 Apr 99 19:34:05 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id TAA18199 for ; Tue, 13 Apr 1999 19:32:01 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id TAA18368 for ; Tue, 13 Apr 1999 19:34:04 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id TAA01502 for ; Tue, 13 Apr 1999 19:32:05 +0900 Message-Id: <199904131033.AA00281@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Tue, 13 Apr 1999 19:33:59 +0900 To: ietf-xml-mime@imc.org Subject: Re: DTD media type? In-Reply-To: <199904130925.SAA23471@sh.w3.mag.keio.ac.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Martin J. Duerst wrote: > > Makoto, I think the things you have mentioned in your mail are quite important. > But my guess is that many of the participants in this discussion don't have > the necessary background. Is there somewhere a web page where all these terms > are defined and explained with simple examples, or something similar? I am obsessed by XML... Here is an imprecise-but-not-totally-inappropriate analogy. XML documents are source programs. External DTD subsets are header files that contain declarations and are referenced at the beginning of XML documents (note: at most one external DTD subset is referenced by one XML document). External parsed entities are include files that contain source program fragments and are referenced in the middle of XML documents. External parameter entities are include files that contain declarations and are referenced by external DTD subsets. XML document ----------------> external DTD subset | |--> external parameter entity | |--> external parsed entity The BNF for XML documents and that for external DTD subsets are quite different. On the other hand, some external parsed entities are legal XML documents, and some external parameter entities are legal external DTD subsets. Viewers for XML documents and viewers for external DTD subsets are quite different. (Please forgive my white lie. I think that this is enough for our discussion. > XML experts) If you would like to know the truth, the best document on the WWW is Tim's annotated XML. Its URL is: http://www.xml.com/axml/testaxml.htm DTDs, external DTD subsets, and internal DTD subsets are defined in 2.8 of XML 1.0 (http://www.xml.com/axml/target.html#dt-doctype) [Definition:] The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD. The document type declaration can point to an external subset (a special kind of external entity) containing markup declarations, or can contain the markup declarations directly in an internal subset, or can do both. The DTD for a document consists of both subsets taken together. Entitites are defined in Section 4 of XML 1.0. (http://www.xml.com/axml/target.html#sec-physical-struct) Parameter entity [Definition:] Parameter entities are parsed entities for use within the DTD. These two types of entities use different forms of reference and are recognized in different contexts. Furthermore, they occupy different namespaces; a parameter entity and a general entity with the same name are two distinct entities. Parsed entity Entities may be either parsed or unparsed. [Definition:] A parsed entity's contents are referred to as its replacement text; this text is considered an integral part of the document. Hope this helps. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Tue Apr 13 05:10:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA08251 for ietf-xml-mime-bks; Tue, 13 Apr 1999 05:10:51 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA08247 for ; Tue, 13 Apr 1999 05:10:50 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id UAA27670 for ; Tue, 13 Apr 1999 20:11:02 +0800 (CST) Message-ID: <001a01be85a5$7308b0c0$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: References: <199904130925.SAA23471@sh.w3.mag.keio.ac.jp> Subject: Positions on "List of issues" Date: Tue, 13 Apr 1999 20:02:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: My 2 cents worth: > Issue 1: Proposals for additional parameters in the past I agree with Tim Bray that it is inappropriate to give the DTD in a parameter: in particular, because XML content models are basically glorified assert() statements. DOCTYPE declarations are fine and appropriate where they are. But I think we need to have some clearer idea of what the MIME headers are supposed to do; is there a nice functional demarcation between the headers and the resource? In particular, I think we are missing a key distinction that the MIME content-type is not so much the "type" of a resource, but the type of a particular *publication* of a resource. For example, lets take a VML file: if I want to publish it for viewing on a VML browser, I should be able to send it out with the MIME type image/vml (or whatever). If I want to publish it out for viewing by generic XML tools, I send it as text/xml. If I want to publish it for viewing as text, I send it as text/plain. (Browsers are, of course, free to implement any application dispatching system they like, which could circumvent my intentions, but that is life.) So IMHO the MIME content-types should be geared at helping information providers publish documents in forms they think are useful. In other words, it is not the function of the MIME header to describe the resource in general; the MIME header should describe the document enough for the particular uses that the information provider has in mind. With this distinction in mind, we can judge the various parameters suggested using the simple maxim that "when I publish a resource, I publish it with a specific use in mind (even if you use it differently)", which means that we dont need to be overly concerned with "graceful degradatation" or to provide an elaborate class mechanism (not to deny that the class relations exist). Furthermore, let me bring up another problem with parameters: the parameters have to be sourced from somewhere: everytime we have to duplicate information from inside an XML document into a header, we create the chance for a mismatch. If we need fast indexing to elements inside a document, we should invent an index format: eg html 23 head 32 meta 44 meta 55 meta 68 to allow (normalized) character indexing into an XML instance. That would be far more useful in many circumstances than cluttering up the header with lots of parameters. > Issue 2: Type of XML mime entities It would be useful to have a text/dtd (and therefore application/xml) MIME type. text/xml should be used for XML entities (well-formed or not). > Issue 3: UTF-16 > RFC 2376 should be revised when charsets for UTF-16 are registered. Yes. And XML appendix F should be revised simultaneously, so that the specifications are kept in sync. > Issue 4: Characters .vs. bytes > An XML MIME entity is a sequence of characters as opposed to a > sequence of bytes. RFC 2376 is not really clear about this. This is the old question. When we discussed it before, didn't we say that: * a text/xml entity is a sequence of characters * an application/xml entity is a sequence of bytes? I hope an application/* is not a sequence of characters. > Issue 5: Packaging > There should be a mechanism for packaging an XML document together > with its stylesheet, catalog, and referenced resources (e.g., links, > external entities). Relative to the issue of bundling resources with a document, I recently put up a proposal for Document Resource Links, for XML. See http://www.ascc.net/~ricko/drlove.htm Rather than extending the MIME headers with lots of parameter, perhaps just the URI of a single resource like that would allow greater extensibility. And the URI acts as a "publication type name". > Issue 6: Ambiguity of CCS conversion > If this is the case, it might make sense to introduce a parameter > "map" to precisely specify which mapping should be used. This also could have bearing on the PUA (private use area) character problem, and the problem of corporate character sets (e.g. Hong Kong's GCCS). > Issue 7: The default of the charset parameter Chris Lilley's recent proposal to revised RFC2376 is as below: > 1) Require explicit charset for overriding the internal encoding > declaration, so if one really wants to re-label a document as US-ASCII > one actually has to send it out as text/xml; charset="US-ASCII" > 2) Define the absence of an explicit charset encoding in the MIME > header not as "US-ASCII" but as "use encoding in XML instance" in > accordance with the XML 1.0 Recommendation. Yes. But...We should encourage the use of application/xml when data integrity is at a premium, and text/xml when data accessibility is a premium. I wonder whether the following is actually what is required to make text/xml work: * if the MIME charset and the XML encoding PI concur, the entity is accepted with the MIME charset; * if the MIME charset and the XML encoding PI disagree, *and* the content-type is application/xml, the resource should be accepted using the XML encoding PI; * if the MIME charset and the XML encoding PI disagree, *and* the content-type is text/xml, the user-agent may (at user selection): - accept the document using the MIME charset (default; status quo in RFC; indicative of transcoding) - accept the document using the XML PI (indicative of poor server labelling); - follow some policy and heuristics determined by the user-agent (indicative that data integrity is not the highest priority); - reject the entity and request it again as application/xml (safest); where "concurring" takes into account the different defaults. This is all so complicated, maybe we should just always recommend application/xml! Rick Jelliffe Academia Sinica Computing Center Taipei, Taiwan From owner-ietf-xml-mime Tue Apr 13 06:12:59 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10180 for ietf-xml-mime-bks; Tue, 13 Apr 1999 06:12:59 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10176 for ; Tue, 13 Apr 1999 06:12:57 -0700 (PDT) Received: from endymion (modem_c [199.93.212.245]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id JAA03251 for ; Tue, 13 Apr 1999 09:09:28 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: Subject: RE: Positions on "List of issues" Date: Tue, 13 Apr 1999 09:16:16 -0400 Message-ID: <004f01be85af$d0708a80$0100007f@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0) In-Reply-To: <001a01be85a5$7308b0c0$dd066d8c@sinica.edu.tw> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > In particular, I think we are missing a key distinction that the MIME > content-type is not so much the "type" of a resource, but the > type of a particular *publication* of a resource. This is a very good distinction, and a very succint summary. Well done. > Relative to the issue of bundling resources with a document, > I recently put up a proposal for Document Resource Links, for XML. See > http://www.ascc.net/~ricko/drlove.htm > > Rather than extending the MIME headers with lots of > parameter, perhaps just the URI of a single resource like that would allow greater > extensibility. Yes, I think this is absolutely the right way to go. The only thing I would add is that packaging itself has many facets: the "catalog" (drlove, XPDL, etc.) definition, packaging in MIME multipart/*, resource name aliasing, push vs. pull, mixed mode push/pull, etc. that all need to be considered. When we considered this before (for MIME SGML), we concluded that MIME *already* provides sufficient infrastructure... you only really needed to register a few more MIME types for the primary objects (document instances, DTD's, SGML declarations< etc.) and that the rest of the requirements really fall onto the "catalog", or perhaps as you might call it, the "publication specification". > And the URI acts as a "publication type name". This is a nice feature. From owner-ietf-xml-mime Tue Apr 13 06:40:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10794 for ietf-xml-mime-bks; Tue, 13 Apr 1999 06:40:09 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10788 for ; Tue, 13 Apr 1999 06:40:08 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id JAA12777; Tue, 13 Apr 1999 09:40:16 -0400 Message-ID: <37134835.A4152774@w3.org> Date: Tue, 13 Apr 1999 15:35:49 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MURATA Makoto CC: ietf-xml-mime@imc.org Subject: Re: DTD media type? References: <199904131033.AA00281@archlute.apsdc.ksp.fujixerox.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: MURATA Makoto wrote: > > Martin J. Duerst wrote: > > Is there somewhere a web page where all these terms > > are defined and explained with simple examples, or something similar? > Here is an imprecise-but-not-totally-inappropriate analogy. > > XML documents are source programs. [...] This is a strikingly good analogy; I wish I had read your mail before giving my tutorial today. Lots of people are familiar with programming; it hadn't occurred to me to > The BNF for XML documents and that for external DTD subsets are quite > different. On the other hand, some external parsed entities are > legal XML documents, and some external parameter entities are legal > external DTD subsets. > > Viewers for XML documents and viewers for external DTD subsets are > quite different. This is a good summary. It shows that, for example, a generic XML parser and router, as has been discussed on this list, would bot be able to deal with external DTD subsets. Since the parser is different (or rather, since the start token is different) then using a parameter would not seem wise. Rather, a different MIME type (for example, text/xml-xdtd ) would seem a better choice. Or application/xml-xdtd if we decide that text/* is unusable for XML. We currently serve DTDs as text/plain on the W3C site; it would be better to use a more descriptive type. -- Chris From owner-ietf-xml-mime Tue Apr 13 07:32:53 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11991 for ietf-xml-mime-bks; Tue, 13 Apr 1999 07:32:53 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11985 for ; Tue, 13 Apr 1999 07:32:52 -0700 (PDT) Received: from simon (slip129-37-221-142.ny.us.ibm.net [129.37.221.142]) by hesketh.net (8.8.8/8.8.8) with SMTP id KAA10774; Tue, 13 Apr 1999 10:33:02 -0400 Message-Id: <199904131433.KAA10774@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Apr 1999 10:36:18 -0400 To: , From: "Simon St.Laurent" Subject: Catalogs and MIME types In-Reply-To: <003601be8563$9dae87b0$0100007f@eps.inso.com> References: <3.0.32.19990407094512.00cee720@pop.intergate.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:25 PM 4/12/99 -0400, Gavin Thomas Nicol wrote: >I should note that both Simon St. Laurent and Chris Lilley have been making >noise about such "catalogs" recently as well. And then later: >> Rather than extending the MIME headers with lots of >> parameter, perhaps just the URI of a single resource like that would allow >greater >> extensibility. > >Yes, I think this is absolutely the right way to go. The only thing I would >add is that packaging itself has many facets: the "catalog" (drlove, XPDL, >etc.) >definition, packaging in MIME multipart/*, resource name aliasing, push vs. >pull, >mixed mode push/pull, etc. that all need to be considered. XPDL (http://purl.oclc.org/NET/xpdl) is exactly about this packaging (and I really should talk with Rick about his drlove project to figure out if we have much in common.) After a number of rounds on XML-Dev complaining about the imprecision of the methods currently available for identifying XML document types (including MIME), I figured it was time to go ahead and write up a proposal for describing such types. At this point, I think I'm leaning toward leaving the MIME type application/xml for documents (and creating something more descriptive for DTDs) and using a different mechanism to connect the descriptions to the document. (The XPDL draft currently has five possibilities, and I'm pondering a sixth.) Rick's point that a single XML document may be a chameleon of MIME types, capable of being presented as text/x-myType, application/xml, possibly text/xml and text/plain, and potentially even more, seems very striking. We've moved beyond "one document - one type" and dealing with that will be difficult. I think I'd rather let MIME identify a basic type - application/xml - and develop another mechanism for detail beyond that. XML documents share some key features as far as transfer over networks, which to me at least is what MIME is best for helping with. Simon St.Laurent XML: A Primer Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Tue Apr 13 10:11:29 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17325 for ietf-xml-mime-bks; Tue, 13 Apr 1999 10:11:29 -0700 (PDT) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA17319 for ; Tue, 13 Apr 1999 10:11:26 -0700 (PDT) Received: from server3.software-ag.de by server1.software-ag.de; (5.65v3.2/1.1.8.2/21Dec95-0433PM) id AA10561; Tue, 13 Apr 1999 19:15:35 +0200 Received: from pcpl.software-ag.de by server3.software-ag.de; (5.65v3.2/1.1.8.2/21Dec95-0542PM) id AA10299; Tue, 13 Apr 1999 19:15:34 +0200 Date: Tue, 13 Apr 1999 19:15:34 +0200 Message-Id: <9904131715.AA10299@server3.software-ag.de> From: Paul Langer To: ricko@gate.sinica.edu.tw Cc: ietf-xml-mime@imc.org In-Reply-To: <001a01be85a5$7308b0c0$dd066d8c@sinica.edu.tw> (ricko@gate.sinica.edu.tw) Subject: Re: Positions on "List of issues" References: <199904130925.SAA23471@sh.w3.mag.keio.ac.jp> <001a01be85a5$7308b0c0$dd066d8c@sinica.edu.tw> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Rick Jelliffe wrote (http://www.imc.org/ietf-xml-mime/mail-archive/msg00064.html): > In particular, I think we are missing a key distinction that the MIME > content-type is not so much the "type" of a resource, but the type of a > particular *publication* of a resource. I disagree with this definiton of the semantics of "MIME content-type". As far as I know, the MIME mechanism is the only mechanism for data typing that is available today on the Internet. The HTTP/1.1 spec (http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt) says: "3.7 Media Types HTTP uses Internet Media Types [17] in the Content-Type (section 14.17) and Accept (section 14.1) header fields in order to provide open and extensible data typing and type negotiation." XML is portable data; the particular use of this data should not be specified by the "publisher". The user should be able to detect the data type and then select an application that he/she likes. How can a "publisher" know, what applications are available at the user's site? All the best, Paul ----------------------------------------------------------- Paul Langer E-mail pl@softwareag.com Software AG Tel. +49-6151-92-1912 Uhlandstr. 12 Fax +49-6151-92-1613 D-64297 Darmstadt From owner-ietf-xml-mime Tue Apr 13 11:31:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19883 for ietf-xml-mime-bks; Tue, 13 Apr 1999 11:31:57 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19879 for ; Tue, 13 Apr 1999 11:31:55 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id CAA01061; Wed, 14 Apr 1999 02:32:04 +0800 (CST) Date: Wed, 14 Apr 1999 02:32:03 +0800 (CST) From: Rick Jelliffe To: Paul Langer cc: ietf-xml-mime@imc.org Subject: Re: Positions on "List of issues" In-Reply-To: <9904131715.AA10299@server3.software-ag.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, Paul Langer wrote: > Rick Jelliffe wrote > (http://www.imc.org/ietf-xml-mime/mail-archive/msg00064.html): > > In particular, I think we are missing a key distinction that the MIME > > content-type is not so much the "type" of a resource, but the type of a > > particular *publication* of a resource. > > I disagree with this definiton of the semantics of "MIME content-type". > XML is portable data; the particular use of this data should not be > specified by the "publisher". The user should be able to detect the > data type and then select an application that he/she likes. How can a > "publisher" know, what applications are available at the user's site? My point is not that a "publication" selects an application, but that it is metadata which is expected to select a class of handler: we expect a MIME content-type of application/xml will select a different class of handler to text/plain. Otherwise, all XML would be text/plain and we wouldn't need this mail list. If you want an example, the DTDs on my site at http://www.ascc.net/xml/ are typically published both as .dtd (text/xml) and .txt (text/plain). This is because I don't know which class of handler the user has: in the case of IE5, the DTD will cause a WF error, and it the user cannot View Source (if they know how) to view the whole DTD, because the file transmission is aborted. Providing this kind of multiple content-type doesnt require any additional MIME parameters, I can do it at on the file system using links. Rick Jelliffe Academia Sinica Computing Center Tapei, Taiwan From owner-ietf-xml-mime Tue Apr 13 23:28:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19715 for ietf-xml-mime-bks; Tue, 13 Apr 1999 23:28:58 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA19700 for ; Tue, 13 Apr 1999 23:28:35 -0700 (PDT) Received: from enoshima (pv24.mag.keio.ac.jp [133.27.195.124]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id PAA02332; Wed, 14 Apr 1999 15:28:31 +0900 (JST) Message-Id: <199904140628.PAA02332@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: Wed, 14 Apr 1999 15:00:31 +0900 To: "Rick Jelliffe" From: "Martin J. Duerst" Subject: Re: Positions on "List of issues" Cc: In-Reply-To: <001a01be85a5$7308b0c0$dd066d8c@sinica.edu.tw> References: <199904130925.SAA23471@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 20:02 99/04/13 +0800, Rick Jelliffe wrote: > My 2 cents worth: > > > Issue 1: Proposals for additional parameters in the past > > I agree with Tim Bray that it is inappropriate to give the DTD in a > parameter: in particular, because XML content models are basically glorified > assert() statements. DOCTYPE declarations are fine and appropriate where > they are. > In particular, I think we are missing a key distinction that the MIME > content-type is not so much the "type" of a resource, but the type of a > particular *publication* of a resource. Well, if it's to distinguish the PS version of a document from the pdf version and from the HTML version, then you are certainly right. And it should also be possible to serve something as text/plain if one really wants. But in the general case, the idea is really that you say what it is, and leave the rest of the choice to the user and it's environment. Cases where this doesn't work are implementation problems, not proofs of concept. > Furthermore, let me bring up another problem with parameters: the parameters > have to be sourced from somewhere: everytime we have to duplicate > information from inside an XML document into a header, we create the chance > for a mismatch. Yes indeed. [I might come back to this point in another discussion :-] The main distinction is: What do you want to be able to do without having to look inside the resource. On many systems, having to look inside or not is a big distinction in practical terms. > > RFC 2376 should be revised when charsets for UTF-16 are registered. > > Yes. And XML appendix F should be revised simultaneously, so that the > specifications are kept in sync. Good point. > > Issue 4: Characters .vs. bytes > > > An XML MIME entity is a sequence of characters as opposed to a > > sequence of bytes. RFC 2376 is not really clear about this. > > This is the old question. When we discussed it before, didn't we say that: > * a text/xml entity is a sequence of characters > * an application/xml entity is a sequence of bytes? > > I hope an application/* is not a sequence of characters. Definitely not. In both cases, there are two levels, the character level and the byte level. In both cases, XML is defined in terms of characters, and not bytes. Therefore, in both cases, an XML document is a sequence of characters. In both cases, when sent as a MIME entity, it has to be sent as a sequence of bytes. You are right that in the case of application/xml, the chance that the bytes don't change is higher than in the case of text/xml, but it is pretty high in both cases anyway. > > Issue 6: Ambiguity of CCS conversion > > > If this is the case, it might make sense to introduce a parameter > > "map" to precisely specify which mapping should be used. > > This also could have bearing on the PUA (private use area) character > problem, and the problem of corporate character sets (e.g. Hong Kong's > GCCS). Adding parameters will just increase the mess with current charsets. It will send the message "it's okay to change a charset slightly, just add a parameter". This is definitely not what we need! Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-ietf-xml-mime Wed Apr 14 04:10:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00328 for ietf-xml-mime-bks; Wed, 14 Apr 1999 04:10:12 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00324 for ; Wed, 14 Apr 1999 04:10:10 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id TAA19338; Wed, 14 Apr 1999 19:10:22 +0800 (CST) Message-ID: <002701be8666$22c6e980$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: "Martin J. Duerst" Cc: References: <199904130925.SAA23471@sh.w3.mag.keio.ac.jp> <199904140628.PAA02332@sh.w3.mag.keio.ac.jp> Subject: Re: Positions on "List of issues" Date: Wed, 14 Apr 1999 19:01:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: From: Martin J. Duerst >But in the general case, the idea is really that you > say what it is, and leave the rest of the choice to the user and it's > environment. "What it is" is a judgement based on the provider's expectations about how the document will act at the recipient. I don't think many people will just stick XML on the net without some intended application. But people feel that text/xml does not allow them to express "what it is"; in particular, I think people want to run a Java program on the XML document without having to load an initial HTML document first. If that is, in fact, the major need, is it something that text/xml should address? Personally, I don't think so. Rick From owner-ietf-xml-mime Thu Apr 15 07:42:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20812 for ietf-xml-mime-bks; Thu, 15 Apr 1999 07:42:47 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20804 for ; Thu, 15 Apr 1999 07:42:45 -0700 (PDT) Received: by mx.fujixerox.co.jp; id XAA24626; Thu, 15 Apr 1999 23:42:48 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma024591; Thu, 15 Apr 99 23:42:23 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id XAA16120 for ; Thu, 15 Apr 1999 23:40:19 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id XAA13655 for ; Thu, 15 Apr 1999 23:42:22 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id XAA14703 for ; Thu, 15 Apr 1999 23:40:14 +0900 Message-Id: <199904151442.AA00303@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 15 Apr 1999 23:42:04 +0900 To: ietf-xml-mime@imc.org Subject: Five proposed solutions MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 1. Summary My first mail to this mailing list lists four possible solutions for dispatching (and content negotiation). Solution 1. Specialized media types (possibly with some parameters) Solution 2: New top-level media type xml and its subtypes Solution 3: A new parameter "externalid" for text/xml and application/xml Solution 4: Yet another parameter "optinfo" or "ADD-PARAM" on top of solution 3 Larry added another. Solution 5: The handler of the XML media types examines the XML MIME entity and then dispatches to one of several possible media type handlers. So far, solution 1 has found some strong support. Solution 2 has neither strong opposition nor strong support, but has been questioned. Solution 3 and 4 do not work. Solution 5 has not received any support. 2. Solution 1 Solution 1 has found some strong support. "I tend to lean towards "every application gets a new media type." (PaulH) "In case it isn't obvious by now, so do I." (Ned) "My quick and dirty way of thinking of this is that the media type/subtype should to be sufficient to get you the right application, but the parameters then can tell that application what to do, or when to do it, or various other sorts of things that for whatever reason are best not stored in or derived from the actual content." (Ned) One concern is the burden of registration, but "Registration of media subtypes is easy." (Agreement 1 in "What we have agreed on"). Furthermore, a specialized media type may require parameters specific to that media type. "However, in the general problem space surrounding these sorts of applications, I see value in using parameters." (Ned) "However, just having a "calendar" media type won't cut it. The CUA needs to be able to search the MIME entity bucket for particular types of "calendar" media types." (Frank) 3. Solution 2 We have not yet found good reasons fot a top-level media type for xml. Fallback is not a good reason, since "Fallback to general-purpose XML applications is not useful." (Agreement 3 in "What we have agreed on"). Here are some other weak reasons. "However, if the answer [My note: the more general question of whether there is to be an attempt to "design" the XML usage space, and if there is, whether such an attempt has any chance of succeeding.] to this is "yes", then the task at hand becomes one of coming up with an appropriate set of rules that people think will actually do the job and will be followed. And in such a world a top-level XML type might have some value, if only as a place to attach the ruleset." (Ned) "The only value I would see is if the fallbacks and other behaviours of the text/* tree were seen to be unavoidable and made the use of XML too fragile there. XML element names and element content can use all sorts of Unicode characters." (Chris) "We can also lift the line termination rule of the top-level media type "text"." (Murata) [Note: There are some possible reasons, which I will mention my personal mail.] However, it might make sense to introduce a top-level media type for document-like XML, since "Document-like XML documents can be handled by general-purpose XML viewers" (Agreement 4 in "What we have agreed on"). 4. Solution 3 and 4 Solution 3 and 4 do not work, since "Dispatch based on parameters are not widely supported" (Agreement 2). "I'm afraid you've missed the biggest problem with this approach -- one that makes it almost a complete nonstarter: The lack of ability to dispatch on parameters in most applications that support MIME." (Ned) 5. Solution 5 Larry advocates this solution. He points out that MIME headers cannot entirely solve the problem of dispatching and negotiation. "In general, you cannot solve the problem of "dispatch to the appropriate handler" by modifying MIME, since finding the appropriate handler is platform and installation dependent." (Larry) "And adding more MIME types for each kind of combination of XML seems like a recipe for disaster. If we have html, xhtml, html-netscape, html-microsoft, html-optimized-for-msie-on-windows-nt50, each with slightly different definitions, would they get separate MIME types?" (Larry) "... specialized media types should be introduced with caution, since a world in which every kind of document has its own media types is one in which there is little interoperability." (Larry) "Neither adding parameters to text/calendar nor inventing new MIME subtypes for text/calendar-request text/calendar-response etc. will help implement the query capabilities that you need. ... Since it doesn't work, stop trying. You need some other kind of query protocol than keying off content-type." (Larry) "Someone has to parse them. Certainly if a search engine can parse web pages to find the words and their lexical equivalences, an event search engine can parse the XML documents and index them in the multiple ways that searching the calendar-event database needs to be searched." (Larry) "Purchase orders that are applicable to the particular division, purchase orders that haven't already been processed, purchase orders that are assigned to a particular account rep, etc. These are all database search problems, not type-indexing problems." (Larry) "You might also want to scan your email for "event invitations from my boss", and you can't solve that problem with specialized MIME media types. So the question is: are there any realistic cases where having a "text/calendar" distinction in the email header actually helps substantially in deciding which email bodies to retrieve?" (Larry) The others disagree for basically two reasons. The first reason is that we should not prevent developers from developing new media types only because they use XML. "If the answer to this is "no, we don't want to try and control the development, direction, and use of XML" then your question is basically out of scope. People will design whatever they want and register whatever they want. The resulting mixtures and granularity will be whatever developers decide is appropriate." (Ned) "Not just developers; increasingly, vertical markets. An XML namespace for real-estate listings, for example. One for dental records. So forth." (Chris) "This is the position of W3C; certain building blocks are made available (foundational blocks such as XML itself, XLink, XPointer, namespaces, etc; useful common things like styleshets, SVG for images, RDF for metadata which can be used or not as appropriate) but the way in which people combine these building blocks is up to them, and the element names that they use (when not using a building block that defines names for them, like XHTML and SVG do) is entirely their own affair." (Chris) The second reason is the burden of parsing. "Certainly with a mail protocol like IMAP you can look through your inbox for entries based on values of the MIME header fields. The example mentioned was a "mail-enabled" application. For this application, the implementors on the IETF CALSCH WG felt very much that the MIME header field parameters were of importance." (Frank) "Yes; especially in the case of IMAP where the initial selection of bodis is done on the server and likely ones are sent to the client for the calendar program to further process." (Chris) "But it [specialized media types] sure cuts down the class of data to be further processed. Instead of searching through the entire mailbox/the entire server, just search in the text/calendar resources." (Frank) "The overhead of having to open up every XML document to find out what document type it is is not practical. As in the case of email, all I should have to do is ask for a particular type of object from the store and get it." (Frank) "There needs to be some balance between an infinite number of media types/subtypes for each transaction type and a smaller, managable number of media types for each logical application object type. As Ned has pointed out, this example and other show that leaving "hooks" on the outside of the object wrapper is very useful in providing a scalable, practical Internet solution using XML." (Frank) "The thing to avoid, though, it to havce to parse the document once to find out what sort of thing it is, dispatch it somewhere else, and then have that "somewhere else" start parsing again from scratch. If that can be avoided by better labelling up front, that is a win." (Chris) Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu Apr 15 08:34:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23408 for ietf-xml-mime-bks; Thu, 15 Apr 1999 08:34:07 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23404 for ; Thu, 15 Apr 1999 08:34:06 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <51855(3)>; Thu, 15 Apr 1999 08:34:26 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <98484>; Thu, 15 Apr 1999 08:34:13 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Five proposed solutions Date: Thu, 15 Apr 1999 08:34:02 PDT Message-ID: <001701be8755$634ccca0$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199904151442.AA00303@archlute.apsdc.ksp.fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I'm afraid you've let your personal viewpoint color your summary of the issues. You said: "Solution 5 has not received any support." and then gave quotes which, for the most part, don't really support that summary. > The others disagree for basically two reasons. The first reason is > that we should not prevent developers from developing new media types > only because they use XML. "Solution 5" doesn't prevent developers from developing new media types. "Solution 5" just asks developers to code new media types using existing media type labels. They are free to develop new kinds of media. "Solution 5" doesn't prevent new developments. It just says that those new developments are labeled as "text/xml" or "application/xml". > "If the answer to this is "no, we don't want to try and > control the development, direction, and use of XML" then your > question is basically out of scope. People will design > whatever they want and register whatever they want. The > resulting mixtures and granularity will be whatever developers > decide is appropriate." (Ned) I thought Ned's position was actually agreeing with Solution 5. I don't think that it's a matter of whether we "want" to control these things, but whether it's practical. I'd like to recommend that applications use text/xml or application/xml, unless they have a strong need to do something else, and note that in most cases, there isn't a strong need, since the actual nature of the data can be determined by looking inside the XML itself. > "Not just developers; increasingly, vertical markets. An XML > namespace for real-estate listings, for example. One for > dental records. So forth." (Chris) I don't see that Chris is arguing against using text/xml or application/xml as the MIME label for external representations for XML bodies that use vertical market namespaces. > "This is the position of W3C; certain building blocks are made > available (foundational blocks such as XML itself, XLink, > XPointer, namespaces, etc; useful common things like > styleshets, SVG for images, RDF for metadata which can be used > or not as appropriate) but the way in which people combine > these building blocks is up to them, and the element names > that they use (when not using a building block that defines > names for them, like XHTML and SVG do) is entirely their own > affair." (Chris) This doesn't argue one way or another against "solution 5". > The second reason is the burden of parsing. The arguments from Chris and Frank are all about IMAP. But the problem isn't a general one for "a mail protocol like IMAP", it is "IMAP" that has the problem. An IMAP server has parsed the MIME bodies of the messages in the mail store, in any case. It's separated out multipart bodies, parsed the mail headers into names and values, dealt with various encoding issues. The only problem is that IMAP contains inconsistent access to parsing and query facilities. But this is just a weakness of IMAP. If you were using, say, WebDAV, to access your mailbox, then the DTD of the XML body of your mail could as easily be a property of the message body. > "Certainly with a mail protocol like IMAP you can look through > your inbox for entries based on values of the MIME header > fields. The example mentioned was a "mail-enabled" > application. For this application, the implementors on the > IETF CALSCH WG felt very much that the MIME header field > parameters were of importance." (Frank) > > "Yes; especially in the case of IMAP where the initial > selection of bodis is done on the server and likely ones are > sent to the client for the calendar program to further > process." (Chris) > "But it [specialized media types] sure cuts down the class of > data to be further processed. Instead of searching through the > entire mailbox/the entire server, just search in the > text/calendar resources." (Frank) > > "The overhead of having to open up every XML document to find > out what document type it is is not practical. As in the case > of email, all I should have to do is ask for a particular type > of object from the store and get it." (Frank) > > "There needs to be some balance between an infinite number of > media types/subtypes for each transaction type and a smaller, > managable number of media types for each logical application > object type. As Ned has pointed out, this example and other > show that leaving "hooks" on the outside of the object wrapper > is very useful in providing a scalable, practical Internet > solution using XML." (Frank) > > "The thing to avoid, though, it to havce to parse the document > once to find out what sort of thing it is, dispatch it > somewhere else, and then have that "somewhere else" start > parsing again from scratch. If that can be avoided by better > labelling up front, that is a win." (Chris) In general, we have to do this anyway: we parse the MIME to separate out the multipart bodies, and then reparse the bodies when we do the dispatch. If there's a generic XML dispatch engine in your operating system, then perhaps it can pass on parsed-XML instead of raw-XML, though, which would save some of the extra processing. The dispatched XML media handlers would operate with DOM rather than by reparsing, even if one of them was a DOM-toothbrush-interpreter and another was a DOM-apartment-for-rent processor. Larry -- http://www.parc.xerox.com/masinter From owner-ietf-xml-mime Fri Apr 16 02:14:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA27556 for ietf-xml-mime-bks; Fri, 16 Apr 1999 02:14:09 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27552 for ; Fri, 16 Apr 1999 02:14:07 -0700 (PDT) Received: by mx.fujixerox.co.jp; id SAA12629; Fri, 16 Apr 1999 18:14:39 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma012435; Fri, 16 Apr 99 18:13:58 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id SAA28076 for ; Fri, 16 Apr 1999 18:11:53 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id SAA12861 for ; Fri, 16 Apr 1999 18:13:56 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id SAA29469 for ; Fri, 16 Apr 1999 18:11:56 +0900 Message-Id: <199904160913.AA00309@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 16 Apr 1999 18:13:53 +0900 To: Subject: Re: Five proposed solutions In-Reply-To: <001701be8755$634ccca0$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > I'm afraid you've let your personal viewpoint color your summary > of the issues. You said: > > "Solution 5 has not received any support." > > and then gave quotes which, for the most part, don't really support > that summary. I tried not to mix my personal viewpoint. Even if I had failed to do so, that was never intended. Anyway, my mail and your note (and probably your response to my questions below) collectively provide a "summary". I have two questions for clarification. Larry Masinter wrote: > I'd like to recommend > that applications use text/xml or application/xml, unless they > have a strong need to do something else, and note that in most > cases, there isn't a strong need, since the actual nature of > the data can be determined by looking inside the XML itself. Q1. Do you propose to revise RFC 2048 and discourage media types that are built on top of XML? Q2. Do you propose to revise RFC 2376 and discourage such media types? Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Fri Apr 16 04:04:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA02229 for ietf-xml-mime-bks; Fri, 16 Apr 1999 04:04:58 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA02225 for ; Fri, 16 Apr 1999 04:04:57 -0700 (PDT) Received: by mx.fujixerox.co.jp; id UAA09839; Fri, 16 Apr 1999 20:05:29 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma009802; Fri, 16 Apr 99 20:05:01 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id UAA23716 for ; Fri, 16 Apr 1999 20:02:57 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id UAA16036 for ; Fri, 16 Apr 1999 20:05:00 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id UAA01294 for ; Fri, 16 Apr 1999 20:03:00 +0900 Message-Id: <199904161104.AA00313@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 16 Apr 1999 20:04:57 +0900 To: ietf-xml-mime@imc.org Subject: Parameters for top-level XML media types? MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: We have agreed on two points about fallback. > 3. Fallback to general-purpose XML applications is not useful. > > 4. Document-like XML documents can be handled by general-purpose > XML viewers Other than fallback, are there any reasons for introducing top-level XML media types? One possible reason is that all subtypes can share parameters of the top-level media types. Possibilities for such parameters are as below: - the version of XML, - the version of Unicode, - how the Private Use Area (PUA) of Unicode is used [Rick Jelliffe wrote: "This also could have bearing on the PUA (private use area) character problem, and the problem of corporate character sets (e.g. Hong Kong's GCCS)."] - which conversion table (Note: for a given CCS, more than one conversion table may exist), - which schema language is used (DTD or the upcoming schema language from W3C), - which stylesheet (XSL, CSS, DSSSL, etc.) is used, and - other issues mentioned in my mail "List of issues". Does anybody think that some of them are good enough reasons for introducing top-level XML media types? (I am just asking.) Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Fri Apr 16 09:09:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12739 for ietf-xml-mime-bks; Fri, 16 Apr 1999 09:09:27 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA12734 for ; Fri, 16 Apr 1999 09:09:25 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <54553(2)>; Fri, 16 Apr 1999 09:09:55 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <98906>; Fri, 16 Apr 1999 09:09:45 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Five proposed solutions Date: Fri, 16 Apr 1999 09:09:40 PDT Message-ID: <001201be8823$885ece20$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199904160913.AA00309@archlute.apsdc.ksp.fujixerox.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Q1. Do you propose to revise RFC 2048 and discourage media types > that are built on top of XML? Certainly not. People can build media types "that are built on top of XML", in the same way that XML is a media type that is built on top of "text/plain". XML inherits many of the characteristics of text/plain, but it isn't text/plain, because that's not how it is intended to be processed. text/plain can be processed with a generic text processor, but you can't tell the difference between my autoexec.bat and a web page. > Q2. Do you propose to revise RFC 2376 and discourage such > media types? I think that the revision of RFC 2376 (necessary anyway) will need to give some guidelines. For the most part, the external representations of components of XML don't need any MIME designation at all, because in order to process them, they have to be supplied in some context or wrapped in some kind of packaging or container that doesn't need to use MIME anyway. (That is, the MIME label might as well be text/plain or application/octet-stream). The only cases where you need a MIME label at all is when the body is being sent as a message body; i.e., in a context where you might be sending almost anything at all. MIME is _not_ the only way of labelling data in Internet protocols. Even in those cases, applications where the type of message body can be distinguished by the DOCTYPE within the XML body need not define a separate MIME type. In some cases, where the body isn't intended to be processed by a general XML processor, but a separately coded processor for some subset of XML that was designed for the application, or where the bodies don't contain sufficient declarations internally to distinguish them from other body types, it might be necessary to register a separate MIME type. So perhaps the calandaring applications have components that use MIME but aren't intended to be processed by a general MIME processor, and so separate MIME types are needed. It would be useful to note that the generic text/xml or application/xml designations are only appropriate for those bodies that contain a DOCTYPE (or whatever new typing mechanism you're going to add.) I.e., "XML bodies that are intended to be used in Internet protocols should always contain a DOCTYPE." You might even want to restrict the use so that the initial segment is easy to parse without invoking a general XML parser. Larry From owner-ietf-xml-mime Fri Apr 16 09:13:13 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13270 for ietf-xml-mime-bks; Fri, 16 Apr 1999 09:13:13 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA13266 for ; Fri, 16 Apr 1999 09:13:12 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <54580(1)>; Fri, 16 Apr 1999 09:13:46 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <98911>; Fri, 16 Apr 1999 09:13:39 PDT From: "Larry Masinter" To: "Larry Masinter" , "MURATA Makoto" , Subject: RE: Five proposed solutions Date: Fri, 16 Apr 1999 09:13:35 PDT Message-ID: <001501be8824$14432ee0$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <001201be8823$885ece20$15d0000d@copper.parc.xerox.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > So perhaps the calandaring applications have components > that use MIME but aren't intended to be processed by a general > MIME processor, and so separate MIME types are needed. er: So perhaps the calendaring applications have components that use XML but aren't intended to be processed by a general XML processor, so separate MIME types are needed. Sorry, Larry From owner-ietf-xml-mime Sun Apr 18 20:15:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA17107 for ietf-xml-mime-bks; Sun, 18 Apr 1999 20:15:49 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA17103 for ; Sun, 18 Apr 1999 20:15:48 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52665(4)>; Sun, 18 Apr 1999 20:16:29 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <99519>; Sun, 18 Apr 1999 20:16:18 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Parameters for top-level XML media types? Date: Sun, 18 Apr 1999 20:16:11 PDT Message-ID: <000d01be8a12$f9b53780$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199904161104.AA00313@archlute.apsdc.ksp.fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > - the version of XML, Not any more than Postscript 1 and Postscript 2 having separate versions. > - the version of Unicode, Not for any other text type, why for XML? > - how the Private Use Area (PUA) of Unicode is used > [Rick Jelliffe wrote: "This also could have bearing on the PUA > (private use area) character problem, and the problem of corporate > character sets (e.g. Hong Kong's GCCS)."] Using Private Use Area in Unicode is tantamount to using a private charset. Suggestion: a) eliminate text/xml b) eliminate 'charset' parameter from application/xml The charset is self-identifying. If there is a PUA in use, then it must be declared in the head of the XML body. Having PUAs in your charset is like having a private use font. > - which conversion table (Note: for a given CCS, more than one conversion > table may exist), > - which schema language is used (DTD or the upcoming schema language > from W3C), > - which stylesheet (XSL, CSS, DSSSL, etc.) is used, and > - other issues mentioned in my mail "List of issues". > > Does anybody think that some of them are good enough reasons for introducing > top-level XML media types? (I am just asking.) These are good reasons for making sure that this information is self-identified in the head of the XML body. From owner-ietf-xml-mime Wed Apr 28 11:30:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27900 for ietf-xml-mime-bks; Wed, 28 Apr 1999 11:30:02 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA27896 for ; Wed, 28 Apr 1999 11:30:01 -0700 (PDT) Received: from simon (slip129-37-221-54.ny.us.ibm.net [129.37.221.54]) by hesketh.net (8.8.8/8.8.8) with SMTP id OAA10940 for ; Wed, 28 Apr 1999 14:31:37 -0400 Message-Id: <4.0.1.19990428142914.00fac100@207.211.141.31> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 28 Apr 1999 14:34:48 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Fwd: RE: Transformation + FOs makes abuse easy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: It's a little ways out from the discussions that have dominated this list, but I thought it might raise some interesting issues. (text/xfo would be for documents using the XSL Formatting Objects vocabulary.) I'm violently opposed to these transmissions, but the use of MIME as a supporting infrastructure component seems likely, so I thought I'd put it on the radar screen. >From: Miles Sabin >To: "'xsl-list@mulberrytech.com'" >Cc: "'simonstl@simonstl.com'" >Subject: RE: Transformation + FOs makes abuse easy >Date: Wed, 28 Apr 1999 18:41:28 +0100 > >Simon St.Laurent wrote, >> As a result, the 'meaningful Web' project that was the >> driving force (at least in public) for the creation of >> XML is at risk. Server-side transformation from >> semantically rich private vocabularies to presentation- >> oriented public vocabularies may leave the Web exactly >> where it was before - interesting to read, but not very >> useful. > >Silly question, but (modulo the invention of a few new >mime types), wouldn't the distinction between, > > Accept: text/xml, text/xsl > >and, > > Accept: text/xfo > >resolve this issue? Ie. if you're happy to recieve a >presentation-oriented server-side processed document you >use the latter. If you want it undigested, you use the >former. > >Cheers, > > >Miles > >-- >Miles Sabin Cromwell Media >Internet Systems Architect 5/6 Glenthorne Mews >+44 (0)181 410 2230 London, W6 0LJ >msabin@cromwellmedia.co.uk England > Simon St.Laurent XML: A Primer Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 04:10:08 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27431 for ietf-xml-mime-bks; Thu, 6 May 1999 04:10:08 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27427 for ; Thu, 6 May 1999 04:10:07 -0700 (PDT) Received: by mx.fujixerox.co.jp; id UAA24969; Thu, 6 May 1999 20:12:19 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma024934; Thu, 6 May 99 20:12:01 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id UAA12168 for ; Thu, 6 May 1999 20:10:00 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id UAA00390 for ; Thu, 6 May 1999 20:12:00 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id UAA17575 for ; Thu, 6 May 1999 20:09:54 +0900 Message-Id: <199905061112.AA00400@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Thu, 06 May 1999 20:12:15 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <000d01be8a12$f9b53780$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > Does anybody think that some of them are good enough reasons for introducing > > top-level XML media types? (I am just asking.) > > These are good reasons for making sure that this information is > self-identified in the head of the XML body. It appears that nobody think parameters are good enough reasons for introducing a top-level media type "xml". Thus, the only possible reason is: > 4. Document-like XML documents can be handled by general-purpose > XML viewers I do not think this is a good reason either. XML browsers only have to examine the stylesheet PI and then invoke appropriate formatting engines. Thus, I believe that there is no reason to introduce a top-level media type "xml". Have we reached a consensus here? > Suggestion: > a) eliminate text/xml > b) eliminate 'charset' parameter from application/xml > The charset is self-identifying. If there is a PUA in use, > then it must be declared in the head of the XML body. > Having PUAs in your charset is like having a private use > font. If the charset parameter is not present, we cannot use negotiation of HTTP 1.1, which is already available. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu May 6 08:32:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29331 for ietf-xml-mime-bks; Thu, 6 May 1999 08:32:58 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA29326 for ; Thu, 6 May 1999 08:32:56 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52318(3)>; Thu, 6 May 1999 08:35:04 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <99509>; Thu, 6 May 1999 08:34:54 PDT From: "Larry Masinter" To: "MURATA Makoto" , Subject: RE: Parameters for top-level XML media types? Date: Thu, 6 May 1999 08:34:53 PDT Message-ID: <000501be97d5$fc629560$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199905061112.AA00400@archlute.apsdc.ksp.fujixerox.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: re: > Suggestion: > a) eliminate text/xml > b) eliminate 'charset' parameter from application/xml > The charset is self-identifying. If there is a PUA in use, > then it must be declared in the head of the XML body. > Having PUAs in your charset is like having a private use > font. Makoto wrote: > If the charset parameter is not present, we cannot use negotiation > of HTTP 1.1, which is already available. This is not true. The scope of "Accept-Charset" is unclear (whether it applies to more than text/plain and text/html), but it does not depend on there being a "charset" parameter on the results. From owner-ietf-xml-mime Thu May 6 08:57:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29595 for ietf-xml-mime-bks; Thu, 6 May 1999 08:57:09 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29590 for ; Thu, 6 May 1999 08:57:08 -0700 (PDT) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA09354; Thu, 6 May 1999 11:55:33 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'Larry Masinter'" , "'MURATA Makoto'" , Subject: RE: Parameters for top-level XML media types? Date: Thu, 6 May 1999 11:58:44 -0400 Message-ID: <000101be97d9$523205e0$577670c6@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 In-Reply-To: <000501be97d5$fc629560$aa66010d@copper.parc.xerox.com> Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Suggestion: > > a) eliminate text/xml > > b) eliminate 'charset' parameter from application/xml > > The charset is self-identifying. If there is a PUA in use, > > then it must be declared in the head of the XML body. > > Having PUAs in your charset is like having a private use > > font. > > Makoto wrote: > > > If the charset parameter is not present, we cannot use negotiation > > of HTTP 1.1, which is already available. Note that the encoding declaration is not mandatory for XML. An XML document does not necessarily have to start with an XML declaration. From owner-ietf-xml-mime Thu May 6 09:50:25 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00190 for ietf-xml-mime-bks; Thu, 6 May 1999 09:50:25 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00186 for ; Thu, 6 May 1999 09:50:23 -0700 (PDT) Received: from simon (slip129-37-221-177.ny.us.ibm.net [129.37.221.177]) by hesketh.net (8.8.8/8.8.8) with SMTP id MAA21526 for ; Thu, 6 May 1999 12:52:36 -0400 Message-Id: <199905061652.MAA21526@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 May 1999 12:54:40 -0400 To: From: "Simon St.Laurent" Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905061112.AA00400@archlute.apsdc.ksp.fujixerox.co.jp> References: <000d01be8a12$f9b53780$aa66010d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 08:12 PM 5/6/99 +0900, MURATA Makoto wrote: >It appears that nobody think parameters are good enough reasons for >introducing a top-level media type "xml". Thus, the only possible reason is: > >> 4. Document-like XML documents can be handled by general-purpose >> XML viewers > >I do not think this is a good reason either. XML browsers only have to >examine the stylesheet PI and then invoke appropriate formatting engines. > >Thus, I believe that there is no reason to introduce a top-level media type "xml". >Have we reached a consensus here? No, we definitely haven't. While I didn't support the case you made earlier for parameters, I still think a top-level media type of 'xml' would be extremely useful. (I probably should have said this sooner, but hadn't read closely enough to realize that parameters were the last 'good' reason for a top-level xml type in the discussion.) A key part of my concern over the use of MIME types is that MIME types are used for more than just deciding how to process information once it has been received. Applications can also use MIME types to negotiate the content types they will accep using mechanisms like the HTTP Accept header. It is not at all difficult for me to imagine scenarios where content negotiation will be important as more and more formats evolve, all riding along (presently) on application/xml. For instance, the recent XSL Formatting Object discussions have brought up a key issue - because FOs are just XML documents, information providers now have another option for shipping readable but otherwise useless text to their customers, saving the semantic XML for those willing to pay a fee. In this case, being able to tell the difference between xml/xfo and xml/x-pfml (where x-pfml is the paid for markup language) is extremely significant. Servers may have to make decisions about what form to send a document in based on received types. Right now, we just have a weak set of tools for guessing what a client is capable of based on its ID string. MIME types haven't been powerful enough (or well-enough used) to handle this work. We have an opportunity here to give MIME types real work in improving server-client relations and improve the efficiency of XML transfers. application/xml (or text/xml) doesn't say anything about the 'real' expectations of the receiving application. As a result, we may see a lot of wasted or terminated transactions as 'junk' arrives to client software that isn't capable of processing what the server sent. Another, more philosophical, point that I'd like to make is that XML isn't _just_ a stream of characters. Unlike regular text documents, or even most binary formats, XML documents contain internal structure that can be used for processing and storage. You _can_ store XML documents as plain old text files in plain old file systems - but you can also store your XML documents in a data store that uses the internal structure of the document to keep it hierarchically. XML may be text, but it is certainly text+. Having meaningful MIME types to describe that information would be much more useful than finagling namespaces and reading into multiple portions of a document to figure out what exactly it contains. If all this goes over like a lead balloon, I'll step out of the way and let you move on to consensus. Simon St.Laurent XML: A Primer Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 10:00:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00295 for ietf-xml-mime-bks; Thu, 6 May 1999 10:00:07 -0700 (PDT) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA00289 for ; Thu, 6 May 1999 10:00:04 -0700 (PDT) To: "'Larry Masinter'" , ietf-xml-mime@imc.org Subject: Scope of Accept-Charset (WAS: RE: Parameters for top-level XML me dia types?) Date: Thu, 6 May 1999 19:02:06 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: "Langer, Paul" Message-Id: <005355AD0596D211B4F30000F81B0D3214B15A@daemsg01.software-ag.de> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: at Thursday, May 06, 1999 5:35 PM Larry Masinter wrote: > [snip] > The scope of "Accept-Charset" is unclear > (whether it applies to more than text/plain and text/html), > [snip] Why do you think that "Accept-Charset" may apply only to text/plain and text/html? All the best, Paul ----------------------------------------------------------- Paul Langer PL@softwareag.com Software AG Tel. +49-6151-92-1912 Uhlandstr. 12 Fax +49-6151-92-1613 D-64297 Darmstadt From owner-ietf-xml-mime Thu May 6 10:49:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00922 for ietf-xml-mime-bks; Thu, 6 May 1999 10:49:12 -0700 (PDT) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA00918 for ; Thu, 6 May 1999 10:49:11 -0700 (PDT) To: "'Simon St.Laurent'" , ietf-xml-mime@imc.org Subject: RE: Parameters for top-level XML media types? Date: Thu, 6 May 1999 19:51:14 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: "Langer, Paul" Message-Id: <005355AD0596D211B4F30000F81B0D3214B15B@daemsg01.software-ag.de> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: at Thursday, May 06, 1999 6:55 PM Simon St.Laurent wrote: > [snip] > You _can_ store XML documents as plain old > text files in plain old file systems - but you can also store your XML > documents in a data store that uses the internal structure of the document > to keep it hierarchically. > [snip] > Having meaningful MIME types to describe that information would be much > more useful than finagling namespaces and reading into multiple portions > of a document to figure out what exactly it contains. > [snip] We are currently developing "a data store that uses the internal structure of the document to keep it hierarchically". I see no chance for media types to be of any help for determining the structure of XML documents. Do you think of one media type for each and every DTD (or whatever schema we use tomorrow)? XML promises to be self-describing data; if it is not possible to get all necessary information out of the XML document itself, something is broken in XML. All the best, Paul ----------------------------------------------------------- Paul Langer PL@softwareag.com Software AG Tel. +49-6151-92-1912 Uhlandstr. 12 Fax +49-6151-92-1613 D-64297 Darmstadt From owner-ietf-xml-mime Thu May 6 11:07:43 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01082 for ietf-xml-mime-bks; Thu, 6 May 1999 11:07:43 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01078 for ; Thu, 6 May 1999 11:07:42 -0700 (PDT) Received: from simon (slip129-37-221-178.ny.us.ibm.net [129.37.221.178]) by hesketh.net (8.8.8/8.8.8) with SMTP id OAA24434 for ; Thu, 6 May 1999 14:09:57 -0400 Message-Id: <199905061809.OAA24434@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 May 1999 14:11:24 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: RE: Parameters for top-level XML media types? In-Reply-To: <005355AD0596D211B4F30000F81B0D3214B15B@daemsg01.software-a g.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 07:51 PM 5/6/99 +0200, Langer, Paul wrote: >We are currently developing "a data store that uses the internal structure >of >the document to keep it hierarchically". >I see no chance for media types to be of any help for determining the >structure of XML documents. Do you think of one media type for each and >every DTD (or whatever schema we use tomorrow)? >XML promises to be self-describing data; if it is not possible to get all >necessary information out of the XML document itself, something is >broken in XML. I'm not arguing that all of the information about the structure of the documents should be provided in the MIME type - one media type per DTD makes even less sense in a world where DTDs are not required. Nonetheless, for many well-defined XML document types, it seems worthwhile. Indeed, XML's promise of 'self-describing data' is important. Unfortunately, we also need useful shorthand descriptions of that data so that we don't waste lots of time transmitting information only to find that it wasn't really what we wanted. I shouldn't have to download an entire text/xml or application/xml document only to find out that the contents are in a form that my application isn't interested in. Self-describing information doesn't reduce the value of a shorthand description that conveys useful meaning. This doesn't mean that XML is broken - it just means that shorthand descriptions are very useful. You may not find MIME types to be of any use within your hierarchical structure, but I think it's easy enough to say that they would be useful for providing shorthand descriptions of what you've got and whether or not they should be stored in your system, not to mention whether the user wanted them in the first place. Simon St.Laurent XML: A Primer Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 12:19:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01711 for ietf-xml-mime-bks; Thu, 6 May 1999 12:19:45 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01707 for ; Thu, 6 May 1999 12:19:44 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53212(4)>; Thu, 6 May 1999 12:21:47 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <103653>; Thu, 6 May 1999 12:21:38 PDT From: "Larry Masinter" To: "Langer, Paul" , Subject: RE: Scope of Accept-Charset (WAS: RE: Parameters for top-level XML media types?) Date: Thu, 6 May 1999 12:21:32 PDT Message-ID: <001001be97f5$a6286740$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <005355AD0596D211B4F30000F81B0D3214B15A@daemsg01.software-ag.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > at Thursday, May 06, 1999 5:35 PM Larry Masinter wrote: > > > [snip] > > The scope of "Accept-Charset" is unclear > > (whether it applies to more than text/plain and text/html), > > [snip] > > Why do you think that "Accept-Charset" may apply only to > text/plain and text/html? Because that's all it is used for in practice. A browser that sends "accept-charset: utf-8" may be able to deal with text/plain and text/html documents in utf-8, but it is unlikely to know whether or not the RTF handler inside application/word is also capable of dealing with utf-8. One of the problems with "accept-charset" (that wouldn't be there if we used RFC 2533 feature sets) is that there's no way to link it to particular media types. Larry From owner-ietf-xml-mime Thu May 6 12:30:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01855 for ietf-xml-mime-bks; Thu, 6 May 1999 12:30:15 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01851 for ; Thu, 6 May 1999 12:30:14 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53226(1)>; Thu, 6 May 1999 12:32:20 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <103658>; Thu, 6 May 1999 12:31:47 PDT From: "Larry Masinter" To: "Simon St.Laurent" , Subject: RE: Parameters for top-level XML media types? Date: Thu, 6 May 1999 12:31:44 PDT Message-ID: <001101be97f7$13304780$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199905061809.OAA24434@hesketh.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I shouldn't have to download an entire > text/xml or application/xml document only to find out that the contents are > in a form that my application isn't interested in. Before we invest a lot of effort into solving this problem, could you please give a couple of _realistic_ examples where a) this is really a problem and b) MIME type labelling would actually help? It sounds nice in principal, but for the most part, the examples given are very weak. For the most part, the examples I've seen are based on some hypothetical world in which there are thousands of different documents and document types in different repositories, and people are browsing indiscriminately among the ones that fit their application. I've not yet seen a real example. The closest I've seen is the calendaring example, where someone gets lots of calendar messages along with other messages in their email box, and the application is trying to sort out which things are calendar requests from just ordinary email by filtering on the MIME type. But I'm suspicious of this application; for a long list of reasons, it seems like the wrong use of the MIME type to determine the intent of the message. Larry From owner-ietf-xml-mime Thu May 6 12:46:19 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA02024 for ietf-xml-mime-bks; Thu, 6 May 1999 12:46:19 -0700 (PDT) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA02020 for ; Thu, 6 May 1999 12:46:17 -0700 (PDT) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id OAA17847; Thu, 6 May 1999 14:47:51 -0500 (CDT) Received: from clv-oh43-18.ix.netcom.com(207.220.174.146) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma017761; Thu May 6 14:47:31 1999 Message-ID: <006f01be97f9$4d06e160$92aedccf@ix.netcom.com> From: "Frank Boumphrey" To: , "Simon St.Laurent" References: <000d01be8a12$f9b53780$aa66010d@copper.parc.xerox.com> <199905061652.MAA21526@hesketh.net> Subject: Re: Parameters for top-level XML media types? Date: Thu, 6 May 1999 15:47:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I would like to second what Simon says. One other point is that there is no requirement for an XML document to have an XML declaration, so without an XML mime the document will probably get sent to the wrong engine Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (Aug) ----- Original Message ----- From: Simon St.Laurent To: Sent: Thursday, May 06, 1999 12:54 PM Subject: Re: Parameters for top-level XML media types? > At 08:12 PM 5/6/99 +0900, MURATA Makoto wrote: > >It appears that nobody think parameters are good enough reasons for > >introducing a top-level media type "xml". Thus, the only possible reason is: > > > >> 4. Document-like XML documents can be handled by general-purpose > >> XML viewers > > > >I do not think this is a good reason either. XML browsers only have to > >examine the stylesheet PI and then invoke appropriate formatting engines. > > > >Thus, I believe that there is no reason to introduce a top-level media > type "xml". > >Have we reached a consensus here? > > No, we definitely haven't. While I didn't support the case you made > earlier for parameters, I still think a top-level media type of 'xml' would > be extremely useful. (I probably should have said this sooner, but hadn't > read closely enough to realize that parameters were the last 'good' reason > for a top-level xml type in the discussion.) > > A key part of my concern over the use of MIME types is that MIME types are > used for more than just deciding how to process information once it has > been received. Applications can also use MIME types to negotiate the > content types they will accep using mechanisms like the HTTP Accept header. > It is not at all difficult for me to imagine scenarios where content > negotiation will be important as more and more formats evolve, all riding > along (presently) on application/xml. > > For instance, the recent XSL Formatting Object discussions have brought up > a key issue - because FOs are just XML documents, information providers now > have another option for shipping readable but otherwise useless text to > their customers, saving the semantic XML for those willing to pay a fee. > In this case, being able to tell the difference between xml/xfo and > xml/x-pfml (where x-pfml is the paid for markup language) is extremely > significant. Servers may have to make decisions about what form to send a > document in based on received types. > > Right now, we just have a weak set of tools for guessing what a client is > capable of based on its ID string. MIME types haven't been powerful enough > (or well-enough used) to handle this work. We have an opportunity here to > give MIME types real work in improving server-client relations and improve > the efficiency of XML transfers. > > application/xml (or text/xml) doesn't say anything about the 'real' > expectations of the receiving application. As a result, we may see a lot > of wasted or terminated transactions as 'junk' arrives to client software > that isn't capable of processing what the server sent. > > Another, more philosophical, point that I'd like to make is that XML isn't > _just_ a stream of characters. Unlike regular text documents, or even most > binary formats, XML documents contain internal structure that can be used > for processing and storage. You _can_ store XML documents as plain old > text files in plain old file systems - but you can also store your XML > documents in a data store that uses the internal structure of the document > to keep it hierarchically. > > XML may be text, but it is certainly text+. Having meaningful MIME types > to describe that information would be much more useful than finagling > namespaces and reading into multiple portions of a document to figure out > what exactly it contains. > > If all this goes over like a lead balloon, I'll step out of the way and let > you move on to consensus. > > Simon St.Laurent > XML: A Primer > Sharing Bandwidth / Cookies > http://www.simonstl.com > From owner-ietf-xml-mime Thu May 6 15:28:31 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03496 for ietf-xml-mime-bks; Thu, 6 May 1999 15:28:31 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03492 for ; Thu, 6 May 1999 15:28:30 -0700 (PDT) Received: from simon (slip129-37-221-101.ny.us.ibm.net [129.37.221.101]) by hesketh.net (8.8.8/8.8.8) with SMTP id SAA01419 for ; Thu, 6 May 1999 18:30:47 -0400 Message-Id: <199905062230.SAA01419@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 May 1999 18:33:56 -0400 To: From: "Simon St.Laurent" Subject: RE: Parameters for top-level XML media types? In-Reply-To: <001101be97f7$13304780$aa66010d@copper.parc.xerox.com> References: <199905061809.OAA24434@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:31 PM 5/6/99 -0700, Larry Masinter wrote: >Before we invest a lot of effort into solving this problem, could you >please give a couple of _realistic_ examples where > a) this is really a problem and > b) MIME type labelling would actually help? Sure. Whenever I hear someone ask for '_realistic_ examples' I expect they're planning to dislike whatever I present on philosophical grounds, but I'll give it a shot. >It sounds nice in principal, but for the most part, the examples given >are very weak. For the most part, the examples I've seen are based on >some hypothetical world in which there are thousands of different documents >and document types in different repositories, and people are browsing >indiscriminately among the ones that fit their application. The principle is extremely simple. File types should be labeled as precisely as possible. XML documents have a double identity - they can be processed by generic XML processors and stored in generic repositories - and they also have specific content that may require a particular processor. At present, MIME types can identify the first identity (using text/xml or application/xml) OR the section (typically using application/x-whatever), but not both. As for 'some hypothetical world', I don't think we're really that far away from the very scenario you describe. People and software browsing indiscriminately is here today, as are thousands of different documents in different repositories. We don't _yet_ have thousands of different document types, but as XML makes plenty of provision for this, it might be wise to be prepared. >I've not yet seen a real example. The closest I've seen is the calendaring >example, where someone gets lots of calendar messages along with other >messages in their email box, and the application is trying to sort out >which things are calendar requests from just ordinary email by filtering >on the MIME type. But I'm suspicious of this application; for a long >list of reasons, it seems like the wrong use of the MIME type to determine >the intent of the message. Lacking any strong theoretical feelings about the 'proper' use of MIME types, I'd happily make the claim that if it works, great, and if we can make it work better, even better. Now for some 'real world' examples, though they'll have to be somewhat vague given the current lack of 'real world' XML currently in circulation. XMLNews (www.xmlnews.org) provides an XML vocabulary for marking up news stories. At present, I can't find them serving any 'live' XMLNews information, so I'll make this up out of the usual conjecture and guesswork. Suppose I subscribe to a news feed that uses XMLNews format, say one focused on XML. (Maybe Robin Cover's site in XML form.) The feed comes in through my email, and hopefully I've finally built a mail program that I like better than Eudora Pro. Because subject headers are such crummy things to sort on, I feed the XMLNews information into a repository that works well with XML. There are a few ways I could set this up: 1) Filter based on sender (okay for simple case) 2) Filter based on MIME-type: all text/xml goes through another processor and into the repository. If I'm smart, a post-processor figures out which XML is which so I don't end up collecting business cards. 3) Filter based on MIME-type: all application/x-xmlnews is separated, inspected to make sure it's 'really' XML and not a mere name collision and then sent into the repository. 4) Filter based on MIME-type: all xml/x-xmlnews is separated, put in the repository. Number 4 seems to me the most trustworthy and requires the least post-processing. Seems like a good combination to me. Similarly, suppose I have a search engine that scours the Web seeking out XMLNews information and indexing it. ('News beyond the Wire' or something.) If XMLNews is identified as text/xml or application/xml, the signal-to-noise ratio is going to be extremely high. I'll be loading lots of documents and throwing them in the discard pile. If it's application/x-xmlnews, the signal-to-noise ratio will be much lower. On the other hand, if I build a search engine that simply indexes XML documents, it's going to have to load all kinds of application/x-* to figure out what's in XML and what isn't - a problem given the likely proliferation of application/x-* that XML makes possible. If it's xml/x-xmlnews, then both my XMLNews-specific search engine and my generic XML search engine are happy - both know that they can index the material, and the odds of wasted transfers decline. (Admittedly, because non-XML formats are likely to grow much more slowly, we could train the generic search engine to ignore bad matches. On the other hand, it seems a lot easier to get the matches right the first time.) Similar issues arise for other specific and generic processors. Browsers can display (either as a tree or with style sheets) any XML that's text/xml or application/xml. If they get an unknown MIME type, however, they're going to have to bug the user to figure out what to do with it. Again, they could check everything they get to find out if it's XML, but why not get it right the first time? Creating a first-level xml space tells generic XML processors that they can do _something_ to the material contained in the file. Then the second level can provide a more specific description useful for processors that don't want to waste their time with the wrong XML information. We have an opportunity here to strengthen the use of MIME types by making them more meaningful. MIME types are an amazingly underutilized and frequently misunderstood resource for identifying information types. Unfortunately, if we continue down the path of text/xml, application/xml, and application/x-*, we're not providing applications with enough information to use MIME types meaningfully and reliably. Simon St.Laurent XML: A Primer Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 18:11:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04869 for ietf-xml-mime-bks; Thu, 6 May 1999 18:11:49 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04865 for ; Thu, 6 May 1999 18:11:47 -0700 (PDT) Received: by mx.fujixerox.co.jp; id KAA07591; Fri, 7 May 1999 10:14:03 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma007370; Fri, 7 May 99 10:13:45 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id KAA28006 for ; Fri, 7 May 1999 10:11:44 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id KAA15262 for ; Fri, 7 May 1999 10:13:44 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id KAA29019 for ; Fri, 7 May 1999 10:11:38 +0900 Message-Id: <199905070113.AA00401@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 10:13:58 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <000501be97d5$fc629560$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > > Makoto wrote: > > > If the charset parameter is not present, we cannot use negotiation > > of HTTP 1.1, which is already available. > > This is not true. The scope of "Accept-Charset" is unclear > (whether it applies to more than text/plain and text/html), > but it does not depend on there being a "charset" parameter > on the results. Oops, you are definetely right. I should have mentioned code conversion by proxy servers. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu May 6 18:18:43 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04964 for ietf-xml-mime-bks; Thu, 6 May 1999 18:18:43 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04960 for ; Thu, 6 May 1999 18:18:41 -0700 (PDT) Received: by mx.fujixerox.co.jp; id KAA10248; Fri, 7 May 1999 10:20:57 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma009999; Fri, 7 May 99 10:20:33 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id KAA00820 for ; Fri, 7 May 1999 10:18:32 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id KAA15635 for ; Fri, 7 May 1999 10:20:32 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id KAA29160 for ; Fri, 7 May 1999 10:18:26 +0900 Message-Id: <199905070120.AA00402@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 10:20:46 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905061652.MAA21526@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent wrote: > > No, we definitely haven't. While I didn't support the case you made > earlier for parameters, I still think a top-level media type of 'xml' would > be extremely useful. Remember that another option is available. I think that you are advocating the use of specialized media types but not arguing for the top-level media type "xml". > > Solution 1. Specialized media types (possibly with some parameters) > Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu May 6 18:46:23 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05194 for ietf-xml-mime-bks; Thu, 6 May 1999 18:46:23 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05190 for ; Thu, 6 May 1999 18:46:21 -0700 (PDT) Message-Id: <4.2.0.37.19990506184041.023df590@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Thu, 06 May 1999 18:48:24 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: RE: Parameters for top-level XML media types? In-Reply-To: <199905062230.SAA01419@hesketh.net> References: <001101be97f7$13304780$aa66010d@copper.parc.xerox.com> <199905061809.OAA24434@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent makes the same argument in a few places, but I'll select the one near the end of his message. >Creating a first-level xml space tells generic XML processors that they can >do _something_ to the material contained in the file. Then the second level >can provide a more specific description useful for processors that don't >want to waste their time with the wrong XML information. There are other ways of doing this without an XML top-level type. The process in your MUA or other viewer that dispatches a document of a particular type/subtype pair can be told to launch an XML viewer even if neither the type or the subtype says "xml". In the case of "text/x-xmlnews", if you don't have an "xmlnews" viewer, you can still tell the MIME dispatcher to dispatch "text/x-xmlnews" to the XML parser. Having a top-level "xml" type allows you to default all subtypes for which there is not a known specialized viewer to the generic XML viewer, just like the top-level "text" type can default to the text viewer. It has generally been found in the text case not to be very useful for most unrecognized text subtypes. In order for us to want to create an "xml" main type, we'd have to be very sure that dispatching to a generic XML viewer is useful, and is more useful than writing the object out to disk. Going back to Larry's challenge for real-world examples, I'd like to see a bunch of examples where launching the generic XML viewer is really useful. What value would I get out of that for many XML types? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Thu May 6 19:03:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA06660 for ietf-xml-mime-bks; Thu, 6 May 1999 19:03:45 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA06651 for ; Thu, 6 May 1999 19:03:44 -0700 (PDT) Received: by mx.fujixerox.co.jp; id LAA25838; Fri, 7 May 1999 11:06:00 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma025732; Fri, 7 May 99 11:05:29 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id LAA15264 for ; Fri, 7 May 1999 11:03:28 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id LAA17447 for ; Fri, 7 May 1999 11:05:29 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id LAA29818 for ; Fri, 7 May 1999 11:03:22 +0900 Message-Id: <199905070205.AA00406@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 11:05:43 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905062230.SAA01419@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent wrote: > XML documents have a double identity - they can be > processed by generic XML processors and stored in generic repositories - > and they also have specific content that may require a particular > processor. We have agreed that generic XML processors cannot do anything useful. In my mail "What we have agreed on" , I wrote: > > 3. Fallback to general-purpose XML applications is not useful. > snip > If these are agreed on, we can eliminate some options and concentrate on > the rest. > > If you disagree with these four points, please speak up now. > > Cheers, > > Makoto > > ---------------------------------------------------------- snip > 3. Fallback to general-purpose XML applications is not useful. > > "What's the XML parser going to do with this block of data? Display it? Not > terribly valuable. Get some namespace information from the inside and then > dispatch based on the namespace? Possibly valuable, but this begs the > question of why wasn't that information out in the MIME headers." (Paul) > > "what experience has shown is that fallback > strategies of *any* sort tend to be overrated. In almost every case something > has messed it up. Either we got the granularity wrong (and I see a very good > chance of this happening here given the emergence of alternative forms of XML), > or it didn't prove to offer useful functionality, or it simply didn't deploy in > the manner in which we envisioned. About the only success story we have, > actually, are the image/audio/video top-level types, and while these have > worked out tolerably well, their actual value to end users isn't that great." (Ned) > > "Not even possible, in some cases. XML is being used for all sorts of > things from serialising Java Beans to Web server configuration files to > interprocess communication - a lot of these uses are not especially > "displayable". In some cases, the fact that they are written in XML is > the least important thing about them. These are likely to need > specialised registrations, too. Further, if the specification for any > such case is not controlled by a single vendor, then registration in the > vendor tree does not seem appropriate. This would be the case for > situations ranging from a small vendor group (such as the Flashpix > group) through groups such as W3C to bodies such as ISO, ITU, IEE and so > on." (Chris) > Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu May 6 19:28:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11403 for ietf-xml-mime-bks; Thu, 6 May 1999 19:28:55 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11396 for ; Thu, 6 May 1999 19:28:54 -0700 (PDT) Received: from simon (slip129-37-221-253.ny.us.ibm.net [129.37.221.253]) by hesketh.net (8.8.8/8.8.8) with SMTP id WAA08055 for ; Thu, 6 May 1999 22:31:11 -0400 Message-Id: <199905070231.WAA08055@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 May 1999 22:34:30 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: RE: Parameters for top-level XML media types? In-Reply-To: <4.2.0.37.19990506184041.023df590@mail.imc.org> References: <199905062230.SAA01419@hesketh.net> <001101be97f7$13304780$aa66010d@copper.parc.xerox.com> <199905061809.OAA24434@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 06:48 PM 5/6/99 -0700, Paul Hoffman / IMC wrote: >There are other ways of doing this without an XML top-level type. The >process in your MUA or other viewer that dispatches a document of a >particular type/subtype pair can be told to launch an XML viewer even if >neither the type or the subtype says "xml". In the case of >"text/x-xmlnews", if you don't have an "xmlnews" viewer, you can still tell >the MIME dispatcher to dispatch "text/x-xmlnews" to the XML parser. Are these ways as efficient? As intuitive? As generally useful across multiple cases? I don't think so. It's extra work that accomplishes very little. Using the xml top level type would accomplish all this and accomodate multiple types of systems at the same time. >Having a top-level "xml" type allows you to default all subtypes for which >there is not a known specialized viewer to the generic XML viewer, just >like the top-level "text" type can default to the text viewer. It has >generally been found in the text case not to be very useful for most >unrecognized text subtypes. In order for us to want to create an "xml" main >type, we'd have to be very sure that dispatching to a generic XML viewer is >useful, and is more useful than writing the object out to disk. I think maybe we should go back to a very simple question: what are MIME types for? I thought at one point that they were to describe file types. If that is indeed the case, it might be a good idea to describe file types as accurately and completely as possible. I'll wait for the official response on "generic XML applications" are useful before throwing out any more 'realistic' examples, or arguing this particular point any further. If I'm not allowed to suggest that generic XML applications are useful, there isn't much point to this case at all, and we may as well stick with a broken and underutilized system. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 19:26:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10830 for ietf-xml-mime-bks; Thu, 6 May 1999 19:26:14 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10821 for ; Thu, 6 May 1999 19:26:12 -0700 (PDT) Received: from simon (slip129-37-221-253.ny.us.ibm.net [129.37.221.253]) by hesketh.net (8.8.8/8.8.8) with SMTP id WAA07977 for ; Thu, 6 May 1999 22:28:31 -0400 Message-Id: <199905070228.WAA07977@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 May 1999 22:29:33 -0400 To: From: "Simon St.Laurent" Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905070205.AA00406@archlute.apsdc.ksp.fujixerox.co.jp> References: <199905062230.SAA01419@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:05 AM 5/7/99 +0900, MURATA Makoto wrote: >We have agreed that generic XML processors cannot do anything useful. > >In my mail "What we have agreed on" , I wrote: >> >> 3. Fallback to general-purpose XML applications is not useful. >> >snip > >> If these are agreed on, we can eliminate some options and concentrate on >> the rest. >> >> If you disagree with these four points, please speak up now. Fine, then. If you'd like to end the argument with "you should have spoken up earlier", you're welcome to continue. Unfortunately, 'Generic XML processors cannot do anything useful' is not true. Generic XML search engines are indeed a possibiliy. Generic XML browsers already exist. Generic XML editors are arriving as well. If they aren't useful, that's really quite unfortunate. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 20:14:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA17468 for ietf-xml-mime-bks; Thu, 6 May 1999 20:14:10 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA17459 for ; Thu, 6 May 1999 20:14:08 -0700 (PDT) Received: by mx.fujixerox.co.jp; id MAA19325; Fri, 7 May 1999 12:16:23 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma019237; Fri, 7 May 99 12:15:49 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id MAA05902 for ; Fri, 7 May 1999 12:13:48 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id MAA20139 for ; Fri, 7 May 1999 12:15:48 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id MAA01024 for ; Fri, 7 May 1999 12:13:41 +0900 Message-Id: <199905070316.AA00407@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 12:16:02 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905070228.WAA07977@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent wrote: > Generic XML search engines are indeed a possibiliy. Generic XML browsers > already exist. Generic XML editors are arriving as well. If they aren't > useful, that's really quite unfortunate. Are you talking about generic XML as documents as opposed to generic XML as data? I do not think generic XML editors are useful for XML data for RPC. We have agreed on another thing. You are arguing top-level media type for document-like XML documents. Right? MURATA Makoto wrote: > > 4. Document-like XML documents can be handled by general-purpose > XML viewers Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Thu May 6 21:41:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA27085 for ietf-xml-mime-bks; Thu, 6 May 1999 21:41:35 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA27077 for ; Thu, 6 May 1999 21:41:33 -0700 (PDT) Received: from simon (slip129-37-221-174.ny.us.ibm.net [129.37.221.174]) by hesketh.net (8.8.8/8.8.8) with SMTP id AAA11251 for ; Fri, 7 May 1999 00:43:53 -0400 Message-Id: <199905070443.AAA11251@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 May 1999 00:47:12 -0400 To: From: "Simon St.Laurent" Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905070316.AA00407@archlute.apsdc.ksp.fujixerox.co.jp> References: <199905070228.WAA07977@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:16 PM 5/7/99 +0900, MURATA Makoto wrote: >Simon St.Laurent wrote: >> Generic XML search engines are indeed a possibiliy. Generic XML browsers >> already exist. Generic XML editors are arriving as well. If they aren't >> useful, that's really quite unfortunate. > >Are you talking about generic XML as documents as opposed to >generic XML as data? I do not think generic XML editors are useful for >XML data for RPC. It depends on what kind of approach you take. If you use a single vocabulary for RPC (like XML-RPC, or something built on IBM's BeanML) you're generally correct. If you take a much more general approach (something like JXML's MDSAX package for program composition from XML documents) then many of the same possibilities for processing generic XML data open up that already existed for documents. I'd be willing to discuss the more general approach in much greater detail if it seems appropriate. For a _very_ rough picture, you can see the later slides in the presentation I've posted at: http://www.simonstl.com/articles/nycod/index.htm >We have agreed on another thing. You are arguing top-level media type for >document-like XML documents. Right? > >MURATA Makoto wrote: >> >> 4. Document-like XML documents can be handled by general-purpose >> XML viewers I'm arguing top-level media type for document-like XML documents and also for XML documents in general. There is no separation between XML for documents and XML for data - both are possible, both can be mixed, both approaches can indeed appear within a single 'document'. Describing the two as different things is useful in some contexts but not always accurate. I remain willing to support your 'agreement' number 4 but opposed to #3. After searching the archives, I find that I joined the list 4/13, while the agreements were posted on 4/11. Makes life difficult, I suppose. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Thu May 6 22:49:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA00896 for ietf-xml-mime-bks; Thu, 6 May 1999 22:49:34 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA00892 for ; Thu, 6 May 1999 22:49:32 -0700 (PDT) Received: by mx.fujixerox.co.jp; id OAA08466; Fri, 7 May 1999 14:51:49 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma008362; Fri, 7 May 99 14:51:14 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id OAA21614 for ; Fri, 7 May 1999 14:49:13 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id OAA26959 for ; Fri, 7 May 1999 14:51:13 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id OAA03511 for ; Fri, 7 May 1999 14:49:06 +0900 Message-Id: <199905070551.AA00412@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 14:51:27 +0900 To: Subject: Re: Parameters for top-level XML media types? In-Reply-To: <199905070443.AAA11251@hesketh.net> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Simon St.Laurent wrote: > > I'll wait for the official response on "generic XML applications" are > useful before throwing out any more 'realistic' examples, or arguing this > particular point any further. There *is* an agreement that generic XML processors cannot do anything useful. I would like to make sure that we go forward (not backward). I also would like to make sure that people's time and effort are well spent. Thus, I do not want to reopen this issue. However, there should be a procedure for reopening previous agreements. If a *new* argument is raised and many people agree to reopen this issue, I think we should reopen it. You might want to read the ENTIRE archive of this ML, write a proposal to reopen this issue, and ask people whether they support your proposal or not. I apologize if I sound like a chair (I am merely a co-author of RFC2376). I am just suggesting the above procedure to participants of this mailing list, hoping that it facilitates discussion and progress. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Fri May 7 00:12:48 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04655 for ietf-xml-mime-bks; Fri, 7 May 1999 00:12:48 -0700 (PDT) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA04651 for ; Fri, 7 May 1999 00:12:45 -0700 (PDT) To: "'Simon St.Laurent'" , ietf-xml-mime@imc.org Subject: Top-level media type xml desirable? (WAS: RE: Parameters for top -level XML media types?) Date: Fri, 7 May 1999 09:14:48 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: "Langer, Paul" Message-Id: <005355AD0596D211B4F30000F81B0D3214B15C@daemsg01.software-ag.de> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: at Friday, May 07, 1999 4:35 AM Simon St.Laurent wrote: > [snip] > I think maybe we should go back to a very simple question: > what are MIME types for? > I thought at one point that they were to describe file types. > If that is indeed the case, it might be a good idea to describe file types as > accurately and completely as possible. > [snip] Agreed. But I think "describe file types as accurately and completely as possible" should refer ONLY to the format of the content of the "file", NOT to possible usages of that content. We will destroy the portability of XML, if media types like xml/my-application are allowed; as soon as something can be labeled as e.g. xml/hugo the owner of application hugo will feel free to add hugo-specific features to XML. I still think that a top-level media type "xml" with application-specific subtypes is an attempt to solve the open schema issues at a wrong place. All the best, Paul ----------------------------------------------------------- Paul Langer PL@softwareag.com Software AG Tel. +49-6151-92-1912 Uhlandstr. 12 Fax +49-6151-92-1613 D-64297 Darmstadt From owner-ietf-xml-mime Fri May 7 00:37:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA05296 for ietf-xml-mime-bks; Fri, 7 May 1999 00:37:46 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05292 for ; Fri, 7 May 1999 00:37:41 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id PAA05020 for ; Fri, 7 May 1999 15:39:49 +0800 (CST) Message-ID: <003701be985b$603cdd40$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: References: <199905070551.AA00412@archlute.apsdc.ksp.fujixerox.co.jp> Subject: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?) Date: Fri, 7 May 1999 15:29:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: From: MURATA Makoto > There *is* an agreement that generic XML processors cannot do anything useful. > I would like to make sure that we go forward (not backward). I also would > like to make sure that people's time and effort are well spent. Thus, I do > not want to reopen this issue. I think Murata-san means "(fallback to) generic processors (on application-specific documents) cannot do anything useful", rather than that text/xml and application/xml are useless, which is what Simon seems to think he means. I thought participants have agreed that * there are generic XML documents which contain enough information in them to be useful (e.g. with a stylesheet), and that these can use text/xml or application/xml; * there are application-specific XML documents which need their own MIME type: e.g., application/*; * fallback from application-specific XML to generic XML and from generic XML to text has not been proved to be particularly useful, except for debugging; * MIME parameters are not particularly useful at the current state of technology (they may be useful for negotiation during requests, but the current and new generation of browsers don't use them for dispatching received documents); * people are seem open to change there minds if there are convincing cases shown and if technology changes. Finally, I cannot see why people are scared of having a million new XML MIME types under application/* or audio/*; or the other places. Perhaps what is needed is an XML MIME registration tree, rather than a new type. Perhaps it could even be an automated system: you send the desired MIME content-type and a minimal RFC to describe it (e.g., the DTD), and the system allocates and confirms MIME content-type, under the XML registration tree. That would be better than x- (no name collisions) and easier than getting a content-type registered under the IETF registration tree (because using XML answers some of the mandated questions about encodings, and because the types would be allocated on demand; a subsequent administrative review would disallow bogus requests). I don't think that new XML-based media types whould require the same scrutiny or comment as text/xml and application/xml; they are just subclasses of them. IETF has a good role to play for text/xml and application/xml comments, for the XML class of documents. But having established that text/xml and application/xml are OK, I think creators of XML document types shouldn't have to duplicate the effort involved in getting an IETF MIME type registered (that effort is small and efficient, but as Murata-san has found out, is not nothing). This would give, for example, application/xml.ddml , which is useable by existing browsers, and allows a program to fall back to generic XML (if it knows that all application/xml.* documents are also application/xml). (Refer http://www.freenic.net/rfcs/rfc2000/rfc2048.txt) Rick Jelliffe From owner-ietf-xml-mime Fri May 7 00:56:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA05418 for ietf-xml-mime-bks; Fri, 7 May 1999 00:56:05 -0700 (PDT) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05414 for ; Fri, 7 May 1999 00:56:04 -0700 (PDT) Received: by mx.fujixerox.co.jp; id QAA19603; Fri, 7 May 1999 16:58:21 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (V3.1) id xma019442; Fri, 7 May 99 16:58:04 +0900 Received: from kspgwy.ksp.fujixerox.co.jp (kspmailer [129.249.213.100]) by ns1.fujixerox.co.jp (8.9.3/3.7W99040814) with ESMTP id QAA28110 for ; Fri, 7 May 1999 16:56:03 +0900 (JST) Received: from sun386i.apsdc.ksp.fujixerox.co.jp (sun386i.apsdc.ksp.fujixerox.co.jp [129.249.240.113]) by kspgwy.ksp.fujixerox.co.jp (8.9.1a/3.6W) with SMTP id QAA01846 for ; Fri, 7 May 1999 16:58:03 +0900 (JST) Received: from archlute.apsdc.ksp.fujixerox.co.jp (archlute.apsdc.ksp.fujixerox.co.jp [129.249.240.52]) by sun386i.apsdc.ksp.fujixerox.co.jp (8.6.9+2.4W/3.4Wbeta3) with SMTP id QAA05371 for ; Fri, 7 May 1999 16:55:57 +0900 Message-Id: <199905070758.AA00418@archlute.apsdc.ksp.fujixerox.co.jp> From: MURATA Makoto Date: Fri, 07 May 1999 16:58:18 +0900 To: Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?) In-Reply-To: <003701be985b$603cdd40$dd066d8c@sinica.edu.tw> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.01 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Rick Jelliffe wrote: > > I thought participants have agreed that Thank you for nice summary and clarifying my intention. I appreciate it. Rick Jelliffe wrote: > Perhaps what is needed is an XML MIME registration tree, rather than a new > type. This is a new and interesting idea. I look forward to comments from MIME experts on this mailing list. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp From owner-ietf-xml-mime Fri May 7 03:11:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA08223 for ietf-xml-mime-bks; Fri, 7 May 1999 03:11:47 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA08219 for ; Fri, 7 May 1999 03:11:42 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id SAA18324; Fri, 7 May 1999 18:13:48 +0800 (CST) Message-ID: <005701be9870$e3d68b00$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: "MURATA Makoto" , References: <199905070758.AA00418@archlute.apsdc.ksp.fujixerox.co.jp> Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?) Date: Fri, 7 May 1999 18:03:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: To make matters more concrete, here is a draft RFC. Actually, I have found it a little hard to work out from the RFCs whether the "xml." goes on the content type (left) or the subtype (right). I am assuming that it goes on the right. If registration trees go on the left, then my fallback suggestion is that the XML RFC also allow subtyping of application/xml under some registration authority. This accomplishes exactly the same thing, with the same syntax. Rick ----- Network Working Group Rick Jelliffe Request for Comments: nnnn Academia Sinica Computing Centre Obsoletes: May 1999 Category: Internet Best Current Practices MIME Registration Tree for XML Status of this Memo This draft provides information on a MIME registration tree for XML. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract RFC 2048 [1] provides for the registration of Additional Registration Tree (s2.1.5). This RFC specifies procedures and scope for a registration tree for XML [3] documents to augment RFC nnn [4] The proposed mechanism is an automated registration system for XML-based MIME media types under an "xml." registration tree. Table of Contents ... 1. Introduction XML [] is a subset of SGML [] optimized for distributing certain kinds of documents over the WWW. RFC nnn [] gives the MIME Media Types which can be used for generic, browsable XML documents: text/xml and application/xml. A generic, browsable XML document contains enough markup inside it for a generic XML browser to use that document: in particular this means stylesheet information. However, XML will also be used to create large numbers of application-specific document types. Documents of these types are XML, but they require specific MIME media types. Because of the large numbers of these document types, it is feared that they either will swamp the IETF registration process or, more likely, that their creators will simply not follow Best Internet Practise and create media types for these types, willy nilly. Furthermore, because RFC nnn [] exists, the registration of an application-specific document type under the IETF tree will not provide much, if any, additional information. It is onerous to the registrees, time-wasting for IANA, and uninformative for readers. 2. Registration Tree The registration tree has the prefix "xml". For example, the MIME media type for the "Question and Answer Markup Language", QAML, would be text/xml.qaml and application/xml.qaml. All document types registered under the XML tree have both text/xml.* adn application/xml.* media types. Any parameters defined in RFCs for generic XML MIME media types [] also may be used. If the document type describes some kind of literature, for example from a word processor, the recommended content type is text/xml.* Otherwise the media type should be application/xml.* In accordence with RFC 2046[] (s1), image/xml.* and the other top-level content types should not be used. 2. Automated Registration The XML registration tree is an automated process. People or organizations seeking to register an application-specific XML document under this tree submit, using an online form, a subset of the information required by IANA for IETF-tree registration [1]: including - registree name and contact details, - the requested MIME content-type identifier, - URL of the DTD or schema giving the document's structures and purpose, - URI of the document's namespace, - URL for user documentation of that document type. The automated process checks if the media type has been registered. If it is available, the media type is registered, and the requester notified by email. If it is already allocated, the requester is instead notified of the contact address of the person of organization who has already registered that content-type; the requestor can then negotiate directly with them. 3. Management XML is a trademark of the World Wide Web Consortium (W3C). Management of the XML registration tree is to be performed by a person or organization (the "registrar") to be agreed by IETF and W3C. The registrar will make available lists of registered types in the XML registration tree over Internet and to IANA, W3C and ISO SC34. There is no provision for handling different versions of application-specific document types at the MIME level. Versions must be signified inside the XML document, signified by markup or by fixed attributes in the DTD; applications should be designed to handle version variants gracefully. 4. Security Considerations This RFC raises no security issues beyond those given in [], as far as document types registered under the "xml." tree. For security of the automation process, automatic registrations should be periodically checked at the discretion of the registrar. Bogus registrations should be removed, and the registree notified. A bogus registration includes the registration of a MIME type for document type which does not exist, or which has not been adequately described by a DTD or other schema, or which has been registered by some body for the purposes of hijacking an established or new technology. 5. References [1] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures" RFC 2048, November 1996 [1] Freed, N., Borenstein, N. "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types" RFC 2046, November 1996 [2] Bray, et al "XML 1.0 Specification",... [3] Whitehead, J., and Mutata, M., "MIME Media Types for XML", RFC nnn, xxx, October 1998. [4] IS 8879:1986 (ammended 1998) "Information Technology -- Standard Generalized Markup Language", ISO SC34 6. Author's Address Rick Jelliffe Computing Centre, Academia Sinica P.O. Box 1-8, Nankang Taipei 11529, Taiwan, ROC Phone: +8862-2-2789-9380 Fax: +8862-2-2783-6444 EMail: ricko@gate.sinica.edu.tw From owner-ietf-xml-mime Fri May 7 07:19:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10594 for ietf-xml-mime-bks; Fri, 7 May 1999 07:19:15 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10590 for ; Fri, 7 May 1999 07:19:13 -0700 (PDT) Received: from simon (slip129-37-221-44.ny.us.ibm.net [129.37.221.44]) by hesketh.net (8.8.8/8.8.8) with SMTP id KAA03495 for ; Fri, 7 May 1999 10:21:35 -0400 Message-Id: <199905071421.KAA03495@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 May 1999 10:24:53 -0400 To: From: "Simon St.Laurent" Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?) In-Reply-To: <005701be9870$e3d68b00$dd066d8c@sinica.edu.tw> References: <199905070758.AA00418@archlute.apsdc.ksp.fujixerox.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 06:03 PM 5/7/99 +0800, Rick Jelliffe wrote: >To make matters more concrete, here is a draft RFC. Rick's concrete proposal appears to satisfy all my concerns and then some. I have no objection to multilayered MIME types - I've always wondered why MIME was built with only two layers of description, though I suppose it made sense at the time. His proposal seems to have all the benefits of an XML layer without the disruption of xml/x-*. At 02:51 PM 5/7/99 +0900, MURATA Makoto wrote: >However, there should be a procedure for reopening previous agreements. >If a *new* argument is raised and many people agree to reopen this >issue, I think we should reopen it. You might want to read the >ENTIRE archive of this ML, write a proposal to reopen this issue, and ask >people whether they support your proposal or not. Sounds good. We'll see how Rick's proposal goes over. If I suspect the discussion is headed down the path to ruin, I'll take my previous arguments and supplement them with new material in a more formal presentation and request that these issues be reconsidered. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Fri May 7 07:28:08 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10698 for ietf-xml-mime-bks; Fri, 7 May 1999 07:28:08 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10694 for ; Fri, 7 May 1999 07:28:07 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52076(2)>; Fri, 7 May 1999 07:30:22 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <99666>; Fri, 7 May 1999 07:30:08 PDT From: "Larry Masinter" To: "Langer, Paul" , "'Simon St.Laurent'" , Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) Date: Fri, 7 May 1999 07:30:04 PDT Message-ID: <001701be9896$18dff780$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <005355AD0596D211B4F30000F81B0D3214B15C@daemsg01.software-ag.de> Importance: Normal Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > [snip] > > I think maybe we should go back to a very simple question: > > what are MIME types for? > > I thought at one point that they were to describe file types. > > If that is indeed the case, it might be a good idea to describe file types > as > > accurately and completely as possible. > > [snip] > > Agreed. But I think "describe file types as accurately and completely as > possible" should refer ONLY to the format of the content of the "file", > NOT to possible usages of that content. Disagree. "as accurately and completely as possible" is not a goal. "Provide the minimum information necessary for a recipient to be able to decide on an appropriate processor for an incoming message". Web browsing was close enough to mail reading to use the same typing mechanism. Different applications may require more specific information to decide on how to process other kinds of data, but that information should not be added to, or required to be supplied as part of, the MIME type. From owner-ietf-xml-mime Fri May 7 08:14:04 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11150 for ietf-xml-mime-bks; Fri, 7 May 1999 08:14:04 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11146 for ; Fri, 7 May 1999 08:14:02 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id KAA21151; Fri, 7 May 1999 10:16:11 -0500 Message-ID: <373303CA.99F08687@themacs.com> Date: Fri, 07 May 1999 10:16:26 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: "Langer, Paul" , "'Simon St.Laurent'" , ietf-xml-mime@imc.org Subject: Re: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) References: <001701be9896$18dff780$15d0000d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > > > > [snip] > > > I think maybe we should go back to a very simple question: > > > what are MIME types for? > > > I thought at one point that they were to describe file types. > > > If that is indeed the case, it might be a good idea to describe file types > > as > > > accurately and completely as possible. > > > [snip] > > > > Agreed. But I think "describe file types as accurately and completely as > > possible" should refer ONLY to the format of the content of the "file", > > NOT to possible usages of that content. > > Disagree. "as accurately and completely as possible" is not a goal. > "Provide the minimum information necessary for a recipient to be able > to decide on an appropriate processor for an incoming message". Web > browsing was close enough to mail reading to use the same typing mechanism. > > Different applications may require more specific information to > decide on how to process other kinds of data, but that information > should not be added to, or required to be supplied as part of, the > MIME type. I agree with this. Within an agent, once the basic container has been determined, the agent will examine the contents further to figure out how to process the content. Part of this is parsing the XML data stream. While an agent might have a single XML parser, it might not. And it doesn't matter. Agents need to know a lot more than we could or should put in a mime type in order to faithfully reflect the intent of the content author. The HTML Working Group and the IETF Conneg groups are both working on ways to reveal this additional information. Let's provide them with the basic tools to let them do their jobs. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Fri May 7 08:45:11 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11436 for ietf-xml-mime-bks; Fri, 7 May 1999 08:45:11 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11432 for ; Fri, 7 May 1999 08:45:10 -0700 (PDT) Received: from simon (slip129-37-21-15.ga.us.ibm.net [129.37.21.15]) by hesketh.net (8.8.8/8.8.8) with SMTP id LAA06627 for ; Fri, 7 May 1999 11:47:29 -0400 Message-Id: <199905071547.LAA06627@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 May 1999 11:50:06 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-Reply-To: <373303CA.99F08687@themacs.com> References: <001701be9896$18dff780$15d0000d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: >> "Provide the minimum information necessary for a recipient to be able >> to decide on an appropriate processor for an incoming message" Why does this bar the door to an XML top-level type? What is so scary about this that you aren't interested in doing the job as well as possible rather than just saying "we've provided you with the least possible amount of information so that you still have to guess what this pile of junk is"? If you're going to describe something, describing it halfway seems like a waste of time. If this is really the approach that MIME is required to take, it may well be time to move on to something more robust. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Fri May 7 08:48:25 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11464 for ietf-xml-mime-bks; Fri, 7 May 1999 08:48:25 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11460 for ; Fri, 7 May 1999 08:48:24 -0700 (PDT) Received: from simon (slip129-37-21-15.ga.us.ibm.net [129.37.21.15]) by hesketh.net (8.8.8/8.8.8) with SMTP id LAA06752 for ; Fri, 7 May 1999 11:50:46 -0400 Message-Id: <199905071550.LAA06752@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 May 1999 11:54:03 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-Reply-To: <373303CA.99F08687@themacs.com> References: <001701be9896$18dff780$15d0000d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:16 AM 5/7/99 -0500, Shane P. McCarron wrote: Within an agent, once the basic container has been >determined, the agent will examine the contents further to figure out >how to process the content. Part of this is parsing the XML data >stream. While an agent might have a single XML parser, it might not. >And it doesn't matter. Agents need to know a lot more than we could or >should put in a mime type in order to faithfully reflect the intent of >the content author. But why is it such a problem to provide the agent with as much information as possible? If the agent knows that the basic content type is XML, it knows that it's safe to poke at it with an XML processor. If the agent knows what kind of XML it's looking at, it can pick and choose which files it wants on that basis if that behavior is appropriate. At least we'd be giving the agent as much information as possible within the constraints of MIME rather than punting and requiring it to search through _everything_ to find what it wants. I don't see this as a case where 'less is more'. I still like Rick's proposal. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Fri May 7 11:25:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15008 for ietf-xml-mime-bks; Fri, 7 May 1999 11:25:51 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA15004 for ; Fri, 7 May 1999 11:25:50 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <54757(1)>; Fri, 7 May 1999 11:28:01 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <99926>; Fri, 7 May 1999 11:27:45 PDT From: "Larry Masinter" To: "Simon St.Laurent" , Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) Date: Fri, 7 May 1999 11:27:44 PDT Message-ID: <000201be98b7$4cd7c9c0$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199905071547.LAA06627@hesketh.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Larry Masinter wrote: > >> "Provide the minimum information necessary for a recipient to be able > >> to decide on an appropriate processor for an incoming message" > > Why does this bar the door to an XML top-level type? What is so scary > about this that you aren't interested in doing the job as well as possible > rather than just saying "we've provided you with the least possible amount > of information so that you still have to guess what this pile of junk is"? Different applications will need different categorizations of information, and attempts to put too many application-specific parameters into the MIME type will result in granularities of descriptions that may support some applications and interfere with others. > If you're going to describe something, describing it halfway seems like a > waste of time. "... In that Empire, the craft of Cartography attained such Perfection that the Map of a Single province covered the space of an entire City, and the Map of the Empire itself an entire Province. In the course of Time, these Extensive maps were found somehow wanting, and so the College of Cartographers evolved a Map of the Empire that was of the same Scale as the Empire and that coincided with it point for point." ---- From Travels of Praiseworthy Men (1658) by J.A. Suarez Miranda in Jorge Luis Borges' 'Of Exactitude in Science' A Universal History of Infamy (1972) From owner-ietf-xml-mime Fri May 7 11:42:57 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16123 for ietf-xml-mime-bks; Fri, 7 May 1999 11:42:57 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16118 for ; Fri, 7 May 1999 11:42:55 -0700 (PDT) Received: from simon (slip129-37-221-183.ny.us.ibm.net [129.37.221.183]) by hesketh.net (8.8.8/8.8.8) with SMTP id OAA12631 for ; Fri, 7 May 1999 14:45:18 -0400 Message-Id: <199905071845.OAA12631@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 May 1999 14:48:37 -0400 To: From: "Simon St.Laurent" Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-Reply-To: <000201be98b7$4cd7c9c0$aa66010d@copper.parc.xerox.com> References: <199905071547.LAA06627@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:27 AM 5/7/99 -0700, Larry Masinter wrote: >Different applications will need different categorizations of information, >and attempts to put too many application-specific parameters into the >MIME type will result in granularities of descriptions that may support >some applications and interfere with others. I'd appreciate an explanation of why a top-level xml type would interfere with applications. Perhaps some were built with no fallback capabilities for unknown types at all - is that your concern? Or is it that applications might not recognize that application/x-myml and xml/x-myxml could be the same thing? It isn't clear to me whether your opposition is to the creation of new top-level media types period, or just to xml/. >"... In that Empire, the craft of Cartography attained such Perfection that the >Map of a Single province covered the space of an entire City, and the Map of the >Empire itself an entire Province. In the course of Time, these Extensive maps >were found somehow wanting, and so the College of Cartographers evolved a Map of >the Empire that was of the same Scale as the Empire and that coincided with it >point for point." "When it was proclaimed that the Library contained all books, the first impression was one of extravagant happiness. All men felt themselves to be the masters of an intact and secret treasure. There was no personal or world problem whose eloquent solution did not exist in some hexagon... but the searchers did not remember that the possibility of a man's finding his Vindication, or some treacherous variation thereof, can be computed as zero."[1] Cataloging and description is important. Borges was a librarian - I suspect he'd agree. [1] - From "The Library of Babel", in _Labyrinths_. (James E. Irby, translator.) Originally from _Ficciones_, 1956. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Fri May 7 12:13:24 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18214 for ietf-xml-mime-bks; Fri, 7 May 1999 12:13:24 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18209 for ; Fri, 7 May 1999 12:13:23 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id OAA22873 for ; Fri, 7 May 1999 14:15:43 -0500 Message-ID: <37333BEE.56D885A2@themacs.com> Date: Fri, 07 May 1999 14:15:58 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Application-specific media types Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: [In this message I am trying a new tactic here to speed up deliberations. -spm] I have previously advocated the use of application specific media types for certain classes of applications. To restate my bias for the record: I believe that HTML is a special class of application now and into the foreseeable future, and as such needs to be handled specially by user agents. Now, how does that fit into the world in which there is an xml/ class of media? Well, it can readily. I don't personally care whether there is a class of xml/*, text/xml.*, or any other variation you might think of. I don't think that is worth debating that this point. Rather, I think that the issue is whether specific applications can control their own namespace within the media type set, or whether they need to work within a single family of media types that is centrally regulated. Instead of having that philosophical discussion, maybe we could short this to ground. Some members of the HTML Working Group would like to define a new media type text/xhtml rather than relying upon text/xml or text/html. The basic reasons for this are: Ease of identifying content by user agents. Special semantics of markup that cannot be expressed in any schema. Historical precedent. Management and evolution of the media type namespace by the responsible body. Within the media type text/xhtml, I expect that the W3C will define additional parameters that can help user agents interpret the contents of the resource more readily from the envelope. However, as with text/html, that is the W3C's problem to deal with. Also, with regard to text/html, and before anyone asks - the reason we cannot use that easily is because there is too much baggage associated with it, and too many broken documents out there. We need a new, distinct media type to make a clean break with the past. XHTML(tm) is a new XML application that is similar to HTML, but that is extensible, and whose documents are guaranteed to be well formed and valid. User agents can operate much more sensible in the presence of such documents than they can in the presence of the mess that is HTML today. The reason I am here talking with you all is that the W3C has determined that, as this is a bigger problem than the general XHTML case, we should all work together to develop a generic solution. I have no problem with that in theory, but I also don't have years to wait for us to define the perfect philosophical answer. So, my question for you all is, would anyone here object to the creation of an application specific media type text/xhtml, registered by the W3C, that would be used to announce resources that are within the XHTML family (as that is defined by the W3C)? And, assuming there are objections, what are they specifically? Maybe if we work from this concrete case we will make more rapid progress toward consensus. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Fri May 7 12:24:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18803 for ietf-xml-mime-bks; Fri, 7 May 1999 12:24:38 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18798 for ; Fri, 7 May 1999 12:24:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19449; Fri, 7 May 1999 12:26:56 -0700 (PDT) Received: from mehitabel.eng.sun.com (mehitabel.Eng.Sun.COM [129.146.82.247]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id MAA00721; Fri, 7 May 1999 12:26:47 -0700 (PDT) Received: from mehitabel by mehitabel.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10958; Fri, 7 May 1999 12:26:10 -0700 Message-Id: <199905071926.MAA10958@mehitabel.eng.sun.com> Date: Fri, 7 May 1999 12:26:10 -0700 (PDT) From: Murray Altheim Reply-To: Murray Altheim Subject: Re: Application-specific media types To: ietf-xml-mime@imc.org, shane@themacs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: snfel3+W/zQCkBD2bujylQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Shane P. McCarron writes: > > [In this message I am trying a new tactic here to speed up > deliberations. -spm] [...] > Instead of having that philosophical discussion, maybe we could short > this to ground. Some members of the HTML Working Group would like to > define a new media type text/xhtml rather than relying upon text/xml or > text/html. The basic reasons for this are: [...] For the record, there are also members of the HTML WG who have expressed a strong protest to creation of a new media type text/xhtml. Sun Microsystems has repeatedly been among these members, with the reasons previously explained in detail within the WG archives. > So, my question for you all is, would anyone here object to the creation > of an application specific media type text/xhtml, registered by the W3C, > that would be used to announce resources that are within the XHTML > family (as that is defined by the W3C)? I unfortunately today cannot spend much time on this reply as I must soon leave the office. The biggest problem I see is that while XHTML may be a special class of application, there needs to be some means of content or 'feature' negotiation that provides specific information about the document type. If this solution is successful, there will be no need for a new media type, and such a single-use solution will keep XHTML off in its own landscape rather than integrated into a more general XML solution. Perhaps that is what some vendors want, especially those that benefit from HTML continuing within its proprietary universe. I think it a big mistake. If the HTML WG is successful in defining 'document type profiles', there will be little need for a new media type. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 An SGML declaration does not an i18n make. From owner-ietf-xml-mime Fri May 7 12:27:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18961 for ietf-xml-mime-bks; Fri, 7 May 1999 12:27:05 -0700 (PDT) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18956 for ; Fri, 7 May 1999 12:27:04 -0700 (PDT) Received: from agranat.com (alice.agranat.com [192.104.71.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id PAA21086 for ; Fri, 7 May 1999 15:26:23 -0400 Received: from oyster (oyster.agranat.com [192.104.71.149]) by agranat.com (8.8.5/8.8.5) with SMTP id PAA19379 for ; Fri, 7 May 1999 15:26:22 -0400 From: "Scott Lawrence" To: Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) Date: Fri, 7 May 1999 15:24:12 -0400 Message-ID: <000301be98bf$3031d420$954768c0@oyster.agranat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <005355AD0596D211B4F30000F81B0D3214B15C@daemsg01.software-ag.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: Langer, Paul > We will destroy the portability of XML, if media types like > xml/my-application are allowed; as soon as something can be labeled as > e.g. xml/hugo the owner of application hugo will feel free to add > hugo-specific features to XML. I find this statement a bit puzzling; the X in XML is from 'eXtensible'. The _goal_ of XML is to be the 'mother tongue' from which new application-specific languages evolve. I think that this is really at the heart of the question of whether or not xml/ is an appropriate media type, and think that it is not a particularly useful one. The interesting and useful attribute of an XML-derived language is not that it is derived from XML; it's in whatever application domain it serves. The MIME registration of any application type that employs XML as its expression/definition mechanism will say so - I don't see any particular value in making that a part of the hierarchy of its name. ASN.1 is used for a great many different things (too many :-), but we don't expect them all to interoperate or even to be interested in interoperating. -- Scott Lawrence Director of R & D Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/ From owner-ietf-xml-mime Sat May 8 00:31:38 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA26413 for ietf-xml-mime-bks; Sat, 8 May 1999 00:31:38 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA26409 for ; Sat, 8 May 1999 00:31:37 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <55674(4)>; Sat, 8 May 1999 00:33:54 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <101524>; Sat, 8 May 1999 00:33:48 PDT From: "Larry Masinter" To: , Subject: RE: Application-specific media types Date: Sat, 8 May 1999 00:33:46 PDT Message-ID: <000001be9925$1b6b2940$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <37333BEE.56D885A2@themacs.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Within the media type text/xhtml, I expect that the W3C will define > additional parameters that can help user agents interpret the contents > of the resource more readily from the envelope. However, as with > text/html, that is the W3C's problem to deal with. The optional and required parameters need to be specified when the media type is registered. Wouldn't application/xhtml be more appropriate? I know we've had text/html in the past, but that was in a fit of fantasy that someone could actually _read_ HTML as if it were text. Larry From owner-ietf-xml-mime Sat May 8 01:10:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26563 for ietf-xml-mime-bks; Sat, 8 May 1999 01:10:44 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA26559 for ; Sat, 8 May 1999 01:10:43 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <55737(3)>; Sat, 8 May 1999 01:13:00 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <101536>; Sat, 8 May 1999 01:12:50 PDT From: "Larry Masinter" To: "Simon St.Laurent" , Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) Date: Sat, 8 May 1999 01:12:43 PDT Message-ID: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <199905071845.OAA12631@hesketh.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > It isn't clear to me whether your opposition is to the creation of new > top-level media types period, or just to xml/. I'm opposed to creating more top-level media types than are necessary, or to adding more parameters and other doodads than are necessary, where I define 'necessary' as 'having a compelling application TODAY'. So far, I've seen some good arguments for text/xml, application/xml, a few calendaring applications and (possibly, if the issues about subsets and compositions are elaborated), text/xhtml. But I don't see any reason for creating new media types otherwise, until they're needed. For the most part, applications can use text/xml, application/xml, or even application/octet-stream, since the MIME type is irrelevant. I don't believe that "xml" fits into the guidelines for new top level types, which seem to rest, not on the argument about "default processing" but rather "device/gateway filtering". At least notionally, the distinction was between text/ image/ audio/ video/ and (now) model/, with "application/" being the catch-all for everything else. I think "xml" is, for the most part, "application/". Larry From owner-ietf-xml-mime Sat May 8 01:56:43 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26727 for ietf-xml-mime-bks; Sat, 8 May 1999 01:56:43 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26723 for ; Sat, 8 May 1999 01:56:41 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id PAA25666; Sat, 8 May 1999 15:29:19 +0800 (CST) Date: Sat, 8 May 1999 15:29:18 +0800 (CST) From: Rick Jelliffe To: ietf-xml-mime@imc.org Subject: Re: Application-specific media types In-Reply-To: <37333BEE.56D885A2@themacs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 7 May 1999, Shane P. McCarron wrote: > So, my question for you all is, would anyone here object to the creation > of an application specific media type text/xhtml, registered by the W3C, > that would be used to announce resources that are within the XHTML > family (as that is defined by the W3C)? Well, without arguing on merits or needs, like I said, I think the form needs to be manageble: so application/xml.html (using an XML registration tree or an xml subtyping mechanism) would a much preferable form. We should create a media-type name framework in which it is easy for any existing format to have an XML version (e.g. application/xml.vrml), and for any ordinary user to be able to read the media type and figure out what is going on. The trouble with application/xhtml is that is disguises what is going on: users may think it means experimental HTML, or they may miss that it is HTML att all. When a browser does not have a handler registered for a media type, it asks the users. This gives moderately sophisiticated users the chance to try some other application: they need to be able to look at the media type name and make some sense of it. So application/xml.html is better than application/xhtml, and application/xml.vrml is better than application/vrxml or application/xvrml (and I think model/xml.vrml is better than both those). This is why I think and "xml." prefix (which would probably require an XML registration tree) and some simple automated registration process (so that people can have instant access to a name) is the most workable solution: it seems to fit into MIME specs, works with existing technology, and provides a nice convention for conveying its meaning to humans. (People can still register XML media types under IETF, experimetal or vendor trees, so a registration tree just adds convenience.) Rick Jelliffe From owner-ietf-xml-mime Sat May 8 08:47:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00674 for ietf-xml-mime-bks; Sat, 8 May 1999 08:47:49 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA00670 for ; Sat, 8 May 1999 08:47:48 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52348(5)>; Sat, 8 May 1999 08:50:05 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <97676>; Sat, 8 May 1999 08:49:59 PDT From: "Larry Masinter" To: "Rick Jelliffe" , Subject: RE: Application-specific media types Date: Sat, 8 May 1999 08:49:52 PDT Message-ID: <000101be996a$69872440$15d0000d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > This is why I think and "xml." prefix (which would probably require an > XML registration tree) and some simple automated registration process (so > that people can have instant access to a name) is the most workable > solution: it seems to fit into MIME specs, works with existing > technology, and provides a nice convention for conveying its meaning to > humans. (People can still register XML media types under IETF, > experimetal or vendor trees, so a registration tree just adds convenience.) I could support this, but I think that the process should encourage the same kinds of considerations for XML types as it does for media types in the "vnd" tree. It's very easy for programmers and developers to forget about the simple security considerations for receiving content that might cause the recipient to make permanent and damaging changes to the recipient's environment. "This media type will only be generated by my own application" is the typical thoughtless reaction. But this is the stuff that viruses are made out of. The problems exist with some extensions to existing media types, too (for example, several trojan attacks were launched using javascript extensions to html), but at least having the considerations apply at type definition might encourage _some_ thought. In the privacy of your own application, you can do whatever you want. It's only when you intend to send some data to another recipient using a different or separate application that you need a MIME type at all, and that's the time when the MIME type considerations (security considerations, being explicit about optional & required parameters) need to be asked. Larry -- http://www.parc.xerox.com/masinter From owner-ietf-xml-mime Sat May 8 09:56:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01906 for ietf-xml-mime-bks; Sat, 8 May 1999 09:56:46 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA01894; Sat, 8 May 1999 09:54:57 -0700 (PDT) Message-Id: <4.2.0.37.19990508093511.02908240@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Sat, 08 May 1999 09:57:02 -0700 To: "Larry Masinter" , "Simon St.Laurent" , From: Paul Hoffman / IMC Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-Reply-To: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> References: <199905071845.OAA12631@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 01:12 AM 5/8/99 -0700, Larry Masinter wrote: >I'm opposed to creating more top-level media types than are necessary, >or to adding more parameters and other doodads than are necessary, >where I define 'necessary' as 'having a compelling application TODAY'. I agree with Larry here. >I don't believe that "xml" fits into the guidelines for new >top level types, which seem to rest, not on the argument about >"default processing" but rather "device/gateway filtering". >At least notionally, the distinction was between text/ image/ >audio/ video/ and (now) model/, with "application/" being the >catch-all for everything else. I think "xml" is, for the >most part, "application/". It sure seems to be. It is an application that can be processed by multiple processors. Let me turn around the "desirable?" question. In many ways, I think it would be better for the XML world to *not* have a top-level "xml" type. Take a look at the situation today, which will probably be the same a year and five years from now: 1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That agent knows how to dispatch based on MIME information. It knows how to dispatch to programs. These dipatched-to programs might display the content directly, or might make a decision and launch a different display program. 2) You have a generic XML-display program (XMLShow) and some programs for displaying particular XML types (DisplayEDI, DisplayCal, and so on). 3) Someone invents a new XML type (XMLFoo) and a special display program (DisplayFoo). At the point that step (3) happens and you receive a message with that content type, you want your agent in (1) to do The Right Thing, which is to launch DisplayFoo or, if you don't have a copy of DisplayFoo, to launch XLMShow. If all XML items come in with MIME types of "xml/foo", then someone needs to tweak the settings in your client to know about DisplayFoo. If all your XML items come in with the type "application/xml", then someone needs to tweak the settings in the dispatched-to program to know about DisplayFoo. I believe that "tweak the dispatched-to program" is a much better environment than "tweak all the MIME-receiving clients" for many reasons: - If you have more than one MIME-receiving client, the user tweaks fewer settings. - There is no need to register every sub-type: XMLShow can decide to launch based on the content of the XML, such as from the DTD or XML namespaces used. This speeds up adoption of new XML types. - If "application/xml" automatically launches XMLShow, it is XMLShow that can be told about the "smarter" applications like DisplayFoo, and it might be able to cooperate with them in many ways. For instance, DisplayFoo might be able to ask XMLShow to render parts of a document while DisplayFoo renders other parts. - XMLShow will be able to open a file off of disk (with no MIME information) and still be able to hand off the file to DisplayFoo. The MIME-receiving clients can never do this. - Given today's MIME-receiving clients, it is more likely that XMLShow will be more flexible about adding new DisplayFoo viewers than the MIME-receiving clients are. In summary, I believe that specialized XML viewers are better off in an environment where they are launched by the thing that "application/XML" launches, not by their own MIME sub-types. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Sat May 8 11:14:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02202 for ietf-xml-mime-bks; Sat, 8 May 1999 11:14:35 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02198 for ; Sat, 8 May 1999 11:14:34 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM> for ietf-xml-mime@imc.org; Sat, 8 May 1999 11:15:53 PDT Date: Sat, 08 May 1999 10:21:04 -0700 (PDT) From: Ned Freed Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-reply-to: "Your message dated Sat, 08 May 1999 01:12:43 -0700 (PDT)" <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> To: Larry Masinter Cc: "Simon St.Laurent" , ietf-xml-mime@imc.org Message-id: <01JAYB4U6D528WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <199905071845.OAA12631@hesketh.net> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > It isn't clear to me whether your opposition is to the creation of new > > top-level media types period, or just to xml/. > I'm opposed to creating more top-level media types than are necessary, > or to adding more parameters and other doodads than are necessary, > where I define 'necessary' as 'having a compelling application TODAY'. > So far, I've seen some good arguments for text/xml, application/xml, > a few calendaring applications and (possibly, if the issues about > subsets and compositions are elaborated), text/xhtml. If registration activity is any indication, there are a lot more XML-derived things out there that need their own media types than this. However, I agree that not everything does, so our disagreement, such as it is, seems to be more a matter of degree than anything else. > But I don't see any reason for creating new media types otherwise, > until they're needed. For the most part, applications can use > text/xml, application/xml, or even application/octet-stream, since > the MIME type is irrelevant. Um, well, actually, in many cases the MIME type is very relevant and is used to get the data delivered to the right place. While it may be nice to imagine a world where there's a separate XML-level dispatch process, such a process doesn't exist in any product I'm aware of and I don't see any moves underway to add it. > I don't believe that "xml" fits into the guidelines for new > top level types, which seem to rest, not on the argument about > "default processing" but rather "device/gateway filtering". I've been thinking about this a lot of late, and I'm afraid that while I was largely neutral about a new top-level type before, I have to agree with Larry on this point. In particular, XML seems to me to cut across existing top-level media types -- an XML object can be a document or some other form of application data, a model, an image, a means of storing audio data, or even some sort of message or multipart object. Mind you, I'm not saying that XML objects will eventually end up being registered under every existing top-level type -- registration under multipart is certainly unlikely at a minimum -- but registration under several top level types seems certain. > At least notionally, the distinction was between text/ image/ > audio/ video/ and (now) model/, with "application/" being the > catch-all for everything else. I think "xml" is, for the > most part, "application/". For the most part, perhaps, but not always. I see a bright future for XML under model at a minimum, and likely under image and audio as well. As for XML appearing as a distinguished registration tree "xml.", the current purpose of differing registration trees is for when someone other than IANA wants to do the registration or when the rules for registration are significantly different from existing trees. But neither of these seem to apply here. W2C is the logical candidate for an alternate registration authority, but they don't seem interested in doing XML registration (according to previous messages on this list at least). And I see nothing about XML that calls for significantly different rules. And remember that the IETF isn't likely to register the XML types it defines in an "xml." tree. They'll prefer the unfaceted IETF tree. So the separate tree would almost certainly fail to capture all XML, making it useless for spotting all XML-based objects. Ned From owner-ietf-xml-mime Sat May 8 11:18:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02218 for ietf-xml-mime-bks; Sat, 8 May 1999 11:18:09 -0700 (PDT) Received: from locke.ccil.org (cowan@[192.190.237.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02214 for ; Sat, 8 May 1999 11:18:08 -0700 (PDT) Received: (from cowan@localhost) by locke.ccil.org (8.8.5/8.8.5) id OAA03883; Sat, 8 May 1999 14:29:48 -0400 (EDT) From: John Cowan Message-Id: <199905081829.OAA03883@locke.ccil.org> Subject: Re: Application-specific media types To: masinter@parc.xerox.com (Larry Masinter) Date: Sat, 8 May 1999 14:29:48 -0400 (EDT) Cc: shane@themacs.com, ietf-xml-mime@imc.org In-Reply-To: <000001be9925$1b6b2940$15d0000d@copper.parc.xerox.com> from "Larry Masinter" at May 8, 99 00:33:46 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter scripsit: > Wouldn't application/xhtml be more appropriate? I know we've had > text/html in the past, but that was in a fit of fantasy that > someone could actually _read_ HTML as if it were text. Well, I suppose it depends on the HTML; all of mine seems perfectly readable to me, as I handcraft it that way (not with any great effort; I simply use a plain text editor or else XED). -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. From owner-ietf-xml-mime Sun May 9 06:10:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA06975 for ietf-xml-mime-bks; Sun, 9 May 1999 06:10:10 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA06971 for ; Sun, 9 May 1999 06:10:09 -0700 (PDT) Received: from simon (slip129-37-221-141.ny.us.ibm.net [129.37.221.141]) by hesketh.net (8.8.8/8.8.8) with SMTP id JAA16147 for ; Sun, 9 May 1999 09:12:35 -0400 Message-Id: <199905091312.JAA16147@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 09 May 1999 09:16:08 -0400 To: From: "Simon St.Laurent" Subject: Negotiated Content Delivery: Maxmimizing Information In-Reply-To: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> References: <199905071845.OAA12631@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:57 AM 5/8/99 -0700, Paul Hoffman / IMC wrote: >1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That >agent knows how to dispatch based on MIME information. It knows how to >dispatch to programs. These dipatched-to programs might display the content >directly, or might make a decision and launch a different display program. >2) You have a generic XML-display program (XMLShow) and some programs for >displaying particular XML types (DisplayEDI, DisplayCal, and so on). >3) Someone invents a new XML type (XMLFoo) and a special display program >(DisplayFoo). Good examples - except that in all cases, you omit the negotiations phase where the two ends of the connection can decide whether transmission is really worthwhile. Once I've downloaded the file, sure, no problem, I can save it as a stream and the user can poke at it manually if they want, I can check to see if it's XML or a binary format, etc. However, I'd really rather not be downloading material I can't use. If I know beforehand - from MIME types exchanges in HTTP negotiations, for instance - that the information is in XML, I may be (depending on my application type) more willing to take the risk. If not, I'll be spending a lot of time downloading junk, finding that it doesn't work, and trying to avoiding getting that type of information the next time around. There are two fairly obvious cases where this is important. The first is the automated engine case - agents and search engines, for the most part. While both of these tools can be built such that they are limited to a particular set of MIME types, 'generic' (oops) engines and agents also make sense, in part because things like namespaces allow document authors to do things like embed information of one type inside of a document that is ostensibly of another type. XHTML, for example, seems like a likely container for XML islands of all kinds, and I suspect we'll see other such container formats arriving. Even formats that aren't 'containers' per se may have lots of such mixed content, and agents and search engines should at least be aware that these formats are searchable, and not compressed binaries or other non-XML information. The second case isn't automated, but it presents as many problems. User intervention in MIME types is always a pain in the neck, something most users aren't fond of. I'll give a new case that may be more relevant than the usual "my browser doesn't do Shockwave". Suppose 'HotSync' information for a PDA - say an address book - is stored in XML. Not everyone's software uses an identical XML format, since people are irritating that way and I haven't seen any move to standardize. I'd like to download an address book in the wrong format to my PDA, which has an option for importing from XML. (I have to do a little manual identification work, but that's all right.) Normally, though, my PDA doesn't like getting files it doesn't understand, a reasonable approach given its limited storage capacity. Am I going to have to go through the 'ok, download it, I know it's a weird MIME type' routine every time I want to download an address book in a different format? Multiply by several million users and support costs, and the need to identify XML documents as XML in some way becomes significant. At 10:21 AM 5/8/99 -0700, Ned Freed wrote: >Um, well, actually, in many cases the MIME type is very relevant and is used to >get the data delivered to the right place. While it may be nice to imagine a >world where there's a separate XML-level dispatch process, such a process >doesn't exist in any product I'm aware of and I don't see any moves underway to >add it. MDSAX (see http://www.jxml.com) does provide a document router that you can use to build such processes, but you'll definitely get exceptions if you feed it non-XML information. Working around that is not that difficult, but in the general case you're right - I see no movement in that direction yet. This would work fine in cases where you had to figure what application/xml meant after you got it, but doesn't do anything for the negotiated cases described above. At 01:12 AM 5/8/99 -0700, Larry Masinter wrote: >I don't believe that "xml" fits into the guidelines for new >top level types, which seem to rest, not on the argument about >"default processing" but rather "device/gateway filtering". >At least notionally, the distinction was between text/ image/ >audio/ video/ and (now) model/, with "application/" being the >catch-all for everything else. I think "xml" is, for the >most part, "application/". Maybe it's time for some new thinking, acknowledging that MIME types are generic type identifiers rather than clinging to their historical roots. Using 'xml' in the mix - top level identifier or somewhere else - is a change, but it's a change that enables a heck of a lot of tools, despite the constant dismissals. I realize that may be difficult to take, but I think users will thank us in the long run for dealing with this now rather than waiting for the traffic jam to develop. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Sun May 9 09:30:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07774 for ietf-xml-mime-bks; Sun, 9 May 1999 09:30:07 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07770 for ; Sun, 9 May 1999 09:30:06 -0700 (PDT) Message-Id: <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Sun, 09 May 1999 09:32:12 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-Reply-To: <199905091312.JAA16147@hesketh.net> References: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:16 AM 5/9/99 -0400, Simon St.Laurent wrote: >At 09:57 AM 5/8/99 -0700, Paul Hoffman / IMC wrote: > >1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That > >agent knows how to dispatch based on MIME information. It knows how to > >dispatch to programs. These dipatched-to programs might display the content > >directly, or might make a decision and launch a different display program. > >2) You have a generic XML-display program (XMLShow) and some programs for > >displaying particular XML types (DisplayEDI, DisplayCal, and so on). > >3) Someone invents a new XML type (XMLFoo) and a special display program > >(DisplayFoo). > >Good examples - except that in all cases, you omit the negotiations phase >where the two ends of the connection can decide whether transmission is >really worthwhile. Correct. Not all MIME-using mechanisms have content negotiation. Internet mail, for example. Content-negotiation can and should be dealt with using content-negotiation protocols. See for details. >However, I'd really rather not be downloading material I can't use. If I >know beforehand - from MIME types exchanges in HTTP negotiations, for >instance - that the information is in XML, I may be (depending on my >application type) more willing to take the risk. If not, I'll be spending >a lot of time downloading junk, finding that it doesn't work, and trying to >avoiding getting that type of information the next time around. Again, this can be handled by using content-negotiation. It would be pretty easy to add a conneg type that would describe the type of XML that you are passing, without breaking the example I gave for protocols that don't do negotiation. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Sun May 9 10:32:21 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08068 for ietf-xml-mime-bks; Sun, 9 May 1999 10:32:21 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08063; Sun, 9 May 1999 10:32:20 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM>; Sun, 9 May 1999 10:33:49 PDT Date: Sun, 09 May 1999 10:22:59 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Sun, 09 May 1999 09:32:12 -0700" <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> To: Paul Hoffman / IMC Cc: ietf-xml-mime@imc.org Message-id: <01JAZNY1KYCY8WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <199905091312.JAA16147@hesketh.net> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > However, I'd really rather not be downloading material I can't use. If I > > know beforehand - from MIME types exchanges in HTTP negotiations, for > > instance - that the information is in XML, I may be (depending on my > > application type) more willing to take the risk. If not, I'll be spending > > a lot of time downloading junk, finding that it doesn't work, and trying to > > avoiding getting that type of information the next time around. > Again, this can be handled by using content-negotiation. It would be pretty > easy to add a conneg type that would describe the type of XML that you are > passing, without breaking the example I gave for protocols that don't do > negotiation. There is also an intermediate case -- IMAP. In IMAP header information for a MIME message can be downloaded and examined prior to downloading the actual message content. But this is restricted to the labelling in header fields -- media type, media type parameters, and disposition information, in other words. There are also instances in HTTP where the MIME type for an external object is already known, but going through a content negotiation step means making an external connection -- a far more costly operation. And there's also the issue of needing to extend existing negotiation mechanisms to accomodate new labelling information. This may be a no-brainer from a protocol design standpoint, but unfortunately it is anything but when you consider the restrictions that exist in deployed software. The long and short of it is that I don't see either extreme position on this issue as tenable. The notion of "all XML goes under the application/xml media type and a different mechanism is used to distinguish different instances of XML usage" is a nonstarter, and so is "every little twiddle to something done in XML gets a new media type". I also don't think that XML is even close to mature enough for us to attempt to establish definitive rules for when a media type is needed and when it isn't. Ned From owner-ietf-xml-mime Sun May 9 10:45:32 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08116 for ietf-xml-mime-bks; Sun, 9 May 1999 10:45:32 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08111; Sun, 9 May 1999 10:45:31 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM>; Sun, 9 May 1999 10:46:59 PDT Date: Sun, 09 May 1999 10:34:56 -0700 (PDT) From: Ned Freed Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-reply-to: "Your message dated Sat, 08 May 1999 09:57:02 -0700" <4.2.0.37.19990508093511.02908240@mail.imc.org> To: Paul Hoffman / IMC Cc: Larry Masinter , "Simon St.Laurent" , ietf-xml-mime@imc.org Message-id: <01JAZOFCAU428WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <199905071845.OAA12631@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > If all XML items come in with MIME types of "xml/foo", then someone needs > to tweak the settings in your client to know about DisplayFoo. If all your > XML items come in with the type "application/xml", then someone needs to > tweak the settings in the dispatched-to program to know about DisplayFoo. > I believe that "tweak the dispatched-to program" is a much better > environment than "tweak all the MIME-receiving clients" for many reasons: > - If you have more than one MIME-receiving client, the user tweaks fewer > settings. > - There is no need to register every sub-type: XMLShow can decide to launch > based on the content of the XML, such as from the DTD or XML namespaces > used. This speeds up adoption of new XML types. > - If "application/xml" automatically launches XMLShow, it is XMLShow that > can be told about the "smarter" applications like DisplayFoo, and it might > be able to cooperate with them in many ways. For instance, DisplayFoo might > be able to ask XMLShow to render parts of a document while DisplayFoo > renders other parts. > - XMLShow will be able to open a file off of disk (with no MIME > information) and still be able to hand off the file to DisplayFoo. The > MIME-receiving clients can never do this. > - Given today's MIME-receiving clients, it is more likely that XMLShow will > be more flexible about adding new DisplayFoo viewers than the > MIME-receiving clients are. While all of these are true, you've missed the big downside to "tweak the dispatched-to program": Such programs lose big-time in the integration they can offer in the client environment. More specifically, what happens when the XML-dispatching program decides, "Surprise! The original client is the agent best suited to display of this particular XML object." The problem is that even in tightly integrated plug in setups there's usually no way to communicate this sort of thing back to the client's dispacher to the point where a truly seamless display can be achieved. The inevitable result is suboptimal integration, which users, myself included, loathe. This is another instance of a problem we first encountered with security multiparts: When you dispatch handling of a security multipart to a separate application, getting the enclosed data back to the original client often isn't possible. And while a few clients have adopted plugin architectures that address this (Eudora, for example), most have not, and worse, plugins capable of working really well in such environments have been slow in coming. The result in the case of container objects like security multiparts has been to force the original client to do this sort of processing. And I suspect that similar forces will work to force a single level of dispatch for XML. And this, I believe, argues strongly for using different media type labels for XML in quite a few (but not all) cases. > In summary, I believe that specialized XML viewers are better off in an > environment where they are launched by the thing that "application/XML" > launches, not by their own MIME sub-types. I'm afraid I have to disagree. Ned From owner-ietf-xml-mime Sun May 9 13:11:45 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08686 for ietf-xml-mime-bks; Sun, 9 May 1999 13:11:45 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08677 for ; Sun, 9 May 1999 13:11:44 -0700 (PDT) Message-Id: <4.2.0.37.19990509125725.01e93b10@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Sun, 09 May 1999 13:01:55 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-Reply-To: <01JAZNY1KYCY8WXB3T@INNOSOFT.COM> References: <"Your message dated Sun, 09 May 1999 09:32:12 -0700" <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <199905091312.JAA16147@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:22 AM 5/9/99 -0700, Ned Freed wrote: There is also an intermediate case -- IMAP. In IMAP header information for >a MIME message can be downloaded and examined prior to downloading the >actual message content. But this is restricted to the labelling in header >fields -- media type, media type parameters, and disposition information, >in other words. If we ever get the rescap protocol finished, however, this won't be an issue, because the sender could have determined that the recipient couldn't (or didn't want) the type of information they were sending by looking at the media features of the receiver. >The long and short of it is that I don't see either extreme position on this >issue as tenable. The notion of "all XML goes under the application/xml media >type and a different mechanism is used to distinguish different instances of >XML usage" is a nonstarter, and so is "every little twiddle to something done >in XML gets a new media type". I also don't think that XML is even close to >mature enough for us to attempt to establish definitive rules for when a media >type is needed and when it isn't. I'll certainly agree with the last parts. The XML community isn't close to agreeing on whether it's FPIs or namespaces or the-next-big-thing that should be used as the identifier for what program should be used to process a particular XML object. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Sun May 9 13:11:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08687 for ietf-xml-mime-bks; Sun, 9 May 1999 13:11:46 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08681 for ; Sun, 9 May 1999 13:11:44 -0700 (PDT) Message-Id: <4.2.0.37.19990509130200.01ea2310@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Sun, 09 May 1999 13:13:47 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-Reply-To: <01JAZOFCAU428WXB3T@INNOSOFT.COM> References: <"Your message dated Sat, 08 May 1999 09:57:02 -0700" <4.2.0.37.19990508093511.02908240@mail.imc.org> <199905071845.OAA12631@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:34 AM 5/9/99 -0700, Ned Freed wrote: >While all of these are true, you've missed the big downside to "tweak the >dispatched-to program": Such programs lose big-time in the integration they >can offer in the client environment. > >More specifically, what happens when the XML-dispatching program decides, >"Surprise! The original client is the agent best suited to display of this >particular XML object." The problem is that even in tightly integrated plug in >setups there's usually no way to communicate this sort of thing back to the >client's dispacher to the point where a truly seamless display can be >achieved. >The inevitable result is suboptimal integration, which users, myself included, >loathe. I can't agree with you here. Yes, Eudora does this badly, but I think this is a problem with the implementation, not the idea. If an MUA or Web display engine says "I can natively display a stream of XML", then the integration with an intermediary is not difficult at all. >This is another instance of a problem we first encountered with security >multiparts: When you dispatch handling of a security multipart to a separate >application, getting the enclosed data back to the original client often >isn't possible. And while a few clients have adopted plugin architectures >that address this (Eudora, for example), most have not, and worse, plugins >capable of working really well in such environments have been slow in coming. I've spoken with people who make such plugins (such as the ones I try to use with Eudora), and they complain about the Eudora API, not about their ability to hand back blobs of text to the program. In my mind, this can't be all that hard for data types that the original program knows how to handle, particularly if they are guaranteed not to get back a multipart. To me, the problems of "original clients" displaying XML handed back to them from a process that decides what goes where isn't a serious issue. The more serious issue in my mind is that we are starting to get a significant number of XML formats and some viewers, and we haven't agreed to a method for them to link those through MIME. I think we need to say "yes, MIME is your linkage and here's exactly how" (which I don't think we are ready to do), or we must say "MIME is not your linkage and you need to come up with your own methods." --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Sun May 9 14:16:31 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08962 for ietf-xml-mime-bks; Sun, 9 May 1999 14:16:31 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08957; Sun, 9 May 1999 14:16:30 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM>; Sun, 9 May 1999 14:17:59 PDT Date: Sun, 09 May 1999 14:13:00 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Sun, 09 May 1999 13:01:55 -0700" <4.2.0.37.19990509125725.01e93b10@mail.imc.org> To: Paul Hoffman / IMC Cc: ietf-xml-mime@imc.org Message-id: <01JAZVRZ55PW8WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <199905091312.JAA16147@hesketh.net> <01JAZNY1KYCY8WXB3T@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > At 10:22 AM 5/9/99 -0700, Ned Freed wrote: > There is also an intermediate case -- IMAP. In IMAP header information for > >a MIME message can be downloaded and examined prior to downloading the > >actual message content. But this is restricted to the labelling in header > >fields -- media type, media type parameters, and disposition information, > >in other words. > If we ever get the rescap protocol finished, however, this won't be an > issue, because the sender could have determined that the recipient couldn't > (or didn't want) the type of information they were sending by looking at > the media features of the receiver. In the case of specific sender to specific receiver perhaps. But how about mailing lists? Mail archives? One of the key uses of IMAP (as opposed to POP) is to provide usable and useful archive and bulletin board services. And like it or not, rescap will never be able to solve the issues that arise with these sorts of things (unless it develops an ability to predict the future, which seems rather unlikely given current technology ;-). And this says nothing about the liklihood of rescap support appearing any time soon, let alone becoming widespread. I hope it does appear as soon as the specifications are done and catches on in a big way, but I'm not sure I want to make protocol design choices in other venues based on my hopes. Ned From owner-ietf-xml-mime Sun May 9 14:34:56 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09024 for ietf-xml-mime-bks; Sun, 9 May 1999 14:34:56 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09019; Sun, 9 May 1999 14:34:55 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM>; Sun, 9 May 1999 14:36:24 PDT Date: Sun, 09 May 1999 14:18:26 -0700 (PDT) From: Ned Freed Subject: RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level XML media types?) In-reply-to: "Your message dated Sun, 09 May 1999 13:13:47 -0700" <4.2.0.37.19990509130200.01ea2310@mail.imc.org> To: Paul Hoffman / IMC Cc: ietf-xml-mime@imc.org Message-id: <01JAZWFS25HQ8WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <199905071845.OAA12631@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <01JAZOFCAU428WXB3T@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > More specifically, what happens when the XML-dispatching program decides, > > "Surprise! The original client is the agent best suited to display of this > > particular XML object." The problem is that even in tightly integrated plug in > > setups there's usually no way to communicate this sort of thing back to the > > client's dispacher to the point where a truly seamless display can be > > achieved. > > The inevitable result is suboptimal integration, which users, myself included, > > loathe. > I can't agree with you here. Yes, Eudora does this badly, but I think this > is a problem with the implementation, not the idea. If an MUA or Web > display engine says "I can natively display a stream of XML", then the > integration with an intermediary is not difficult at all. Actually, in my opinion Eudora is far and away the best agent out there when it comes to this sort of thing, which is why I held it up as a fairly unique counterexample to what I see as the current state of affairs. Nothing else I've seen even comes close to having Eudora's capabilities. If you know of something else I'd like to hear about it. > > This is another instance of a problem we first encountered with security > > multiparts: When you dispatch handling of a security multipart to a separate > > application, getting the enclosed data back to the original client often > > isn't possible. And while a few clients have adopted plugin architectures > > that address this (Eudora, for example), most have not, and worse, plugins > > capable of working really well in such environments have been slow in coming. > I've spoken with people who make such plugins (such as the ones I try to > use with Eudora), and they complain about the Eudora API, not about their > ability to hand back blobs of text to the program. In my mind, this can't > be all that hard for data types that the original program knows how to > handle, particularly if they are guaranteed not to get back a multipart. Well, as it happens I'm familiar with the Eudora API -- I was asked to review its capabilities in this area some time back, and I liked them so much that I modelled some aspects of a similar API in our product after what Qualcomm had done. So while I cannot claim to have actually written code to the Eudora API, I can claim to have developed a similar API and written code that uses it to do similar things. And I can assure you that not only are such transformations possible, they are easy to implement using APIs of this sort. So I'm afraid I'm not prepared to accept the complaints you have heard as valid. Perhaps they were directed at an earlier version of Eudora, or something like that. (Please note that I don't work for Qualcomm and I only use Eudora rarely. So I have no vested interest in their MUA.) > To me, the problems of "original clients" displaying XML handed back to > them from a process that decides what goes where isn't a serious issue. The > more serious issue in my mind is that we are starting to get a significant > number of XML formats and some viewers, and we haven't agreed to a method > for them to link those through MIME. I think we need to say "yes, MIME is > your linkage and here's exactly how" (which I don't think we are ready to > do), or we must say "MIME is not your linkage and you need to come up with > your own methods." Again, I don't think you can say either one is right in general. I think that for some applications separate MIME types are appropriate and necessary; for others a single MIME type for an entire family of things is appropriate; and for others a generic MIME label is fine. Ned From owner-ietf-xml-mime Mon May 10 07:12:14 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01882 for ietf-xml-mime-bks; Mon, 10 May 1999 07:12:14 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01878 for ; Mon, 10 May 1999 07:12:12 -0700 (PDT) Received: from simon (slip129-37-221-175.ny.us.ibm.net [129.37.221.175]) by hesketh.net (8.8.8/8.8.8) with SMTP id KAA14873 for ; Mon, 10 May 1999 10:14:44 -0400 Message-Id: <199905101414.KAA14873@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 10 May 1999 10:18:01 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-Reply-To: <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> References: <199905091312.JAA16147@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:32 AM 5/9/99 -0700, Paul Hoffman / IMC wrote: >Correct. Not all MIME-using mechanisms have content negotiation. Internet >mail, for example. Content-negotiation can and should be dealt with using >content-negotiation protocols. See for >details. > >[...] > >Again, this can be handled by using content-negotiation. It would be pretty >easy to add a conneg type that would describe the type of XML that you are >passing, without breaking the example I gave for protocols that don't do >negotiation. The need for content negotiation in certain circumstance seems real - maybe, just maybe, I've extracted this much of a concession. The question then becomes whether it is better to describe content in one concise description (the MIME type) or using separate protocols. 1) What are the real 'costs' of adding a new top-level MIME type? 1a) What are the costs of adding xml- as a prefix to XML-based MIME types? (Rick Jelliffe's proposal.) 2) What are the real 'costs' of creating separate content-negotiation protocols? I'm afraid that I'm unconvinced that the costs of 1 are greater than the costs of 2. Are there genuine compatibility issues, or is this just philosophical opposition? Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Mon May 10 08:37:55 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02656 for ietf-xml-mime-bks; Mon, 10 May 1999 08:37:55 -0700 (PDT) Received: from smtp.gatewaymail.net (smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02651 for ; Mon, 10 May 1999 08:37:54 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id IAA25015 for ; Mon, 10 May 1999 08:39:58 -0700 Message-Id: <3.0.32.19990510084025.009deb40@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 May 1999 08:40:29 -0700 To: ietf-xml-mime@imc.org From: Tim Bray Subject: media types and ignorance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:22 AM 5/9/99 -0700, Ned Freed wrote: >The long and short of it is that I don't see either extreme position on this >issue as tenable. The notion of "all XML goes under the application/xml media >type and a different mechanism is used to distinguish different instances of >XML usage" is a nonstarter, and so is "every little twiddle to something done >in XML gets a new media type". I also don't think that XML is even close to >mature enough for us to attempt to establish definitive rules for when a media >type is needed and when it isn't. Hard to argue with that. This discussion has been peeving me seriously because with each exchange, I realize I understand less than I thought about how the Internet is supposed to fit together. I honestly don't have an opinion I'm comfy with, but here are a few data points that might be useful: - I'm currently helping work on a language whose mime type will almost certainly be encoded as "model/x3d" - it will be encoded in XML - Internet Explorer 5 has a facility I've found very useful - send it a well-formed XML document with no stylesheet and it constructs a nice collapsing-tree view of it in real time. Tremendously helpful when you're getting some chunk of XML vocabulary for the first time and want to get a handle on it. This is, in fact, a useful general-purpose XML processor, something I seem to recall denying the existence of here not too long ago. - There are going to be a lot of new formats that happen to be encoded in XML, for which the fact of the encoding syntax is an irrelevant side-issue. It's obvious that there is a real need for application/xml; among other things, it clarifies i18n immensely. Three days out of each week, I don't believe that text/xml is useful. I know this is heresy, but sometimes I think that what you need is not a media type but another parameter akin to charset, so that you can say for some arbitrary mimetype content-type: text/foo; charset="ISO-8859-1" syntax="xml-1.0" which lets you know that there's a really useful fallback (ie your XML-savvy-browser) in the case that you're not set up for text/foo. Or maybe the top-level xml/* type has the same utility. Or maybe the whole notion that a rigid 2-level type hierarchy is a useful vehicle for interoperability is becoming bogus. I just don't know, so I'm going to shut up and listen. -Tim From owner-ietf-xml-mime Mon May 10 09:06:11 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA02960 for ietf-xml-mime-bks; Mon, 10 May 1999 09:06:11 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02956 for ; Mon, 10 May 1999 09:06:06 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id AAA23426; Tue, 11 May 1999 00:08:19 +0800 (CST) Date: Tue, 11 May 1999 00:08:18 +0800 (CST) From: Rick Jelliffe To: Tim Bray cc: ietf-xml-mime@imc.org Subject: Re: media types and ignorance In-Reply-To: <3.0.32.19990510084025.009deb40@pop.intergate.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 10 May 1999, Tim Bray wrote: > Or maybe the whole notion that a rigid 2-level type hierarchy is a useful > vehicle for interoperability is becoming bogus. I think Tim's ambivalence is just a sign that that all these are useful, and that we should provide enough richness to cover the major cases: * generic XML using stylesheets and fallback (text/xml & application/xml); * application-specific XML with no need for fallback (application/*, model/*, etc); * application-specific XML but which allows some measure of fallback, even if just to allow browser users to figure out which is the best handler for it (the XML registration tree: application/xml.*): we can expect smarter broswers to check for ; Mon, 10 May 1999 09:24:06 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM> for ietf-xml-mime@imc.org; Mon, 10 May 1999 09:26:01 PDT Date: Mon, 10 May 1999 09:16:43 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Mon, 10 May 1999 10:18:01 -0400" <199905101414.KAA14873@hesketh.net> To: "Simon St.Laurent" Cc: ietf-xml-mime@imc.org Message-id: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <199905091312.JAA16147@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Again, this can be handled by using content-negotiation. It would be pretty > > easy to add a conneg type that would describe the type of XML that you are > > passing, without breaking the example I gave for protocols that don't do > > negotiation. > The need for content negotiation in certain circumstance seems real - > maybe, just maybe, I've extracted this much of a concession. > The question then becomes whether it is better to describe content in one > concise description (the MIME type) or using separate protocols. > 1) What are the real 'costs' of adding a new top-level MIME type? It has been reported that there is deployed software that has to be changed to deal with new top-level types (a big design botch in my opinion). This came up when the model top-level type was added. There's also the cost of writing it up and getting it standardized. It is likely that there would be strong objection to defining such a type (I certainly would object because I don't see this as being properly orthogonal to several of the existing top-level types). > 1a) What are the costs of adding xml- as a prefix to XML-based MIME types? > (Rick Jelliffe's proposal.) There are actually three possible proposals in this space: (1) Add a "xml." facet and corresponding registration tree. Again, this requires writing a specification, and it is likely to be controversial because this doesn't meet the criteria for a new registration tree and also isn't orthogonal to existing trees. (2) Recommend/require that the names of XML-based types have "xml-" after the registration facet. This could be done simply by adding some text to this effect to a revision of the XML in MIME document -- once in place the media types reviewer (me) will see to it that appropriate names are selected for new types. (3) Recommand/require that the names of XML-based types have "-xml" at the end of the name. This is the same as (2) in terms of effort, but might be a win in that matching a suffix might be easier/cleaner to do in some contexts (the beginnnings of these strings are grotted up with registration tree information). > 2) What are the real 'costs' of creating separate content-negotiation > protocols? The costs are that there are contexts where you're unlikely to see the ability to use such things in the forseeable future, and where you'd really like to make choices based on knowing the XML variant in use. > I'm afraid that I'm unconvinced that the costs of 1 are greater than the > costs of 2. Are there genuine compatibility issues, or is this just > philosophical opposition? The former, according to reports we've gotten in the past. Ned From owner-ietf-xml-mime Mon May 10 10:36:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03731 for ietf-xml-mime-bks; Mon, 10 May 1999 10:36:12 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03727 for ; Mon, 10 May 1999 10:36:08 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53001(5)>; Mon, 10 May 1999 10:38:34 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <100596>; Mon, 10 May 1999 10:38:24 PDT From: "Larry Masinter" To: Subject: Using CONNEG instead of MIME types for compound types & references Date: Mon, 10 May 1999 10:38:16 PDT Message-ID: <000101be9b0b$e2c8ab60$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199905101414.KAA14873@hesketh.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: There are a number of situations where MIME types don't solve the problem for "content negotiation" because the XML bodies that are transferred will be compound objects that contain multiple kinds of markup. In such situations, having a "top level" type other than "application/xml" doesn't do any good, since there's no useful way to use MIME to describe the combination of elements that are contained within. For example, if, as it seems, there will be XML body parts which contain XHTML and, embedded within (not using multipart), contain equations using the MathML and molecular diagrams using ChemML, and some Dublin Core metadata using RDF, there is no useful designation of the entire top level type that accurately describes the content, or allows you to say that you accept XHTML, MathML but don't accept ChemML. For *these* kind of XML bodies where multiple applications are intermixed, having new MIME types doesn't solve the problem. In this situation, though adding additional MIME types doesn't solve the problem, the media feature mechanisms *do* allow content negotiation and are appropriate. I want to distinguish between a "protocol" (rules of engagement) and a "protocol element" (a string or data structure used within one or more protocols). CONNEG developed content negotiation *protocol elements* for describing data, sender and recipient capabilities, characteristics and preferences. Most of the work on different content negotiation *protocols* has happened outside of the CONNEG working group, since content negotiation is usually in the context of some other communication protocol. HTTP and Internet Fax both have some kind of "content negotiation". The Internet Fax mechanisms are, IMHO, the best you can do for email. (Section 3 of RFC 2532 describes how a sender may determine an email recipient's capabilities.) HTTP has both "accept" requests, "Vary" responses, and some experimental protocols (Transparent Content Negotiation and RVSA). ------ RFC 2506 Media Feature Tag Registration Procedure. March 1999. (Also BCP0031) (Status: BEST CURRENT PRACTICE) How to register features. The simplest thing to do would be to define an "XML namespace" feature and a "XML DTD" feature, whose values are the pointer to the XML namespace and DTD respectively. ------- RFC 2533 A Syntax for Describing Media Feature Sets. March 1999. (Status: PROPOSED STANDARD) How to combine a set of features into a feature set -------- draft-ietf-conneg-feature-hash-01.txt: Identifying composite media features April 1999. How to use URLs or hashes to indentify complex sets of features or feature profiles. and, while you're at it (although only relevant to some XML applications): ------- RFC 2534 Media Features for Display, Print, and Fax. March 1999. (Status: PROPOSED STANDARD) This is as useful for HTML as it is for anything. In fact, it was originally motivated by wanting to do better than the "screen size" in the User Agent field. ------ RFC 2530 Indicating Supported Media Features Using Extensions to DSN and MDN.March 1999. (Status: PROPOSED STANDARD) This is a way of adding content negotiation to email. ------ RFC 2531 Content Feature Schema for Internet Fax. March 1999. (Status: PROPOSED STANDARD) The color space description protocol elements here are applicable to any calibrated-color application, even though designed originally for "fax". ------ Two proposals for content negotiation *protocols* in HTTP: RFC 2295 Transparent Content Negotiation in HTTP. March 1998. (Status: EXPERIMENTAL) RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. March 1998. (Status: EXPERIMENTAL) From owner-ietf-xml-mime Mon May 10 10:46:02 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03791 for ietf-xml-mime-bks; Mon, 10 May 1999 10:46:02 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03787 for ; Mon, 10 May 1999 10:46:01 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id BAA07395; Tue, 11 May 1999 01:48:28 +0800 (CST) Date: Tue, 11 May 1999 01:48:28 +0800 (CST) From: Rick Jelliffe To: ietf-xml-mime@imc.org Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-Reply-To: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 10 May 1999, Ned Freed wrote: > > 1a) What are the costs of adding xml- as a prefix to XML-based MIME types? > > (Rick Jelliffe's proposal.) > > There are actually three possible proposals in this space: > > (1) Add a "xml." facet and corresponding registration tree. Again, this > requires writing a specification, and it is likely to be controversial > because this doesn't meet the criteria for a new registration tree and > also isn't orthogonal to existing trees. Why doesnt it meet the criteria for new trees? The point of a registration tree is to accomodate registration authorities other than the IETF/RFC mechanism: a program administered by a registrar accepted by W3C (the copyright holders) and IETF seems to meet the criteria as far as I read them. Also, where did this requirement for orthogonality spring from? > (2) Recommend/require that the names of XML-based types have "xml-" after > the registration facet. The RFC for MIME media types does not allow for delegation of IETF registration tree names, which is what you seem to suggest here. All new MIME media types require writing a specification (an RFC). The only ways around this is either to rewrite the MIME media type spec, or to add a registration tree. I don't see how it can be done inside the XML spec, under the current procedures. If the MIME spec is rewritten to allow the registration of a prefix (application/xml-*) and to allow people to use that prefix without creating an RFC, we increase the likelihood for collision: this is why we need a registration tree. We are easily getting a DTD a day being announced, and many more being created. There is no way they can all be vetted adequately; and they do not need to be vetted if they use XML: it already has the RFC out. They should be able to piggyback on top of the XML RFC, and just provide minimal extra information. This is why I think it is more than just an issue of the inconvenience of getting an XML registration tree up: I think other approaches will cause more trouble. Rick Jelliffe From owner-ietf-xml-mime Mon May 10 10:52:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03873 for ietf-xml-mime-bks; Mon, 10 May 1999 10:52:07 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03869 for ; Mon, 10 May 1999 10:52:06 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id BAA07981; Tue, 11 May 1999 01:54:21 +0800 (CST) Date: Tue, 11 May 1999 01:54:21 +0800 (CST) From: Rick Jelliffe To: Larry Masinter cc: ietf-xml-mime@imc.org Subject: Re: Using CONNEG instead of MIME types for compound types & references In-Reply-To: <000101be9b0b$e2c8ab60$aa66010d@copper.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 10 May 1999, Larry Masinter wrote: > There are a number of situations where MIME types don't solve the > problem for "content negotiation" because the XML bodies that are > transferred will be compound objects that contain multiple kinds > of markup. In such situations, having a "top level" type other > than "application/xml" doesn't do any good, since there's no useful > way to use MIME to describe the combination of elements that are > contained within. Let us solve the simple needs of transmitting a simple document before attempting to get multipart documents correct! Divide and conquer. The multipart problems (sending a document rather than an entity) are a black hole from which we may never return. Rick Jelliffe From owner-ietf-xml-mime Mon May 10 11:05:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04014 for ietf-xml-mime-bks; Mon, 10 May 1999 11:05:12 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04010 for ; Mon, 10 May 1999 11:05:11 -0700 (PDT) Message-Id: <4.2.0.37.19990510110224.02762d30@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Mon, 10 May 1999 11:05:31 -0700 To: ietf-xml-mime@imc.org From: Paul Hoffman / IMC Subject: Re: Using CONNEG instead of MIME types for compound types & references In-Reply-To: References: <000101be9b0b$e2c8ab60$aa66010d@copper.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 01:54 AM 5/11/99 +0800, Rick Jelliffe wrote: >Let us solve the simple needs of transmitting a simple document >before attempting to get multipart documents correct! Divide and >conquer. I'll disagree here. Because we know they exist and believe they will continue to exist, it is our responsibility to try hard to make sure they're covered by whatever solution we come up with. It's fine for us to eventually say "nope, we couldn't handle it so here's a system for single-parts only", but we need to try. Otherwise, a MIME-creating program with an outgoing document won't be able to figure out how to tag it. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-xml-mime Mon May 10 11:31:13 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04319 for ietf-xml-mime-bks; Mon, 10 May 1999 11:31:13 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04315 for ; Mon, 10 May 1999 11:31:09 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JB13DWEYK08WXISK@INNOSOFT.COM> for ietf-xml-mime@imc.org; Mon, 10 May 1999 11:32:42 PDT Date: Mon, 10 May 1999 11:12:48 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Tue, 11 May 1999 01:48:28 +0800 (CST)" To: Rick Jelliffe Cc: ietf-xml-mime@imc.org Message-id: <01JB14BCPK7K8WXISK@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > On Mon, 10 May 1999, Ned Freed wrote: > > > 1a) What are the costs of adding xml- as a prefix to XML-based MIME types? > > > (Rick Jelliffe's proposal.) > > > > There are actually three possible proposals in this space: > > > > (1) Add a "xml." facet and corresponding registration tree. Again, this > > requires writing a specification, and it is likely to be controversial > > because this doesn't meet the criteria for a new registration tree and > > also isn't orthogonal to existing trees. > Why doesnt it meet the criteria for new trees? The point of a > registration tree is to accomodate registration authorities other than > the IETF/RFC mechanism: a program administered by a registrar accepted by > W3C (the copyright holders) and IETF seems to meet the criteria as far as > I read them. No, the point of having different registration authorities is to allow different rulesets to be brought to bear on different classes of media types. And insofar as the W3C is concerned, my understanding is that they don't want to act as a registration authority for XML types. I haven't heard any other organizations suggested that would be appropriate for this job. And if you assume that the W3C wanted its own tree where its own rules would apply, it would be silly to restrict it to XML. As such, you'd likely end up with a "w3c." facet. > Also, where did this requirement for orthogonality spring from? It isn't a requirement, it is just a common sense concern. I think it is inevitable that the IETF will use XML for some of its future work. But such types will be registered in the IETF tree, not an XML tree -- I can assure you that the idea that the IETF would be forced to use an "xml." or worse "w3c." tree and hence someone else would have this sort of control over the IETF's use of something it created is a complete anathema to many, and hence is a 100% complete nonstarer. So what you end up with is a registration tree designed to capture all registrations of a given type that cannot possibly get all the registrations it is supposed to. And that makes it fairly useless in my book. > > (2) Recommend/require that the names of XML-based types have "xml-" after > > the registration facet. > The RFC for MIME media types does not allow for delegation of IETF > registration tree names, which is what you seem to suggest here. No, what said is that the prefix would appear after the registration facet, that is, xml-, vnd.xml-, prs.vnd.xml-, and possibly w3c.xml-. > All new MIME media types require writing a specification (an RFC). No they do not. Read RFC 2048 (which as it happens I wrote). > The only ways around this is either to rewrite the MIME media type spec, > or to add a registration tree. I don't see how it can be done inside the XML > spec, under the current procedures. If the MIME spec is rewritten to allow > the registration of a prefix (application/xml-*) and to allow people to use > that prefix without creating an RFC, we increase the likelihood for > collision: this is why we need a registration tree. Again, I'm not suggest a prefix that goes before the registration facet, I'm suggesting one that goes after it. > We are easily getting a DTD a day being announced, and many more being > created. There is no way they can all be vetted adequately; and they do > not need to be vetted if they use XML: it already has the RFC out. They > should be able to piggyback on top of the XML RFC, and just provide > minimal extra information. And the media types registration process has shown that it can handle one registration a day if need be. Moreover, such a need is unlikely to exist since only a subset of all the DTDs that are announced will actually need a media type. > This is why I think it is more than just an issue of the inconvenience of > getting an XML registration tree up: I think other approaches will cause > more trouble. I can assure you that this assessment is incorrect. Ned From owner-ietf-xml-mime Mon May 10 11:34:39 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04350 for ietf-xml-mime-bks; Mon, 10 May 1999 11:34:39 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA04346 for ; Mon, 10 May 1999 11:34:37 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53191(2)>; Mon, 10 May 1999 11:37:11 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <100674>; Mon, 10 May 1999 11:36:46 PDT From: "Larry Masinter" To: "Rick Jelliffe" Cc: Subject: RE: Using CONNEG instead of MIME types for compound types & references Date: Mon, 10 May 1999 11:36:39 PDT Message-ID: <000701be9b14$0a7d7d40$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Let us solve the simple needs of transmitting a simple document > before attempting to get multipart documents correct! Divide and > conquer. Let's solve the problems that caused us to start this mailing list in the first place; those problems include the problems of properly labelling XHTML with various kinds of embedded tables, math, markup and use of features. If XML could only allow you to have simple documents without any of the complexities of compound mixed features, we wouldn't have started this discussion in the first place, since it would be fine just to create a new MIME type for each. Larry From owner-ietf-xml-mime Tue May 11 00:39:42 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA11868 for ietf-xml-mime-bks; Tue, 11 May 1999 00:39:42 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA11864 for ; Tue, 11 May 1999 00:39:38 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id PAA22528; Tue, 11 May 1999 15:42:04 +0800 (CST) Message-ID: <004001be9b80$541c1bc0$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: "Ned Freed" Cc: References: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> <01JB14BCPK7K8WXISK@INNOSOFT.COM> Subject: Re: Negotiated Content Delivery: Maxmimizing Information Date: Tue, 11 May 1999 15:31:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: From: Ned Freed > > On Mon, 10 May 1999, Ned Freed wrote: > No, the point of having different registration authorities is to allow > different rulesets to be brought to bear on different classes of media types. So where it the problem?...the different ruleset is the automated registration for a definite class of documents on the provision of a DTD or schema. > And insofar as the W3C is concerned, my understanding is that they don't > want to act as a registration authority for XML types. I haven't heard any > other organizations suggested that would be appropriate for this job. Which is why I didn't suggest that they should act: merely that they, and IETF, agree on someone to act as registrar. I could do it (through Academia Sinica, for example). Because the procedure is automated, the registrar is nominal. W3C needs to give some consent because they are the trademark holders of XML, not because they need be principals. > And if you assume that the W3C wanted its own tree where its own rules > would apply, it would be silly to restrict it to XML. As such, you'd likely > end up with a "w3c." facet. No, I was not assuming that W3C wanted its own tree. That is why I did not call the facet "w3c.". > > Also, where did this requirement for orthogonality spring from? > > It isn't a requirement, it is just a common sense concern. I think it is > inevitable that the IETF will use XML for some of its future work. But such > types will be registered in the IETF tree, not an XML tree -- I can assure you > that the idea that the IETF would be forced to use an "xml." or worse "w3c." > tree and hence someone else would have this sort of control over the IETF's use > of something it created is a complete anathema to many, and hence is a 100% > complete nonstarer. You are assuming a step which I am not: that all XML must be registered using the xml. registration tree. It would be a service made available for convenience; if it were a new top-level MIME type, then one would expect everyone to use it. > So what you end up with is a registration tree designed to capture all > registrations of a given type that cannot possibly get all the registrations > it is supposed to. And that makes it fairly useless in my book. If that was what I was proposing, I would agree with you. > > All new MIME media types require writing a specification (an RFC). > > No they do not. Read RFC 2048 (which as it happens I wrote). I know you wrote it: we are indebted to you, it is a great thing. But that is not what you wrote: "2.1.1. IETF Tree The IETF tree is intended for types of general interest to the Internet Community. Registration in the IETF tree requires approval by the IESG and publication of the media type registration as some form of RFC." That says that new MIME types require an RFC (from my context it should be obvious that I am talking about MIME types in the default, IETF, tree, because my proposal is based on MIME types in other registration trees not requiring an RFC.) > Again, I'm not suggest a prefix that goes before the registration facet, I'm > suggesting one that goes after it. And I again I'm saying that RFC 2048 only allows, in its plain reading, registration of specific media-content types. I cannot see where it allows bulk open-ended registrations by registering a prefix. > And the media types registration process has shown that it can handle one > registration a day if need be. Moreover, such a need is unlikely to exist since > only a subset of all the DTDs that are announced will actually need a media > type. I agree that now that vendors are starting to use vnd. vendor tree, things are not grim. My point is this: it would be convenient and useful to have an automated procedure which circumvented the need for an RFC for each MIME type, which RFC 2048 requires (as quoted above). Because, as far as I can construe RFC 2048, there is no scope to bulk-declare prefixes, the only solution I could see is a registration tree. However, it may well be, as you advise, that this would be more trouble than it is worth. Especially because the kind of information that I am suggesting would be needed for registration (the schema) should be available in the document itself, as a DOCTYPE or schema or namespace declaration. Rick Jelliffe From owner-ietf-xml-mime Tue May 11 01:16:54 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA13269 for ietf-xml-mime-bks; Tue, 11 May 1999 01:16:54 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA13265 for ; Tue, 11 May 1999 01:16:52 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JAXDYNR6UO8WXB3T@INNOSOFT.COM> for ietf-xml-mime@imc.org; Tue, 11 May 1999 01:18:24 PDT Date: Tue, 11 May 1999 01:04:30 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Tue, 11 May 1999 15:31:47 +0800" <004001be9b80$541c1bc0$dd066d8c@sinica.edu.tw> To: Rick Jelliffe Cc: Ned Freed , ietf-xml-mime@imc.org Message-id: <01JB1X537ECY8WXB3T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> <01JB14BCPK7K8WXISK@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > You are assuming a step which I am not: that all XML must be registered > using the xml. registration tree. It would be a service made available for > convenience; if it were a new top-level MIME type, then one would expect > everyone to use it. Then I fail to see the point of adding the tree. Nearly equivalent rules would have apply to it, the same procedures, and it doesn't serve to distinguish XML usage. Unless you can explain why you think the present registration procedure isn't working for XML I fail to see the point of having a new one that isn't going to be able to be materially different from the old. > > So what you end up with is a registration tree designed to capture all > > registrations of a given type that cannot possibly get all the registrations > > it is supposed to. And that makes it fairly useless in my book. > That says that new MIME types require an RFC (from my context it should be > obvious that I am talking about MIME types in the default, IETF, tree, > because my proposal is based on MIME types in other registration trees not > requiring an RFC.) No, it says that types in the IETF tree have to be backed up with an RFC, and it is NOT obvious or even correct that you're talking about the IETF tree only here. You were responding to my proposal, and my proposal was in no way limited to the IETF tree. > > Again, I'm not suggest a prefix that goes before the registration facet, > > I'm suggesting one that goes after it. > And I again I'm saying that RFC 2048 only allows, in its plain reading, > registration of specific media-content types. I cannot see where it allows > bulk open-ended registrations by registering a prefix. I'm sorry, but this is nonsensical in that I'm not talking about registration in the IETF tree. > I agree that now that vendors are starting to use vnd. vendor tree, things > are not grim. My point is this: it would be convenient and useful to have an > automated procedure which circumvented the need for an RFC for each MIME > type, which RFC 2048 requires (as quoted above). The problem is it won't work. The rules for these things require substantive review. You cannot avoid this review and automate the process by setting up a new registration tree; there would be tremendous objection to attempting to circumvent the review process. It took years of wrangling to get the vnd. and prs. trees approved and the rules for registration in them lightened to the point where people would use them, and to this day there are plenty of people who don't think we did the right thing when we did this. Every single time I approve one of these things I think about whether or not I'm making an egregious blunder that is going to wreck the whole process. It is my assessment that a proposal which lifts even more of the review requirements, especially when there doesn't solve any current problem, is going to be a total nonstarter. And believe me, it isn't because I love reviewing the things that I say this. Ned From owner-ietf-xml-mime Tue May 11 03:49:13 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19127 for ietf-xml-mime-bks; Tue, 11 May 1999 03:49:13 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA19123 for ; Tue, 11 May 1999 03:49:12 -0700 (PDT) Received: from themacs.com (slip129-37-160-75.on.ca.ibm.net [129.37.160.75]) by out1.ibm.net (8.8.5/8.6.9) with ESMTP id KAA98110; Tue, 11 May 1999 10:51:23 GMT Message-ID: <37380BA3.371B5ECF@themacs.com> Date: Tue, 11 May 1999 05:51:15 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: Rick Jelliffe , ietf-xml-mime@imc.org Subject: Re: Using CONNEG instead of MIME types for compound types & references References: <000701be9b14$0a7d7d40$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Larry Masinter wrote: > Let's solve the problems that caused us to start this mailing > list in the first place; those problems include the problems > of properly labelling XHTML with various kinds of embedded > tables, math, markup and use of features. Well... Our strategy in the HTML Working Group has been to avoid the issue of compound documents as well. Instead, we are defining a mechanism whereby popular feature sets with DTDs can be combined into single DTDs that are in the XHTML family. Thus, as long as the document is announced as XHTML, a conforming user agent will need to deal with it. Part of this relates to XHTML Profiles. While this effort is still in its infancy, my belief is that it is likely to include a method of specifying the various feature sets that are required by a document and/or supported by a user agent. This is needed for content negotiation. If we can leverage the CONNEG work on this, so much the better! -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Tue May 11 05:29:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21959 for ietf-xml-mime-bks; Tue, 11 May 1999 05:29:49 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21955 for ; Tue, 11 May 1999 05:29:47 -0700 (PDT) Received: from simon (slip129-37-221-170.ny.us.ibm.net [129.37.221.170]) by hesketh.net (8.8.8/8.8.8) with SMTP id IAA21111; Tue, 11 May 1999 08:32:24 -0400 Message-Id: <199905111232.IAA21111@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 11 May 1999 08:35:37 -0400 To: Ned Freed From: "Simon St.Laurent" Subject: Re: Negotiated Content Delivery: Maxmimizing Information Cc: ietf-xml-mime@imc.org In-Reply-To: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> References: <"Your message dated Mon, 10 May 1999 10:18:01 -0400" <199905101414.KAA14873@hesketh.net> <199905091312.JAA16147@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:16 AM 5/10/99 -0700, Ned Freed wrote: >> 1) What are the real 'costs' of adding a new top-level MIME type? > >It has been reported that there is deployed software that has to be changed >to deal with new top-level types (a big design botch in my opinion). This >came up when the model top-level type was added. > >There's also the cost of writing it up and getting it standardized. It is >likely that there would be strong objection to defining such a type (I >certainly would object because I don't see this as being properly orthogonal to >several of the existing top-level types). So the practical costs are caused by 'reports' of poorly written software, while the political costs are caused by a group of dug-in individuals on philosophical grounds. It doesn't sound promising, but it also sounds like the real costs are political, not caused by implementations. (We would hope that those folks fixed their software correctly after the experience of model, but can't count on it, of course.) >(3) Recommand/require that the names of XML-based types have "-xml" at the > end of the name. This is the same as (2) in terms of effort, but might > be a win in that matching a suffix might be easier/cleaner to do in > some contexts (the beginnnings of these strings are grotted up with > registration tree information). I could live with this. >> 2) What are the real 'costs' of creating separate content-negotiation >> protocols? > >The costs are that there are contexts where you're unlikely to see the >ability to use such things in the forseeable future, and where you'd >really like to make choices based on knowing the XML variant in use. Here we agree completely, it seems. >> I'm afraid that I'm unconvinced that the costs of 1 are greater than the >> costs of 2. Are there genuine compatibility issues, or is this just >> philosophical opposition? > >The former, according to reports we've gotten in the past. I'd like to hear more detail on these 'reports'. It's hard to base a cost-benefit analysis on reports with no owners or details. As I noted above, it sounds like philosophical opposition - politics - is the real roadblock. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Tue May 11 05:34:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22045 for ietf-xml-mime-bks; Tue, 11 May 1999 05:34:33 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22041 for ; Tue, 11 May 1999 05:34:31 -0700 (PDT) Received: from simon (slip129-37-221-170.ny.us.ibm.net [129.37.221.170]) by hesketh.net (8.8.8/8.8.8) with SMTP id IAA21217; Tue, 11 May 1999 08:37:09 -0400 Message-Id: <199905111237.IAA21217@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 11 May 1999 08:40:23 -0400 To: "Larry Masinter" , From: "Simon St.Laurent" Subject: Re: Using CONNEG instead of MIME types for compound types & references In-Reply-To: <000101be9b0b$e2c8ab60$aa66010d@copper.parc.xerox.com> References: <199905101414.KAA14873@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:38 AM 5/10/99 -0700, Larry Masinter wrote: >There are a number of situations where MIME types don't solve the >problem for "content negotiation" because the XML bodies that are >transferred will be compound objects that contain multiple kinds >of markup. In such situations, having a "top level" type other >than "application/xml" doesn't do any good, since there's no useful >way to use MIME to describe the combination of elements that are >contained within. So long as I can gather from the MIME type that the content I'm getting or about to get is XML, that's a big step forward. Multi-part XML doesn't frighten me, and in hard cases where content negotiation is genuinely needed, it'll be worth the effort of the many proposals you've noted. I do not, on the other hand, want to be forced to go through content negotiation protocols just to find out that a document uses XML syntax. For short documents, that could be almost as bad as downloading the document in its entirety. The beauty of MIME types is that they present a lot of useful information in a very tiny capsule that's easy to work with. I'd like to make sure they contain as much useful information as possible without making that capsule any larger. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Tue May 11 06:44:47 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23415 for ietf-xml-mime-bks; Tue, 11 May 1999 06:44:47 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23411 for ; Tue, 11 May 1999 06:44:46 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id IAA20328; Tue, 11 May 1999 08:46:12 -0500 (CDT) Received: from clv-oh38-48.ix.netcom.com(207.220.172.48) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma020291; Tue May 11 08:45:51 1999 Message-ID: <006401be9bb4$99235240$8daddccf@ix.netcom.com> From: "Frank Boumphrey" To: "Larry Masinter" , "Rick Jelliffe" Cc: References: <000701be9b14$0a7d7d40$aa66010d@copper.parc.xerox.com> Subject: Re: Using CONNEG instead of MIME types for compound types & references Date: Tue, 11 May 1999 09:41:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Let's solve the problems that caused us to start this mailing > list in the first place; those problems include the problems > of properly labelling XHTML with various kinds of embedded > tables, math, markup and use of features. I would like to reiterate these problems, it is the problem of how a user agent treats an XHTML file. Basically if I send an XHTML file as text/html, then a browser will send that file off to its HTML engine, and parse it as an HTML file. If I send the file as text/xml, then the browser will send it of to its XML parser, and just create a parse tree. Now there may be some devices that do not want to accept an XML file but will be quite happy to accept an XHTML or an HTML file. Such a device may be a traditional browser There will also be some devices that are happy to accept an XML or an XHTML file but not an HTML file, they have no wish at all to deal with unclosed tags etc. Both these devivices would like to know what kind of file they are dealing with before down loading the whole file, hence the need to identify a file as an XHTML file in some way. The second problem is as Larry points out is the file with embedded xml from different namespaces. A browser may be quite happy to accept an XHTML file and will 'know' how to display basic XHTML1.0, but will not know how to display mathXML or MusicXML. Because the Namespaces can be scoped in the document, and don't have to be in the head of the document, the browser may be well into rendering the document before it realises that it can't display the relevant code. It would be nice from the browsers point of view if it had prior knowledge of the namespaces before downloading the document, because then it could either 1. Decide to display it as a tree. 2. Send a mesage to the user asking whether it wants the document down loaded or not. 3. Decide not to down load the document at all. For this reason there are many who would like to see a text/xhtml mime type. (This includes my self as I see that this is the easiest solution to our problem, but then I am just being selfish). For the record I think that application/xml.html would be quite acceptable and presumably (please correct me if I'm wrong) one could include a whole series of these to define all the namespaces used in an XHTML document, i.e. application/xml.html, application/xml.mathml, application/xml.musicml etc. Others such as Murray (I hope I am not mis-interpreting him!) have pointed out that they would like a more general solution, because they feel that an XHTML mime type will keep XHTML off in it's own landscape and not encourage it to join the more general XML solution. Frank ----- Original Message ----- From: Larry Masinter To: Rick Jelliffe Cc: Sent: Monday, May 10, 1999 2:36 PM Subject: RE: Using CONNEG instead of MIME types for compound types & references > > Let us solve the simple needs of transmitting a simple document > > before attempting to get multipart documents correct! Divide and > > conquer. > > Let's solve the problems that caused us to start this mailing > list in the first place; those problems include the problems > of properly labelling XHTML with various kinds of embedded > tables, math, markup and use of features. > > If XML could only allow you to have simple documents without > any of the complexities of compound mixed features, we wouldn't > have started this discussion in the first place, since it would > be fine just to create a new MIME type for each. > > Larry > > From owner-ietf-xml-mime Tue May 11 07:32:23 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24847 for ietf-xml-mime-bks; Tue, 11 May 1999 07:32:23 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24843 for ; Tue, 11 May 1999 07:32:22 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id WAA02394 for ; Tue, 11 May 1999 22:34:54 +0800 (CST) Message-ID: <00d801be9bba$008cc380$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: References: <000701be9b14$0a7d7d40$aa66010d@copper.parc.xerox.com> <006401be9bb4$99235240$8daddccf@ix.netcom.com> Subject: Re: Using CONNEG instead of MIME types for compound types & references Date: Tue, 11 May 1999 22:24:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: From: Frank Boumphrey > > Let's solve the problems that caused us to start this mailing > > list in the first place; those problems include the problems > > of properly labelling XHTML with various kinds of embedded > > tables, math, markup and use of features. > > I would like to reiterate these problems, it is the problem of > how a user agent treats an XHTML file. Oh I see the problem: I thought this list was for improving RFC 2376 following on from Murata-san's original list of problems. But Frank B and Larry M are saying that the pressing problem is in fact how to make RFC 2376 handle XHTML. That means widening the scope of discussion from the simple XML-specific categories of * generic documents (*/xml) * application-specific documents (application/*) * application-specific documents with fallback/manageability (application/xml[-.]*) because XHTML does not fit in any of those categories. Instead its category is * application-specific framework documents with application-specific extensions and possibly some embedded generic bits (e.g., XHTML with MathML and "XML Data Islands") (N.b. I am using application-specific to mean that the nominal target application of the document has functionality hardwired to the element type names; a generic applicaton is one in which uses stylesheets and scripts.) I wasn't suggesting that we avoid this topic, merely that we should avoid the multipart packaging issue. There is supposed to be a W3C working group on packaging (according to appendix B of the Fragment Interchange spec.): I wonder what their requirements are? Rick Jelliffe From owner-ietf-xml-mime Tue May 11 08:12:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26373 for ietf-xml-mime-bks; Tue, 11 May 1999 08:12:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26369 for ; Tue, 11 May 1999 08:12:47 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JB2A53Y4S08WXQ88@INNOSOFT.COM> for ietf-xml-mime@imc.org; Tue, 11 May 1999 08:14:32 PDT Date: Tue, 11 May 1999 07:58:00 -0700 (PDT) From: Ned Freed Subject: Re: Negotiated Content Delivery: Maxmimizing Information In-reply-to: "Your message dated Tue, 11 May 1999 08:35:37 -0400" <199905111232.IAA21111@hesketh.net> To: "Simon St.Laurent" Cc: Ned Freed , ietf-xml-mime@imc.org Message-id: <01JB2BO1J8768WXQ88@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <199905091312.JAA16147@hesketh.net> <000701be992a$8c228020$15d0000d@copper.parc.xerox.com> <199905071845.OAA12631@hesketh.net> <4.2.0.37.19990509092638.01ebc9b0@mail.imc.org> <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > It has been reported that there is deployed software that has to be changed > > to deal with new top-level types (a big design botch in my opinion). This > > came up when the model top-level type was added. > > There's also the cost of writing it up and getting it standardized. It is > > likely that there would be strong objection to defining such a type (I > > certainly would object because I don't see this as being properly orthogonal to > > several of the existing top-level types). > So the practical costs are caused by 'reports' of poorly written software, > while the political costs are caused by a group of dug-in individuals on > philosophical grounds. It doesn't sound promising, but it also sounds like > the real costs are political, not caused by implementations. (We would > hope that those folks fixed their software correctly after the experience > of model, but can't count on it, of course.) Well, if comments on this list are any indicator, there appears to be close to a consensus that this isn't the way to go. The reasons people give for this fall all over the map, but people don't have to agree on why something is bad to block it. And given the feedback here coming from the subset of the community that is likely to be the most amenable to this idea, the chances of this getting approved in a wider context look bad. > > > I'm afraid that I'm unconvinced that the costs of 1 are greater than the > > > costs of 2. Are there genuine compatibility issues, or is this just > > > philosophical opposition? > > The former, according to reports we've gotten in the past. > I'd like to hear more detail on these 'reports'. As I said before, this came up in conjunction with the discussion that led up to the creation of the model top-level type, and blocked the creation of a "chemistry" top-level type. See the archives for the ietf-types list for May-June 1995 for the full story. > It's hard to base a > cost-benefit analysis on reports with no owners or details. As I noted > above, it sounds like philosophical opposition - politics - is the real > roadblock. Philosophy isn't necessarily politics. My problem with the xml top-level type proposal is that it doesn't mesh well with how existing top-level types have been done. XML could be application material, image material, audio material, model material, or even message material, and by creating a top level XML type you may break the ability people currently have to assess the broad category of something by looking at its top-level type. This is a philosophical point, but it has ongoing real-world consequences outside the purely political realm. Ned From owner-ietf-xml-mime Tue May 11 09:24:31 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29109 for ietf-xml-mime-bks; Tue, 11 May 1999 09:24:31 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29105 for ; Tue, 11 May 1999 09:24:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14046; Tue, 11 May 1999 09:26:58 -0700 (PDT) Received: from mehitabel.eng.sun.com (mehitabel.Eng.Sun.COM [129.146.82.247]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id JAA11860; Tue, 11 May 1999 09:26:39 -0700 (PDT) Received: from mehitabel by mehitabel.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01908; Tue, 11 May 1999 09:26:04 -0700 Message-Id: <199905111626.JAA01908@mehitabel.eng.sun.com> Date: Tue, 11 May 1999 09:26:03 -0700 (PDT) From: Murray Altheim Reply-To: Murray Altheim Subject: Re: Using CONNEG instead of MIME types for compound types & references To: masinter@parc.xerox.com, ricko@gate.sinica.edu.tw, bckman@ix.netcom.com Cc: ietf-xml-mime@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HW/D6dPqAJNdG+BqIClAUw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Frank Boumphrey writes: [...] > Basically if I send an XHTML file as text/html, then a browser > will send that file off to its HTML engine, and parse it as an HTML file. > > If I send the file as text/xml, then the browser will send it > of to its XML parser, and just create a parse tree. It seems to me a mistaken assumption that as the XML processor begins to parse the incoming file that it couldn't *actually read* what is happening and act accordingly. If the processor is aware of XHTML's numerous 'cookies', it could process the file correctly. There is no enforced 'XML blindness' operating here. [...] > The second problem is as Larry points out is the file with > embedded xml from different namespaces. A browser may be quite > happy to accept an XHTML file and will 'know' how to display basic > XHTML1.0, but will not know how to display mathXML or MusicXML. > Because the Namespaces can be scoped in the document, and don't > have to be in the head of the document, the browser may be well > into rendering the document before it realises that it can't > display the relevant code. It would be nice from the browsers > point of view if it had prior knowledge of the namespaces before > downloading the document, because then it could either This is one of the (pardon my French) stupidities of embedding what is essentially prolog information deep within an instance. In traditional SGML systems the benefit of having a prolog is that the engine can learn all about the document instance *before* it begins processing. This is simply poor design on the part of XML Namespaces, probably brought about by design constrains or 'market pressure'. I maintain that this is something that should be fixed in the Namespace spec, not hacked in XML. But of course that would be asking for the moon, since that spec has somehow become a Recommendation, inviolate and immutable. [...] > Others such as Murray (I hope I am not mis-interpreting him!) > have pointed out that they would like a more general solution, > because they feel that an XHTML mime type will keep XHTML off > in it's own landscape and not encourage it to join the more > general XML solution. Well, yes. And since there is a strong requirement that a solution be found for XML, if a stop-gap solution is arrived at for XHTML it will probably be *different* than XML, which would further push XHTML off into its own unique landscape. I doubt vendors would want to do both. What we need instead is a solution that *integrates* XHTML into the XML environment, both as a 'family' of valid document types and also as document types and modules mixed into instances via 'namespaces' (whatever that really means). While the latter is an enormously more complicated problem than the former, it's obvious we can't all push it off into the future very far since the world has already gone off and created many (IMO) broken solutions. As Rick has pointed out, XHTML is 'application-specific', but no more so than MathML or any other XML application that requires specialized processing not provided in a stylesheet. It also happens to be potentially the most widely used XML markup language, and a framework for creation of many others. So we all need to work together to create a solution that works for both XHTML and XML in general. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 An SGML declaration does not an i18n make. From owner-ietf-xml-mime Tue May 11 13:15:43 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA06260 for ietf-xml-mime-bks; Tue, 11 May 1999 13:15:43 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA06256 for ; Tue, 11 May 1999 13:15:42 -0700 (PDT) Received: (from ricko@localhost) by gate.sinica.edu.tw (8.9.3/8.9.3) id EAA06429; Wed, 12 May 1999 04:18:16 +0800 (CST) Date: Wed, 12 May 1999 04:18:16 +0800 (CST) From: Rick Jelliffe To: ietf-xml-mime@imc.org Subject: XHTML notation structures In-Reply-To: <199905111626.JAA01908@mehitabel.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thinking about what people are saying about XHTML, and, recasting it in XML/SGML terminology, it sounds like people want to be able to list the the notations used in a document, and to have this information available somewhere in the MIME header to figure out whether a document is acceptable. (I.e. after content negotiation) Lets invent a language for representing notation dependencies: () to group alternatives or derived type | for alternatives versions of the same resource, where the LHS is preferred and more specific to the RHS , for alternative notations useable for the same resource, where LHS is preferred to and a subclass of the RHS + for additional types, where the first one is the framework notation (e.g., text/xhtml or application/rdf ) -> for additional types, pointed to from the document, which may be overriden by content negotiation Using this, the notation structure for an XHTML document with lots of things embedded might be: (text/xhtml , text/html , text/xml , text/plain ) + ( application/mathml , text/xml ) + ( application/ms.vml , text/xml ) + ( application/x-dublincore , application/rdf , text/xml ) -> ( text/xhtml ) -> ( image/gif ) -> ( image/jpg | image/gif ) -> ( application/pdf | text/xhtml ) (Note that I do not repeat the "," alternatives) So then the issue becomes, can we derive a useful signature from these, to be used in a media type name? If not, then is some language like this appropriate, presumably to be used as a parameter? If it weren't for XHTML, I think this kind of thing would be better kept out of MIME and made part of the W3C fragments or packaging work. Rick Jelliffe From owner-ietf-xml-mime Tue May 11 13:28:32 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA06742 for ietf-xml-mime-bks; Tue, 11 May 1999 13:28:32 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA06738 for ; Tue, 11 May 1999 13:28:31 -0700 (PDT) Received: from simon (slip129-37-221-92.ny.us.ibm.net [129.37.221.92]) by hesketh.net (8.8.8/8.8.8) with SMTP id QAA07118 for ; Tue, 11 May 1999 16:30:11 -0400 Message-Id: <199905112030.QAA07118@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 11 May 1999 16:32:14 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Modest Proposal In-Reply-To: <199905111626.JAA01908@mehitabel.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Rather than continuing to kick landmines, however much I may dislike their presence, I'm putting forward something that may settle the political waters while still providing as much information as seems practical within the scope of a MIME type. All XML documents can continue to use application/xml if their designers choose. Software will be expected to figure out what exactly is contained in that XML on its own. (I'll leave the fate of text/xml to the rest of you.) If the developers of a particular XML document type want to register a specific MIME type for it, they go through the normal IETF registration process using the top-level headers that already exist. The only difference is that all document types that use XML as their base format will be suffixed '-xml'. This provides for things like: graphics/svg-xml application/xpdl-xml application/ice-xml model/x3d-xml This way, applications can know which overall category the information belongs to (graphics and model are, of course, more meaningful than application, but that's the breaks), tools like editors, browsers, agents, and search engines don't have to suffer too mightily guessing which content they can open and which should be left alone, and we can assign meaningful (well, sort of) names to XML formats, identifying them more precisely than plain old vanilla XML. In cases where content negotiation is required, other protocols can provide that support. Applications can at least get a broad feeling for the type of information being transferred from the MIME type, avoiding unnecessary negotiations for 'simple' cases. Does this seem possible? Or does it still raise flags? Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Wed May 12 03:37:34 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA11917 for ietf-xml-mime-bks; Wed, 12 May 1999 03:37:34 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA11912 for ; Wed, 12 May 1999 03:37:32 -0700 (PDT) Received: from pnc01.sinica.edu.tw ([140.109.6.221]) by gate.sinica.edu.tw (8.9.3/8.9.3) with SMTP id SAA09985 for ; Wed, 12 May 1999 18:40:09 +0800 (CST) Message-ID: <004601be9c62$5dbabdc0$dd066d8c@sinica.edu.tw> From: "Rick Jelliffe" To: References: <199905111626.JAA01908@mehitabel.eng.sun.com> Subject: FYI: XML Notation Schemas Date: Wed, 12 May 1999 18:29:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: For anyone interested, the discussion yesterday on XHTML prompted me to finish a counter-proposal to the XML Schema draft. My proposal "XML Notation Schemas" is at http://www.ascc.net/~ricko/notation.htm The relevance of the proposal to this group is that, by concentrating on notations and not on content models or namespace names, a MIME media-type signature like the one I gave yesterday could be automatcally extracted from the schema. This might help some of the XHTML issues. Rick Jelliffe Computing Centre Academia Sinica Taipei, Taiwan From owner-ietf-xml-mime Wed May 12 09:08:23 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14556 for ietf-xml-mime-bks; Wed, 12 May 1999 09:08:23 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14552 for ; Wed, 12 May 1999 09:08:21 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id MAA26913; Wed, 12 May 1999 12:11:01 -0400 Message-ID: <3739A670.B3C7AC38@w3.org> Date: Wed, 12 May 1999 11:04:00 -0500 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Simon St.Laurent" CC: ietf-xml-mime@imc.org Subject: Re: Modest Proposal References: <199905112030.QAA07118@hesketh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Simon St.Laurent" wrote: > If the developers of a particular XML document type want to register a > specific MIME type for it, they go through the normal IETF registration > process using the top-level headers that already exist. The only > difference is that all document types that use XML as their base format > will be suffixed '-xml'. > > This provides for things like: > graphics/svg-xml There isn't a "graphics" top-level type. We expect the MIME type for the SVG image format (which is, indeed, written in xml) to be image/xml. This is because it is an image format, and we need to do content negotiation. For stand-alone files, the fact that it happens to be written in xml is less important than the fact that it is an image. -- Chris From owner-ietf-xml-mime Wed May 12 09:17:05 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14654 for ietf-xml-mime-bks; Wed, 12 May 1999 09:17:05 -0700 (PDT) Received: from smtp.gatewaymail.net (root@smtp.gatewaymail.net [207.34.179.250]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14650 for ; Wed, 12 May 1999 09:17:04 -0700 (PDT) Received: from a2a00204 (a2a00204.intergate.bconnected.net [209.53.8.6]) by smtp.gatewaymail.net (8.8.7/8.8.7) with SMTP id JAA25807; Wed, 12 May 1999 09:19:40 -0700 Message-Id: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> X-Sender: tbray@pop.intergate.bc.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 May 1999 09:20:06 -0700 To: Chris Lilley , "Simon St.Laurent" From: Tim Bray Subject: Re: Modest Proposal Cc: ietf-xml-mime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:04 AM 5/12/99 -0500, Chris Lilley wrote: >We expect the MIME type for the SVG image format (which is, indeed, >written in xml) to be image/xml. > >This is because it is an image format, and we need to do content >negotiation. For stand-alone files, the fact that it happens to be >written in xml is less important than the fact that it is an image. I would have thought that the fact that it's in SVG is also more important for dispatching purposes than the fact that SVG happens to use XML syntax. Also... is this going to be the only xml-encoded image format anyone ever creates? I'm dubious about the modest proposal, but both image/svg or image/svg-xml seem much more useful than image/xml. -Tim From owner-ietf-xml-mime Wed May 12 10:08:43 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14990 for ietf-xml-mime-bks; Wed, 12 May 1999 10:08:43 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14986 for ; Wed, 12 May 1999 10:08:41 -0700 (PDT) Received: from simon (slip129-37-221-140.ny.us.ibm.net [129.37.221.140]) by hesketh.net (8.8.8/8.8.8) with SMTP id NAA10600 for ; Wed, 12 May 1999 13:11:25 -0400 Message-Id: <199905121711.NAA10600@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 12 May 1999 13:14:19 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Modest Proposal In-Reply-To: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:20 AM 5/12/99 -0700, Tim Bray wrote: >At 11:04 AM 5/12/99 -0500, Chris Lilley wrote: > >>We expect the MIME type for the SVG image format (which is, indeed, >>written in xml) to be image/xml. >> >>This is because it is an image format, and we need to do content >>negotiation. For stand-alone files, the fact that it happens to be >>written in xml is less important than the fact that it is an image. > >I would have thought that the fact that it's in SVG is also more >important for dispatching purposes than the fact that SVG happens >to use XML syntax. Also... is this going to be the only xml-encoded >image format anyone ever creates? I definitely have to agree here. I'll be very surprised if svg is the only image format ever created with XML. (And yes, it's image, not graphics. Never try to give up coffee. You get headaches and end up stupid. I'm brewing some now in what's probably a vain attempt to get my head working again.) >I'm dubious about the modest proposal, but both image/svg or image/svg-xml >seem much more useful than image/xml. At least it's a response, dubious or not. What would you (or anyone) like to change? Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Wed May 12 10:45:18 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15393 for ietf-xml-mime-bks; Wed, 12 May 1999 10:45:18 -0700 (PDT) Received: from tribble.eps.inso.com (tribble.eps.inso.com [198.112.118.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15389 for ; Wed, 12 May 1999 10:45:17 -0700 (PDT) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id NAA09513; Wed, 12 May 1999 13:42:49 -0400 (EDT) Reply-To: From: "Gavin Thomas Nicol" To: "'Tim Bray'" , "'Chris Lilley'" , "'Simon St.Laurent'" Cc: Subject: RE: Modest Proposal Date: Wed, 12 May 1999 13:44:22 -0400 Message-ID: <000501be9c9f$12330820$577670c6@eps.inso.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2212 (4.71.2419.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal In-Reply-To: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I'm dubious about the modest proposal, but both image/svg or > image/svg-xml seem much more useful than image/xml. Chris almost surely meant image/svg... From owner-ietf-xml-mime Wed May 12 13:15:15 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16424 for ietf-xml-mime-bks; Wed, 12 May 1999 13:15:15 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16419 for ; Wed, 12 May 1999 13:15:13 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id PAA10447; Wed, 12 May 1999 15:17:49 -0500 Message-ID: <3739E1F8.AB9F712A@themacs.com> Date: Wed, 12 May 1999 15:18:00 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Jelliffe CC: ietf-xml-mime@imc.org Subject: Re: XHTML notation structures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Rick Jelliffe wrote: > > Thinking about what people are saying about XHTML, and, recasting it in > XML/SGML terminology, it sounds like people want to be able to list the > the notations used in a document, and to have this information available > somewhere in the MIME header to figure out whether a document is > acceptable. (I.e. after content negotiation) Ummm... There might be some people that want to do that. That's not our current strategy. Our current strategy is to declare a "profile" somehow (e.g. in an attribute on the root element, as a parameter to a media type, a header in an HTTP GET request from a client, ...) We expect that documents will want to announce their requirements as you have described, and also that clients will be required to announce their capabilities. The purpose of this is to enable smarter servers/proxy servers, content translation and transcoding, etc. The profile name, likely a URI, can be viewed opaquely or retrieved and examined. Well known profiles will most likely be viewed opaquely, and less well known profiles will need to be (automatically and mechanically) examined to help ascertain the capabilities of the client or the requirements of a resource. > If it weren't for XHTML, I think this kind of thing would be better kept > out of MIME and made part of the W3C fragments or packaging work. Well, I cannot speak for the XHTML working group, but I also think this level of detail should be kept out of the media type. We just want to present this information in an ancillary way so that clients/servers/proxies that are instrumented to take advantage of it can do so. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Wed May 12 14:18:04 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17011 for ietf-xml-mime-bks; Wed, 12 May 1999 14:18:04 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17007 for ; Wed, 12 May 1999 14:18:03 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id RAA14885; Wed, 12 May 1999 17:20:45 -0400 Message-ID: <3739EF23.1055D76D@w3.org> Date: Wed, 12 May 1999 16:14:11 -0500 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gtn@eps.inso.com CC: "'Tim Bray'" , "'Simon St.Laurent'" , ietf-xml-mime@imc.org Subject: Re: Modest Proposal References: <000501be9c9f$12330820$577670c6@eps.inso.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Gavin Thomas Nicol wrote: > > > I'm dubious about the modest proposal, but both image/svg or > > image/svg-xml seem much more useful than image/xml. > > Chris almost surely meant image/svg... Yes, I did. -- Chris From owner-ietf-xml-mime Wed May 12 14:17:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16997 for ietf-xml-mime-bks; Wed, 12 May 1999 14:17:17 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16992 for ; Wed, 12 May 1999 14:17:15 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id RAA14866; Wed, 12 May 1999 17:19:48 -0400 Message-ID: <3739EEEA.3C36A6E3@w3.org> Date: Wed, 12 May 1999 16:13:14 -0500 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Bray CC: "Simon St.Laurent" , ietf-xml-mime@imc.org Subject: Re: Modest Proposal References: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tim Bray wrote: > > At 11:04 AM 5/12/99 -0500, Chris Lilley wrote: > > >We expect the MIME type for the SVG image format (which is, indeed, > >written in xml) to be image/xml. Duh. Sorry to everyone for being confusing. I meant to type "image/svg" but obviously was thinking of too many things at once. > >This is because it is an image format, and we need to do content > >negotiation. For stand-alone files, the fact that it happens to be > >written in xml is less important than the fact that it is an image. > > I would have thought that the fact that it's in SVG is also more > important for dispatching purposes than the fact that SVG happens > to use XML syntax. ;-) yes. > I'm dubious about the modest proposal, but both image/svg or image/svg-xml > seem much more useful than image/xml. -Tim Yes, I agree. And I don't see the value of image/svg-xml, since there is not likely to be a different, non-xml, svg. -- Chris From owner-ietf-xml-mime Wed May 12 14:39:51 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17146 for ietf-xml-mime-bks; Wed, 12 May 1999 14:39:51 -0700 (PDT) Received: from spm.themacs.com (spm.themacs.com [209.98.204.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17142 for ; Wed, 12 May 1999 14:39:49 -0700 (PDT) Received: from themacs.com (spmdesktop.themacs.com [209.98.204.131]) by spm.themacs.com (8.8.5/8.8.5) with ESMTP id QAA10938; Wed, 12 May 1999 16:42:23 -0500 Message-ID: <3739F5CA.82FC5DAC@themacs.com> Date: Wed, 12 May 1999 16:42:34 -0500 From: "Shane P. McCarron" Reply-To: shane@themacs.com Organization: MACS, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Lilley CC: Tim Bray , "Simon St.Laurent" , ietf-xml-mime@imc.org Subject: Re: Modest Proposal References: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> <3739EEEA.3C36A6E3@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > I'm dubious about the modest proposal, but both image/svg or image/svg-xml > > seem much more useful than image/xml. -Tim > > Yes, I agree. And I don't see the value of image/svg-xml, since there is > not likely to be a different, non-xml, svg. I think that the benefit is to user agents that don't already know what SVG is. When presented with a resource of type image/svg they need to punt. If the resource was image/svg-xml it would be clear at least that it could be parsed as XML, even if rendition would be somewhat useless. I don't think this is useful, but I think that was the intent of the original proposal. -- Shane P. McCarron phone: +1 612 434-4431 Testing Research Manager fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@themacs.com OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. From owner-ietf-xml-mime Wed May 12 14:56:12 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17252 for ietf-xml-mime-bks; Wed, 12 May 1999 14:56:12 -0700 (PDT) Received: from tux.w3.org (root@tux.w3.org [18.29.0.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17247 for ; Wed, 12 May 1999 14:56:11 -0700 (PDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id RAA17228; Wed, 12 May 1999 17:58:34 -0400 Message-ID: <3739F7FF.D9D38343@w3.org> Date: Wed, 12 May 1999 16:51:59 -0500 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ned Freed CC: Rick Jelliffe , ietf-xml-mime@imc.org Subject: Re: Negotiated Content Delivery: Maxmimizing Information References: <01JB0ZVBH65K8WXB3T@INNOSOFT.COM> <01JB14BCPK7K8WXISK@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Ned Freed wrote: > And insofar as the W3C is concerned, my understanding is that they don't > want to act as a registration authority for XML types. This is correct. > I haven't heard any > other organizations suggested that would be appropriate for this job. Oasis has been suggested. > > And if you assume that the W3C wanted its own tree where its own rules > would apply, it would be silly to restrict it to XML. As such, you'd likely > end up with a "w3c." facet. Yes. That might make sense; for example, where the defining document was a W3C Recommendation rather than an IETF RFC. -- Chris From owner-ietf-xml-mime Wed May 12 17:07:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17889 for ietf-xml-mime-bks; Wed, 12 May 1999 17:07:35 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA17885 for ; Wed, 12 May 1999 17:07:33 -0700 (PDT) Received: from simon (slip129-37-221-195.ny.us.ibm.net [129.37.221.195]) by hesketh.net (8.8.8/8.8.8) with SMTP id UAA25976 for ; Wed, 12 May 1999 20:10:20 -0400 Message-Id: <199905130010.UAA25976@hesketh.net> X-Sender: simonstl@207.211.141.31 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 12 May 1999 20:13:27 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Modest Proposal In-Reply-To: <3739F5CA.82FC5DAC@themacs.com> References: <3.0.32.19990512092003.01231010@pop.intergate.bc.ca> <3739EEEA.3C36A6E3@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 04:42 PM 5/12/99 -0500, Shane P. McCarron wrote: >[Tim Bray] >> > I'm dubious about the modest proposal, but both image/svg or image/svg-xml >> > seem much more useful than image/xml. -Tim > >[Chris Lilley] >> Yes, I agree. And I don't see the value of image/svg-xml, since there is >> not likely to be a different, non-xml, svg. > >I think that the benefit is to user agents that don't already know what >SVG is. When presented with a resource of type image/svg they need to >punt. If the resource was image/svg-xml it would be clear at least that >it could be parsed as XML, even if rendition would be somewhat useless. > >I don't think this is useful, but I think that was the intent of the >original proposal. Well, actually, since SVG has text elements[1], there's plenty of potentially useful information in those that an XML-aware search engine could use to identify the file as relevant to a particular topic. image/svg-xml would have the benefit of making it obvious to such programs that there is some chance that they can read and meaningfully process that information. It would also make it clear that the information in an SVG file could be edited in a generic XML editor. If you don't have a custom-to-SVG editor around, that capability could be important. I'd call it very useful. Talk about a revolution! Graphics with text you can reliably index, and using generic tools at that! [1] - http://www.w3.org/TR/1999/WD-SVG-19990412/text.html Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com From owner-ietf-xml-mime Wed May 12 17:13:53 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17916 for ietf-xml-mime-bks; Wed, 12 May 1999 17:13:53 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA17912 for ; Wed, 12 May 1999 17:13:52 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JB48RDN1SG8WXS9K@INNOSOFT.COM> for ietf-xml-mime@imc.org; Wed, 12 May 1999 17:15:34 PDT Date: Wed, 12 May 1999 17:14:29 -0700 (PDT) From: Ned Freed Subject: Re: Modest Proposal In-reply-to: "Your message dated Tue, 11 May 1999 16:32:14 -0400" <199905112030.QAA07118@hesketh.net> To: "Simon St.Laurent" Cc: ietf-xml-mime@imc.org Message-id: <01JB48V5NETS8WXS9K@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <199905111626.JAA01908@mehitabel.eng.sun.com> Sender: owner-ietf-xml-mime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Rather than continuing to kick landmines, however much I may dislike their > presence, I'm putting forward something that may settle the political > waters while still providing as much information as seems practical within > the scope of a MIME type. > All XML documents can continue to use application/xml if their designers > choose. Software will be expected to figure out what exactly is contained > in that XML on its own. (I'll leave the fate of text/xml to the rest of you.) > If the developers of a particular XML document type want to register a > specific MIME type for it, they go through the normal IETF registration > process using the top-level headers that already exist. The only > difference is that all document types that use XML as their base format > will be suffixed '-xml'. > This provides for things like: > graphics/svg-xml > application/xpdl-xml > application/ice-xml > model/x3d-xml > This way, applications can know which overall category the information > belongs to (graphics and model are, of course, more meaningful than > application, but that's the breaks), tools like editors, browsers, agents, > and search engines don't have to suffer too mightily guessing which content > they can ope