Received: by ns.secondary.com (8.9.3/8.9.3) id VAA19880 for ietf-xml-mime-bks; Fri, 29 Sep 2000 21:18:28 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19876 for ; Fri, 29 Sep 2000 21:18:27 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.194]) by prserv.net (out1) with SMTP id <20000930042156252014qooce>; Sat, 30 Sep 2000 04:21:56 +0000 To: ietf-xml-mime@imc.org Subject: Re: Conformance value of "+xml"? In-Reply-To: <39D207BF.44699835@canada.sun.com> References: <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> <4.3.2.7.2.20000926112809.02305a10@pop.intergate.ca> <39D207BF.44699835@canada.sun.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000930132206G.muraw3c@attglobal.net> Date: Sat, 30 Sep 2000 13:22:06 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am happy to to see discussion about XPointer and media types, and encourage it. Nevertheless, I believe that there are no problems in promoting the latest I-D to an RFC. Since XPointer is not a W3C recommendation but rather a candidate recommendation, the latest I-D merely mentions it and does NOT reference it in a normative manner. After publication of a proposed standard, XPointer and SVG will probably be promoted to W3C recommendations. I hope to incorporate necessary changes when we publish another RFC for XML media types. Cheers, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15530 for ietf-xml-mime-bks; Fri, 29 Sep 2000 17:55:52 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15526 for ; Fri, 29 Sep 2000 17:55:51 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10782; Fri, 29 Sep 2000 20:59:22 -0400 Message-ID: <39D53AE8.B1E5DF1A@w3.org> Date: Sat, 30 Sep 2000 02:59:20 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Simon St.Laurent" CC: Lloyd Rutledge , ietf-xml-mime@imc.org, symm@w3.org Subject: Re: References: <200009271516.RAA05004@mast.cwi.nl> <200009292241.SAA09790@hesketh.net> <200009300048.UAA15380@hesketh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Simon St.Laurent" wrote: > > At 01:33 AM 9/30/00 +0200, Chris Lilley wrote: > >> Used in a query string, XPointers could be processed by the server, > > > >they could be, but then they wouldn't be fragment identifiers. besides, > >that s what the XML Query WG is cooking up, right? > > I'm not sure why you feel they wouldn't be fragment identifiers. I am using the term fragment identifiers in the sense it is used in the UROI specifications. If you mean some other, more general usage then that might be correct depending on your definition. > I strongly hope that the XML Query WG doesn't feel compelled to reinvent > this particular wheel or worse, create a syntax that bars the reuse of > XPointers for this work. My understanding is that their work builds on XPointer. -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15327 for ietf-xml-mime-bks; Fri, 29 Sep 2000 17:44:30 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15323 for ; Fri, 29 Sep 2000 17:44:25 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id UAA15380; Fri, 29 Sep 2000 20:48:01 -0400 Message-Id: <200009300048.UAA15380@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 29 Sep 2000 20:51:19 -0400 To: Chris Lilley From: "Simon St.Laurent" Subject: Re: Cc: Lloyd Rutledge , ietf-xml-mime@imc.org, symm@w3.org In-Reply-To: <39D526D9.24436369@w3.org> References: <200009271516.RAA05004@mast.cwi.nl> <200009292241.SAA09790@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:33 AM 9/30/00 +0200, Chris Lilley wrote: >> Used in a query string, XPointers could be processed by the server, > >they could be, but then they wouldn't be fragment identifiers. besides, >that s what the XML Query WG is cooking up, right? I'm not sure why you feel they wouldn't be fragment identifiers. I strongly hope that the XML Query WG doesn't feel compelled to reinvent this particular wheel or worse, create a syntax that bars the reuse of XPointers for this work. I'd hate to have to learn two different sets of rules for identifying parts of documents... >> >Yes, and then the client locates the relevant part of this resource using >> >the fragment identifier. >> >> In some cases, that's great, but in others it's a giant waste of network >> resources. > >Which is why we have both ? and # Yep. And let's try to let the two options work together, rather than as totally different universes. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id QAA14613 for ietf-xml-mime-bks; Fri, 29 Sep 2000 16:30:18 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA14609 for ; Fri, 29 Sep 2000 16:30:17 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA05058; Fri, 29 Sep 2000 19:33:47 -0400 Message-ID: <39D526D9.24436369@w3.org> Date: Sat, 30 Sep 2000 01:33:45 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Simon St.Laurent" CC: Lloyd Rutledge , ietf-xml-mime@imc.org, symm@w3.org Subject: Re: References: <200009271516.RAA05004@mast.cwi.nl> <200009292241.SAA09790@hesketh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Simon St.Laurent" wrote: > > At 12:38 AM 9/30/00 +0200, Chris Lilley wrote: > >> but servers process XPointer, > >> not clients -- right?. > > > >No. > > Used in a query string, XPointers could be processed by the server, they could be, but then they wouldn't be fragment identifiers. besides, that s what the XML Query WG is cooking up, right? > resulting in much less network overhead. It's a cheap form of querying, > but there do seem to be a lot of people interested in such activity. I agree lots of people are interested. Nothing against queries. > >Yes, and then the client locates the relevant part of this resource using > >the fragment identifier. > > In some cases, that's great, but in others it's a giant waste of network > resources. Which is why we have both ? and # -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13583 for ietf-xml-mime-bks; Fri, 29 Sep 2000 15:37:42 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13579 for ; Fri, 29 Sep 2000 15:37:41 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id SAA09790; Fri, 29 Sep 2000 18:41:06 -0400 Message-Id: <200009292241.SAA09790@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 29 Sep 2000 18:44:24 -0400 To: Chris Lilley , Lloyd Rutledge From: "Simon St.Laurent" Subject: Re: Cc: ietf-xml-mime@imc.org, symm@w3.org In-Reply-To: <39D519EC.D648F2E@w3.org> References: <200009271516.RAA05004@mast.cwi.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:38 AM 9/30/00 +0200, Chris Lilley wrote: >> but servers process XPointer, >> not clients -- right?. > >No. Used in a query string, XPointers could be processed by the server, resulting in much less network overhead. It's a cheap form of querying, but there do seem to be a lot of people interested in such activity. >> the >> server processes it and returns the located data to the client. > >Yes, and then the client locates the relevant part of this resource using >the fragment identifier. In some cases, that's great, but in others it's a giant waste of network resources. Good for the networking companies, though! Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13528 for ietf-xml-mime-bks; Fri, 29 Sep 2000 15:35:13 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13524 for ; Fri, 29 Sep 2000 15:35:10 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA32006; Fri, 29 Sep 2000 18:38:38 -0400 Message-ID: <39D519EC.D648F2E@w3.org> Date: Sat, 30 Sep 2000 00:38:36 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Lloyd Rutledge CC: ietf-xml-mime@imc.org, simonstl@simonstl.com, symm@w3.org Subject: Re: References: <200009271516.RAA05004@mast.cwi.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lloyd Rutledge wrote: > The reason that the SMIL 2.0 spec does not require that > browsers process XPointer is that browsers don't and can't process > XPointer -- servers do. Please correct me if my understanding of the > general architecture is too primitive, OK. Your understanding is not correct. Servers do not process the fragment identifiers, because therse are not sent to the server (queries, following a ? character, *are* sent to the server and perhaps that is what you are thinking of?) > but servers process XPointer, > not clients -- right?. No. > Clients send URI's to the given server, yes. The fragment is not part of the URI and is not sent > the > server processes it and returns the located data to the client. Yes, and then the client locates the relevant part of this resource using the fragment identifier. -- Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25912 for ietf-xml-mime-bks; Wed, 27 Sep 2000 08:13:38 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25902 for ; Wed, 27 Sep 2000 08:13:36 -0700 (PDT) Received: from mast.cwi.nl (mast.cwi.nl [192.16.196.89]) by hera.cwi.nl with ESMTP id RAA14196 for ; Wed, 27 Sep 2000 17:16:25 +0200 (MET DST) Received: from spruit.cwi.nl (IDENT:lloyd@spruit.cwi.nl [192.16.196.101]) by mast.cwi.nl (8.9.3/8.9.3/FLW-3.11M) with ESMTP id RAA05004; Wed, 27 Sep 2000 17:16:21 +0200 Message-Id: <200009271516.RAA05004@mast.cwi.nl> To: ietf-xml-mime@imc.org, simonstl@simonstl.com cc: symm@w3.org Date: Wed, 27 Sep 2000 17:16:21 +0200 From: Lloyd Rutledge Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 26 Sep 2000 11:29:50 -0400, Simon St.Laurent wrote [1] > At 09:59 AM 9/26/00 -0400, Mark Baker wrote: > >My understanding from Dan was that the cat's already out of the bag; SVG > >uses +xml. > > On fragment identifiers, SVG, SMIL, and XHTML all have potential problems. > > I'm even more concerned that there are a lot of XML applications out there > which haven't considered the problem at all - it's not something that comes > up as a question in XML tutorials that I've seen. (I'll be adding it to > future editions, believe me.) > > On the other hand, I'm not sure that the problem is quite as drastic as it > seems. Any XML application can point into an SVG, SMIL, or XHTML document > using XPointer. It's just that SVG, SMIL, and XHTML applications may not > let those documents point _out_ using XPointer. > > While I'd like to say across the board that EVERYONE should use XPointer in > all its glory when they use XML, it's awfully hard to push that when the > W3C hasn't made that case across the board. > > It's hard to push it while we still have language like this [1]: > > >XPointer [XPTR] allows components of XML documents to be addressed > >in terms of their placement in the XML structure rather than on > >their unique identifiers. This allows referencing of any portion > >of an XML document without having to modify that document. Without > >XPointer, pointing within a document may require adding unique > >identifiers to it, or inserting specific elements into the document, > >such as a named anchor in HTML. XPointers are put within the fragment > >identifier part of a URI [URI]. The SMIL 2.0 specification does not > >require that browsers be able to process XPointers in SMIL 2.0 URI > >attributes. > > [1] - > http://www.w3.org/TR/smil20/extended-linking.html#SMILLinking-Relationship-t > o-XPointer > > Simon St.Laurent > XML Elements of Style / XML: A Primer, 2nd Ed. > XHTML: Migrating Toward XML > http://www.simonstl.com - XML essays and books The above text from the SMIL spec is not meant to demean XPointer, it is there to discourage misconceptions about its potential relation with SMIL. The reason that the SMIL 2.0 spec does not require that browsers process XPointer is that browsers don't and can't process XPointer -- servers do. Please correct me if my understanding of the general architecture is too primitive, but servers process XPointer, not clients -- right?. Clients send URI's to the given server, the server processes it and returns the located data to the client. Since browsers are clients, they don't process XPointer, they just package up much of the URI string and send it out, and wait for the response. Keep in mind that SMIL does not require the use of any format other than SMIL, even though it is completely dependent on other formats. SMIL is an integration language: it contains locations of media objects and descriptions of how these are combined to make a multimedia presentation. The formats of these media objects is not specified for SMIL. Authors in SMIL choose formats for their integrated media that they can determine receives substantial support in SMIL browsers. It's a free-market integration format, and that's the best way to go about it. Similarly, authors will also choose locations format like XPointer in SMIL if there there are servers that process it and return useful media data. Authors are completely able to use XPointer in SMIL presentations, and nothing in the current spec inhibits this. Some SMIL attributes take URI's, primarily to locate media, and URI's these days can contain XPointer. The ability of browsers to process presentations with XPointer depends not on their processing XPointer, since that's done by servers, but their ability to process the media these servers return and to integrate it into the presentation. Authors will choose to use XPointer in SMIL presentations if there are XPointer servers at the URI's giving media they need, and if the SMIL browsers can processes the non-XPointer media data that is returned. I believe what's written above applies to HTML, and perhaps to SVG as well. Nonetheless, XPointer is certainly a specified and required part of SMIL. SMIL uses XPointer values in certain attributes for internal SMIL-to-SMIL communication, such as specifying endpoints of links and synchronization relationships. -Lloyd [1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00583.html -- Lloyd Rutledge vox: +31 20 592 41 27 fax: +31 20 592 41 99 CWI net: Lloyd.Rutledge@cwi.nl Web: http://www.cwi.nl/~lloyd Post: PO Box 94079 | NL-1090 GB Amsterdam | The Netherlands Street: Kruislaan 413 | NL-1098 SJ Amsterdam | The Netherlands Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24785 for ietf-xml-mime-bks; Wed, 27 Sep 2000 07:31:21 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24781 for ; Wed, 27 Sep 2000 07:31:20 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28270 for ; Wed, 27 Sep 2000 07:34:38 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA16997 for ; Wed, 27 Sep 2000 10:34:34 -0400 (EDT) Message-ID: <39D207BF.44699835@canada.sun.com> Date: Wed, 27 Sep 2000 10:44:15 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Conformance value of "+xml"? References: <39D0ABBF.1AA4C5EB@canada.sun.com> <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> <4.3.2.7.2.20000926112809.02305a10@pop.intergate.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim Bray wrote: > Right. I think that the +xml idiom is useful even if it doesn't guarantee > that such documents are going use XLink/XPointer for outgoing links. Right. I hadn't considered outgoing links, but I don't believe them relevant to this discussion. Only the processor of the document that is referenced should care. > Hmm, it also seems that anything that's of type *+xml has, per definition, > internal structures which can be addressed by xpointer whether the > media-type designers foresaw that or not. -Tim Well, you're right if you're talking about doing this all by hand, outside the context of an architecture, i.e. if you just pass (however you want to do it) an SVG document to an XML processor that supports XPointer, then you can address that SVG with XPointer. No problem. The issue is, in the context of MIME dispatch, what can the *dispatched* processor be guaranteed to interpret for us. >From RFC 2396, 4.1; The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. Which means that if a processor is dispatched to handle a particular media type, then it is the registration of that media type that defines the normative syntax to be used to reference its internal structure via that processor. In other words, there's no guarantee that the processor can interpret XPointer fragment identifiers. If you want to use the knowledge that the media type ends with "+xml" to dispatch to a {text|application}/xml processor instead, then that will give you XPointer (though draft-murata-xml references it non-normatively, due to the scheduling problem I assume). But a content author is now SOL in terms of being able to guarantee that there's any further dispatch to the SVG processor (see draft-murata-xml section 3, last paragraph), so the image may not get displayed. MB Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA08174 for ietf-xml-mime-bks; Tue, 26 Sep 2000 20:25:01 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08169 for ; Tue, 26 Sep 2000 20:24:59 -0700 (PDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id MAA06534; Wed, 27 Sep 2000 12:28:03 +0900 (JST) Message-Id: <4.2.0.58.J.20000927111059.00ccae70@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 27 Sep 2000 11:22:04 +0900 To: "Eve L. Maler" From: "Martin J. Duerst" Subject: Re: XPointer scheme names (was Re: Conformance value of "+xml"?) Cc: Chris Lilley , Dan Kohn , ietf-xml-mime@imc.org, Mark Baker , Daniel.Veillard@w3.org In-Reply-To: <4.3.2.7.2.20000926103818.00aba6b0@abnaki.east.sun.com> References: <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> <39CF6986.971D7449@w3.org> <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 00/09/26 10:50 -0400, Eve L. Maler wrote: >At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote: >>XPointer, at http://www.w3.org/TR/xptr#schemes, says how >>such extensions can happen. I think the RFC should make sure >>that it references that part or is otherwise in sync with it. >> >>So what I would like to see here is some text that says that >>any registrations must use a subset of the XPointer syntax. >> >>For new applications, that means that if they need an xpointer >>scheme not currently in the xpointer TR, they have to make sure >>it gets registered by getting added to the XPointer errata document. > >I like the idea of defining subsets of XPointer for the fragment >identifiers into their XML-based languages. However, I'm not crazy about >having to modify XPointer through errata every time. We were required to >remove the "arbitrary scheme" functionality in XPointer in order to avoid >a situation where designers choose conflicting scheme names; the note >about "errata" that's in there now is just because we weren't sure how we >were going to get out of this mess, and we wanted to keep people informed. Okay, so the XPointer errata are a hook to whatever may happen in the future, rather than the actual location of a registry. I think that makes sense. >Murata Makoto has since pointed out to me that we simply need to rely on >the system of IETF media type registration documents to avoid this. I think that works very well is a given media type wants to define a subset of the xpointer scheme, for example. >In this manner, SVG could perhaps define its fragment identifier language >to be a "subset" of XPointer that consists of an svg(...) scheme plus a >few things from the xpointer(...) scheme. No one else could choose "svg" >as a scheme name and get away with it. I'm not sure that the IETF media type registry is very efficient for this. If somebody has a new idea for an XPointer scheme foo(), they would have to search through all registered types (not only the +xml types, because as far as I understand, there is no MUST to register an xml type with +xml). That's really a lot. On the other hand, I think that the list of XPointer schemes should be kept very small, and that it will stay very small. For example, SVG doesn't define an svg() scheme. The most obvious candidates are for temporal and spacial identification for audio, video, and graphics. Because of this small number, I think it would be very good to actually maintain a list of pointers (e.g. in the XPoiter errata or in a document pointed to from there), whereas the actual definition of a new scheme could be in the IETF media types registry or in the spec of a document type referenced from there. >>The registration should then document which part of XPointer it >>supports. >> >>For interoperability, this means that any +xml type will support >>a subset of XPointer as a fragment identifier. Some may only support >>the bare # syntax, some may add #xpointer(id()) >>as SVG did, some may support the full xpointer scheme, some may >>support some other scheme (e.g. a temporal scheme for audio or video,...). >>The interoperability guarantee that this gives is that it is not possible >>to construct a fragment identifier that means one thing for one type >>and another thing for another type. Either it means something for >>a given type, or it's not understood for that given type. >> >>I'm not sure I'm happy with this; defining a minimum that every >>+xml type has to support would be very desirable in my eyes. >>That's one of the ideas behind the +xml suffix, isn't it. >>So how should this minimum look like? > >Does a document such as draft-murata-xml-0[78] have the "right" to define >such a minimum? If so, I'd be very interested to hear what people think >it should contain. It defines the +xml convention, and therefore can say what a document type has to do to fit this convention. Regards, Martin. Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25917 for ietf-xml-mime-bks; Tue, 26 Sep 2000 11:28:22 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25913 for ; Tue, 26 Sep 2000 11:28:20 -0700 (PDT) Received: from rune.antarcti.ca (dyn205.dev.antarcti.ca [10.1.1.205]) by mail.dev.antarcti.ca (Postfix) with ESMTP id DDBBE103D9; Tue, 26 Sep 2000 11:31:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20000926112809.02305a10@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 11:30:53 -0700 To: "Simon St.Laurent" , ietf-xml-mime@imc.org From: Tim Bray Subject: Re: Conformance value of "+xml"? In-Reply-To: <200009261526.LAA14289@hesketh.net> References: <39D0ABBF.1AA4C5EB@canada.sun.com> <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:29 AM 26/09/00 -0400, Simon St.Laurent wrote: >At 09:59 AM 9/26/00 -0400, Mark Baker wrote: >>My understanding from Dan was that the cat's already out of the bag; SVG >>uses +xml. Not quite yet, but as Chris says, probably will. >On the other hand, I'm not sure that the problem is quite as drastic as it >seems. Any XML application can point into an SVG, SMIL, or XHTML document >using XPointer. It's just that SVG, SMIL, and XHTML applications may not >let those documents point _out_ using XPointer. Right. I think that the +xml idiom is useful even if it doesn't guarantee that such documents are going use XLink/XPointer for outgoing links. Hmm, it also seems that anything that's of type *+xml has, per definition, internal structures which can be addressed by xpointer whether the media-type designers foresaw that or not. -Tim Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA24700 for ietf-xml-mime-bks; Tue, 26 Sep 2000 10:15:17 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24696 for ; Tue, 26 Sep 2000 10:15:15 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09854; Tue, 26 Sep 2000 10:18:30 -0700 (PDT) Received: from suneast.East.Sun.COM (suneast.East.Sun.COM [129.148.9.3]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23452; Tue, 26 Sep 2000 10:50:48 -0400 (EDT) Received: from abnaki.East.Sun.COM (abnaki [129.148.171.26]) by suneast.East.Sun.COM (8.9.3+Sun/8.8.8) with SMTP id KAA14891; Tue, 26 Sep 2000 10:50:48 -0400 (EDT) Received: from flame-pc.east.sun.com by abnaki.East.Sun.COM (SMI-8.6/SMI-SVR4) id KAA17771; Tue, 26 Sep 2000 10:50:46 -0400 Message-Id: <4.3.2.7.2.20000926103818.00aba6b0@abnaki.east.sun.com> X-Sender: elm@abnaki.east.sun.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 10:50:07 -0400 To: "Martin J. Duerst" From: "Eve L. Maler" Subject: XPointer scheme names (was Re: Conformance value of "+xml"?) Cc: Chris Lilley , Dan Kohn , ietf-xml-mime@imc.org, Mark Baker , Daniel.Veillard@w3.org In-Reply-To: <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> References: <39CF6986.971D7449@w3.org> <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote: >At 00/09/25 17:04 +0200, Chris Lilley wrote: >> > For the fifth paragraph I'd recommend changing the wording to reflect >> > that for fragment identifiers at least, registrations are free to >> > *extend* the syntax, but must at least support the XML syntax; >> >>In the case of SVG, since there seemed to be little prior experience with >>the full complexities of XPoinbter, SVG supports a subset of the syntax. So >>the uses in an SVG instance will all conform to the XPointer spec, but the >>converse is not true - not all valid XPointers are guaranteed to be >>processd by SVG-aware user agents. > >XPointer, at http://www.w3.org/TR/xptr#schemes, says how >such extensions can happen. I think the RFC should make sure >that it references that part or is otherwise in sync with it. > >So what I would like to see here is some text that says that >any registrations must use a subset of the XPointer syntax. > >For new applications, that means that if they need an xpointer >scheme not currently in the xpointer TR, they have to make sure >it gets registered by getting added to the XPointer errata document. I like the idea of defining subsets of XPointer for the fragment identifiers into their XML-based languages. However, I'm not crazy about having to modify XPointer through errata every time. We were required to remove the "arbitrary scheme" functionality in XPointer in order to avoid a situation where designers choose conflicting scheme names; the note about "errata" that's in there now is just because we weren't sure how we were going to get out of this mess, and we wanted to keep people informed. Murata Makoto has since pointed out to me that we simply need to rely on the system of IETF media type registration documents to avoid this. In this manner, SVG could perhaps define its fragment identifier language to be a "subset" of XPointer that consists of an svg(...) scheme plus a few things from the xpointer(...) scheme. No one else could choose "svg" as a scheme name and get away with it. Does this make sense to all you experts? >The registration should then document which part of XPointer it >supports. > >For interoperability, this means that any +xml type will support >a subset of XPointer as a fragment identifier. Some may only support >the bare # syntax, some may add #xpointer(id()) >as SVG did, some may support the full xpointer scheme, some may >support some other scheme (e.g. a temporal scheme for audio or video,...). >The interoperability guarantee that this gives is that it is not possible >to construct a fragment identifier that means one thing for one type >and another thing for another type. Either it means something for >a given type, or it's not understood for that given type. > >I'm not sure I'm happy with this; defining a minimum that every >+xml type has to support would be very desirable in my eyes. >That's one of the ideas behind the +xml suffix, isn't it. >So how should this minimum look like? Does a document such as draft-murata-xml-0[78] have the "right" to define such a minimum? If so, I'd be very interested to hear what people think it should contain. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ east.sun.com Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24634 for ietf-xml-mime-bks; Tue, 26 Sep 2000 10:12:47 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24630 for ; Tue, 26 Sep 2000 10:12:45 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id NAA21823 for ; Tue, 26 Sep 2000 13:16:04 -0400 Message-Id: <200009261716.NAA21823@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 26 Sep 2000 13:19:18 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Conformance value of "+xml"? In-Reply-To: <39D0C7A2.751414DE@w3.org> References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> <200009261526.LAA14289@hesketh.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:58 PM 9/26/00 +0200, Chris Lilley wrote: >"Simon St.Laurent" wrote: >> On fragment identifiers, SVG, SMIL, and XHTML all have potential problems. > >Such as? Just this, which came a bit further down. >> Any XML application can point into an SVG, SMIL, or XHTML document >> using XPointer. It's just that SVG, SMIL, and XHTML applications may not >> let those documents point _out_ using XPointer. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22959 for ietf-xml-mime-bks; Tue, 26 Sep 2000 08:55:17 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22954 for ; Tue, 26 Sep 2000 08:55:15 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA22997; Tue, 26 Sep 2000 11:58:26 -0400 Message-ID: <39D0C7A2.751414DE@w3.org> Date: Tue, 26 Sep 2000 17:58:26 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Simon St.Laurent" CC: ietf-xml-mime@imc.org Subject: Re: Conformance value of "+xml"? References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> <200009261526.LAA14289@hesketh.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Simon St.Laurent" wrote: > > At 09:59 AM 9/26/00 -0400, Mark Baker wrote: > >My understanding from Dan was that the cat's already out of the bag; SVG > >uses +xml. Actually we currently use -xml which was what an earlier version of the internet draft said, and will consider switching to whatever the eventual internet standard says once it settles down. > On fragment identifiers, SVG, SMIL, and XHTML all have potential problems. Such as? > I'm even more concerned that there are a lot of XML applications out there > which haven't considered the problem at all - it's not something that comes > up as a question in XML tutorials that I've seen. (I'll be adding it to > future editions, believe me.) > > On the other hand, I'm not sure that the problem is quite as drastic as it > seems. Any XML application can point into an SVG, SMIL, or XHTML document > using XPointer. It's just that SVG, SMIL, and XHTML applications may not > let those documents point _out_ using XPointer. > > While I'd like to say across the board that EVERYONE should use XPointer in > all its glory when they use XML, it's awfully hard to push that when the > W3C hasn't made that case across the board. Yes, I share the concern. That is why SVG 1.0 uses #xptr(id(foo)) when this gives no more functionality than good old #foo - it indicates future direction, and I would expect versions of SVG greater than 1.0 to use the ful xpointer syntax. The WG didn't want to bite off fully general pointers, but didn't want to indicate that XPointer was not to be used, either. -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19955 for ietf-xml-mime-bks; Tue, 26 Sep 2000 08:23:20 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19944 for ; Tue, 26 Sep 2000 08:23:18 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id LAA14289 for ; Tue, 26 Sep 2000 11:26:37 -0400 Message-Id: <200009261526.LAA14289@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 26 Sep 2000 11:29:50 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: Conformance value of "+xml"? In-Reply-To: <39D0ABBF.1AA4C5EB@canada.sun.com> References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:59 AM 9/26/00 -0400, Mark Baker wrote: >My understanding from Dan was that the cat's already out of the bag; SVG >uses +xml. On fragment identifiers, SVG, SMIL, and XHTML all have potential problems. I'm even more concerned that there are a lot of XML applications out there which haven't considered the problem at all - it's not something that comes up as a question in XML tutorials that I've seen. (I'll be adding it to future editions, believe me.) On the other hand, I'm not sure that the problem is quite as drastic as it seems. Any XML application can point into an SVG, SMIL, or XHTML document using XPointer. It's just that SVG, SMIL, and XHTML applications may not let those documents point _out_ using XPointer. While I'd like to say across the board that EVERYONE should use XPointer in all its glory when they use XML, it's awfully hard to push that when the W3C hasn't made that case across the board. It's hard to push it while we still have language like this [1]: >XPointer [XPTR] allows components of XML documents to be addressed >in terms of their placement in the XML structure rather than on >their unique identifiers. This allows referencing of any portion >of an XML document without having to modify that document. Without >XPointer, pointing within a document may require adding unique >identifiers to it, or inserting specific elements into the document, >such as a named anchor in HTML. XPointers are put within the fragment >identifier part of a URI [URI]. The SMIL 2.0 specification does not >require that browsers be able to process XPointers in SMIL 2.0 URI >attributes. [1] - http://www.w3.org/TR/smil20/extended-linking.html#SMILLinking-Relationship-t o-XPointer Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16160 for ietf-xml-mime-bks; Tue, 26 Sep 2000 06:46:36 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16156 for ; Tue, 26 Sep 2000 06:46:34 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.6.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25729 for ; Tue, 26 Sep 2000 06:49:52 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19761 for ; Tue, 26 Sep 2000 09:49:50 -0400 (EDT) Message-ID: <39D0ABBF.1AA4C5EB@canada.sun.com> Date: Tue, 26 Sep 2000 09:59:27 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Conformance value of "+xml"? References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Martin J. Duerst" wrote: > I'm not sure I'm happy with this; defining a minimum that every > +xml type has to support would be very desirable in my eyes. > That's one of the ideas behind the +xml suffix, isn't it. > So how should this minimum look like? My understanding from Dan was that the cat's already out of the bag; SVG uses +xml. However, SVG isn't yet a W3C recommendation. According to http://www.w3.org/TR/SVG, SVG 1.0 is in CR as of August 2nd. This CR references a version of draft-murata-xml that used the "-xml" suffix, so that's what's used; http://www.w3.org/TR/SVG/intro.html#MIMEType Also, IANA shows that a MIME media type for SVG has not yet been registered. I think this means we have an opportunity to guarantee *something* about fragment identifiers. Here's some options I've come up with. Each of them has drawbacks, but hopefully those involved with SVG can weigh that against the future cost of not having a consistent fragment identifier notation on +xml media types. 1. leave the SVG MIME media type as-is with "-xml" so it user agents don't expect the rules of "+xml" to hold. I don't believe that this is a great loss for SVG because it's an image/ type, not text/ or application/ about which encoding rules are defined. Or just change it to image/svg. 2. remove that section (1.2) from the spec (as we did with XHTML 1.0, so we could add it later). 3. break out and document your subset of XPointer so that draft-murata-xml can reference it Any other options? Chris? MB Received: by ns.secondary.com (8.9.3/8.9.3) id WAA02987 for ietf-xml-mime-bks; Mon, 25 Sep 2000 22:56:12 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02983 for ; Mon, 25 Sep 2000 22:56:10 -0700 (PDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id OAA01292; Tue, 26 Sep 2000 14:58:53 +0900 (JST) Message-Id: <4.2.0.58.J.20000926141535.009ca870@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 26 Sep 2000 14:40:29 +0900 To: Chris Lilley , Dan Kohn From: "Martin J. Duerst" Subject: Re: Conformance value of "+xml"? Cc: ietf-xml-mime@imc.org, Mark Baker In-Reply-To: <39CF6986.971D7449@w3.org> References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 00/09/25 17:04 +0200, Chris Lilley wrote: > > For the fifth paragraph I'd recommend changing the wording to reflect > > that for fragment identifiers at least, registrations are free to > > *extend* the syntax, but must at least support the XML syntax; > >In the case of SVG, since there seemed to be little prior experience with >the full complexities of XPoinbter, SVG supports a subset of the syntax. So >the uses in an SVG instance will all conform to the XPointer spec, but the >converse is not true - not all valid XPointers are guaranteed to be >processd by SVG-aware user agents. XPointer, at http://www.w3.org/TR/xptr#schemes, says how such extensions can happen. I think the RFC should make sure that it references that part or is otherwise in sync with it. So what I would like to see here is some text that says that any registrations must use a subset of the XPointer syntax. For new applications, that means that if they need an xpointer scheme not currently in the xpointer TR, they have to make sure it gets registered by getting added to the XPointer errata document. The registration should then document which part of XPointer it supports. For interoperability, this means that any +xml type will support a subset of XPointer as a fragment identifier. Some may only support the bare # syntax, some may add #xpointer(id()) as SVG did, some may support the full xpointer scheme, some may support some other scheme (e.g. a temporal scheme for audio or video,...). The interoperability guarantee that this gives is that it is not possible to construct a fragment identifier that means one thing for one type and another thing for another type. Either it means something for a given type, or it's not understood for that given type. I'm not sure I'm happy with this; defining a minimum that every +xml type has to support would be very desirable in my eyes. That's one of the ideas behind the +xml suffix, isn't it. So how should this minimum look like? Regards, Martin. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14952 for ietf-xml-mime-bks; Mon, 25 Sep 2000 08:51:07 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14946 for ; Mon, 25 Sep 2000 08:51:05 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA21809; Mon, 25 Sep 2000 11:54:15 -0400 Message-ID: <39CF6986.971D7449@w3.org> Date: Mon, 25 Sep 2000 17:04:38 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Kohn CC: ietf-xml-mime@imc.org, Mark Baker Subject: Re: Conformance value of "+xml"? References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Kohn wrote: > The concern with fragment identifiers was that certain media types developed > before the XLink spec (I remember SVG being mentioned), SVG was developed concurrently with the XLink spec and is, in fact, the first W3C specification to use XLink. However, since you mention fragment identifiers, I suspect you were thinking of XPointer? SVG supports a subset of XPointer, not the ful spec. > might not confirm to > the later linking spec. If all it takes to conform to the linking spec is > to be valid XML, No, conformance to XLink requires use of the XLink spec (which SVG for example does); conformance to XPointer requires an application to conform to XPointer, and cannot be inferred from looking at the content that is being pointed into. > Let me close by quoting the RFC 2119 definitions for MUST and SHOULD, to > point out that the distance between them is really quite large. We worked > hard to only use MUST when interoperability guarantees demanded it: I think it was interoperability guarantees that Mark was looking for. However, the point about non-XML applcations MUST NOT be registered with a +xml suffix seems to at least guarantee that the message body will be a well formed XML instance. > For the fifth paragraph I'd recommend changing the wording to reflect > that for fragment identifiers at least, registrations are free to > *extend* the syntax, but must at least support the XML syntax; In the case of SVG, since there seemed to be little prior experience with the full complexities of XPoinbter, SVG supports a subset of the syntax. So the uses in an SVG instance will all conform to the XPointer spec, but the converse is not true - not all valid XPointers are guaranteed to be processd by SVG-aware user agents. -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07929 for ietf-xml-mime-bks; Thu, 21 Sep 2000 10:51:55 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07925 for ; Thu, 21 Sep 2000 10:51:54 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.3.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12165 for ; Thu, 21 Sep 2000 10:54:47 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA01244 for ; Thu, 21 Sep 2000 13:54:46 -0400 (EDT) Message-ID: <39CA4D7E.511ED2B8@canada.sun.com> Date: Thu, 21 Sep 2000 14:03:42 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Re: Conformance value of "+xml"? References: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The concern with fragment identifiers was that certain media types developed > before the XLink spec (I remember SVG being mentioned), might not confirm to > the later linking spec. If all it takes to conform to the linking spec is > to be valid XML, than by definition all +xml media types do so, so there's > no problem with the current draft. If something extra is required, than the > SHOULD language is appropriate since some media types may not do so, so > there's still no problem with the current draft. After thinking about this some more, I realized that it was fragment identifiers alone that I was concerned about. It's too bad XPointer couldn't be ready in time for this draft to reference normatively, but I accept your explanation as resolving my issue. Thanks for the clarification. MB Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA15978 for ietf-xml-mime-bks; Wed, 20 Sep 2000 23:06:07 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15974 for ; Wed, 20 Sep 2000 23:06:06 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 23:09:37 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com> From: Dan Kohn To: ietf-xml-mime@imc.org, Mark Baker Subject: RE: Conformance value of "+xml"? Date: Wed, 20 Sep 2000 23:08:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe the guarantee you are looking for is in the last sentence of the last paragraph of Section 7: The registration process for these media types is described in [RFC2048]. The registrar for the IETF tree will encourage new XML-based media type registrations in the IETF tree to follow this guideline. Registrars for other trees SHOULD follow this convention in order to ensure maximum interoperability of their XML-based documents. Similarly, media subtypes that do not represent XML entities MUST NOT be allowed to register with a '+xml' suffix. MIME types with a +xml label are XML. Stated in the negative (i.e., the contrapositive), it is violation of the spec to send +xml MIME objects that are not XML. Note though, that not all XML MIME types are required to use a +xml label (see Section A15). That is the main reason for the SHOULDs. Secondarily, certain registrations may have additional or slightly different concerns, so it didn't seem reasonable to constrain them to the identical registration language that we used. The concern with fragment identifiers was that certain media types developed before the XLink spec (I remember SVG being mentioned), might not confirm to the later linking spec. If all it takes to conform to the linking spec is to be valid XML, than by definition all +xml media types do so, so there's no problem with the current draft. If something extra is required, than the SHOULD language is appropriate since some media types may not do so, so there's still no problem with the current draft. Let me close by quoting the RFC 2119 definitions for MUST and SHOULD, to point out that the distance between them is really quite large. We worked hard to only use MUST when interoperability guarantees demanded it: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Thanks for the note on the email address, which we'll ask the IESG to fix in their note to the RFC editor, if they approve the draft when it finishes last call on 2000-09-27. - dan -- Dan Kohn -----Original Message----- From: Mark Baker [mailto:mark.baker@Canada.Sun.COM] Sent: Wednesday, 2000-09-20 11:49 To: ietf-xml-mime@imc.org Subject: Conformance value of "+xml"? Greetings, I've been writing the registration of a new media type in the HTML WG for XHTML using draft-murata-xml-0[78]. In doing this, I've come to the conclusion that the draft does not provide implementors and authors enough guarantees in order to be able to do anything more than is done today without the "+xml" convention. Before actually implementing the recommendations in this draft, I was under the impression that using or seeing a media type suffixed with "+xml" could provide me, as a user agent implementor, certain guarantees. However, because of a lack of any MUSTs in 7.1, I am not guaranteed that *any* of those things in 7.1 actually hold. It is quite possible that I could receive a document described as "text/foo+xml", yet not be able to do anything with it except fallback as text/plain. Granted, that isn't any worse than today, but if I wanted that behaviour, I don't need "+xml" to get it. Therefore, I'd like to propose the following modifications for 7.1; - first paragraph; SHOULD to MUST - second; SHOULD to MUST - forth; SHOULD to MUST For the fifth paragraph I'd recommend changing the wording to reflect that for fragment identifiers at least, registrations are free to *extend* the syntax, but must at least support the XML syntax; "These registrations SHOULD also make reference to RFC XXXX in specifying magic numbers, but MUST reference it for base URIs and use of the BOM. Fragment identifier syntax MAY be extended by the registration, but it MUST at least reference RFC XXXX. BTW, Appendix C references an incorrect email address for this list, "xml-mime-types@imc.org". MB Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04134 for ietf-xml-mime-bks; Wed, 20 Sep 2000 11:37:08 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04130 for ; Wed, 20 Sep 2000 11:37:07 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.3.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20772 for ; Wed, 20 Sep 2000 11:39:52 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA21457 for ; Wed, 20 Sep 2000 14:39:51 -0400 (EDT) Message-ID: <39C9069B.AC981E1D@canada.sun.com> Date: Wed, 20 Sep 2000 14:48:59 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Conformance value of "+xml"? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings, I've been writing the registration of a new media type in the HTML WG for XHTML using draft-murata-xml-0[78]. In doing this, I've come to the conclusion that the draft does not provide implementors and authors enough guarantees in order to be able to do anything more than is done today without the "+xml" convention. Before actually implementing the recommendations in this draft, I was under the impression that using or seeing a media type suffixed with "+xml" could provide me, as a user agent implementor, certain guarantees. However, because of a lack of any MUSTs in 7.1, I am not guaranteed that *any* of those things in 7.1 actually hold. It is quite possible that I could receive a document described as "text/foo+xml", yet not be able to do anything with it except fallback as text/plain. Granted, that isn't any worse than today, but if I wanted that behaviour, I don't need "+xml" to get it. Therefore, I'd like to propose the following modifications for 7.1; - first paragraph; SHOULD to MUST - second; SHOULD to MUST - forth; SHOULD to MUST For the fifth paragraph I'd recommend changing the wording to reflect that for fragment identifiers at least, registrations are free to *extend* the syntax, but must at least support the XML syntax; "These registrations SHOULD also make reference to RFC XXXX in specifying magic numbers, but MUST reference it for base URIs and use of the BOM. Fragment identifier syntax MAY be extended by the registration, but it MUST at least reference RFC XXXX. BTW, Appendix C references an incorrect email address for this list, "xml-mime-types@imc.org". MB Received: by ns.secondary.com (8.9.3/8.9.3) id JAA25704 for ietf-xml-mime-bks; Thu, 14 Sep 2000 09:54:16 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25700 for ; Thu, 14 Sep 2000 09:54:15 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 09:56:37 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0010597DF@tdmail2.teledesic.com> From: Dan Kohn To: "pcalhoun@eng.sun.com" Cc: roamops@tdmx.rutgers.edu, ietf-xml-mime@imc.org Subject: RE: draft-ietf-roamops-phonebook-xml-05.txt Date: Thu, 14 Sep 2000 09:56:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Given that is still in IETF last call, I do not think it is necessary to modify your draft. Instead, I would suggest an informational supplement with the registration, or just making a registration straight to IANA (as described in RFC 2048, with review on ietf-types@iana.org). - dan -- Dan Kohn -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Thursday, 2000-09-14 07:04 To: Dan Kohn Cc: roamops@tdmx.rutgers.edu; ietf-xml-mime@imc.org Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt Dan, Given that this particular document has already been through WG, IESG *and* IETF last call, how strongly do you feel about this proposed appendix? PatC > I would recommend adding an appendix to > > where you register a MIME type for a roamops phonebook based on the advice > provided in . > > It would appear that application/phonebook+xml may be a good choice. > > - dan > -- > Dan Kohn > Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23053 for ietf-xml-mime-bks; Thu, 14 Sep 2000 08:27:41 -0700 (PDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23043 for ; Thu, 14 Sep 2000 08:27:40 -0700 (PDT) Received: from gwzlaptop (ssh.cisco.com [171.69.10.34]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA23175; Thu, 14 Sep 2000 08:28:34 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "pcalhoun@eng.sun.com" , "Dan Kohn" Cc: , Subject: RE: draft-ietf-roamops-phonebook-xml-05.txt Date: Thu, 14 Sep 2000 08:26:29 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd be a little stronger -- too late, too bad, write another draft. > -----Original Message----- > From: owner-roamops@tdmx.rutgers.edu > [mailto:owner-roamops@tdmx.rutgers.edu]On Behalf Of pcalhoun@eng.sun.com > Sent: Thursday, September 14, 2000 7:04 AM > To: Dan Kohn > Cc: roamops@tdmx.rutgers.edu; ietf-xml-mime@imc.org > Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt > > > Dan, > > Given that this particular document has already been through WG, > IESG *and* > IETF last call, how strongly do you feel about this proposed appendix? > > PatC > > I would recommend adding an appendix to > > > xml-05.txt > > > where you register a MIME type for a roamops phonebook based > on the advice > > provided in > . > > > > It would appear that application/phonebook+xml may be a good choice. > > > > - dan > > -- > > Dan Kohn > > > > > Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17282 for ietf-xml-mime-bks; Thu, 14 Sep 2000 07:04:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17278 for ; Thu, 14 Sep 2000 07:04:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08794; Thu, 14 Sep 2000 08:05:49 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA00797; Thu, 14 Sep 2000 07:05:48 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27270; Thu, 14 Sep 2000 07:05:46 -0700 (PDT) Date: Thu, 14 Sep 2000 07:03:58 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: draft-ietf-roamops-phonebook-xml-05.txt To: Dan Kohn Cc: roamops@tdmx.rutgers.edu, ietf-xml-mime@imc.org In-Reply-To: "Your message with ID" <25D0C66E6D25D311B2AC0008C7913EE0010597B7@tdmail2.teledesic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Given that this particular document has already been through WG, IESG *and* IETF last call, how strongly do you feel about this proposed appendix? PatC > I would recommend adding an appendix to > > where you register a MIME type for a roamops phonebook based on the advice > provided in . > > It would appear that application/phonebook+xml may be a good choice. > > - dan > -- > Dan Kohn > Received: by ns.secondary.com (8.9.3/8.9.3) id XAA02648 for ietf-xml-mime-bks; Wed, 13 Sep 2000 23:12:09 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02644 for ; Wed, 13 Sep 2000 23:12:07 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 23:14:20 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0010597B7@tdmail2.teledesic.com> From: Dan Kohn To: roamops@tdmx.rutgers.edu Cc: ietf-xml-mime@imc.org Subject: draft-ietf-roamops-phonebook-xml-05.txt Date: Wed, 13 Sep 2000 23:14:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would recommend adding an appendix to where you register a MIME type for a roamops phonebook based on the advice provided in . It would appear that application/phonebook+xml may be a good choice. - dan -- Dan Kohn Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12858 for ietf-xml-mime-bks; Wed, 13 Sep 2000 09:13:12 -0700 (PDT) Received: from prserv.net (out5.prserv.net [32.97.166.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12854 for ; Wed, 13 Sep 2000 09:13:11 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.117]) by prserv.net (out5) with SMTP id <2000091316152120500bjaeqe>; Wed, 13 Sep 2000 16:15:22 +0000 To: ietf-xml-mime@imc.org, iesg@ietf.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard In-Reply-To: <01JTVWKHO4SK000BHR@mauve.mrochek.com> References: <20000907233037M.muraw3c@attglobal.net> <01JTVWKHO4SK000BHR@mauve.mrochek.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000914011515L.muraw3c@attglobal.net> Date: Thu, 14 Sep 2000 01:15:15 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: ned.freed@INNOSOFT.COM Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard Date: Thu, 07 Sep 2000 08:56:12 -0700 (PDT) > Sounds fine to me. Please submit an updated version of the draft. > Unfortunately, given that this is a change to requirements language I think > we'll have to restart the last call, so the sooner the better on this. After the minor modification, a new I-D has been published. Its URL is: http://www.ietf.org/internet-drafts/draft-murata-xml-08.txt The second edition of XML 1.0 is being prepared and is expected to be published in the very near future. At present, it references to RFC 2376. If the last call has to be really restarted, the second edition will probably have to continue to reference to RFC 2376. Cheers, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id AAA06876 for ietf-xml-mime-bks; Fri, 8 Sep 2000 00:04:56 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06871 for ; Fri, 8 Sep 2000 00:04:55 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 00:06:32 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0010595B0@tdmail2.teledesic.com> From: Dan Kohn To: ned.freed@INNOSOFT.COM Cc: ietf-xml-mime@imc.org, iesg@ietf.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard Date: Fri, 8 Sep 2000 00:06:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned, as you are the Area Director reviewing this spec, we (the co-authors) will defer to your judgement on the need to restart the Last Call period. For obvious reasons, we would rather skip the extra month necessary to do so. I will also note that Section 6.1.2 of RFC 2026 doesn't set any specific guidelines for what level of change does or does not require a restart of Last Call. Given that the suggested change does not affect the normal operation of the protocol (where external parsed entities are supposed to use their own MIME type), and that the issue comes down to how deal with any existing implementations that (could possibly) differ from the new spec, I would suggest that it is not a significant change. We don't actually have any examples from the wild of software or messages that would even be affected by this change. Again, however, we defer to your judgement as to whether any changes to requirements language mandates a Last Call restart. In either event, we'll be submitting the -08 draft tomorrow. - dan -- Dan Kohn -----Original Message----- From: ned.freed@INNOSOFT.COM [mailto:ned.freed@INNOSOFT.COM] Sent: Thursday, 2000-09-07 08:56 To: muraw3c@attglobal.net Cc: ietf-xml-mime@imc.org; iesg@ietf.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard > In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly > revise the latest draft (draft-murata-xml-07.txt). Dave Peterson > agreed. > > For backward compatibility, application/xml and text/xml MAY, > > but SHOULD NOT, also be used for "external parsed entities", > > "external DTD subsets", and "external parameter entities". > > I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119 > > terminology, or called for. How about: > > application/xml and text/xml MUST NOT be used for "external parsed > > entities", "external DTD subsets", and "external parameter entities". > > Note that RFC 2376 (obsoleted) allowed this usage, although > > in practice it is likely to be rare. > I spoke with my co-authors: Dan Kohn and Simon St. Laurent. We > have agreed to accept the proposed change. Sounds fine to me. Please submit an updated version of the draft. Unfortunately, given that this is a change to requirements language I think we'll have to restart the last call, so the sooner the better on this. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id WAA03691 for ietf-xml-mime-bks; Thu, 7 Sep 2000 22:01:55 -0700 (PDT) Received: from prserv.net (out5.prserv.net [32.97.166.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03687 for ; Thu, 7 Sep 2000 22:01:54 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.24]) by prserv.net (out5) with SMTP id <2000090804594620505gca0le>; Fri, 8 Sep 2000 04:59:47 +0000 To: ietf-xml-mime@imc.org, iesg@ietf.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard In-Reply-To: <01JTVWKHO4SK000BHR@mauve.mrochek.com> References: <20000907233037M.muraw3c@attglobal.net> <01JTVWKHO4SK000BHR@mauve.mrochek.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000908140214E.muraw3c@attglobal.net> Date: Fri, 08 Sep 2000 14:02:14 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned wrote: > Sounds fine to me. Please submit an updated version of the draft. I slightly changed Larry's wording, since some external parsed entities are well-formed XML documents and are also used as XML documents. application/xml and text/xml MUST NOT be used for "external DTD subsets" and "external parameter entities", and MUST NOT be used for "external parsed entities" unless they are also well-formed "document entities" and used as such. Note that RFC2376 (obsoleted) allowed this usage, although in practice it is likely to be rare. > Unfortunately, given that this is a change to requirements language I think > we'll have to restart the last call, so the sooner the better on this. I am surprised to hear that this slight change requires four week review again. But I will follow your instruction. IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21187 for ietf-xml-mime-bks; Thu, 7 Sep 2000 08:57:29 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21183 for ; Thu, 7 Sep 2000 08:57:28 -0700 (PDT) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JTVEKTKSB4000BHR@mauve.mrochek.com> for ietf-xml-mime@imc.org; Thu, 07 Sep 2000 08:58:52 -0700 (PDT) Date: Thu, 07 Sep 2000 08:56:12 -0700 (PDT) Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard In-reply-to: "Your message dated Thu, 07 Sep 2000 23:30:37 +0900 (JST)" <20000907233037M.muraw3c@attglobal.net> To: muraw3c@attglobal.net Cc: ietf-xml-mime@imc.org, iesg@ietf.org Message-id: <01JTVWKHO4SK000BHR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <25D0C66E6D25D311B2AC0008C7913EE0AE5379@tdmail2.teledesic.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly > revise the latest draft (draft-murata-xml-07.txt). Dave Peterson > agreed. > > For backward compatibility, application/xml and text/xml MAY, > > but SHOULD NOT, also be used for "external parsed entities", > > "external DTD subsets", and "external parameter entities". > > I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119 > > terminology, or called for. How about: > > application/xml and text/xml MUST NOT be used for "external parsed > > entities", "external DTD subsets", and "external parameter entities". > > Note that RFC 2376 (obsoleted) allowed this usage, although > > in practice it is likely to be rare. > I spoke with my co-authors: Dan Kohn and Simon St. Laurent. We > have agreed to accept the proposed change. Sounds fine to me. Please submit an updated version of the draft. Unfortunately, given that this is a change to requirements language I think we'll have to restart the last call, so the sooner the better on this. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15607 for ietf-xml-mime-bks; Thu, 7 Sep 2000 07:30:10 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15603 for ; Thu, 7 Sep 2000 07:30:09 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.111]) by prserv.net (out2) with SMTP id <2000090714304422900ooe2ve>; Thu, 7 Sep 2000 14:30:45 +0000 To: ietf-xml-mime@imc.org Cc: iesg@ietf.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard In-Reply-To: References: <25D0C66E6D25D311B2AC0008C7913EE0AE5379@tdmail2.teledesic.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000907233037M.muraw3c@attglobal.net> Date: Thu, 07 Sep 2000 23:30:37 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In the IETF-XML-MIME ML, Larry Masinter made proposed to slightly revise the latest draft (draft-murata-xml-07.txt). Dave Peterson agreed. > For backward compatibility, application/xml and text/xml MAY, > but SHOULD NOT, also be used for "external parsed entities", > "external DTD subsets", and "external parameter entities". > > I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119 > terminology, or called for. How about: > > application/xml and text/xml MUST NOT be used for "external parsed > entities", "external DTD subsets", and "external parameter entities". > Note that RFC 2376 (obsoleted) allowed this usage, although > in practice it is likely to be rare. I spoke with my co-authors: Dan Kohn and Simon St. Laurent. We have agreed to accept the proposed change. Sincerely yours, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto (FAMILY Given) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA21429 for ietf-xml-mime-bks; Tue, 5 Sep 2000 01:06:13 -0700 (PDT) Received: from unknown (ts005d03.atl-ga.concentric.net [64.1.54.207]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA21418; Tue, 5 Sep 2000 01:06:10 -0700 (PDT) From: bench1@techspot.com Subject: your imaging supplies Date: Fri, 5 Sep 1997 00:23:59 Message-Id: <418.695188.347193@> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: STATIC SYSTEMS 5334 LAKE VIEW CLUB ATLANTA GA 30338 770-399-0953 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL,UNIVERSITY AND LARGE CORPORATE PURCHASE ORDERS. JUST LEAVE YOUR PO # WITH CORRECT BILLING AND SHIPPING ADDRESS. WHY PAY MORE FOR YOUR LASER PRINTER CARTRIDGES? SAVE FROM 20-40% BY PURCHASING FROM STATIC SYSTEMS. ALL CARTRIDGES COME WITH A 90 DAY WARRANTY. WE WILL IMMEDIATELY REPLACE YOUR CARTRIDGE (NO QUESTIONS ASKED) IF IT GOES BAD WITHIN 90 DAYS FROM THE DATE OF PURCHASE. CHECK OUT OUR NEW CARTRIDGE PRICES FOR THE FOLLOWING PRINTERS: APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $89 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $79 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE OEM COMPATABILE. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES ****OUR ORDER LINE IS 770-399-0953 **** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: STATIC SYSTEMS 5334 LAKE VIEW CLUB ATLANTA GA 30338 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. N0TE: (PRINTER TRADEMARK NAMES ARE USED ABOVE FOR REFERENCE ONLY AND ARE NOT INTENDED TO INFRINGE ON THOSE TRADEMARKS)