Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14035 for ietf-xml-mime-bks; Mon, 6 Nov 2000 08:14:22 -0800 (PST) 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 IAA14031 for ; Mon, 6 Nov 2000 08:14:20 -0800 (PST) Received: from fastrack.Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00749; Mon, 6 Nov 2000 08:20:51 -0800 (PST) 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 LAA28022; Mon, 6 Nov 2000 11:20:46 -0500 (EST) Message-ID: <3A06DAF5.BD295DF5@canada.sun.com> Date: Mon, 06 Nov 2000 11:23:17 -0500 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Rick Jelliffe CC: ietf-xml-mime@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: 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: Sorry for my tardy response ... Rick Jelliffe wrote: > Perhaps it would be better to redefine text/* to clarify that readability > by naive readers is not the defining characteristic, but that the freedom > of intermediate systems to transcode it (perhaps even at the cost of > losing characters, how awful) is. It sounds like you're suggesting that only text/* types can be transcoded. I disagree. text/* types are currently (AFAIK) the only types to be transcoded because the user agent has additional information about the encodings on these types that allow it to always access the content. While it's true that processors of application/* types don't have this additional information available to them, the use of "+xml" changes that, and allows transcoding. Note that this isn't written down anywhere. However, in considering application/xhtml+xml vs. text/xhtml+xml, I did thoroughly review the MIME RFCs and draft-murata-xml to ensure that nothing precluded application/xhtml+xml (or any application/*+xml type) described-content from being transcoded. I hope this is consistent with others' views. MB Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12817 for ietf-xml-mime-bks; Thu, 2 Nov 2000 06:34:14 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12804 for ; Thu, 2 Nov 2000 06:34:12 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA02364; Thu, 2 Nov 2000 09:40:22 -0500 (EST) Message-Id: <200011021440.JAA02364@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rick Jelliffe cc: John Cowan , "ietf-xml-mime@imc.org" Subject: Re: text/xhtml+xml vs. application/xhtml+xml In-reply-to: Your message of "Thu, 02 Nov 2000 18:16:26 +0800." Date: Thu, 02 Nov 2000 09:40:22 -0500 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The people in my office love HTML mail. They do not use public mailing > lists. It may be inconvenient for technocrats, but HTML is popular. 'technocrats' have nothing to do with it. There are lots of data formats that work well in limited environments. MIME allows consenting adults to happily exchange mail in a wide variety of limited use formats, including MS Word, Powerpoint, RTF, PDF, and even HTML - and the ability to do this is popular. But what is acceptable between consenting adults is not necessarily acceptable in public. HTML might become acceptable eventually - once 99% of user agents can display it effectively, and without creating security or privacy risks for those who read it. Until that time, recipients are quite justified in rejecting it, and they don't need to be technocrats to do so. Sending garbage to someone else's screen is simply rude. Keith p.s. I have used mh for many years and I haven't found anything more effective for what I need to do. Since mh's MIME support is pretty primitive, I've been writing new versions of some of the mh commands. I wrote a version of the 'show' command that handles MIME fairly well and which decodes and displays most HTML constructs. What I've found is that for the most part, the only messages which actually make use of HTML (as opposed to sending HTML which displays identicallly to the text/plain portion) are spam. so a user agent that refuses to display HTML (detects it and refuses to display it, rather than displaying garbage) actually makes a fairly effective spam filter. Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11881 for ietf-xml-mime-bks; Thu, 2 Nov 2000 06:15:12 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11873 for ; Thu, 2 Nov 2000 06:15:11 -0800 (PST) Received: from 146-115-74-219.c5-0.brl-ubr1.sbo-brl.ma.cable.rcn.com ([146.115.74.219]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #1) id 13rLFH-0002mZ-00 for ietf-xml-mime@imc.org; Thu, 02 Nov 2000 09:21:35 -0500 Mime-Version: 1.0 X-Sender: sgmlworks@pop.rcn.com Message-Id: In-Reply-To: References: Date: Thu, 2 Nov 2000 09:06:20 -0500 To: "ietf-xml-mime@imc.org" From: Dave Peterson Subject: Re: text/xhtml+xml vs. application/xhtml+xml 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 6:16 PM +0800 11/2/00, Rick Jelliffe wrote: >On Wed, 1 Nov 2000, John Cowan wrote: > > Common practice for senders is to send mail in HTML, or both text and HTML. >> Common practice for receivers is to despise HTML mail; it is banned >> on most public mailing lists. > >The people in my office love HTML mail. They do not use public mailing >lists. It may be inconvenient for technocrats, but HTML is popular. But people whose mailer doesn't handle HTML mail get screwed--mail becomes almost uninterpretable. And visually handicapped people don't appreciate having fonts and font sizes forced upon them. Even I find that most people's incoming HTML mail displays in a size too small to read, so I have to go through the process of highlighting and resizing for every such message. Occasionally I just trash them, and often I'm tempted to. You should know your receiver before sending HTML mail. If you don't know that they can handle it easily, don't do it. I doubt it's just the technocrats running mailing lists that don't like the HTML; it's probably that they get complaints from their users. Who are people with hardware, software, or visual restrictions that make HTML mail, like most accessibility-unfriendly web sites, very much a pain in the neck or other part of the anatomy. -- Dave Peterson SGMLWorks! davep@acm.org Received: by ns.secondary.com (8.9.3/8.9.3) id CAA24975 for ietf-xml-mime-bks; Thu, 2 Nov 2000 02:10:26 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA24971 for ; Thu, 2 Nov 2000 02:10:24 -0800 (PST) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id eA2AGRt18201; Thu, 2 Nov 2000 18:16:27 +0800 (CST) Date: Thu, 2 Nov 2000 18:16:26 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: John Cowan cc: "ietf-xml-mime@imc.org" Subject: Re: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: <3A008C63.D7493A5D@reutershealth.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: On Wed, 1 Nov 2000, John Cowan wrote: > Rick Jelliffe wrote: > > > What user frustration would it cause to bless common practise? > > Common practice for senders is to send mail in HTML, or both text and HTML. > Common practice for receivers is to despise HTML mail; it is banned > on most public mailing lists. The people in my office love HTML mail. They do not use public mailing lists. It may be inconvenient for technocrats, but HTML is popular. Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10938 for ietf-xml-mime-bks; Wed, 1 Nov 2000 13:27:51 -0800 (PST) Received: from mail.reutershealth.com (mail.reutershealth.com [204.243.9.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10933 for ; Wed, 1 Nov 2000 13:27:50 -0800 (PST) Received: from reutershealth.com (IDENT:cowan@[192.168.3.11]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id QAA18740; Wed, 1 Nov 2000 16:34:43 -0500 (EST) Message-ID: <3A008C63.D7493A5D@reutershealth.com> Date: Wed, 01 Nov 2000 16:34:27 -0500 From: John Cowan Organization: Reuters Health Information X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rick Jelliffe , "ietf-xml-mime@imc.org" Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: 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: Rick Jelliffe wrote: > What user frustration would it cause to bless common practise? Common practice for senders is to send mail in HTML, or both text and HTML. Common practice for receivers is to despise HTML mail; it is banned on most public mailing lists. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein Received: by ns.secondary.com (8.9.3/8.9.3) id MAA07484 for ietf-xml-mime-bks; Wed, 1 Nov 2000 12:03:24 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07478 for ; Wed, 1 Nov 2000 12:03:22 -0800 (PST) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id eA1K9bj28333 for ; Thu, 2 Nov 2000 04:09:37 +0800 (CST) Date: Thu, 2 Nov 2000 04:09:37 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: <200011012000.PAA09418@hesketh.net> 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: On Wed, 1 Nov 2000, Simon St.Laurent wrote: > I can't say I encourage anyone to use text/* for uses other than plain text > at this point. Yes, and actually I guess that dumb transcoding of xml is something that should not be encouraged anyway. Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06898 for ietf-xml-mime-bks; Wed, 1 Nov 2000 11:54:09 -0800 (PST) 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 LAA06893 for ; Wed, 1 Nov 2000 11:54:08 -0800 (PST) Received: from zingo (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id PAA09418 for ; Wed, 1 Nov 2000 15:00:29 -0500 Message-Id: <200011012000.PAA09418@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: Wed, 01 Nov 2000 15:04:10 -0500 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: References: <25D0C66E6D25D311B2AC0008C7913EE00105A2FC@tdmail2.teledesic.com> 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 03:53 AM 11/2/00 +0800, Rick Jelliffe wrote: >On Wed, 1 Nov 2000, Dan Kohn wrote: > >> RFC 2646 was exactly about dealing with these practical issues of how to >> role out new functionality within text/* without generating user >> frustration. > >What user frustration would it cause to bless common practise? I think Dan was describing the frustration of users who get to sort out mostly incomprehensible junk in their email or in other areas. I don't find HTML mail especially fun to read by hand, and I used to have problems with people sending me RTF as text and expecting me to do something with it. I'd say I was pretty frustrated, personally. My current email program (Eudora 4.1) still barfs on HTML email containing XML processing instructions, like Microsoft Word 2000 output. If that wasn't all spam, I'd be really genuinely irritated. I can't say I encourage anyone to use text/* for uses other than plain text at this point. Common practice is sometimes best practice, sometimes not. 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 LAA06748 for ietf-xml-mime-bks; Wed, 1 Nov 2000 11:48:54 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06744 for ; Wed, 1 Nov 2000 11:48:53 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id OAA26988 for ; Wed, 1 Nov 2000 14:53:46 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 1 Nov 2000 15:02:05 -0500 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: <25D0C66E6D25D311B2AC0008C7913EE00105A2F9@tdmail2.teledesic.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Gavin, I just want to point out that no one is arguing that > MHTML is a bad thing. I'm sorry for going down a rat hole. My reaction was to Keith's statements... >I think the general consensus of the MIME community is that making HTML >a subtype of "text/" was a mistake. ... >So IMHO we should learn from this experience and make XHTML and other >XML-ish things subtypes of application/. and I was just trying to point out that text/* is fine for some things... for example text/xml *if* the text is generic/not application specific. For example, if I have a multipart message with an XML document, and a CSS stylesheet, I think text/xml would be fine for the XML (and perhaps application/css for the CSS ;-)). Apart from that I agree with the general direction. Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06708 for ietf-xml-mime-bks; Wed, 1 Nov 2000 11:47:48 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06702 for ; Wed, 1 Nov 2000 11:47:46 -0800 (PST) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id eA1Jrpx25935; Thu, 2 Nov 2000 03:53:51 +0800 (CST) Date: Thu, 2 Nov 2000 03:53:51 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: Dan Kohn cc: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE00105A2FC@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: On Wed, 1 Nov 2000, Dan Kohn wrote: > RFC 2646 was exactly about dealing with these practical issues of how to > role out new functionality within text/* without generating user > frustration. What user frustration would it cause to bless common practise? Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06643 for ietf-xml-mime-bks; Wed, 1 Nov 2000 11:45:10 -0800 (PST) Received: from mgate-02.teledesic.com (mgate-02.teledesic.com [216.190.22.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06639 for ; Wed, 1 Nov 2000 11:45:09 -0800 (PST) Received: from mgate-02.teledesic.com (localhost [127.0.0.1]) by mgate-02.teledesic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WC14HSTA; Wed, 1 Nov 2000 11:51:30 -0800 Received: from 10.100.10.13 by mgate-02.teledesic.com (InterScan E-Mail VirusWall NT); Wed, 01 Nov 2000 11:51:30 -0800 (Pacific Standard Time) Received: from mgate-01.teledesic.com ([10.100.10.14]) by 10.100.10.13 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 01 Nov 2000 19:51:30 0000 (GMT) Received: by MGATE-01 with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 11:51:28 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A2FC@tdmail2.teledesic.com> From: Dan Kohn To: Rick Jelliffe Cc: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 1 Nov 2000 11:51:28 -0800 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: >Making text/* rely on being naively readable makes it only useful for >plain text and Wiki. But unfortunately, that is precisely the situation, because unknown subtypes of text default to text/plain, so the material MUST be understandable to naive users. We can all agree that it would be great to go back 8 years and have done x or y differently, but then people in hell would like a glass of ice water too. RFC 2646 was exactly about dealing with these practical issues of how to role out new functionality within text/* without generating user frustration. To quote Larry Masinter on a previous issue within the draft, "We live in a complex world of our own making." - dan -- Dan Kohn Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05569 for ietf-xml-mime-bks; Wed, 1 Nov 2000 11:17:49 -0800 (PST) Received: from mgate-02.teledesic.com (mgate-02.teledesic.com [216.190.22.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05564 for ; Wed, 1 Nov 2000 11:17:47 -0800 (PST) Received: from mgate-02.teledesic.com (localhost [127.0.0.1]) by mgate-02.teledesic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WC14HSQ8; Wed, 1 Nov 2000 11:24:08 -0800 Received: from 10.100.10.13 by mgate-02.teledesic.com (InterScan E-Mail VirusWall NT); Wed, 01 Nov 2000 11:24:08 -0800 (Pacific Standard Time) Received: from mgate-01.teledesic.com ([10.100.10.14]) by 10.100.10.13 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 01 Nov 2000 19:24:08 0000 (GMT) Received: by MGATE-01 with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 11:24:06 -0800 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A2F9@tdmail2.teledesic.com> From: Dan Kohn To: Gavin Thomas Nicol , ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 1 Nov 2000 11:24:05 -0800 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: Gavin, I just want to point out that no one is arguing that MHTML is a bad thing. It's just that in retrospect, we wish application/html had been used. But, just because we are locked into text/html, does not mean that we need to repeat the same mistakes for new media types. For a description of the evolving view of where text types are (and are not) appropriate, see Section 3.3 of RFC 2646 and Section 3 of . (For a description of when to do +xml, see Section 7 of the latter.) Further, it has been stated that it is better to have a single registration rather than registering under both text and application, since if we are having trouble evaluating the tradeoffs, it seems unlikely that most document authors would understand the subtlety. I subscribe to section 3.2 of RFC 1958 on Architectural Principles of the Internet, which says, "If there are several ways of doing the same thing, choose one." >From my understanding, everyone else on this list agrees with this direction, and sees a certain consistency there. Rather than doing a line by line rebuttal of certain points, could I suggest that you state an alternative viewpoint for future registrations (such as "always do text unless the material is binary"), and then we can compare that viewpoint to the ones listed above. Otherwise, the discussion becomes needlessly abstract. - dan -- Dan Kohn -----Original Message----- From: Gavin Thomas Nicol [mailto:gtn@ebt.com] Sent: Wednesday, 2000-11-01 09:59 To: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml > This continued argument about the exact nature of past > mistakes is going nowhere fast, so I'm not going to > bother to respond further to it. Fine. One question though... Given 1) choices for types text/xml application/xml application/foo+xml 2) clear guidelines on their use. do *you* have faith that developers will do what is right? Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04155 for ietf-xml-mime-bks; Wed, 1 Nov 2000 10:58:46 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04146 for ; Wed, 1 Nov 2000 10:58:44 -0800 (PST) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id eA1J4s218791; Thu, 2 Nov 2000 03:04:54 +0800 (CST) Date: Thu, 2 Nov 2000 03:04:54 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: Gavin Thomas Nicol cc: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: 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: On Wed, 1 Nov 2000, Gavin Thomas Nicol wrote: > The point is that there is a use driven by a need. Can I jump on my hobby horse and say that text/html does serve a useful purpose, but perhaps it is not the purpose for which it was created but merely a side-effect: that being that it signals that transcoding and newline massaging is allowed, in effect. If it turns out that HTML does not fit into the definition or intent of the text/* type, then I suggest that the definition of text/* does not capture practise enough. Perhaps it would be better to redefine text/* to clarify that readability by naive readers is not the defining characteristic, but that the freedom of intermediate systems to transcode it (perhaps even at the cost of losing characters, how awful) is. The distinction therefore should be the old, useful one of "text" versus "binary" with application/* being binary. Making text/* rely on being naively readable makes it only useful for plain text and Wiki. Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02002 for ietf-xml-mime-bks; Wed, 1 Nov 2000 10:22:24 -0800 (PST) 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 KAA01997 for ; Wed, 1 Nov 2000 10:22:23 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVWYJZVHHS00011D@mauve.mrochek.com> for ietf-xml-mime@imc.org; Wed, 01 Nov 2000 10:28:41 -0700 (PDT) Date: Wed, 01 Nov 2000 10:00:27 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Wed, 01 Nov 2000 12:59:28 -0500" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JW0TPVAQBE00011D@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01JW0RRT2H4800011D@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > This continued argument about the exact nature of past > > mistakes is going nowhere fast, so I'm not going to > > bother to respond further to it. > Fine. One question though... > Given > 1) choices for types > text/xml > application/xml > application/foo+xml > 2) clear guidelines on their use. > do *you* have faith that developers > will do what is right? I think the above is necessary but not sufficient. Past experience has shown that no matter how clear you make the guidelines, people will misinterpret them or not read them at all. What does work is to add a registration process that people actively want to use and sound review and feedback as part of that process. In hindsight, not having this initally in MIME was what led to most past problems with media types. But we have such a process in place now, and it appears to be working. And I see no reason to presume it won't continue to work. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01824 for ietf-xml-mime-bks; Wed, 1 Nov 2000 10:14:00 -0800 (PST) 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 KAA01819 for ; Wed, 1 Nov 2000 10:13:59 -0800 (PST) Received: from zingo (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id NAA01307 for ; Wed, 1 Nov 2000 13:20:19 -0500 Message-Id: <200011011820.NAA01307@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: Wed, 01 Nov 2000 13:24:00 -0500 To: From: "Simon St.Laurent" Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: References: <01JW0RRT2H4800011D@mauve.mrochek.com> 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:59 PM 11/1/00 -0500, Gavin Thomas Nicol wrote: >Given > > 1) choices for types > text/xml > application/xml > application/foo+xml > 2) clear guidelines on their use. > >do *you* have faith that developers >will do what is right? I do, actually. I've spent a fair amount of time dealing with developers who got so used to text/html that they figured text/xml was the way to go. It doesn't take much explaining to get them to shift to application/xml for light use and application/xyz+xml for cases where they want to identify their types further. So far, that explaining's been on a one-on-one basis through email and conference encounters, but the explaining hasn't been the hard part. The hard part is just getting people to think about it in the first place. When we have an RFC to point to, I'm planning on posting more general discussion of these issues to xml-dev, xml-l, and comp.text.xml. 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 JAA00653 for ietf-xml-mime-bks; Wed, 1 Nov 2000 09:46:16 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00648 for ; Wed, 1 Nov 2000 09:46:15 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id MAA18859 for ; Wed, 1 Nov 2000 12:51:09 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 1 Nov 2000 12:59:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <01JW0RRT2H4800011D@mauve.mrochek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This continued argument about the exact nature of past > mistakes is going nowhere fast, so I'm not going to > bother to respond further to it. Fine. One question though... Given 1) choices for types text/xml application/xml application/foo+xml 2) clear guidelines on their use. do *you* have faith that developers will do what is right? Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29456 for ietf-xml-mime-bks; Wed, 1 Nov 2000 09:26:57 -0800 (PST) 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 JAA29452 for ; Wed, 1 Nov 2000 09:26:55 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVWYJZVHHS00011D@mauve.mrochek.com> for ietf-xml-mime@imc.org; Wed, 01 Nov 2000 09:32:59 -0700 (PDT) Date: Wed, 01 Nov 2000 09:18:17 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Wed, 01 Nov 2000 11:40:06 -0500" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JW0RRT2H4800011D@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01JVZZX0ZI7M00046H@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This continued argument about the exact nature of past mistakes is going nowhere fast, so I'm not going to bother to respond further to it. Ned Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26381 for ietf-xml-mime-bks; Wed, 1 Nov 2000 08:26:54 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26377 for ; Wed, 1 Nov 2000 08:26:52 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA13062 for ; Wed, 1 Nov 2000 11:31:46 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 1 Nov 2000 11:40:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: <01JVZZX0ZI7M00046H@mauve.mrochek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > But the analogy is gravely flawed in any case -- text/html > > > has proved to have no value whatsoever. And this goes far > > > beyond the notion of "good" and "bad" use. > > > I think the millions of messages sent using text/html would > > disprove the notion that "text/html has proved to have no value > > whatsoever". > > Actually, the type's use proves nothing, since as I pointed out > previously, it isn't necessary to use the type to get the > right effect. The point is that there is a use driven by a need. Your statement that "text/html has proved to be of no value whatsoever" is simply false. The fact is that text/html (while being used in ways other than strictly intended), has served a tremendous use in allowing people to exchange richer email messages than text/plain. > And you are arguing a strawman here. I never said that sending HTML > was of no use, only that the labelling of it as text/html was and > is unnecessary. "unnecessary" != "no value whatsoever" The community adopted text/html because they weren't presented with any other mechanism (or at least, the alternatives weren't presented anywhere nearly as clearly or forcibly). The community made great use out of it. > > Anyway, the genie *is* out of the bag. > > For HTML it is. Doesn't mean it is out of the bag for other > types. We should learn from our mistakes. I agree. I think *the* mistake (at the MIME level)with HTML is *not* text/html, but rather one of specification and under education: text/html could have been registered, and the specification could have clearly stated that alternatives existed for use when the amount of markup rendered the message essentially uninterpretable. That said, I would argue that the real mistake is in abusing HTML in the first place, but that practise is well established now. > Because it isn't what we told them to do. We told them to use > text/html, so that's what they did. Right. They were not presented with a choice, and *that* is the historical mistake. > But we also said that the HTML had to be legible. That didn't > happen. Sure, but what else could have happened? Vendors were shoe-horning HTML support onto existing tools, and there was a marketing need to get products shipping with support for exchanging HTML content. > The point is now we know better, so we should not let it happen > again. I strongly agree with you. That to me means presenting 1) choices for types 2) clear guidelines on their use. I have faith that when presented with those two things, developers will do what is right. > I believe my argument discounts it quite effectively. Well, belief is a very personal, very subjective thing. I do *not* believe your argument discounts it at all. Your arguments seem to me to be an overreaction to something I think we can all agree is less than perfect. > In addition, I haven't noticed a lot of support for other > quarters for your approach. Perhaps people are just tired of debate and are moving with their feet? XML 1.0 *has* been around for a long time, and SGML, even longer. Developers come to the IETF looking for guidance in standards conformant deployment. In lieu of a standard, a draft will suffice. In lieu of a draft, rough concensus will suffice. I think the developer community has largely already made up it's mind.