Received: by mail.proper.com (8.9.3/8.9.3) id KAA15330 for ietf-822-bks; Thu, 23 Sep 1999 10:47:20 -0700 (PDT) Received: from inet16.us.oracle.com (inet16.us.oracle.com [209.246.15.50]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA15326 for ; Thu, 23 Sep 1999 10:47:19 -0700 (PDT) Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet16.us.oracle.com (8.9.2/8.8.5) with SMTP id KAA19377 for ; Thu, 23 Sep 1999 10:51:21 -0700 (PDT) Received: from skwong-pc3 by usmail04 with SMTP (SMI-8.6/37.9) id KAA01250; Thu, 23 Sep 1999 10:51:21 -0700 Message-ID: <003501bf05eb$df90de90$b6be1990@skwong-pc3.us.oracle.com> From: "Simon K. Wong" To: Subject: Encoding and decoding of an encoded word in Java Date: Thu, 23 Sep 1999 10:48:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01BF05B1.3317C7D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0032_01BF05B1.3317C7D0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Hi, According to RFC2047, 8 bit characters in header fields=20 are encoded in 'encoded words'. Is there any place I can find the encoding and decoding Java code for 'encoded word'? Thanks, Simon ------=_NextPart_000_0032_01BF05B1.3317C7D0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable

Hi,

According to RFC2047, 8 bit = characters in=20 header fields

are encoded in 'encoded = words'.

Is there any place I can find = the encoding=20 and decoding

Java code for 'encoded = word'?

Thanks,

Simon

------=_NextPart_000_0032_01BF05B1.3317C7D0-- Received: by mail.proper.com (8.9.3/8.9.3) id EAA00437 for ietf-822-bks; Tue, 14 Sep 1999 04:13:01 -0700 (PDT) Received: from m1.cs.man.ac.uk (IDENT:0@m1.cs.man.ac.uk [130.88.192.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA00433 for ; Tue, 14 Sep 1999 04:12:58 -0700 (PDT) Received: from clw.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id MAA09307; Tue, 14 Sep 1999 12:15:40 +0100 (BST) Received: (from news@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id MAA06588 for ietf-822@imc.org; Tue, 14 Sep 1999 12:12:06 +0100 (BST) To: ietf-822@imc.org Xref: clerew local.mime:235 Newsgroups: local.mime Path: clerew!chl From: chl@clw.cs.man.ac.uk (Charles Lindsey) Subject: Re: Ignoring non-MIME mailers? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> Date: Tue, 14 Sep 1999 09:42:12 GMT Lines: 23 Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In Jacob Palme writes: >I have been wondering when the time would come when we could stop >having non-mime compatibility as a major goal. I would guess 98 % of >all mail users today use mime-compliant mailers. But there is the >rest. We have, at our university department, a teacher who refuses to >use anything else than some old non-MIME unix mailer. She says that >if she gets a message her mailer cannot handle, she will forward it >to another e-mail address at which she can read it using MIME. But >only as a last resort! ITYM 98% of users use mailers that _imagine_ they are mime-compliant :-( . -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: by mail.proper.com (8.9.3/8.9.3) id DAA29159 for ietf-822-bks; Tue, 14 Sep 1999 03:14:13 -0700 (PDT) Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA29155 for ; Tue, 14 Sep 1999 03:14:10 -0700 (PDT) Received: from GK-Portable (unverified [193.149.81.244]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id ; Tue, 14 Sep 1999 11:05:55 +0100 Message-Id: <3.0.32.19990914110920.009dfaa0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 14 Sep 1999 11:15:00 +0100 To: Laurence Lundblade From: Graham Klyne Subject: Re: Alternative multipart/alternative? Cc: ietf-822@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 15:36 13/09/99 -0700, Laurence Lundblade wrote: >At 11:29 PM 9/13/99 +0100, Graham Klyne wrote: > >>The case I am considering is to do with fax image formats, so that doesn't >>really help. I was checking to ascertain whether or not there might be an >>existing mechanism before considerations turn to inventing someting new. > > >Ahh, then maybe it makes sense to resurrect my draft for one-pass >processing, or at least something similar? Well, maybe. As it stands, "-1pass-" is not quite enough because it deals with content types only, and we wish to distinguish different instances of the same content type, but I believe we've discussed this... Actually, the idea of sending multiple copies of data is not favoured by many for Internet fax -- an idea I have been playing with, though, is to use a combination of multipart/alternative and message/external-body. But that is dogged by the one-pass issue. #g ------------ Graham Klyne (GK@ACM.ORG) Received: by mail.proper.com (8.9.3/8.9.3) id RAA13131 for ietf-822-bks; Mon, 13 Sep 1999 17:42:06 -0700 (PDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA13127 for ; Mon, 13 Sep 1999 17:42:04 -0700 (PDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 3.0a14); Mon, 13 Sep 1999 19:44:59 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> X-Mailer: Eudora [Macintosh version 4.2b??] Date: Mon, 13 Sep 1999 19:44:49 -0500 To: Jacob Palme From: Pete Resnick Subject: Re: Ignoring non-MIME mailers? Cc: ietf-822@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On 9/14/99 at 2:30 AM +0200, Jacob Palme wrote: >I have been wondering when the time would come when we could stop >having non-mime compatibility as a major goal. I would guess 98 % of >all mail users today use mime-compliant mailers. Given that AOL is only vaguely MIME compliant (if you squint your eyes a lot), I think your estimate of 98% is wildly exaggerated. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by mail.proper.com (8.9.3/8.9.3) id RAA12976 for ietf-822-bks; Mon, 13 Sep 1999 17:32:31 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA12972 for ; Mon, 13 Sep 1999 17:32:30 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id CAA28534 for ; Tue, 14 Sep 1999 02:35:43 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> References: <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> Date: Tue, 14 Sep 1999 02:30:04 +0200 To: ietf-822@imc.org From: Jacob Palme Subject: Ignoring non-MIME mailers? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10.29 -0700 99-09-13, Laurence Lundblade wrote: >However if we ignore non-MIME mailers for arguments sake then >reversing the order would help with low memory implementations. The >client skips alternatives until one is found that can be handled >without having to "save" the previous part during the parse. I have been wondering when the time would come when we could stop having non-mime compatibility as a major goal. I would guess 98 % of all mail users today use mime-compliant mailers. But there is the rest. We have, at our university department, a teacher who refuses to use anything else than some old non-MIME unix mailer. She says that if she gets a message her mailer cannot handle, she will forward it to another e-mail address at which she can read it using MIME. But only as a last resort! ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme Received: by mail.proper.com (8.9.3/8.9.3) id PAA11843 for ietf-822-bks; Mon, 13 Sep 1999 15:46:55 -0700 (PDT) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11839 for ; Mon, 13 Sep 1999 15:46:54 -0700 (PDT) Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id PAA29862; Mon, 13 Sep 1999 15:50:04 -0700 (PDT) Message-Id: <4.2.0.58.19990913153354.00a89600@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Sep 1999 15:36:16 -0700 To: Graham Klyne From: Laurence Lundblade Subject: Re: Alternative multipart/alternative? Cc: ietf-822@imc.org In-Reply-To: <3.0.32.19990913203419.009957d0@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11:29 PM 9/13/99 +0100, Graham Klyne wrote: >The case I am considering is to do with fax image formats, so that doesn't >really help. I was checking to ascertain whether or not there might be an >existing mechanism before considerations turn to inventing someting new. Ahh, then maybe it makes sense to resurrect my draft for one-pass processing, or at least something similar? If there aren't a lot of implementations out there and you can strongly suggest implementations add the "types" parameter you avoid the main reason for which I abandoned it - it was not used by the installed base that had to be interoperated with. LL Received: by mail.proper.com (8.9.3/8.9.3) id PAA11724 for ietf-822-bks; Mon, 13 Sep 1999 15:29:07 -0700 (PDT) Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11720 for ; Mon, 13 Sep 1999 15:29:02 -0700 (PDT) Received: from GK-Portable (unverified [62.188.142.59]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id ; Mon, 13 Sep 1999 23:20:24 +0100 Message-Id: <3.0.32.19990913203419.009957d0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 13 Sep 1999 23:29:34 +0100 To: Laurence Lundblade From: Graham Klyne Subject: Re: Alternative multipart/alternative? Cc: ietf-822@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:29 13/09/99 -0700, Laurence Lundblade wrote: >At 09:35 AM 9/13/99 -0400, Keith Moore wrote: >> > Did somebody once propose an modified form of multipart/alternative, with >> > reversed ordering of the alternative parts (i.e. high-to-low fidelity >> > rather than the standard low-to-high)? >> >>in the absence of a mechansim to know whether the recipient could >>handle such a construct, what would be the point? > >There's a distinction here between the recipient handling MIME and the >recipient handling the particular most rich alternative. I believe m/a >ordering was chosen with the user of a non-MIME mailer in mind where the >text part will show up before the (for them) alphabet soup b64'd PDF or >such. Being friendly to non-MIME mailers is important and probably >eliminates any possibility of reversing the order. I generally agree with all of the above. Your belief is what I understand to be stated by RFC 2046 on m/a. >However if we ignore non-MIME mailers for arguments sake then reversing the >order would help with low memory implementations. The client skips >alternatives until one is found that can be handled without having to >"save" the previous part during the parse. Yes... "if". >.... If you're >trying to MIME parse one-pass right of the wire because you can't store >much of the message at all then you're sort of stuck. I believe this is the >*single aspect of MIME* that prohibits one-pass processing. Again, I agree. (w.r.t MIME conformance per RFC 2049?) >One option to get around this might be to assume that m/a is generally used >only for text/plain and text/html. I can't recall seeing anything else. If >that's the case then you make your decision at coding time. If your >implementation can deal with HTML you always skip the text/plain >alternative. If it can't you always take the text/plain alternative. The case I am considering is to do with fax image formats, so that doesn't really help. I was checking to ascertain whether or not there might be an existing mechanism before considerations turn to inventing someting new. Thanks, #g ------------ Graham Klyne (GK@ACM.ORG) Received: by mail.proper.com (8.9.3/8.9.3) id OAA11328 for ietf-822-bks; Mon, 13 Sep 1999 14:55:20 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11324 for ; Mon, 13 Sep 1999 14:55:18 -0700 (PDT) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.Beta0/8.10.0.Beta0) with ESMTP id d8DLJil19664; Mon, 13 Sep 1999 17:19:45 -0400 Message-Id: <199909132119.d8DLJil19664@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: Laurence Lundblade Cc: ietf-822@imc.org Subject: Re: Alternative multipart/alternative? In-Reply-To: Your message of "Mon, 13 Sep 1999 10:29:26 PDT." <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2009913088P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 13 Sep 1999 17:19:38 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --==_Exmh_-2009913088P Content-Type: text/plain; charset=us-ascii On Mon, 13 Sep 1999 10:29:26 PDT, Laurence Lundblade said: > One option to get around this might be to assume that m/a is generally used > only for text/plain and text/html. I can't recall seeing anything else. If I've actually seen one that had text/plain, text/html, and application/msword. I seeme to remember one that was text/html and an external-bodypart reference to a VRML file, but that could have been just a bad dream ;) > that's the case then you make your decision at coding time. If your > implementation can deal with HTML you always skip the text/plain > alternative. If it can't you always take the text/plain alternative. I've seen *plenty* of borked multipart/alternative that only includes a text/plain bodypart. This would Lose Big Time if your implementation always chooses the HTML variant. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-2009913088P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN91qaNQBOOoptg9JAQFduQP9EHP3HjUrgn614+nfAuX7Rgk5xngV9Nu0 iy5wa/9SKS0t3m+By3Kw0luEv7WXu79nu2UFJqTnAlKgZTu4dpSBzQ1CdyVKk1pk D6hMbGPbHjfriNQWyUxL95YxX4kLdGs5FUDfQe5gx1HD1Aa3WIgcfSw51g6XxYqV SYaW7f+sS0Y= =LJIE -----END PGP MESSAGE----- --==_Exmh_-2009913088P-- Received: by mail.proper.com (8.9.3/8.9.3) id KAA07221 for ietf-822-bks; Mon, 13 Sep 1999 10:11:54 -0700 (PDT) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07213 for ; Mon, 13 Sep 1999 10:11:50 -0700 (PDT) Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id KAA18713; Mon, 13 Sep 1999 10:14:50 -0700 (PDT) Message-Id: <4.2.0.58.19990913101617.009f4bb0@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Sep 1999 10:29:26 -0700 To: Keith Moore , Graham Klyne From: Laurence Lundblade Subject: Re: Alternative multipart/alternative? Cc: ietf-822@imc.org In-Reply-To: <199909131335.JAA22550@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:35 AM 9/13/99 -0400, Keith Moore wrote: > > Did somebody once propose an modified form of multipart/alternative, with > > reversed ordering of the alternative parts (i.e. high-to-low fidelity > > rather than the standard low-to-high)? > >in the absence of a mechansim to know whether the recipient could >handle such a construct, what would be the point? There's a distinction here between the recipient handling MIME and the recipient handling the particular most rich alternative. I believe m/a ordering was chosen with the user of a non-MIME mailer in mind where the text part will show up before the (for them) alphabet soup b64'd PDF or such. Being friendly to non-MIME mailers is important and probably eliminates any possibility of reversing the order. However if we ignore non-MIME mailers for arguments sake then reversing the order would help with low memory implementations. The client skips alternatives until one is found that can be handled without having to "save" the previous part during the parse. I gave up on the parameter for one-pass processing because I had enough room to store the whole message (or at least the more important first 32Kb of the message) and there's so much m/a that it had to be processed anyway. There was also less than stellar support for it. So my implementation stores the whole message coming off the wire and then remembers a pointer to the start of the previous alternative so it can go back to it when an alternative is found that can't be handled. If you're trying to MIME parse one-pass right of the wire because you can't store much of the message at all then you're sort of stuck. I believe this is the *single aspect of MIME* that prohibits one-pass processing. One option to get around this might be to assume that m/a is generally used only for text/plain and text/html. I can't recall seeing anything else. If that's the case then you make your decision at coding time. If your implementation can deal with HTML you always skip the text/plain alternative. If it can't you always take the text/plain alternative. LL Received: by mail.proper.com (8.9.3/8.9.3) id GAA03854 for ietf-822-bks; Mon, 13 Sep 1999 06:37:46 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA03850 for ; Mon, 13 Sep 1999 06:37:45 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id JAA22550; Mon, 13 Sep 1999 09:35:24 -0400 (EDT) Message-Id: <199909131335.JAA22550@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: ietf-822@imc.org Subject: Re: Alternative multipart/alternative? In-reply-to: Your message of "Mon, 13 Sep 1999 12:03:37 BST." <3.0.32.19990913112007.007b5b30@pop.dial.pipex.com> Date: Mon, 13 Sep 1999 09:35:24 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Did somebody once propose an modified form of multipart/alternative, with > reversed ordering of the alternative parts (i.e. high-to-low fidelity > rather than the standard low-to-high)? in the absence of a mechansim to know whether the recipient could handle such a construct, what would be the point? (and if you had such a mechanism, you could dispense with multipart/ alternative altogether) Received: by mail.proper.com (8.9.3/8.9.3) id EAA01684 for ietf-822-bks; Mon, 13 Sep 1999 04:02:40 -0700 (PDT) Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA01680 for ; Mon, 13 Sep 1999 04:02:38 -0700 (PDT) Received: from GK-Portable (unverified [62.188.146.143]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id for ; Mon, 13 Sep 1999 11:54:21 +0100 Message-Id: <3.0.32.19990913112007.007b5b30@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 13 Sep 1999 12:03:37 +0100 To: From: Graham Klyne Subject: Alternative multipart/alternative? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-822@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Did somebody once propose an modified form of multipart/alternative, with reversed ordering of the alternative parts (i.e. high-to-low fidelity rather than the standard low-to-high)? In its present form, multipart/alternative is not an option for low-memory receiving systems. (I am aware of Laurence Lundblade's proposal , now expired, for a header to simplify one-pass processing by listing the inner content types.) #g ------------ Graham Klyne (GK@ACM.ORG)