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: