From owner-cnrp-ietf@LISTS.INTERNIC.NET Fri Mar 3 17:20:18 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10938 for ; Fri, 3 Mar 2000 17:20:18 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA06967; Fri, 3 Mar 2000 17:19:42 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8622808 for CNRP-IETF@LISTS.INTERNIC.NET; Fri, 3 Mar 2000 17:19:40 -0500 Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id RAA06951 for ; Fri, 3 Mar 2000 17:19:38 -0500 (EST) Received: from marshall (sdn-ar-003oreugeP251.dialsprint.net [158.252.228.141]) by scaup.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id OAA28529 for ; Fri, 3 Mar 2000 14:14:11 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01BF851A.38E77500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <003201bf855d$480e1b40$8de4fc9e@marshall> Date: Fri, 3 Mar 2000 14:10:25 -0800 Reply-To: "Marshall L. Moseley" From: "Marshall L. Moseley" Subject: ISO 639 Syntax To: CNRP-IETF@LISTS.INTERNIC.NET This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BF851A.38E77500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm working on version three of the WG draft. Does anyone know the = syntax for region/language (or language/region) described in ISO 639? = Or know where there's a link to a description? Thanks. --Marshall ------=_NextPart_000_002F_01BF851A.38E77500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm working on version three of the WG draft. Does anyone = know the=20 syntax for region/language (or language/region) described in ISO = 639? Or=20 know where there's a link to a description? Thanks.

--Marshall

