Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA20332 for ietf-xml-mime-bks; Tue, 30 May 2000 00:55:45 -0700 (PDT) Received: from unknown ([208.242.34.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA20313; Tue, 30 May 2000 00:55:41 -0700 (PDT) From: bench3@themail.com Subject: your imaging supplies Date: Mon, 29 May 2000 12:20:01 Message-Id: <241.783535.691685@> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES FOR THE FOLLOWING PRINTERS: APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $84 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19948 for ietf-xml-mime-bks; Thu, 18 May 2000 08:02:45 -0700 (PDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19939 for ; Thu, 18 May 2000 08:02:34 -0700 (PDT) From: jsaiya@mindspring.com Received: from smui4.eng00.mindspring.net (smui4.eng00.mindspring.net [207.69.200.49]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA08158; Thu, 18 May 2000 11:08:54 -0400 (EDT) Received: by smui4.eng00.mindspring.net id LAA0000003097; Thu, 18 May 2000 11:08:53 -0400 (EDT) Date: Thu, 18 May 2000 11:08:53 -0400 To: ietf-xml-mime@imc.org Cc: jsaiya@formatdata.com Subject: Re: Announcement of yet another I-D for XML media types Message-ID: X-Originating-IP: 208.22.162.54 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MURATA, Dan, and Simon, You might want to proof Appendix C. Revision History of the latest I-D. It appears you did a global replace of "|xml" with "+xml" (and in version 03, of "-xml" with "|xml") -- by doing so, you've changed history, so to speak. :) Jim Saiya FormatData http://www.formatdata.com/ mailto:jsaiya@formatdata.com P.S. Forgive me if I've used a surname where I meant to use a given name; I'm not familiar with the Japanese convention. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17755 for ietf-xml-mime-bks; Tue, 16 May 2000 09:39:08 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17751 for ; Tue, 16 May 2000 09:39:07 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.39]) by prserv.net (out1) with SMTP id <20000516164512252012p229e>; Tue, 16 May 2000 16:45:12 +0000 To: ietf-xml-mime@imc.org Subject: Announcement of yet another I-D for XML media types X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000517014611A.muraw3c@attglobal.net> Date: Wed, 17 May 2000 01:46:11 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Simon, and I created yet another I-D for XML media types. It is available at: http://www.ietf.org/internet-drafts/draft-murata-xml-04.txt The biggest change is the suffix. It is "+xml" rather than "|xml". Miles Sabin pointed out that "|" is missing in some variations of EBCDIC. We thus believe "|" is inappropriate. We believe that the mojority of this ML prefer "+" to "-". In reply to Rick Jelliffee, we added arguments against the charset parameter of application/xml. We have also made it clear that users are not forced to read and write %HH. We are looking forward to your feedbacks. MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28273 for ietf-xml-mime-bks; Fri, 12 May 2000 11:27:19 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28269 for ; Fri, 12 May 2000 11:27:18 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12464 for ; Fri, 12 May 2000 11:33:28 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA20159 for ; Fri, 12 May 2000 14:33:26 -0400 (EDT) Message-ID: <391C4E84.1D7B36F0@canada.sun.com> Date: Fri, 12 May 2000 14:33:41 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Separator References: <39197333.8218B8A9@w3.org> <01JP9UHLCLLQ0000BY@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings, I don't like "|" precisely because it means "or" in many contexts. "Accept: text/html text/xml" has "or" semantics, and I'd prefer not to prompt people to wonder whether "Accept: text/html|xml" means the same thing. A similar but weaker argument would hold for "+". But it's not *that* big an issue for me. It's just the biggest one I could think of. 8-) MB Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21662 for ietf-xml-mime-bks; Thu, 11 May 2000 12:01:56 -0700 (PDT) Received: from mauve.innosoft.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21653 for ; Thu, 11 May 2000 12:01:54 -0700 (PDT) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JP9L7M0X680000BY@mauve.mrochek.com> for ietf-xml-mime@imc.org; Thu, 11 May 2000 12:07:46 -0800 (PST) Date: Thu, 11 May 2000 12:05:39 -0800 (PST) Subject: Re: Announcement of a new I-D In-reply-to: "Your message dated Wed, 10 May 2000 12:17:43 -0400" <200005101617.MAA06647@astro.cs.utk.edu> To: Keith Moore Cc: Chris Lilley , muraw3c@attglobal.net, davep@acm.org, ietf-xml-mime@imc.org Message-id: <01JP9UHLCLLQ0000BY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <39197333.8218B8A9@w3.org> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > the bare symbol "-" was not being proposed as a separator al by itself. > actually, a big problem with the "-xml" suffix proposal is that it > assumes that there will never be any other content-type frobs used > in combination with "-xml". but enough things like this have been > proposed over the past 10 years that it seems likely that there will > be more such frobs. so I'd like to see a unique separator character > as opposed to one which already appears in several content-types. I really don't want to restart this debate, however, I have to note that there is substantial disagreement with your assessment that "enough things like this have been proposed over the past 10 years...". But regardless, I think avoiding separators we already use is a good idea. I personally like "+", but I could live with any of the others as well. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01253 for ietf-xml-mime-bks; Wed, 10 May 2000 09:39:28 -0700 (PDT) Received: from smtp.gatewaymail.net (IDENT:root@[207.34.179.250]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01249 for ; Wed, 10 May 2000 09:39:27 -0700 (PDT) Received: from FRITZ (00-10-4b-22-27-db.bconnected.net [209.53.11.246]) by smtp.gatewaymail.net (8.9.3/8.9.3) with SMTP id JAA13670; Wed, 10 May 2000 09:41:25 -0700 Message-Id: <3.0.32.20000510094325.0152f220@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 10 May 2000 09:44:07 -0700 To: John Cowan , muraw3c@attglobal.net, davep@acm.org, "ietf-xml-mime@imc.org" From: Tim Bray Subject: Re: Announcement of a new I-D 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 10:35 AM 5/10/00 -0400, John Cowan wrote: >muraw3c@attglobal.net wrote: > >> Which one do you strongly recommend? It is not too late. > >I like "+", which could be understood as meaning "and also". Me too. -Tim Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00200 for ietf-xml-mime-bks; Wed, 10 May 2000 09:11:50 -0700 (PDT) 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 JAA00193 for ; Wed, 10 May 2000 09:11:48 -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 MAA06647; Wed, 10 May 2000 12:17:44 -0400 (EDT) Message-Id: <200005101617.MAA06647@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Chris Lilley cc: muraw3c@attglobal.net, davep@acm.org, ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D In-reply-to: Your message of "Wed, 10 May 2000 16:33:23 +0200." <39197333.8218B8A9@w3.org> Date: Wed, 10 May 2000 12:17:43 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > the bare symbol "-" was not being proposed as a separator al by itself. actually, a big problem with the "-xml" suffix proposal is that it assumes that there will never be any other content-type frobs used in combination with "-xml". but enough things like this have been proposed over the past 10 years that it seems likely that there will be more such frobs. so I'd like to see a unique separator character as opposed to one which already appears in several content-types. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27608 for ietf-xml-mime-bks; Wed, 10 May 2000 07:42:49 -0700 (PDT) Received: from odin.cromwellmedia.co.uk ([212.2.15.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27604 for ; Wed, 10 May 2000 07:42:48 -0700 (PDT) Received: by odin.cromwellmedia.co.uk with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 15:50:31 +0100 Message-ID: <43C2F98D8414D411865A00508BC22AB908CB27@odin.cromwellmedia.co.uk> From: Miles Sabin To: muraw3c@attglobal.net, davep@acm.org Cc: ietf-xml-mime@imc.org Subject: RE: Announcement of a new I-D Date: Wed, 10 May 2000 15:50:25 +0100 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: MURATA Makoto wrote, > Dave Peterson wrote, > > At 1:37 AM +0900 5/10/00, muraw3c@attglobal.net wrote: > > > At the ietf-822 mailing list, Keith Moore [1] pointed out > > > that "-" is already used too heavily by existing media > > > types. Chris Newman [2] suggested ~!$^+{}| We picked | > > > > One of the others would have had the advantage that it > > doesn't look like another character (e.g., Cap I and/or > > lower case L in san-serif) in any common fonts. > > Which one do you strongly recommend? It is not too late. One possible problem with '|'. Judging from RFC 1345 there are a couple of EBCDIC variants it's missing from, in particular IBM038 aka EBCDIC-INT. I've no idea if _anyone_ would ever want to be able to round-trip MIME headers with XML Content-Types through that encoding, but if they did it might be fiddly. ISO 646 specifies the following 'invariant graphic characters' which should be available in any encoding worth bothering with, ! " % ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? A B C D E F G H I J K L M N O P Q R S T U V W X Y Z _ a b c d e f g h i j k l m n o p q r s t u v w x y z and the intersection of that set with Chris Newmans selection boils down to, ! $ + in which case I'd probably opt for '+'. OTOH, maybe this just isn't worth worrying about. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England msabin@cromwellmedia.com http://www.cromwellmedia.com/ Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27559 for ietf-xml-mime-bks; Wed, 10 May 2000 07:39:37 -0700 (PDT) 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 HAA27555 for ; Wed, 10 May 2000 07:39:35 -0700 (PDT) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id e4AEjI212024; Wed, 10 May 2000 22:45:18 +0800 (CST) Date: Wed, 10 May 2000 22:45:18 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: davep@acm.org, "ietf-xml-mime@imc.org" Subject: Re: Announcement of a new I-D In-Reply-To: <391973AD.C81076E0@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, 10 May 2000, John Cowan wrote: > muraw3c@attglobal.net wrote: > > > Which one do you strongly recommend? It is not too late. I like svg|xml because it gives the idea "you can process this as SVG or XML" (if we take | to mean choice). Also, it suggests UNIX pipes, "this is SVG through XML" which is also neat. Things change between drafts: would it really cause trouble to change svg-xml to svg|xml ? Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27376 for ietf-xml-mime-bks; Wed, 10 May 2000 07:30:20 -0700 (PDT) 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 HAA27372 for ; Wed, 10 May 2000 07:30:19 -0700 (PDT) Received: from reutershealth.com (IDENT:cowan@skunk.reutershealth.com [204.243.9.153]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id KAA18340; Wed, 10 May 2000 10:36:16 -0400 (EDT) Message-ID: <391973AD.C81076E0@reutershealth.com> Date: Wed, 10 May 2000 10:35:25 -0400 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: muraw3c@attglobal.net, davep@acm.org, "ietf-xml-mime@imc.org" Subject: Re: Announcement of a new I-D References: <3918373C.29FE0BA6@w3.org> <20000510013705U.muraw3c@attglobal.net> <20000510231055O.muraw3c@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: muraw3c@attglobal.net wrote: > Which one do you strongly recommend? It is not too late. I like "+", which could be understood as meaning "and also". For example, "image/svg+xml" would mean that this is an image using the format named "svg" which is also an instance of XML. -- Schlingt dreifach einen Kreis um dies! || John Cowan Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27325 for ietf-xml-mime-bks; Wed, 10 May 2000 07:27:33 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27321 for ; Wed, 10 May 2000 07:27:31 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA00516; Wed, 10 May 2000 10:33:23 -0400 Message-ID: <39197333.8218B8A9@w3.org> Date: Wed, 10 May 2000 16:33:23 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: muraw3c@attglobal.net CC: davep@acm.org, ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D References: <3918373C.29FE0BA6@w3.org> <20000510013705U.muraw3c@attglobal.net> <20000510231055O.muraw3c@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: muraw3c@attglobal.net wrote: > > From: Dave Peterson > Subject: Re: Announcement of a new I-D > Date: Tue, 9 May 2000 13:11:29 -0400 > > > At 1:37 AM +0900 5/10/00, muraw3c@attglobal.net wrote: > > > > >At the ietf-822 mailing list, Keith Moore [1] pointed out that "-" is > > >already used too heavily by existing media types. Chris Newman [2] > > >suggested ~!$^+{}| We picked | > > > > One of the others would have had the advantage that it doesn't look like > > another character (e.g., Cap I and/or lower case L in san-serif) in any > > common fonts. > > Which one do you strongly recommend? It is not too late. Well if it is not too late, I would very much like to see the separator altered back to "-". The trailing string "-xml" does not occur, as you say, in any registered MIME types. The frequency of "-" or indeed of "x" "m" and "l" elsewhere in registered types is irrelevant. the bare symbol "-" was not being proposed as a separator al by itself. It was the terminal string "-xml" which, as you point out, is unused in any existing MIME type and thus there is no possibility of confusion. However, SVG is getting close to finished and we would like a stable naming system to use. The latest SVG last call working draft in fact stated that the MIME type for SVG would be registered as "image/svg-xml". If the trailing string is altered to "|xml" then the SVG WG has to choose between moving to the new preferred syntax, or staying with the old one and loosing any semantic about general XML processing. -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26944 for ietf-xml-mime-bks; Wed, 10 May 2000 07:05:42 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26940 for ; Wed, 10 May 2000 07:05:41 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.244]) by prserv.net (out2) with SMTP id <2000051014111622900bcat9e>; Wed, 10 May 2000 14:11:17 +0000 To: davep@acm.org Cc: ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D In-Reply-To: References: <3918373C.29FE0BA6@w3.org> <20000510013705U.muraw3c@attglobal.net> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510231055O.muraw3c@attglobal.net> Date: Wed, 10 May 2000 23:10:55 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Dave Peterson Subject: Re: Announcement of a new I-D Date: Tue, 9 May 2000 13:11:29 -0400 > At 1:37 AM +0900 5/10/00, muraw3c@attglobal.net wrote: > > >At the ietf-822 mailing list, Keith Moore [1] pointed out that "-" is > >already used too heavily by existing media types. Chris Newman [2] > >suggested ~!$^+{}| We picked | > > One of the others would have had the advantage that it doesn't look like > another character (e.g., Cap I and/or lower case L in san-serif) in any > common fonts. Which one do you strongly recommend? It is not too late. Cheers, MURATA Makoto Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA26339 for ietf-xml-mime-bks; Tue, 9 May 2000 21:03:51 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26335 for ; Tue, 9 May 2000 21:03:50 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.195]) by prserv.net (out4) with SMTP id <20000510040946239039sajre>; Wed, 10 May 2000 04:09:46 +0000 To: ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D In-Reply-To: <20000509233703R.muraw3c@attglobal.net> References: <20000509233703R.muraw3c@attglobal.net> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510131020Q.muraw3c@attglobal.net> Date: Wed, 10 May 2000 13:10:20 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 101 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rick, Thank you for your comments. Some of your comments (XML Base, UTF-16LE/BE) should actually go to the XML Core WG of W3C and the ietf-charset mailing list. > 1) Charset "should" be given for application/xml. HTTP has a character > set handling concept that comes from fantasyland. I would recommend a > very different policy: never use xml/data, always use application/xml; > never use charset, always use xml encoding declarations. RFC 2376 already has this attribute. We cannot remove it. You do not have to use this attribute. Then, you will get what you want. I am willing to add arguments for and against this attribute to the next I-D. > 2) "When non-validating processors handle XML documents, they do not > always read external parsed entities. Thus, interoperability is > not guaranteed." > This is just FUD: why isnt this handled by the "standalone" declaration. > If it is a comment about bugs in software, that is out-of-place here. If two processors emit different element structures, we do not have interoperability. Thus, XML 1.0 does not provide full interoperability unfortunately. (I keep kicking myself for not voting against external parsed entities.) standalone="no" provides helpful warning. But it does not provide interoperability. It merely makes the problem explicit. > 3) Support for xml:base. If XML Base becomes a W3C recommendation, our upcoming RFC must mention XML Base. If it does not, it must be omitted. The I-D mentions it, since XML Base is in the last call phase. You might want to send your comments to www-xml-linking-comments@w3.org. I am personally not a big fan of xml:base. It may be useful for XLink&XPointer. But XML Base is intended to affects *any* attribute if application programs use it as a relave URI reference. I do not think all application programmers will agree to implement XML Base. But I have had little support. > 4) The rocket scientists at IETF have managed a new thing with the spec > for utf16be (if you use utf16be you cannot have a BOM apparantly): it This issue has been extensively discussed at Unicode Consortium as well as the ietf-charset mailing list. We already have an RFC (RFC 2781). I believe that the consensus at W3C is to allow UTF-16LE/BE as optional charsets for XML (encoding declarations are requried, though.) Again, you might want to argue at W3C (I18N IG and XML Core WG). I am personally not a fan of UTF-16LE/BE either. > 5) Along similar lines, but far worse and of major importance for > internationalization, the fragment identifier of a URI has to be in > US-ASCII with %HH escaping. Here I am in Taipei and I want to include > an Xpointer to refer to an ID or element name or attribute name or > value, and I have to first find the numeric values of my Big5, then > trancode it into Unicode, then find out what the Unicode values are in > HEX, then put them in. Is that the way it is supposed to work? No, it is not the way it is supposed to work. Believe me, I would never agree on such a horrible scenario! (But I am willing to expand the I-D to address your concern.) You write a "URI reference" in Big5. This is fine. Before sending the "URI reference" to protocols such as HTTP, programs have to convert it to the %HH format. In other words, %HH exists on the wire only. When interpreting such URIs containing %HH, recipient programs have to reconstruct Unicode characters. HTML 4.01 already recommend users agents to convert non-ASCII characters to %HH. See http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.1 URI is defined by RFC 2396, and it allows a limited subset of the repertoire of ASCII characters only. (Since a URI is a protocol element, I think that this is acceptable.) A new spec for IURI is being developed. It is available at: http://search.ietf.org/internet-drafts/draft-masinter-url-i18n-05.txt > Good to see: > > > 1) |xml suffix is great idea > > > 2) MIME types for DTDs and external parsed entities Thanks. Cheers, Makoto Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA26280 for ietf-xml-mime-bks; Tue, 9 May 2000 21:00:00 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26273 for ; Tue, 9 May 2000 20:59:59 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.195]) by prserv.net (out4) with SMTP id <200005100405512390301svve>; Wed, 10 May 2000 04:05:52 +0000 To: ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D In-Reply-To: <20000509233703R.muraw3c@attglobal.net> References: <20000509233703R.muraw3c@attglobal.net> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510130626P.muraw3c@attglobal.net> Date: Wed, 10 May 2000 13:06:26 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 139 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rick Jelliffe posted this reply to xml-dev. Since this I-D should be discussed here, I am forwarding his message. > Murata Makoto wrote: > > > We are looking forward to your feedbacks. > > > Very disappointing to see: > > > 1) Charset "should" be given for application/xml. HTTP has a character > set handling concept that comes from fantasyland. I would recommend a > very different policy: never use xml/data, always use application/xml; > never use charset, always use xml encoding declarations. > > > 2) "When non-validating processors handle XML documents, they do not > always read external parsed entities. Thus, interoperability is > not guaranteed." > This is just FUD: why isnt this handled by the "standalone" declaration. > If it is a comment about bugs in software, that is out-of-place here. > > > > 3) Support for xml:base. Xml:base is currently being railroaded through > W3C with requirements document--on behalf of my organization which is a > W3C member I have repeatedly asked what its justification is, and there > has never been any answer. Xml:base is dangerous because it creates an > unlabelled dialect of XML--a general XML editor cannot treat URIs as > text when cutting and pasting, it also may have to do something with > xml:base. It would be OK if managed as part of some more general > package, but not by itself. In any case, it is not clear whether > xml:base applies to all data marked by a schema as a URI or just to data > marked as an xlink:href. It does not apply to URIs in SYSTEM identifiers > in entities, ASAIK. > > > Without knowing which URIs are "known" by xml:base, and what its > interaction is with xml schemas, broad statements that embedded URIs > should be interpreted relative to xml:base are surely incorrect, or at > least too early. There is no need for F with xml:base, but U and D are > certainly warranted. > > > 4) The rocket scientists at IETF have managed a new thing with the spec > for utf16be (if you use utf16be you cannot have a BOM apparantly): it > means that not only can you do too little as far as labelling your data, > you can now do *too much*! If you want to use big-endian utf16 and your > software sticks in a BOM just to be safe you are ruined. I thought I had > seen everything. This makes the well-intentioned user pay: it looks like > an enabling provision, but its effect is surely to prevent the use of > big-endian UTF16. Users should not be penalized for providing "too > much" labelling. > > > 5) Along similar lines, but far worse and of major importance for > internationalization, the fragment identifier of a URI has to be in > US-ASCII with %HH escaping. Here I am in Taipei and I want to include > an Xpointer to refer to an ID or element name or attribute name or > value, and I have to first find the numeric values of my Big5, then > trancode it into Unicode, then find out what the Unicode values are in > HEX, then put them in. Is that the way it is supposed to work? This is > exactly the sort of thing that should be provided by the XML > infrastructure, not by the poor user: to tell the user "you can say > 'yes' in your native language in that attribute value, but you cannot > type it directly when you want to reference that elemement" is not > acceptable. And what about XSLT: does it mean that when I use an XPath > which includes a document() reference, that I have to suddenly stop when > I get to the fragment identifier of the URI and switch to %HH? > > > This draft has lost the plot. XML is first and foremost a markup > language: that is its name, that is its purpose, that is what we want. > Someone should be able to open their local text editor and create a > legitimate document using all the characters available in that editor, > without every having to perform any character-to-number conversions or > looking up any character tables. This is a basic operational simplicity > which gives XML 99% of its value. > > > If HTTP requires data in a different format, the XML infrastructure > should provide that transparently. If IETF or any RFC pupports to make > any requirement on how I can mark up legitimate characters, then the > comment we should respond is terse an monosyllabic: it is not the > business of an RFC to mandate any particular encodings within an XML > document. It is ultra vires. (Note, I am *not* saying that an RFC cannot > proscribe certain characters. I am saying that an RFC oversteps itself > if it tries to tell me that I must use %HH rather than &#HHHH; or a > direct character inside my XML document.) > > > If a future technology like xml:base is included in discussion, why is > there no discussion of international domain names? XML should not > constrain the domain names to be any character (the RFCs currently keep > the door open): whatever mechanism is eventually used to allow > internationalised domain names, that should be handled transparently by > the XML processor and the user should be able to see and type the direct > characters (or have NCRS). > So mandating %HH has the problem that we will have to revisit this RFC > as soon as international DNS comes online (which will probably be sooner > rather than later: there is a staggering demand here in Asia for it). > It would be best if XML kept out of the issue entirely: in particular, > if it is decided that CNRP should be used to convert IDNS names into > ASCII domain names, then that is definitely something that would make > the approach of %HH in the domain name part unneeded: why should we have > one rule in the domain name and another rule for other places. > > > > Good to see: > > > 1) |xml suffix is great idea > > > 2) MIME types for DTDs and external parsed entities > > > > I regret to say, I think these flaws are so great that the draft should > be withdrawn and retought at once. Especially point 5 is a disaster. In > particular, whenever there is some conversion between IETF syntax > requirements and simple plain text editing, this should be hidden from > the user and taken care of by the XML processor. > > > The current draft is a step backwards for internationalization of the > WWW in practise. Or, at least, it makes life simpler for ASCII users > but much more difficult for us non-ASCII users. And I think it makes > life much more complicated for implementers: it means that user > interfaces will have to have data conversion routines built in, rather > than just leaving it to the URI referencing library routines. > > > > Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22590 for ietf-xml-mime-bks; Tue, 9 May 2000 10:05:03 -0700 (PDT) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22586 for ; Tue, 9 May 2000 10:05:02 -0700 (PDT) Received: from [63.27.160.90] (1Cust176.tnt3.bos2.da.uu.net [63.22.79.176]) by snipe.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id KAA08097 for ; Tue, 9 May 2000 10:10:47 -0700 (PDT) Mime-Version: 1.0 X-Sender: sgmlworks@mail.earthlink.net Message-Id: In-Reply-To: <20000510013705U.muraw3c@attglobal.net> References: <20000509233703R.muraw3c@attglobal.net> <3918373C.29FE0BA6@w3.org> <20000510013705U.muraw3c@attglobal.net> Date: Tue, 9 May 2000 13:11:29 -0400 To: ietf-xml-mime@imc.org From: Dave Peterson Subject: Re: Announcement of a new I-D 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 1:37 AM +0900 5/10/00, muraw3c@attglobal.net wrote: >At the ietf-822 mailing list, Keith Moore [1] pointed out that "-" is >already used too heavily by existing media types. Chris Newman [2] >suggested ~!$^+{}| We picked | One of the others would have had the advantage that it doesn't look like another character (e.g., Cap I and/or lower case L in san-serif) in any common fonts. -- Dave Peterson SGMLWorks! davep@acm.org Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22069 for ietf-xml-mime-bks; Tue, 9 May 2000 09:31:51 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22065 for ; Tue, 9 May 2000 09:31:50 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.124]) by prserv.net (out1) with SMTP id <2000050916372225201i3uece>; Tue, 9 May 2000 16:37:22 +0000 To: ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D In-Reply-To: <3918373C.29FE0BA6@w3.org> References: <20000509233703R.muraw3c@attglobal.net> <3918373C.29FE0BA6@w3.org> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510013705U.muraw3c@attglobal.net> Date: Wed, 10 May 2000 01:37:05 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Chris Lilley Subject: Re: Announcement of a new I-D Date: Tue, 09 May 2000 18:05:16 +0200 > > The suffix is changed from "-xml" to "|xml". As of now, > > no media types ending with "-xml" are registered yet. > > I looked but did not see any reason given for this change. Is "|" superior > to "-" in some way? If so, it should be documented. If not, why change it? Yes, it should be documented. We will fix this. At the ietf-822 mailing list, Keith Moore [1] pointed out that "-" is already used too heavily by existing media types. Chris Newman [2] suggested ~!$^+{}| We picked | As of today, no registered media types [3] use "-xml" yet. Cheers, Makoto [1] http://www.imc.org/ietf-822/mail-archive/msg01797.html [2] http://www.imc.org/ietf-822/mail-archive/msg01803.html [3] ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21481 for ietf-xml-mime-bks; Tue, 9 May 2000 08:59:32 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21477 for ; Tue, 9 May 2000 08:59:31 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA06722; Tue, 9 May 2000 12:05:16 -0400 Message-ID: <3918373C.29FE0BA6@w3.org> Date: Tue, 09 May 2000 18:05:16 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: muraw3c@attglobal.net CC: ietf-xml-mime@imc.org Subject: Re: Announcement of a new I-D References: <20000509233703R.muraw3c@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: muraw3c@attglobal.net wrote: > > Simon St. Laurent, Dan Kohn, and I create a new I-D for XML media > types. It is available at: > 4. appendix comparing alternatives to '|xml' suffix added. This is a valuable write up, and summarises well the need for a suffic. > The suffix is changed from "-xml" to "|xml". As of now, > no media types ending with "-xml" are registered yet. I looked but did not see any reason given for this change. Is "|" superior to "-" in some way? If so, it should be documented. If not, why change it? -- Chris Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19654 for ietf-xml-mime-bks; Tue, 9 May 2000 07:30:58 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19649 for ; Tue, 9 May 2000 07:30:57 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.231]) by prserv.net (out4) with SMTP id <20000509143650239021hub3e>; Tue, 9 May 2000 14:36:50 +0000 To: ietf-xml-mime@imc.org Subject: Announcement of a new I-D X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000509233703R.muraw3c@attglobal.net> Date: Tue, 09 May 2000 23:37:03 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon St. Laurent, Dan Kohn, and I create a new I-D for XML media types. It is available at: http://www.ietf.org/internet-drafts/draft-murata-xml-03.txt Major differences from previous versions are as below: 1. Fragment identifiers for text/xml and application/xml are escaped XPointers (section 6). This addition was requested by the XML Core WG of W3C. 2. The base URI may be embedded in text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity (section 7). Again, this addition was requested by the XML Core WG of W3C. 3. utf-16le and utf-16be are mentioned (sections 5 and 9). Since RFC 2781 (UTF-16, an encoding of ISO 10646) introduce these two charsets, they have to be mentioned. 4. appendix comparing alternatives to '|xml' suffix added. The suffix is changed from "-xml" to "|xml". As of now, no media types ending with "-xml" are registered yet. 5. The security section is expanded on the basis of David Megginson's presentation to XTech 2000. 6. Lots of minor editing. We are looking forward to your feedbacks. MURATA Makoto Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16585 for ietf-xml-mime-bks; Fri, 5 May 2000 14:55:27 -0700 (PDT) Received: from peace.netnation.com (mail@peace.netnation.com [204.174.223.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16563; Fri, 5 May 2000 14:55:23 -0700 (PDT) Received: from [172.143.15.158] (helo=suzannejacob) by peace.netnation.com with smtp (Exim 3.13 #5) id 12nq8C-0001Nl-00; Fri, 05 May 2000 14:59:33 -0700 From: "Salus Financial" To: "Salus Financial" Subject: THE INSURANCE PROFESSIONALS Date: Fri, 5 May 2000 14:59:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01BFB6A2.72FE7860" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01BFB6A2.72FE7860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit THE INSURANCE PROFESSIONALS It’s a fact that one out of every three Canadians will experience a life altering illness during his or her lifetime. With today’s advances in medical science the chances of survival are greater than ever! Should you be diagnosed with...and survive...any of the following 17 conditions covered under this plan the insurer will provide you with a lump sum payment of tax free cash. *Heart Attack *Cancer *Stroke *Coronary Artery Bypass Surgery *Multiple Sclerosis *Alzheimer’s Disease *Parkinson’s Disease *Major Organ Transplant *Paralysis *Kidney Failure *Coma *Blindness *Severe Burns *Loss of Speech *Occupational HIV *Loss of Limbs *Deafness Picture receiving $100,000 or $250,000 or more to help towards recovery, maintaining your lifestyle or saving your business. Fax (604) 647-0631 or return this e-mail today for more information on this new, innovative and affordable living benefit product. Name: __________________________________ Address: ________________________________ ________________________________ Date of Birth: ____________________________ Phone: _____________ Fax: ________________ I am not interested in further information. Please take me off of your list. ------=_NextPart_000_00EF_01BFB6A2.72FE7860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 THE=20 INSURANCE PROFESSIONALS

It’s a fact = that one out of every three = Canadians will=20 experience a life altering illness during his or her = lifetime.

With today’s advances in medical science = the chances of=20 survival are greater than ever!

 

Should you be = diagnosed=20 with...and survive...any of the following 17 conditions covered under = this plan=20 the insurer will provide you with a lump=20 sum payment of tax free=20 cash.

 

           =20 *Heart Attack              &nbs= p;         =20 *Cancer

           =20 *Stroke           &nbs= p;                    &nb= sp;   *Coronary=20 Artery Bypass Surgery

           =20 *Multiple Sclerosis              =20 *Alzheimer’s Disease

           =20 *Parkinson’s Disease          *Ma= jor=20 Organ Transplant

           =20 *Paralysis           &nbs= p;     =20        =20       *Kidney=20 Failure

           =20 *Coma           &nbs= p;           =20            =20   *Blindness    =20

           =20 *Severe Burns          =20            =20 *Loss of Speech

           =20 *Occupational HIV   =            =20 *Loss of Limbs

           =20 *Deafness

 

Picture receiving = $100,000 or $250,000 or more = to help=20 towards recovery, maintaining your lifestyle or saving your=20 business.

 

Fax (604) 647-0631 or return this = e-mail=20 today for more information on this new, innovative and affordable living = benefit=20 product.

 

           =20 Name: = __________________________________

 

           =20 Address: = ________________________________

 

           &nbs= p;           =20   =20 ________________________________

 

           =20 Date of Birth: = ____________________________

 

           =20 Phone: _____________ Fax: ________________

I=20 am not interested in further information.  Please take me off of = your=20 list.

------=_NextPart_000_00EF_01BFB6A2.72FE7860-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA16419 for ietf-xml-mime-bks; Fri, 5 May 2000 14:44:36 -0700 (PDT) Received: from peace.netnation.com (mail@peace.netnation.com [204.174.223.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16397; Fri, 5 May 2000 14:44:32 -0700 (PDT) Received: from [172.143.15.158] (helo=suzannejacob) by peace.netnation.com with smtp (Exim 3.13 #5) id 12npsv-0006Y3-00; Fri, 05 May 2000 14:43:46 -0700 From: "Salus Financial" To: "Salus Financial" Subject: THE INSURANCE PROFESSIONALS Date: Fri, 5 May 2000 14:43:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01BFB6A0.3CE311C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01BFB6A0.3CE311C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit THE INSURANCE PROFESSIONALS It’s a fact that one out of every three Canadians will experience a life altering illness during his or her lifetime. With today’s advances in medical science the chances of survival are greater than ever! Should you be diagnosed with...and survive...any of the following 17 conditions covered under this plan the insurer will provide you with a lump sum payment of tax free cash. *Heart Attack *Cancer *Stroke *Coronary Artery Bypass Surgery *Multiple Sclerosis *Alzheimer’s Disease *Parkinson’s Disease *Major Organ Transplant *Paralysis *Kidney Failure *Coma *Blindness *Severe Burns *Loss of Speech *Occupational HIV *Loss of Limbs *Deafness Picture receiving $100,000 or $250,000 or more to help towards recovery, maintaining your lifestyle or saving your business. Fax (604) 647-0631 or return this e-mail today for more information on this new, innovative and affordable living benefit product. Name: __________________________________ Address: ________________________________ ________________________________ Date of Birth: ____________________________ Phone: _____________ Fax: ________________ I am not interested in further information. Please take me off of your list. ------=_NextPart_000_00A7_01BFB6A0.3CE311C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 THE=20 INSURANCE PROFESSIONALS

It’s a fact = that one out of every three = Canadians will=20 experience a life altering illness during his or her = lifetime.

With today’s advances in medical science = the chances of=20 survival are greater than ever!

 

Should you be = diagnosed=20 with...and survive...any of the following 17 conditions covered under = this plan=20 the insurer will provide you with a lump=20 sum payment of tax free=20 cash.

 

           =20 *Heart Attack          &nbs= p;   =20          =20 *Cancer

           =20 *Stroke           &nbs= p;                    &nb= sp;   *Coronary=20 Artery Bypass Surgery

           =20 *Multiple Sclerosis              =20 *Alzheimer’s Disease

           =20 *Parkinson’s Disease          *Ma= jor=20 Organ Transplant

           =20 *Paralysis           &nbs= p;     =20        =20       *Kidney=20 Failure

           =20 *Coma           &nbs= p;           =20            =20   *Blindness    =20

           =20 *Severe Burns          =20            =20 *Loss of Speech

           =20 *Occupational HIV   =            =20 *Loss of Limbs

           =20 *Deafness

 

Picture receiving = $100,000 or $250,000 or more = to help=20 towards recovery, maintaining your lifestyle or saving your=20 business.

 

Fax (604) 647-0631 or return this = e-mail=20 today for more information on this new, innovative and affordable living = benefit=20 product.

 

           =20 Name: = __________________________________

 

           =20 Address: = ________________________________

 

           &nbs= p;           =20   =20 ________________________________

 

           =20 Date of Birth: = ____________________________

 

           =20 Phone: _____________ Fax: ________________

I=20 am not interested in further information.  Please take me off of = your=20 list.

------=_NextPart_000_00A7_01BFB6A0.3CE311C0--