Received: by above.proper.com (8.11.6/8.11.3) id g3J4UKE25725 for ietf-xml-mime-bks; Thu, 18 Apr 2002 21:30:20 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J4UIb25721 for ; Thu, 18 Apr 2002 21:30:18 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3J4UJx13171; Fri, 19 Apr 2002 00:30:19 -0400 (EDT) Message-Id: <200204190430.g3J4UJx13171@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Prescod cc: Keith Moore , "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "Thu, 18 Apr 2002 21:06:47 PDT.") <3CBF97D7.741DFC98@prescod.net> Date: Fri, 19 Apr 2002 00:30:19 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But if we agree that it is possible to construct URIs that are both > likely to survive for a long, long time, AND be dereferencable using > widely deployed software then what are we arguing about? Why not change > the RFC to say: > > The IETF hereby commits to maintaining a namespace rooted in > "http://www.ietf/org/xmlns". This should be used as the root for > IETF-defined namespaces. I would strongly argue against IETF making such an agreement - it imposes too many long-term constraints on the operation of the IETF web service for what I see as a a very dubious gain. Keith Received: by above.proper.com (8.11.6/8.11.3) id g3J45aF25102 for ietf-xml-mime-bks; Thu, 18 Apr 2002 21:05:36 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J45Yb25098 for ; Thu, 18 Apr 2002 21:05:35 -0700 (PDT) Received: from smtp3.ActiveState.com (smtp3.ActiveState.com [192.168.3.19]) by smtp1.ActiveState.com (8.11.6/8.11.6) with ESMTP id g3J45U207784; Thu, 18 Apr 2002 21:05:30 -0700 Received: from prescod.net (ssh1.ActiveState.com [192.168.3.32]) by smtp3.ActiveState.com (8.11.6/8.11.6) with ESMTP id g3J45Ne30255; Thu, 18 Apr 2002 21:05:24 -0700 Message-ID: <3CBF97D7.741DFC98@prescod.net> Date: Thu, 18 Apr 2002 21:06:47 -0700 From: Paul Prescod X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <200204190339.g3J3dhx12793@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Filtered-By: PerlMx makes it fast and easy. See http://www.ActiveState.com/Products/PerlMx/Header Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > > > Why are HTTP URIs unstable over the long term? Why shouldn't the URI > > "http://www.ietf.org/rfc/rfc0821.txt" last for 100 years? > > That particular URI might last. The vast majority of URIs will not. But if we agree that it is possible to construct URIs that are both likely to survive for a long, long time, AND be dereferencable using widely deployed software then what are we arguing about? Why not change the RFC to say: The IETF hereby commits to maintaining a namespace rooted in "http://www.ietf/org/xmlns". This should be used as the root for IETF-defined namespaces. > So in general it's not a good idea to trust URIs to be a stable > reference over a long period of time. In general no. But just as the "IETF URN" subset of the URI space is going to be stable because the IETF says so, couldn't the "IETF URL" subset of the URI space be stable for the same reason? > ... But you still won't be able to assume good stability for http > URIs in general. But who cares about HTTP URIs in general? We're talking about the tiny subset defined in IETF specifications. Paul Prescod Received: by above.proper.com (8.11.6/8.11.3) id g3J3UAa24178 for ietf-xml-mime-bks; Thu, 18 Apr 2002 20:30:10 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J3U8b24173 for ; Thu, 18 Apr 2002 20:30:08 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3J3U0x12716; Thu, 18 Apr 2002 23:30:00 -0400 (EDT) Message-Id: <200204190330.g3J3U0x12716@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Bray cc: Keith Moore , "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "Thu, 18 Apr 2002 18:05:18 PDT.") <3CBF6D4E.5030105@textuality.com> Date: Thu, 18 Apr 2002 23:30:00 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Indeed. But I think that what's being said is that where dereferencing > is a required part of the scenario, URNs are contraindicated. -Tim and I think that's a reasonable assumption, at least for the time being. Received: by above.proper.com (8.11.6/8.11.3) id g3J1eMs20260 for ietf-xml-mime-bks; Thu, 18 Apr 2002 18:40:22 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J1eL720256 for ; Thu, 18 Apr 2002 18:40:21 -0700 (PDT) Received: from smtp3.ActiveState.com (smtp3.ActiveState.com [192.168.3.19]) by smtp1.ActiveState.com (8.11.6/8.11.6) with ESMTP id g3J1eB228623; Thu, 18 Apr 2002 18:40:11 -0700 Received: from prescod.net (ssh1.ActiveState.com [192.168.3.32]) by smtp3.ActiveState.com (8.11.6/8.11.6) with ESMTP id g3J1eAe21035; Thu, 18 Apr 2002 18:40:10 -0700 Message-ID: <3CBF75CF.218A8E13@prescod.net> Date: Thu, 18 Apr 2002 18:41:35 -0700 From: Paul Prescod X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <200204172059.g3HKxXx18779@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Filtered-By: PerlMx makes it fast and easy. See http://www.ActiveState.com/Products/PerlMx/Header Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > >... > > If you want an identifer that is stable over the long term, then you > want to avoid burdening the name with any dependencies or associations > with things that aren't stable over a long term -- such as directory > structures, domain names, and access protocols. I'm sure every argument has been made and remade so I ask only for my own education: Why are HTTP URIs unstable over the long term? Why shouldn't the URI "http://www.ietf.org/rfc/rfc0821.txt" last for 100 years? All it would take is sane management and about a thousand dollars in domain name fees. But more to the point, isn't this the exact same situation with ISBN numbers? If the "International ISBN Agency" and "US ISBN Agency" were shut down for lack of funding then who whould arbitrate disputes about ownership of ISBNs? What if those groups started leaking changed data through their publications. What if I broke in and scrambled their database to swap the ISBNs for my book and that of Stephen King's latest book? Longevity seems to me to come down to money, willpower, security and trust, not to one syntax versus the other. Paul Prescod Received: by above.proper.com (8.11.6/8.11.3) id g3J16XE19540 for ietf-xml-mime-bks; Thu, 18 Apr 2002 18:06:33 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J16V719536 for ; Thu, 18 Apr 2002 18:06:31 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 1EB22102DA; Thu, 18 Apr 2002 18:06:29 -0700 (PDT) Message-ID: <3CBF6D4E.5030105@textuality.com> Date: Thu, 18 Apr 2002 18:05:18 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <200204181304.g3ID4Tx08164@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > it's meaningless to try to define URNs' success by comparing them > to URLs. they have different use cases, and different scenarios for > deployment. Indeed. But I think that what's being said is that where dereferencing is a required part of the scenario, URNs are contraindicated. -Tim Received: by above.proper.com (8.11.6/8.11.3) id g3J12wx19487 for ietf-xml-mime-bks; Thu, 18 Apr 2002 18:02:58 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J12u719483 for ; Thu, 18 Apr 2002 18:02:56 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id E192F102DA; Thu, 18 Apr 2002 18:02:53 -0700 (PDT) Message-ID: <3CBF6C77.6090104@textuality.com> Date: Thu, 18 Apr 2002 18:01:43 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <200204172059.g3HKxXx18779@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > > What I have a really hard time understanding is the belief that everything > should run over HTTP, or that everything should be named using HTTP URLs, > when it's abundantly clear that HTTP and HTTP URIs are a poor choice for > many applications - even if HTTP is only used as a mechanism to negotiate > another protocol. Neither side in this debate wins by accusing the other of absolutist positions. Having said that, my position is fairly absolutist within the context of my own experience. It turns out that for 100% of the applications that I deal with, it is good and useful if names can be dereferenced to yield definitive and other related information about whatever the name is naming. Whereas URN dereference is possible in theory it is not widely available in practice. Hence for the stuff I'm working on, "http" class URIs are the way to go. I can understand that there are other application classes where the requirement for stability trumps the desirability of dereference. -Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J0oD219255 for ietf-xml-mime-bks; Thu, 18 Apr 2002 17:50:13 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J0oB719251 for ; Thu, 18 Apr 2002 17:50:11 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 1E1A2102DA; Thu, 18 Apr 2002 17:50:08 -0700 (PDT) Message-ID: <3CBF6979.7040501@textuality.com> Date: Thu, 18 Apr 2002 17:48:57 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baker Cc: ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <20020417145730.H5388@www.markbaker.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Baker wrote: > I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and > saw this; > > "The "application/xml" media type is most appropriate for general > XML; [...]" Thanks Mark for spotting this. As time goes on, I am having more and more difficulty believing in the notion of "general XML" - I have not seen and am less and less able to imagine a scenario in which one party sends another a message in "general XML". > Also, I believe that "text/xml" should be explicitly not recommended, Yes. I have been arguing in the TAG context that we should take another whack at RFC 3023 to say that "text/xml" SHOULD NOT or maybe even MUST NOT be used - the baggage carried by "text/" seems never useful and often harmful in the case of XML. -Tim > Lastly, there's no mention of the RFC 3023 "+xml" suffix convention, > which should at least be mentioned as a possibility for use. Yep. > Plus, FWIW, I'm in the "don't use URNs" camp. Me too. -Tim Received: by above.proper.com (8.11.6/8.11.3) id g3ID6HJ09351 for ietf-xml-mime-bks; Thu, 18 Apr 2002 06:06:17 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ID6Fm09346 for ; Thu, 18 Apr 2002 06:06:15 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3ID4Tx08164; Thu, 18 Apr 2002 09:04:30 -0400 (EDT) Message-Id: <200204181304.g3ID4Tx08164@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Bray cc: Keith Moore , "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "Wed, 17 Apr 2002 22:34:14 PDT.") <3CBE5AD6.7080106@textuality.com> Date: Thu, 18 Apr 2002 09:04:29 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If the knowledge has existed for 7 years and implementations are > still largely absent, I would take this as strong empirical evidence > that resolution implementations will continue to be absent. -Tim protocol implementation isn't the issue - several protocols suitable for URN resolution were up and running long before URNs were defined. it's meaningless to try to define URNs' success by comparing them to URLs. they have different use cases, and different scenarios for deployment. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I6j5829953 for ietf-xml-mime-bks; Wed, 17 Apr 2002 23:45:05 -0700 (PDT) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I6j4m29944 for ; Wed, 17 Apr 2002 23:45:04 -0700 (PDT) Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7BEDF15BC; Thu, 18 Apr 2002 15:44:52 +0900 (JST) Message-Id: <4.2.0.58.J.20020418153104.02185ec8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 18 Apr 2002 15:32:42 +0900 To: Mark Baker , Keith Moore From: Martin Duerst Subject: Re: application/xml in ietf-xml-guidelines Cc: Mark Baker , ietf-xml-mime@imc.org In-Reply-To: <20020417203756.J5388@www.markbaker.ca> References: <200204172028.g3HKSIx18667@astro.cs.utk.edu> <20020417145730.H5388@www.markbaker.ca> <200204172028.g3HKSIx18667@astro.cs.utk.edu> 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 20:37 02/04/17 -0400, Mark Baker wrote: > > > Also, I believe that "text/xml" should be explicitly not recommended, > > > due to the text/plain fallback of all text/* types. > > > > if it's just a fallback behavior, why does it matter much? The other problem with text/xml and text/...+xml is the charset default of US-ASCII, i.e. Content-Type: text/xml is exactly the same as Content-Type: text/xml; charset=us-ascii This doesn't work that well in many cases. Regards, Martin. > > actually "display as text" is probably a better fallback for XML > > than for HTML - XML generally seems to be more readable than HTML :) > >When I was first introduced to this issue while writing RFC 3236, it >was made quite clear to me (on this list, I believe), that text/* >was for content that anybody could easily read. The XML prolog would >scare off most people! And those that make it past that would surely >be overwhelmed by xmlns declarations! 8-) > >MB >-- >Mark Baker, Chief Science Officer, Planetfred, Inc. >Ottawa, Ontario, CANADA. mbaker@planetfred.com >http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g3I5ZWh19289 for ietf-xml-mime-bks; Wed, 17 Apr 2002 22:35:32 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I5ZUm19285 for ; Wed, 17 Apr 2002 22:35:30 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 3E097102DA; Wed, 17 Apr 2002 22:35:24 -0700 (PDT) Message-ID: <3CBE5AD6.7080106@textuality.com> Date: Wed, 17 Apr 2002 22:34:14 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: "Simon St.Laurent" , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines References: <200204180227.g3I2Rdx19959@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > We've known essentially how we were going to resolve URNs since 1 November > 1995. If the knowledge has existed for 7 years and implementations are still largely absent, I would take this as strong empirical evidence that resolution implementations will continue to be absent. -Tim Received: by above.proper.com (8.11.6/8.11.3) id g3I2wQB14851 for ietf-xml-mime-bks; Wed, 17 Apr 2002 19:58:26 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I2wOm14841 for ; Wed, 17 Apr 2002 19:58:24 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3I2wIg22011; Wed, 17 Apr 2002 22:58:18 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: application/xml in ietf-xml-guidelines From: "Simon St.Laurent" To: Keith Moore Cc: ietf-xml-mime@imc.org In-Reply-To: <200204180227.g3I2Rdx19959@astro.cs.utk.edu> References: <200204180227.g3I2Rdx19959@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 17 Apr 2002 23:03:51 -0400 Message-Id: <1019099031.982.229.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2002-04-17 at 22:27, Keith Moore wrote: > opacity of URNs is a design feature - URNs need to be opaque to do their jobs. > > OTOH, I have no fondness for use of URNs to identify vocabularies either. > > We've known essentially how we were going to resolve URNs since 1 November > 1995. The biggest problem we've had in finishing the specifications is that > URNs were so widely misunderstood that we were continually having to argue with > people who were insisting that they have properties that would make them > unusable for their intended purpose. I suspect there's a level of agreement underneath the apparent disagreement. You want URNs to be opaque; I want namespace identifiers to be transparent (or at least translucent.) Using URIs as namespace identifiers may have been a bad choice all round, though I've not heard anyone really admit that, much less shout it out loud. The question here seem to come down to whether it's the namespace identifier-nature that matters or the URI-nature that matters. Given that the document section is titled "Namespaces", I'm inclined to vote for the namespace identifier-nature and focus on what works best for identifying vocabularies rather than arguing about the value of URN/L/I. Given current IETF politics/policy, I suspect there's not much room for such an opinion. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g3I2SlD13969 for ietf-xml-mime-bks; Wed, 17 Apr 2002 19:28:47 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I2Skm13964 for ; Wed, 17 Apr 2002 19:28:46 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3I2Rdx19959; Wed, 17 Apr 2002 22:27:39 -0400 (EDT) Message-Id: <200204180227.g3I2Rdx19959@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: Keith Moore , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "17 Apr 2002 18:14:17 EDT.") <1019081658.982.220.camel@localhost.localdomain> Date: Wed, 17 Apr 2002 22:27:39 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > What I have a really hard time understanding is the belief that everything > > should run over HTTP, or that everything should be named using HTTP URLs, > > when it's abundantly clear that HTTP and HTTP URIs are a poor choice for > > many applications - even if HTTP is only used as a mechanism to negotiate > > another protocol. > > I have no fondness for HTTP identifiers. At the same time, I have no > fondness for opaque identifiers, especially when used to identify > vocabularies. opacity of URNs is a design feature - URNs need to be opaque to do their jobs. OTOH, I have no fondness for use of URNs to identify vocabularies either. We've known essentially how we were going to resolve URNs since 1 November 1995. The biggest problem we've had in finishing the specifications is that URNs were so widely misunderstood that we were continually having to argue with people who were insisting that they have properties that would make them unusable for their intended purpose. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I0VRJ11138 for ietf-xml-mime-bks; Wed, 17 Apr 2002 17:31:27 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I0VQm11134 for ; Wed, 17 Apr 2002 17:31:26 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id UAA19579; Wed, 17 Apr 2002 20:37:56 -0400 Date: Wed, 17 Apr 2002 20:37:56 -0400 From: Mark Baker To: Keith Moore Cc: Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines Message-ID: <20020417203756.J5388@www.markbaker.ca> References: <20020417145730.H5388@www.markbaker.ca> <200204172028.g3HKSIx18667@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200204172028.g3HKSIx18667@astro.cs.utk.edu>; from moore@cs.utk.edu on Wed, Apr 17, 2002 at 04:28:18PM -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Apr 17, 2002 at 04:28:18PM -0400, Keith Moore wrote: > depending on what you mean by "dispatch", neither, really, does > any other content-type. in particular, content-types don't specify > anything about presentation or processing; these decisions are up > to the recipient. We could talk about this again (I'm game!), or I could just reference the same discussion we held on this topic on www-tag. My position is very close to Roy's, and I don't have much to add to what he said at this time. The posts of his that best reflect my position are; http://lists.w3.org/Archives/Public/www-tag/2002Jan/0162.html http://lists.w3.org/Archives/Public/www-tag/2002Jan/0167.html > > Also, I believe that "text/xml" should be explicitly not recommended, > > due to the text/plain fallback of all text/* types. > > if it's just a fallback behavior, why does it matter much? > actually "display as text" is probably a better fallback for XML > than for HTML - XML generally seems to be more readable than HTML :) When I was first introduced to this issue while writing RFC 3236, it was made quite clear to me (on this list, I believe), that text/* was for content that anybody could easily read. The XML prolog would scare off most people! And those that make it past that would surely be overwhelmed by xmlns declarations! 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g3HMFej06599 for ietf-xml-mime-bks; Wed, 17 Apr 2002 15:15:40 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HMFcm06595 for ; Wed, 17 Apr 2002 15:15:38 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3HM8kg13886; Wed, 17 Apr 2002 18:08:46 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: application/xml in ietf-xml-guidelines From: "Simon St.Laurent" To: Keith Moore Cc: Mark Baker , ietf-xml-mime@imc.org In-Reply-To: <200204172059.g3HKxXx18779@astro.cs.utk.edu> References: <200204172059.g3HKxXx18779@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 17 Apr 2002 18:14:17 -0400 Message-Id: <1019081658.982.220.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2002-04-17 at 16:59, Keith Moore wrote: > What I have a really hard time understanding is the belief that everything > should run over HTTP, or that everything should be named using HTTP URLs, > when it's abundantly clear that HTTP and HTTP URIs are a poor choice for > many applications - even if HTTP is only used as a mechanism to negotiate > another protocol. I have no fondness for HTTP identifiers. At the same time, I have no fondness for opaque identifiers, especially when used to identify vocabularies. If the IETF plans to provide some mechanism whereby developers can look at a namespace URN used in a protocol and find information about it - preferably something more substantial than a Google search on RFC+urn:ietf... - I have no objection whatsoever. I'd love it if the W3C and the IETF could get their act together on making URIs in general less opaque, but the W3C doesn't seem to get that and the IETF doesn't presently seem interested in building the infrastructure it takes to look behind its own URNs. As the Internet-Draft for IANA URN Namespace states "The namespace is primarily opaque", I have a very hard time imagining this situation changing any time soon. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HL18H03097 for ietf-xml-mime-bks; Wed, 17 Apr 2002 14:01:08 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HL17m03092 for ; Wed, 17 Apr 2002 14:01:07 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3HKxXx18779; Wed, 17 Apr 2002 16:59:33 -0400 (EDT) Message-Id: <200204172059.g3HKxXx18779@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: Keith Moore , Mark Baker , ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "17 Apr 2002 16:41:17 EDT.") <1019076078.982.211.camel@localhost.localdomain> Date: Wed, 17 Apr 2002 16:59:33 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I'm having a really hard time understanding why the IETF is so keen on > inflicting URNs on the world. What's so hard to understand? URNs are useful for the same reason that ISBNs, ISSNs, etc. are useful. They weren't intended to replace URLs; they were intended to cover a case for which DNS-based and protocol-based URLs have repeatedly been demonstrated to work poorly -- specifically, as identifiers which have a high probability of being stably bound to the same resource over very long periods of time (decades or more). The assumption is that for some purposes a stable association between the resource name and the resource is more important than being able to access that resource using that name from anywhere at any time. If you want an identifer that is stable over the long term, then you want to avoid burdening the name with any dependencies or associations with things that aren't stable over a long term -- such as directory structures, domain names, and access protocols. The design of URNs follows almost directly from that realization, and from the requirement for global uniqueness. Other identifiers that were intended for similar purposes (e.g. handles/DOIs) have very similar designs to URNs. What I have a really hard time understanding is the belief that everything should run over HTTP, or that everything should be named using HTTP URLs, when it's abundantly clear that HTTP and HTTP URIs are a poor choice for many applications - even if HTTP is only used as a mechanism to negotiate another protocol. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HKbnS01056 for ietf-xml-mime-bks; Wed, 17 Apr 2002 13:37:49 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HKbmm01049 for ; Wed, 17 Apr 2002 13:37:48 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g3HKZlg09175; Wed, 17 Apr 2002 16:35:47 -0400 X-Originating-IP: [24.24.11.230] X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: application/xml in ietf-xml-guidelines From: "Simon St.Laurent" To: Keith Moore Cc: Mark Baker , ietf-xml-mime@imc.org In-Reply-To: <200204172028.g3HKSIx18667@astro.cs.utk.edu> References: <200204172028.g3HKSIx18667@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 17 Apr 2002 16:41:17 -0400 Message-Id: <1019076078.982.211.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2002-04-17 at 16:28, Keith Moore wrote: > > Lastly, there's no mention of the RFC 3023 "+xml" suffix convention, > > which should at least be mentioned as a possibility for use. > > agreed. And agreed. > > I believe > > that my first point above highlights a large part of the value of > > specific media types (whether +xml is used or not), as the required > > dispatch behaviour can be assigned to them. > > we need to be careful about how we use the word "dispatch" - > it's used to distinguish different types from one another, > but not to actually specify the processing to be performed. I agree with Keith on this one. The types identify "what something is", not "how you should process that something". I'd be strongly opposed to any attempt to impose a particular style of namespace processing on any of the types described by RFC 3023 or to +xml generically. I've not yet gotten around to writing POND (Perversely-Oriented Namespace-based Datatyping), but believe me, it's coming. > > Plus, FWIW, I'm in the "don't use URNs" camp. > > nobody's perfect :) I'm having a really hard time understanding why the IETF is so keen on inflicting URNs on the world. The best answers I've heard suggest merely that the IETF isn't to be trusted with URLs, which seems, well, an extraordinarily weak answer. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g3HKSSU29616 for ietf-xml-mime-bks; Wed, 17 Apr 2002 13:28:28 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HKSRm29607 for ; Wed, 17 Apr 2002 13:28:27 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3HKSIx18667; Wed, 17 Apr 2002 16:28:18 -0400 (EDT) Message-Id: <200204172028.g3HKSIx18667@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Baker cc: ietf-xml-mime@imc.org Subject: Re: application/xml in ietf-xml-guidelines In-reply-to: (Your message of "Wed, 17 Apr 2002 14:57:30 EDT.") <20020417145730.H5388@www.markbaker.ca> Date: Wed, 17 Apr 2002 16:28:18 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and > saw this; > > "The "application/xml" media type is most appropriate for general > XML; [...]" > > I have three concerns about it. In descending order of priority; > > "application/xml" (and text/xml for that matter) do not have any > specified namespace dispatch behaviour. depending on what you mean by "dispatch", neither, really, does any other content-type. in particular, content-types don't specify anything about presentation or processing; these decisions are up to the recipient. this wasn't so clear at the time that MIME was designed because it was assumed to be for interpersonal email - hence there's a lot of language in the MIME spec about default presentation behaviors. these days we're using MIME for many other applications than interpersonal messaging, so we don't assume a priori that just because a bit of content is encapsulated in MIME that it's going to be presented to some recipient as if it were an email message. (for that matter, we no longer assume that something sent via SMTP is intended for human consumption either) we really ought to make this clearer when we update the MIME spec. > That is, if I send some > XHTML as application/xml, the recipient agent doesn't know whether I > want it displayed as XHTML, or in some tree like XML format, nor do > I have any expectation of what the agent might do with it. According > to RFC 3023, both behaviours are fine, and IMO this makes > "application/xml" less suitable than believed as a generic type. it makes application/xml neither more or less suitable - no type should be expected to dictate behavior. > Also, I believe that "text/xml" should be explicitly not recommended, > due to the text/plain fallback of all text/* types. if it's just a fallback behavior, why does it matter much? actually "display as text" is probably a better fallback for XML than for HTML - XML generally seems to be more readable than HTML :) > Lastly, there's no mention of the RFC 3023 "+xml" suffix convention, > which should at least be mentioned as a possibility for use. agreed. > I believe > that my first point above highlights a large part of the value of > specific media types (whether +xml is used or not), as the required > dispatch behaviour can be assigned to them. we need to be careful about how we use the word "dispatch" - it's used to distinguish different types from one another, but not to actually specify the processing to be performed. > Plus, FWIW, I'm in the "don't use URNs" camp. nobody's perfect :) Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HIp0k24270 for ietf-xml-mime-bks; Wed, 17 Apr 2002 11:51:00 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HIowm24263 for ; Wed, 17 Apr 2002 11:50:59 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id OAA14500 for ietf-xml-mime@imc.org; Wed, 17 Apr 2002 14:57:30 -0400 Date: Wed, 17 Apr 2002 14:57:30 -0400 From: Mark Baker To: ietf-xml-mime@imc.org Subject: application/xml in ietf-xml-guidelines Message-ID: <20020417145730.H5388@www.markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hey, I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and saw this; "The "application/xml" media type is most appropriate for general XML; [...]" I have three concerns about it. In descending order of priority; "application/xml" (and text/xml for that matter) do not have any specified namespace dispatch behaviour. That is, if I send some XHTML as application/xml, the recipient agent doesn't know whether I want it displayed as XHTML, or in some tree like XML format, nor do I have any expectation of what the agent might do with it. According to RFC 3023, both behaviours are fine, and IMO this makes "application/xml" less suitable than believed as a generic type. Here's the relevant paragraph; ] An XML document labeled as text/xml or application/xml might contain ] namespace declarations, stylesheet-linking processing instructions ] (PIs), schema information, or other declarations that might be used ] to suggest how the document is to be processed. For example, a ] document might have the XHTML namespace and a reference to a CSS ] stylesheet. Such a document might be handled by applications that ] would use this information to dispatch the document for appropriate ] processing. (emphasis on "might" in that last sentence) Also, I believe that "text/xml" should be explicitly not recommended, due to the text/plain fallback of all text/* types. It's possible that text/* has already been abused so badly (text/html being the biggie) that a text/plain fallback cannot be assumed, but I'll let others decide if that's actually the case or not. Lastly, there's no mention of the RFC 3023 "+xml" suffix convention, which should at least be mentioned as a possibility for use. I believe that my first point above highlights a large part of the value of specific media types (whether +xml is used or not), as the required dispatch behaviour can be assigned to them. Plus, FWIW, I'm in the "don't use URNs" camp. Thanks. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g36Jmbl22419 for ietf-xml-mime-bks; Sat, 6 Apr 2002 11:48:37 -0800 (PST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g36Jmam22410; Sat, 6 Apr 2002 11:48:36 -0800 (PST) Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g36JoIp03116; Sat, 6 Apr 2002 11:50:18 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g36Jmuq21253; Sat, 6 Apr 2002 11:48:56 -0800 (PST) Received: from larrypad ([130.248.184.142]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GU5WCS00.HF3; Sat, 6 Apr 2002 11:48:28 -0800 Reply-To: From: "Larry Masinter" To: , , Cc: "'Paul Hoffman / IMC'" , "'Marshall Rose'" , "Scott Hollenbeck" , Subject: "Guidelines for the Use of XML in IETF Protocols" Date: Sat, 6 Apr 2002 11:47:48 -0800 Message-ID: <000a01c1dda3$f3808b20$6ace8642@larrypad> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Abstract: The eXtensible Markup Language (XML) is a framework for structuring data. While it evolved from SGML -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely- used mechanism for representing structured data. There are a wide variety of Internet protocols; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. Intended Publication Status It is the goal of the authors that this draft (when completed and then approved by the IESG) be published as a Best Current Practice (BCP). Submitted to the Internet Drafts, but available now at http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt or http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html with a mailing list ietf-xml-use@imc.org , archive at http://www.imc.org/ietf-xml-use/index.html "To subscribe to the mailing list, send a message to ietf-xml-use-request@imc.org with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message." Larry -- http://larry.masinter.net