------=_NextPart_000_002F_01BF851A.38E77500-- From owner-cnrp-ietf@LISTS.INTERNIC.NET Sat Mar 4 02:06:24 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28637 for ; Sat, 4 Mar 2000 02:06:24 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id CAA26008; Sat, 4 Mar 2000 02:05:00 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8622990 for CNRP-IETF@LISTS.INTERNIC.NET; Sat, 4 Mar 2000 02:04:58 -0500 Received: from muro.bes.es ([195.53.182.2]) by lists.internic.net (8.9.3/8.9.3) with SMTP id BAA23883; Sat, 4 Mar 2000 01:54:52 -0500 (EST) Received: from Mailhub by muro.bes.es id AA07016; Sat, 4 Mar 2000 07:48:28 +0100 Message-ID: <0003040648.AA07016@muro.bes.es> Date: Sat, 4 Mar 2000 07:48:28 +0100 Reply-To: lkoxbkzwvncwjjkt@HOTBOT.COM From: lkoxbkzwvncwjjkt@HOTBOT.COM Subject: ACCEPT CREDIT CARDS OVER THE INTERNET.....NO SETUP FEES!! ujvax To: CNRP-IETF@LISTS.INTERNIC.NET INCREASE SALES UP TO 50%.... ACCEPT CREDIT CARDS OVER THE INTERNET.....NO SETUP FEES!! Good Credit/Bad Credit/No Credit.....*** NO PROBLEM*** It just Doesn't Matter - Everyone Gets Approved No Upfront Fees For application-Processing! While Others Charge You From $195 to $250 to Get Set Up WE CHARGE ZERO FOR SETUP FEES!!! Limited Offer So Take Advantage of it!! We Specialize in Servicing The Following: ** Multilevel Marketing ** Mail Order! Phone Sales ** Home Based Business ** INTERNET BASED BUSINESS ** New Business ** Small Business ** Whatever!! We Do It ALL!!! Everyone is Welcome!! Toll Free 1-888-594-8155 Removal mailto:teeremove@mycampus.com?subject=remove From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 6 15:50:02 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28483 for ; Mon, 6 Mar 2000 15:50:01 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA27381; Mon, 6 Mar 2000 15:32:13 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8623898 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 6 Mar 2000 15:32:11 -0500 Received: from lists.scripps.com ([204.78.32.110]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA24602 for ; Mon, 6 Mar 2000 15:22:09 -0500 (EST) Received: from localhost (63.249.254.6:2718) by lists.scripps.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00001398@lists.scripps.com>; Mon, 6 Mar 2000 14:17:04 -0500 X-In-Response-To: 01BF210DF Content-Type: text/plain MessageID: X-See-Also: 0E36DD45F X-Mailer: Mozilla 2.11 [en] (Win95; I) X-Other-References: 077BADA92 X-References: 019A20094, 0B51ED6E8 X-Accept-Language: en MIME-Version: 1.0 Message-ID: <200003062022.PAA24602@lists.internic.net> Date: Mon, 6 Mar 2000 15:32:11 -0500 Reply-To: zak02@MAILUTAH.COM From: zak02@MAILUTAH.COM Subject: Expose your business to the Internet To: CNRP-IETF@LISTS.INTERNIC.NET PUT EMAIL MARKETING TO WORK FOR YOU... Call NOW and receive 50,000 FREE emails with your order! see below for removal. Special Ends Friday March 10, 2000 MLM'ers, We can build your downline. Imagine having a product or idea and selling it for only $10. Now imagine sending an ad for your product or idea to 25 million people! If you only get a 1/10 of 1% response you have just made $250,000!! You hear about people getting rich off the Internet everyday on TV, now is the perfect time for you to jump in on all the action. FACT. With the introduction of the Internet, one primary KEY to conducting your business successfully is creating massive exposure in a cost effective manner. FACT. The experts agree that email marketing is one of the most cost effective forms of promotion in existence today. Electronic mail has overtaken the telephone as the primary means of business communication.(American Management Association) Of online users 41 percent check their email daily. "A gold mine for those who can take advantage of bulk email programs"- The New York Times "Email is an incredible lead generation tool" -Crains Magazine "Blows away traditional Mailing"-Advertising Age "It's truly arrived. Email is the killer app so far in the online world"-Kate Delhagen, Forrester Research Analyst Why not let a professional company handle your direct email marketing efforts for you? *We will assist you in developing your entire campaign! *We can even create your ad or annoucement for you! *No responses? We resend at no cost! For More Information CALL NOW-702-248-1043 For removal see below. SPECIAL RATES SPECIAL ENDS Friday March 10, 2000 Targeted Rates Upon Request. BONUS!!! Call In and receive 50,000 Extra Emails at No Cost! Call NOW - 702-248-1043 ++++++++++++++++++++++++++++++++++++++++++++++++++ We are terribly sorry if you received this message in error: nick1@hmongonline.com If you wish to be removed. Please, type "REMOVE" in the subject line: ++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-cnrp-ietf@LISTS.INTERNIC.NET Wed Mar 8 16:18:00 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09983 for ; Wed, 8 Mar 2000 16:17:59 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA22714; Wed, 8 Mar 2000 16:09:30 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8624854 for CNRP-IETF@LISTS.INTERNIC.NET; Wed, 8 Mar 2000 16:09:28 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA22687 for ; Wed, 8 Mar 2000 16:09:25 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA25231; Wed, 8 Mar 2000 15:53:25 -0500 (EST) References: <003201bf855d$480e1b40$8de4fc9e@marshall> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000308155325.D25050@bailey.dscga.com> Date: Wed, 8 Mar 2000 15:53:25 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: ISO 639 Syntax To: CNRP-IETF@LISTS.INTERNIC.NET In-Reply-To: <003201bf855d$480e1b40$8de4fc9e@marshall>; from mlmoseley@EARTHLINK.NET on Fri, Mar 03, 2000 at 02:10:25PM -0800 On Fri, Mar 03, 2000 at 02:10:25PM -0800, Marshall L. Moseley wrote: > I'm working on version three of the WG draft. Does anyone know the syntax for region/language (or language/region) described in ISO 639? Or know where there's a link to a description? Thanks. Its actually RFC 1766 which defines the countrycode-languagecode mechanism. See http://www.ietf.org/rfc/rfc1766.txt BTW, I have some DTD changes and some wording changes. When can I see a few version so I can make them to a relatively stable copy? -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-cnrp-ietf@LISTS.INTERNIC.NET Wed Mar 8 20:23:38 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19079 for ; Wed, 8 Mar 2000 20:23:38 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id UAA15083; Wed, 8 Mar 2000 20:09:24 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8624963 for CNRP-IETF@LISTS.INTERNIC.NET; Wed, 8 Mar 2000 20:09:23 -0500 Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA13047 for ; Wed, 8 Mar 2000 19:59:19 -0500 (EST) Received: from enoshima (ppp0ppp6.sfc.keio.ac.jp [133.27.13.27]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with SMTP id JAA02778; Thu, 9 Mar 2000 09:53:38 +0900 (JST) X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) References: <003201bf855d$480e1b40$8de4fc9e@marshall> <003201bf855d$480e1b40$8de4fc9e@marshall> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200003090053.JAA02778@sh.w3.mag.keio.ac.jp> Date: Thu, 9 Mar 2000 09:44:03 +0900 Reply-To: "Martin J. Duerst" From: "Martin J. Duerst" Subject: Re: ISO 639 Syntax To: CNRP-IETF@LISTS.INTERNIC.NET In-Reply-To: <20000308155325.D25050@bailey.dscga.com> At 15:53 00/03/08 -0500, Michael Mealling wrote: > On Fri, Mar 03, 2000 at 02:10:25PM -0800, Marshall L. Moseley wrote: > > I'm working on version three of the WG draft. Does anyone know the syntax for region/language (or language/region) described in ISO 639? Or know where there's a link to a description? Thanks. > > Its actually RFC 1766 which defines the countrycode-languagecode > mechanism. See http://www.ietf.org/rfc/rfc1766.txt Sorry, but 1766 is about languages. One kind of tags is ll-cc, where ll is a language code, and cc is a country code. If you are out for something that is just about country/region, then 1766 is the wrong place to look for. Regards, Martin. > BTW, I have some DTD changes and some wording changes. When can I > see a few version so I can make them to a relatively stable copy? > > -MM > > -- > -------------------------------------------------------------------------------- > Michael Mealling | Vote Libertarian! | www.rwhois.net/michael > Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 > Network Solutions | www.lp.org | michaelm@netsol.com > > #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-cnrp-ietf@LISTS.INTERNIC.NET Wed Mar 8 21:22:15 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08455 for ; Wed, 8 Mar 2000 21:22:15 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA02625; Wed, 8 Mar 2000 21:11:34 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8624977 for CNRP-IETF@LISTS.INTERNIC.NET; Wed, 8 Mar 2000 21:11:33 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id VAA02599 for ; Wed, 8 Mar 2000 21:11:30 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id UAA25978; Wed, 8 Mar 2000 20:55:32 -0500 (EST) References: <003201bf855d$480e1b40$8de4fc9e@marshall> <003201bf855d$480e1b40$8de4fc9e@marshall> <20000308155325.D25050@bailey.dscga.com> <200003090053.JAA02778@sh.w3.mag.keio.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000308205531.A25753@bailey.dscga.com> Date: Wed, 8 Mar 2000 20:55:32 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: ISO 639 Syntax To: CNRP-IETF@LISTS.INTERNIC.NET In-Reply-To: <200003090053.JAA02778@sh.w3.mag.keio.ac.jp>; from duerst@W3.ORG on Thu, Mar 09, 2000 at 09:44:03AM +0900 On Thu, Mar 09, 2000 at 09:44:03AM +0900, Martin J. Duerst wrote: > At 15:53 00/03/08 -0500, Michael Mealling wrote: > > On Fri, Mar 03, 2000 at 02:10:25PM -0800, Marshall L. Moseley wrote: > > > I'm working on version three of the WG draft. Does anyone know the syntax for region/language (or language/region) described in ISO 639? Or know where there's a link to a description? Thanks. > > > > Its actually RFC 1766 which defines the countrycode-languagecode > > mechanism. See http://www.ietf.org/rfc/rfc1766.txt > > Sorry, but 1766 is about languages. One kind of tags is ll-cc, > where ll is a language code, and cc is a country code. If you > are out for something that is just about country/region, > then 1766 is the wrong place to look for. This one is specifically for language since its for a well known type of the language property. The geography property is about countries and regions and thus 3166-2 is one of its well known types... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-cnrp-ietf@LISTS.INTERNIC.NET Fri Mar 10 16:24:06 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23842 for ; Fri, 10 Mar 2000 16:24:04 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA18116; Fri, 10 Mar 2000 15:48:28 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8625567 for CNRP-IETF@LISTS.INTERNIC.NET; Fri, 10 Mar 2000 15:48:25 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id PAA18095 for ; Fri, 10 Mar 2000 15:48:23 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id PAA01160 for cnrp-ietf@lists.internic.net; Fri, 10 Mar 2000 15:32:27 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000310153227.E1069@bailey.dscga.com> Date: Fri, 10 Mar 2000 15:32:27 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: new version of the protocol draft heading this way To: CNRP-IETF@LISTS.INTERNIC.NET FYI: I just sent in a new copy of the protocol draft. It has some wordsmithing from Nico and Marshall and some minor corrections for the DTD from me. Please look it over and comment on it. The URI document also needs some review. From the minimal comments I'm assuming you guys think its the best thing going. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-cnrp-ietf@LISTS.INTERNIC.NET Wed Mar 15 12:58:52 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10324 for ; Wed, 15 Mar 2000 12:58:49 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id NAA19441; Wed, 15 Mar 2000 13:00:31 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8628794 for CNRP-IETF@LISTS.INTERNIC.NET; Wed, 15 Mar 2000 13:00:29 -0500 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id MAA17007 for ; Wed, 15 Mar 2000 12:50:27 -0500 (EST) Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id MAA27006 for ; Wed, 15 Mar 2000 12:44:29 -0500 (EST) Received: (qmail 16681 invoked from network); 15 Mar 2000 17:44:16 -0000 Received: from xerox.arkipelago.ca (206.191.94.8) by 192.168.119.15 with SMTP; 15 Mar 2000 17:44:16 -0000 Received: from rkirk (arkipel14.arkipelago.com [206.191.94.14]) by xerox.arkipelago.ca (Build 98 8.9.3/NT-8.9.3) with SMTP id MAA01053 for ; Wed, 15 Mar 2000 12:43:50 -0500 Received: by rkirk with Microsoft Mail id <01BF8E7C.54B68580@rkirk>; Wed, 15 Mar 2000 12:45:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <01BF8E7C.54B68580@rkirk> Date: Wed, 15 Mar 2000 12:45:22 -0500 Reply-To: Ron Kirk From: Ron Kirk Subject: FW: Gap Certificates To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit -----Original Message----- From: Cheryl Dale - Cumberland Bellair Inv Inc [SMTP:cumbel@ilap.com] Sent: Wednesday, March 15, 2000 11:19 AM To: ron kirk Subject: Fw: Gap Certificates ----- Original Message ----- From: Pat Fox To: Barb Burling ; Bonnie Gibson ; Don Potter ; Liz Thomson ; Ted Salter ; windsor ; Barb Harrington (E-mail) ; Bob and Pat Fox (E-mail) ; Brian Sugimoto (E-mail) ; Cathy Russell (E-mail) ; Cheryle (Krik) Dale (E-mail) ; Diane Oliver (E-mail) ; Frank Mielewczyk (E-mail) ; Gail Hinton (E-mail) ; Graham Hurst (E-mail) ; Helen Mckirdy (E-mail) ; Joanne Court (E-mail) ; Karen Hurst (E-mail) ; Laura Miller (E-mail) ; Melissa Russell (E-mail) ; Phil Sent: Tuesday, March 14, 2000 1:35 PM Subject: FW: Gap Certificates > > > > > > >>> > Hey guys, I finally found one that is TRUE! > > > >>> > I went down to the gap myself and redeemed > > > >>> > my GIFT CERTIFICATES already!!! I sent > > > >>> > enough e-mails to get over two hundred dollars > > > >>> > worth of clothes from the GAP! > > > >>> > You know, with all the crap sent over the mail, > > > >>> > it is good to know that something finally rings > > > >>> > true in this environment of virtual deception. > > > >>> > Send it to everyone you know, and you too can > > > >>> > have a whole new wardrobe, courtesy of THE GAP! > > > >>> > > > > >>> > Isn't it grand? > > > >>> > J > > > >>> > > > > >>> > One more detail, my "screen" only came up after I > > > >>> > had sent out nineteen different messages. It must > > > >>> > have something to do with how the strange program > > > >>> > works... What will they think of next... > > > >>> > > > > >>> > ------------------------- > > > >>> > > > > >>> > Hi! My name is Janelle McCan, Founder of the Gap. > > > >>> > I am offering thirty five dollar gift certificates to > > > >>> > every seven people you send this to. > > > >>> > > > > >>> > When you have finished sending this letter to as > > > >>> > many people as you wish, a screen will come up. > > > >>> > It will tell you how much you have earned in Gap > > > >>> > gift certificates. Print that screen out and bring it > > > >>> > to your local Gap store. The sales clerk will give > > > >>> > you your certificates and you can SHOP BABY! > > > >>> > This is a sales promotion to get our name out to > > > >>> > young people around the world.We believe this > > > >>> > project can be a success, but only with your help. > > > >>> > > > > >>> > Thank you for your support > > > >>> > > > > >>> > Sincerely, > > > >>> > Janelle McCan > > > >>> > Founder of Gap > > > >>> > > > > >>> > _____________________________________________________ > > > >>> > Get Your Private, Free Email at > > > >>> > > > > >>> > > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Jamie E. Smith > > >Feminist majority Foundation > > >Program Assistant > > >1600 Wilson Blvd, Suite 801 > > >Arlington, VA 22314 > > >(703) 522-2214 > > >(703) 522-2219 (f) > > >rjsmith@feminist.org > > >www.feminist.org > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com > > > > > From owner-cnrp-ietf@LISTS.INTERNIC.NET Wed Mar 15 18:50:24 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00861 for ; Wed, 15 Mar 2000 18:50:22 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id SAA10778; Wed, 15 Mar 2000 18:52:34 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8628999 for CNRP-IETF@LISTS.INTERNIC.NET; Wed, 15 Mar 2000 18:52:32 -0500 Received: from tor-smtp2.netcom.ca (tor-smtp2.netcom.ca [207.181.101.101]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id SAA10761 for ; Wed, 15 Mar 2000 18:52:31 -0500 (EST) Received: from thinkingcat.com (mon-pq12-10.netcom.ca [207.181.92.10]) by tor-smtp2.netcom.ca (8.8.7-s-4/8.8.7) with ESMTP id SAA13339 for ; Wed, 15 Mar 2000 18:46:27 -0500 (EST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D01F89.64AE7C59@thinkingcat.com> Date: Wed, 15 Mar 2000 18:40:57 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: proposed agenda for Adelaide meeting To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, Please find attached the proposed agenda for the Adelaide meeting. If there are any additional issues we should address, please let me know. Note that, AFAIK the -02 version of the protocol doc isn't yet in the archives, but it should eventually clear the Friday-submission backlog. As always, comments to the list on the documents would be appreciated -- either editorial remarks, or if there are any things missing in these documents as per our charter. As a hint -- I currently expect the Adelaide meeting to be our last. I'm reading the silence on this list to mean that these docs are pretty much what the WG is looking for, and we can wrap up any editorial issues on the mailing list after Adelaide. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- Common Name Resolution Protocol WG (cnrp) Adelaide, Australia Thursday, March 30, 2000 13h00-15h00 ======================== Chair: Leslie Daigle AGENDA: min topic 5 Agenda review 10 WG/work status [Leslie] 45 Discussion of protocol document [Nico & Marshall] draft-ietf-cnrp-02.txt 45 Discussion of URI document [Michael] draft-ietf-cnrp-uri-00.txt 10 Wrap up, and where do we go from here [Leslie] From owner-cnrp-ietf@LISTS.INTERNIC.NET Thu Mar 16 16:25:33 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25953 for ; Thu, 16 Mar 2000 16:25:33 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA17850; Thu, 16 Mar 2000 16:24:08 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8629595 for CNRP-IETF@LISTS.INTERNIC.NET; Thu, 16 Mar 2000 16:24:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id QAA15053 for ; Thu, 16 Mar 2000 16:14:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18925; Thu, 16 Mar 2000 16:08:31 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200003162108.QAA18925@ietf.org> Date: Thu, 16 Mar 2000 16:08:30 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cnrp-02.txt To: CNRP-IETF@LISTS.INTERNIC.NET --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Name Resolution Protocol Working Group of the IETF. Title : CNRP PROTOCOL SPECIFICATION Author(s) : N. Popp, M. Mealling, M. Moseley Filename : draft-ietf-cnrp-02.txt Pages : Date : 15-Mar-00 People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable. Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase 'Internet Engineering Task Force' is a common name in the 'organization' category, as is 'Moby Dick' in the book category. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cnrp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cnrp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cnrp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cnrp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cnrp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132139.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cnrp-ietf@LISTS.INTERNIC.NET Fri Mar 24 01:51:31 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17918 for ; Fri, 24 Mar 2000 01:51:30 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id BAA23119; Fri, 24 Mar 2000 01:47:44 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8633391 for CNRP-IETF@LISTS.INTERNIC.NET; Fri, 24 Mar 2000 01:47:42 -0500 Received: from mail.vest.co.jp (psnsv01.vest.co.jp [210.141.111.170]) by lists.internic.net (8.9.3/8.9.3) with SMTP id BAA21019 for ; Fri, 24 Mar 2000 01:37:39 -0500 (EST) Received: from localhost (unverified [63.249.254.3]) by mail.vest.co.jp (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 24 Mar 2000 15:32:55 +0900 X-Mailer: Internet Mail Service [57.1.2266.35] (Solaris; Sparc10) X-Accept-Language: en X-References: 0DC508D53, 0E91A96A8 X-Other-References: 048849952 Content-Type: text/plain Message-ID: <3dju6ykj7wv2jx5.240320000046@localhost> Date: Fri, 24 Mar 2000 01:47:42 -0500 Reply-To: larp2@ANGELFAN.COM From: larp2@ANGELFAN.COM Subject: Freedom, Security and Profits To: CNRP-IETF@LISTS.INTERNIC.NET If you would like to pay off your bills, buy a new car, take long vacations, build a new home, start a generous college fund for your children, or just spend more time with your family then you need to seriously review the easy to implement business opportunity offered by the US. Congress approved Tax Relief System. Freedom, Security and Profits CALL NOW 1-800-962-5441 From owner-cnrp-ietf@LISTS.INTERNIC.NET Sun Mar 26 08:12:46 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26655 for ; Sun, 26 Mar 2000 08:12:42 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA23842; Sun, 26 Mar 2000 08:13:39 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8635502 for CNRP-IETF@LISTS.INTERNIC.NET; Sun, 26 Mar 2000 08:13:37 -0500 Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id IAA23798 for ; Sun, 26 Mar 2000 08:13:28 -0500 (EST) Received: from dhcp-32-153.ietf.connect.com.au [169.208.32.153] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id WAA29863 for return ; Sun, 26 Mar 2000 22:37:53 +0930 (CST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DC3F59.155EBBB5@thinkingcat.com> Date: Fri, 24 Mar 2000 23:23:53 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, First, let me say that (barring other input from the WG), the protocol itself seems pretty well settled out. The remaining work, then, is in the details & clarification of the document. There are 4 categories of comments here: 1. general statement about the structure & organization of the document 2. details yet to be addressed -- needed for completion 3. editorial comments on the -02 draft 4. editorial comments left over from the -00 draft, not yet addressed... 1. Structure & Organization I think the document is getting to be a pretty good record of the state of thinking of the WG. However, I have the impression that it's a difficult read for anyone wanting to pick up and learn what CNRP is/is not. Paying a bit more attention to introducing the concepts in an overview before launching into detailed definition would help a lot, for example. 2. Remaining Details (Re)definition of properties: (This is somewhat dependent on the IANA question below). Can a service redefine a property (i.e., in the properties it declares to be local to itself)? Can a service extend a property by allowing different property value types? Security threats: . what ones will be addressed . how are the addressed . signed XML? Errors: what are the error codes? what is the numbering "scheme" (e.g., 500-level are fatal, etc). Are they result-set level only, or can there be errors offered per-result (e.g., "hints ignored"). Result set ordering: are results presented in some kind of an ordered list? (would facilitate presenting per-result errors). Property/type registrations: Assuming we really do want to do this through IANA (and if not...?) we need a clearly defined registration procedure, including: who can redefine a property, or extend a property to encompass new property value types? (E.g., extending the "geography" property to have some new geographic classification as a valid type). Also, are types defined on a per-property basis, or are they valid across all types? How/where is the relationship expressed. 3. Editorial comments -- 02 > common name and a resource. (Note: common names may be > expressed in a URI, the syntax for which is described > herein.) No -- it's described in a separate document. > 4.1 Hints > A hint is an assertion by the user about him or her self and > the context in which he/she is operating. There is no data > type `hint'; a hint is expressed within the structure of the > query itself and is limited or enabled by the richness of > the defined query namespace. In effect, a query and any > property within it is a hint. > > An example of this would be the required property ^^^^^^^^ > "language", in which a query might be created that specifies > the primary language in which you want to see results, the Required by what? . server support . included in client query . included in return data > 5.1 Properties: > 5.1.1 Base properties A table, showing base properties (core & optional) and their definitions/applicable types would be very useful in this section, I think. > 5.1.2.3 Common name - String encoding and equivalence rules > CNRP specifies that common name strings should be encoded > using UTF-8. CNRP does not specify any string equivalence > rules for matching a common name in the query against a > common name of a Resource. String equivalence rules are I believe this is the first mention of "Resource". First of all, to use it, it should be defined (particularly as it is easily confused with the end-thing that the CommonName is associated with, should that actually be a web page...). Secondly, it may be a poor word to use. In the context of much of this work, "Record" would perhaps be a much clearer term to use -- I strongly advocate a global search & replace... To wit: > 5.3.1 Resource > A Resource object describes a resource (e.g. a Web page, a > person, an object identified by a URI). This is tripping into a whole other space of "what is metadata" that we really don't need to get mired in. The "resource/record" object may well do no such job of description. It is a record that contains certain pieces of data, which has (for whatever reason -- descriptive or otherwise) been associated with a CommonName. Period. Whether it describes a web page, a service, a human being or a hunan dumpling is irrelevant to our purposes. > The Resource object > can contain the commonname, URI, ID, description, language, > geography, and category of the resource. A Resource can also > be augmented using custom properties. Lastly, a Resource can > also reference a service object to indicate its origin. "The Record object contains a CommonName, and may contain a URI, ID, description, language, geography and category data -- e.g., describing a particular web resource. A Record can also be augmented using custom properties. Lastly, a Record can also reference a service object to indicate its origin." As in -- the Record's origin, not some resource's origin. > 5.3.2 Service > The Service object provides an encapsulation of an instance > of a CNRP service. A service is uniquely identified through > the ServiceURI property. Services can also include a > description, a brief textual description of the service. > > > http://cnrp.foo.com It wasn't clear to me if this was meant to be a URI for an actual CNRP server, or (e.g.) a page describing the service. If not explicitly a CNRP server, then I would suggest making that clearer, and illustrated in the example. E.g., http://www.foo.com/cnrp/intro.html > > > > I believe the above section is anachronistic and should be deleted. > 6.3 Sending A Query and Getting A Response > > This is the query that is sent from the client to the > server: > > > "D:\WINNT\Profiles\Administrator\Desktop\CNRPDTD.xml"> > > > Fido > > CA-QC > source="explicit">CA ^^^^^^^^^^^^^^^^^ Ditto. > This is the result set. It is sent back in response to the > query. This result set includes a referral and a non-fatal > error. I didn't see any error, fatal or otherwise... 4. Editorial comments -- 00 The following comments were made in reviewing the -00 draft. Looking over them, they appear to all still be unaddressed by the -02 draft, although some of the exact quoted wording may have changed. These need to be addressed (i.e., done or counter reasons given). > 2. Abstract This isn't. I suggest stripping the Abstract section down and pushing more into the Introduction: --> begin LLD proposes: 2. Abstract People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable. For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is intended to address the issues of internationalization and privacy as well. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added. 3. Introduction Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category. Two classes of clients of such services are being built, browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via a browser. In some cases, the search site may also be the back- end resolution service, but in others, the search site is a front-end to a collection of back-end services. This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is intended to address the issues of internationalization and privacy as well. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added. Several other issues, while of importance to the deployment of common name resolution services, are outside of the resolution protocol itself and are not in the initial scope of the proposed effort. These include discovery and selection of resolution service providers, administration of resolution services, name registration, name ownership, and methods for creating, identifying or insuring unique common names. For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. These common names will be used primarily by humans, as opposed to machine agents. A common name "resolution service" handles these associations between common names and data (resources, information about resources, pointers to locations, etc). A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service. Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. (Note: common names may be expressed in a URI, the syntax for which is described herein.) This document will define a protocol for the parameterized resolution necessary to make common names useful. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-property descriptor. Descriptors are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query. end LLD proposes <-- Note that I changed the "multi-component" to "multi-property" in the last paragraph above -- as a segue into using "property" instead of "parameter" from now on. > 4. Basic object model This is, or should be, the "Basic Interaction Model". Then, I think there needs to be a paragraph of (gentle) introduction saying what that model is, in the broadest of terms: . the protocol is based on a simple request/response model . requests are objects, defined and expressed in XML, see below; requests are made as "assertions", rather than detailed instructions for the server to carry out . responses are also objects, defined and expressed in XML > 2. A `standard' query, which is the submission of the common > name along with parameters. > > search string to the database. The query will conform to > the previously established schema. The last 2 lines seem to be trailing edit doots. > result set). CNRP allows database service providers to > create unique data types and surface them to any CNRP client > via the CNRP schema XML documents. "surface"? perhaps "expose"? > Discovery of the transport associated with a CNRP database > is accomplished through DNS. The syntax for a CNRP URI is: > > CNRP:<[host]>:<[port]>/path/; > paraname=value,paraname=value,... > > "CNRP", in conjunction, with the URI content, denotes a DNS > entry containing a Naming Authority Pointer (NAPTR). The > NAPTR specifies how a CNRP URI is dynamically rewritten by > the client to adhere to some transport (HTTP, GOPHER, etc.) > Because this rewrite can be a URL, a CNRP URI can thus be > cached and assigned a time-to-live (TTL). I think the above should be cut -- insofar as it is covered, it is covered in the CNRP URI document. > that many services, especially large one, will implement "ones", not "one" > 1. Language: The language of a resource associated > with a resource. Eeuhh?! "Which which is which?"! And there should be a reference to Appendix "A", which defines the base properties. The language property is expressed using language values as defined by ISO-3166. > The multi-type properties and the main types are defined Perhaps "their main" instead of "the main"? For the following, clarify if this is true for all properties, or just "category": > When the "type" is unspecified, the value defaults to > "free form". The free form type is important because it > allows very simple user interface where the user can > enter a value in a text field. It is up to the serviced > to interpret the value correctly and take advantage of > it to increase the relevance of results (using > specialized dictionaries for instance). Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-cnrp-ietf@LISTS.INTERNIC.NET Sun Mar 26 22:43:02 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29392 for ; Sun, 26 Mar 2000 22:43:01 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id WAA10623; Sun, 26 Mar 2000 22:44:34 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8635777 for CNRP-IETF@LISTS.INTERNIC.NET; Sun, 26 Mar 2000 22:44:32 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id WAA10538 for ; Sun, 26 Mar 2000 22:44:11 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id WAA04695; Sun, 26 Mar 2000 22:27:02 -0500 (EST) References: <38DC3F59.155EBBB5@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000326222701.A4673@bailey.dscga.com> Date: Sun, 26 Mar 2000 22:27:02 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET In-Reply-To: <38DC3F59.155EBBB5@thinkingcat.com>; from leslie@THINKINGCAT.COM on Fri, Mar 24, 2000 at 11:23:53PM -0500 On Fri, Mar 24, 2000 at 11:23:53PM -0500, Leslie Daigle wrote: > 2. Remaining Details > > (Re)definition of properties: (This is somewhat dependent on the > IANA question below). Can a service redefine a property (i.e., > in the properties it declares to be local to itself)? Can a service > extend a property by allowing different property value types? After thinking about edge conditions I think that 1) A service cannot redefine a property. It can define a new type but not a new definition for a registered property. 2) A service can extend a property by allowing new property value types if the property definition allows it. > Security threats: > . what ones will be addressed > . how are the addressed > . signed XML? Yes. This is on my list to do. I would appreciate some ideas for possible security threats. I'll fill them out if you want to just forward brief descriptions. > Errors: what are the error codes? what is the numbering "scheme" > (e.g., 500-level are fatal, etc). Are they result-set level only, > or can there be errors offered per-result (e.g., "hints ignored"). Ahh, yes. Since we assume that a given set of results may have a records from different servers then how do we associate an error with a given set of records. > Result set ordering: are results presented in some kind of an > ordered list? (would facilitate presenting per-result errors). If I remember corectly we simply said that it was ordered but didn't say what that meant. > Property/type registrations: Assuming we really do want to do this > through IANA (and if not...?) we need a clearly defined registration > procedure, including: who can redefine a property, or extend a > property to encompass new property value types? (E.g., extending > the "geography" property to have some new geographic classification > as a valid type). Also, are types defined on a per-property basis, > or are they valid across all types? How/where is the relationship > expressed. In the document I did allow for a property type to say it was valid for all properties but that sounds problematic. More to come when I have better connectivity... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 27 10:42:25 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20870 for ; Mon, 27 Mar 2000 10:42:25 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id KAA16344; Mon, 27 Mar 2000 10:38:30 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8636033 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 27 Mar 2000 10:38:28 -0500 Received: from bab5.dscga.com (bab5.dscga.com [207.120.28.7]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id KAA12788 for ; Mon, 27 Mar 2000 10:28:20 -0500 (EST) Received: from hermes ([207.120.28.194]) by bab5.dscga.com (8.8.7/8.8.7) with SMTP id KAA02039 for ; Mon, 27 Mar 2000 10:23:04 -0500 References: <38DC3F59.155EBBB5@thinkingcat.com> <20000326222701.A4673@bailey.dscga.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000901bf9800$8bb6d3e0$382d10ac@netsol.com> Date: Mon, 27 Mar 2000 10:24:23 -0500 Reply-To: Ben Schepens From: Ben Schepens Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Mealling > Ahh, yes. Since we assume that a given set of results may have a Mealling > records from different servers then how do we associate an error Mealling > with a given set of records. Could we add a ServiceRef to each error so that the errors could be related to a Service source the same way that Resources are? > Result set ordering: are results presented in some kind of an > ordered list? (would facilitate presenting per-result errors). Formally speaking, as the DTD is defined, 'Errors' are grouped per 'Result'. If you meant to say per-'Resource' errors, I am not sure how that would be useful. It seems to me that a 'Resoure' returned in the Result represents a successful answer. If there were a problem, an 'Error' element would have been returned in the 'Result' INSTEAD of a 'Resource'. ---------------------------------------------------------------------------- Ben Schepens bschepens@netsol.com Sr. Research Engineer Network Solutions From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 27 18:25:31 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26979 for ; Mon, 27 Mar 2000 18:25:30 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id SAA29344; Mon, 27 Mar 2000 18:14:57 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8636430 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 27 Mar 2000 18:14:55 -0500 Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id SAA29322 for ; Mon, 27 Mar 2000 18:14:51 -0500 (EST) Received: from dhcp-193-74.ietf.connect.com.au [169.208.193.74] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id IAA01469 return ; Tue, 28 Mar 2000 08:39:09 +0930 (CST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DC3F59.155EBBB5@thinkingcat.com> <20000326222701.A4673@bailey.dscga.com> <000901bf9800$8bb6d3e0$382d10ac@netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DFE8AD.2C6FA256@thinkingcat.com> Date: Mon, 27 Mar 2000 18:03:09 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, Ben Schepens wrote: > > Result set ordering: are results presented in some kind of an > > ordered list? (would facilitate presenting per-result errors). > > Formally speaking, as the DTD is defined, 'Errors' are grouped > per 'Result'. If you meant to say per-'Resource' errors, I am Gee, Ben, if you're going to be snooty about splitting a semantic hair with me, get it right! The element is "Results", not "Result". The further point being that I wasn't speaking in DTD elements, but rather general terminology -- "result" being one thing in a "result set". > not sure how that would be useful. It seems to me that a 'Resoure' > returned in the Result represents a successful answer. If there > were a problem, an 'Error' element would have been returned in the > 'Result' INSTEAD of a 'Resource'. To explain a bit further: In the case of non-fatal errors, e.g., hints ignored. In the general case of system messages, can also include informational messages. Thinking ahead, perhaps, there's also the issue of what happens if the service you're connected to is in fact fronting for a number of services or namespaces; having only "failed" or "succeeded" as report codes for the entire result set is pretty much lame. (This is the part that Michael referred to). The most important thing to get resolved in the CNRP document is whether or not the client should expect the components of the "Results" to be ordered for any reason. Next, do we want to impose any semantics on the ordering (if they are ordered) -- e.g., error messages that apply only to the resource/record element that follows, etc. This may make more sense in the context of messages that are "system messages including error messages", as opposed only to fatal/non-fatal error messages. It may well be the case that we don't want to impose such an ordering -- but we need to be clear either way. > Mealling > Ahh, yes. Since we assume that a given set of results may have a > Mealling > records from different servers then how do we associate an error > Mealling > with a given set of records. > > Could we add a ServiceRef to each error so that the errors > could be related to a Service source the same way that Resources are? This works to the granularity of per-service errors/system messages. It doesn't work within a given service. Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 27 19:12:11 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27642 for ; Mon, 27 Mar 2000 19:12:10 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA10789; Mon, 27 Mar 2000 19:07:37 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8636459 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 27 Mar 2000 19:07:36 -0500 Received: from bab5.dscga.com (bab5.dscga.com [207.120.28.7]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA10768 for ; Mon, 27 Mar 2000 19:07:32 -0500 (EST) Received: from hermes ([207.120.28.194]) by bab5.dscga.com (8.8.7/8.8.7) with SMTP id TAA07272 for ; Mon, 27 Mar 2000 19:02:13 -0500 References: <38DC3F59.155EBBB5@thinkingcat.com> <20000326222701.A4673@bailey.dscga.com> <000901bf9800$8bb6d3e0$382d10ac@netsol.com> <38DFE8AD.2C6FA256@thinkingcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <004b01bf9849$13516840$382d10ac@netsol.com> Date: Mon, 27 Mar 2000 19:03:34 -0500 Reply-To: Ben Schepens From: Ben Schepens Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit > Howdy, > > Ben Schepens wrote: > > > Result set ordering: are results presented in some kind of an > > > ordered list? (would facilitate presenting per-result errors). > > > > Formally speaking, as the DTD is defined, 'Errors' are grouped > > per 'Result'. If you meant to say per-'Resource' errors, I am > > Gee, Ben, if you're going to be snooty about splitting a semantic hair > with me, get it right! The element is "Results", not "Result". The > further point being that I wasn't speaking in DTD elements, but rather > general terminology -- "result" being one thing in a "result set". Sorry... not trying to be snooty. I was just trying to be specific... and yet I still didn't get it quite right ;-) > > > not sure how that would be useful. It seems to me that a 'Resoure' > > returned in the Result represents a successful answer. If there > > were a problem, an 'Error' element would have been returned in the > > 'Result' INSTEAD of a 'Resource'. > > To explain a bit further: > > In the case of non-fatal errors, e.g., hints ignored. > > In the general case of system messages, can also include > informational messages. > > Thinking ahead, perhaps, there's also the issue of what happens > if the service you're connected to is in fact fronting for a > number of services or namespaces; having only "failed" or > "succeeded" as report codes for the entire result set is pretty > much lame. (This is the part that Michael referred to). > I have a question. Isn't it possible for a Result Set to contain both Resources that could represent successful results and Errors that could be fatal or non-fatal error values? If so, given the possible scenario where one service fronts for others, could we not represent problems with some services mixed in with the successful results of others in a single result set? Or am I looking at the problem too simplisitcally? Or am I off track completely? If it is more complicated, would adding an Error/Info element list to each Resource be a valid way to increase the specific details we can send back for each Resource? > > The most important thing to get resolved in the CNRP document is > whether or not the client should expect the components of the "Results" > to be ordered for any reason. > > Next, do we want to impose any semantics on the ordering (if they > are ordered) -- e.g., error messages that apply only to the > resource/record element that follows, etc. This may make more sense > in the context of messages that are "system messages including > error messages", as opposed only to fatal/non-fatal error messages. > > It may well be the case that we don't want to impose such an ordering > -- but we need to be clear either way. > > > Mealling > Ahh, yes. Since we assume that a given set of results may have a > > Mealling > records from different servers then how do we associate an error > > Mealling > with a given set of records. > > > > Could we add a ServiceRef to each error so that the errors > > could be related to a Service source the same way that Resources are? > > This works to the granularity of per-service errors/system messages. > It doesn't work within a given service. > > Leslie. > > -- > > ------------------------------------------------------------------- > "My body obeys Aristotelian laws of physics." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 27 19:49:17 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28077 for ; Mon, 27 Mar 2000 19:49:16 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA18113; Mon, 27 Mar 2000 19:42:20 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8636496 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 27 Mar 2000 19:42:18 -0500 Received: from mail.iagu.net (ns.iagu.net [203.32.153.69]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id TAA18086 for ; Mon, 27 Mar 2000 19:42:14 -0500 (EST) Received: from dhcp-193-74.ietf.connect.com.au [169.208.193.74] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id KAA01804 return ; Tue, 28 Mar 2000 10:06:28 +0930 (CST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DC3F59.155EBBB5@thinkingcat.com> <20000326222701.A4673@bailey.dscga.com> <000901bf9800$8bb6d3e0$382d10ac@netsol.com> <38DFE8AD.2C6FA256@thinkingcat.com> <004b01bf9849$13516840$382d10ac@netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DFFD24.7DD4FE57@thinkingcat.com> Date: Mon, 27 Mar 2000 19:30:28 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET Content-Transfer-Encoding: 7bit Howdy, Ben Schepens wrote: > I have a question. Isn't it possible for a Result Set to contain both > Resources > that could represent successful results and Errors that could be fatal or > non-fatal > error values? If so, given the possible scenario where one service fronts > for > others, could we not represent problems with some services mixed in with the > successful results of others in a single result set? > Or am I looking at the problem too simplisitcally? > Or am I off track completely? To this extent, I think we are in agreement, violent or otherwise. (My comment was trying to respond to what I thought was your question about why this might be useful...). So, the "serviceref" suggestion works for this, I think. > If it is more complicated, would adding an Error/Info element list to each > Resource be a valid way to increase the specific details we can send > back for each Resource? ... and we could do this if we want to get to the level of per-result/record/resource information. I _was_ alluding to that -- I think it's useful, but I have concerns that it would be making things too complex. Working group thoughts? No matter what we do, and how we do it, we do need to say whether things are ordered or not... Leslie. -- ------------------------------------------------------------------- "My body obeys Aristotelian laws of physics." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-cnrp-ietf@LISTS.INTERNIC.NET Mon Mar 27 20:08:43 2000 Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28321 for ; Mon, 27 Mar 2000 20:08:42 -0500 (EST) Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id UAA23742; Mon, 27 Mar 2000 20:08:17 -0500 (EST) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8d) with spool id 8636516 for CNRP-IETF@LISTS.INTERNIC.NET; Mon, 27 Mar 2000 20:08:15 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.internic.net (8.9.3/8.9.3) with ESMTP id UAA23716 for ; Mon, 27 Mar 2000 20:08:11 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id TAA06563; Mon, 27 Mar 2000 19:51:18 -0500 (EST) References: <38DC3F59.155EBBB5@thinkingcat.com> <20000326222701.A4673@bailey.dscga.com> <000901bf9800$8bb6d3e0$382d10ac@netsol.com> <38DFE8AD.2C6FA256@thinkingcat.com> <004b01bf9849$13516840$382d10ac@netsol.com> <38DFFD24.7DD4FE57@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Message-ID: <20000327195117.C6485@bailey.dscga.com> Date: Mon, 27 Mar 2000 19:51:17 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Comments & work to do on protocol draft To: CNRP-IETF@LISTS.INTERNIC.NET In-Reply-To: <38DFFD24.7DD4FE57@thinkingcat.com>; from leslie@THINKINGCAT.COM on Mon, Mar 27, 2000 at 07:30:28PM -0500 On Mon, Mar 27, 2000 at 07:30:28PM -0500, Leslie Daigle wrote: > No matter what we do, and how we do it, we do need to say whether > things are ordered or not... I think we do need to say that. If its not in the document already then it should be... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com