From sm@resistor.net Fri Mar 1 00:01:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63D721F886A for ; Fri, 1 Mar 2013 00:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfllKDAK4jTk for ; Fri, 1 Mar 2013 00:01:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1921F8833 for ; Fri, 1 Mar 2013 00:01:29 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2181DT4008541; Fri, 1 Mar 2013 00:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362124880; bh=sZo5SAA964mmqzKCUMkEnJyFomm8d+neQWtpqkLK1Pw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bbH+gcrtMd01F65aQMGKrHTyKA4oEz93pgg3tUlaAVShHT8sT6moB+r2aGCZzZqVk EJkuTMOsQVDfQjdSGjoHaSl+qUBe+aLiayynSQvJHNBUh7s2jNGMJ2OANDe8HHoieJ TJ2x2ApZX3newdW8W0vf58guuoexwl3JGsOm2zrw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362124880; i=@resistor.net; bh=sZo5SAA964mmqzKCUMkEnJyFomm8d+neQWtpqkLK1Pw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pPJOXGNNc1cAHuCPAfsxo+nYXot4bNnMtM8olQNyd4v4Hcxo6it451mkDcJbvG055 HuS5Yr5oSFZ6aS/xBLWVKFifq479ZOPpLA2wbW9+ybFZx+YBdDn7uTiDXU+p6IfA2Y Kt1lb/7AIj0MLgJKqenQNlNZaDN0tTCGq5vfCXJs= Message-Id: <6.2.5.6.2.20130228234842.0ae30530@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 23:57:03 -0800 To: Andy Newton From: SM In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04A8@CHAXCH01.corp.ari n.net> References: <6.2.5.6.2.20130228223223.0ad6c7f0@resistor.net> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04A8@CHAXCH01.corp.arin.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:01:29 -0000 Hi Andy, At 23:29 28-02-2013, Andy Newton wrote: >Care to explain? It is better not to express information in a identifier (string). I do not have to get into UTF-8 if the string is merely about something unique. Otherwise, I have to deal with UTF-8; I have to deal with the various conventions which anyone in the world can dream about. Regards, -sm From andy@arin.net Fri Mar 1 00:19:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB64321F8984 for ; Fri, 1 Mar 2013 00:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddVqafXSpbLx for ; Fri, 1 Mar 2013 00:19:46 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5821F8899 for ; Fri, 1 Mar 2013 00:19:46 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 79EA5213693; Fri, 1 Mar 2013 03:19:45 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 2CBFA213648; Fri, 1 Mar 2013 03:19:45 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 1 Mar 2013 03:18:51 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 1 Mar 2013 03:19:31 -0500 From: Andy Newton To: SM Thread-Topic: [weirds] Entity "Objects" Thread-Index: Ac4VpSpYsI/bTeI7RJeUXSF9/NAbNQAECmOAABu3eIAAFG7BAP//qRdngADiEoD//y7vF4AA3vgA Date: Fri, 1 Mar 2013 08:19:30 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04D4@CHAXCH01.corp.arin.net> In-Reply-To: <6.2.5.6.2.20130228234842.0ae30530@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:19:46 -0000 On 3/1/13 3:57 PM, "SM" wrote: >It is better not to express information in a identifier (string). I >do not have to get into UTF-8 if the string is merely about something >unique. Otherwise, I have to deal with UTF-8; I have to deal with >the various conventions which anyone in the world can dream about. It is not meaningful information to anybody but the server operator. If they wish to prefix certain types of contact ids with a specific string or represent them as integers only divisible by 3 they are free to do so. To the client is an opaque identifier only. -andy From nkong@cnnic.cn Fri Mar 1 02:16:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC021F8700 for ; Fri, 1 Mar 2013 02:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+fhNtuk3YI6 for ; Fri, 1 Mar 2013 02:16:37 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id C771D21F86BE for ; Fri, 1 Mar 2013 02:16:36 -0800 (PST) Received: from unknown127.0.0.1 (HELO [218.241.103.89]) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 01 Mar 2013 18:16:29 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> Date: Fri, 1 Mar 2013 18:16:29 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> To: SM X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 10:16:38 -0000 Hi SM, > I took a quick look at draft-ietf-weirds-rdap-sec-01. Is it a = protocol specification or a requirements document? Our goal is to make a protocol spec although it maybe looks more like a = requierments document now.=20 > What is the meaning of "security services"? Security services in this document means authentication, authorization, = availability, and data confidentiality service for the RDAP. You could = find a description of each of these security services in RFC 4949. Cheers, Ning= From simon.perreault@viagenie.ca Fri Mar 1 02:33:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453AB21F85A0 for ; Fri, 1 Mar 2013 02:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEJkhSt3ej2y for ; Fri, 1 Mar 2013 02:33:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F58821F858E for ; Fri, 1 Mar 2013 02:33:11 -0800 (PST) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EA3BF4685C for ; Fri, 1 Mar 2013 05:33:10 -0500 (EST) Message-ID: <513083E6.3000107@viagenie.ca> Date: Fri, 01 Mar 2013 11:33:10 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> <6.2.5.6.2.20130228143447.0a0c76f0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] loop breaking, was I-D Action: draft-ietf-weirds-redirects-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 10:33:12 -0000 Le 2013-02-28 23:48, John R Levine a écrit : >>> curl and wget recognize and break redirect loops. Javascript depends >>> on the browser in which it's running, but they all break redirect >>> loops, too. It's very simple: after some large fixed number of >>> redirects, like 20, they declare failure and stop. >> >> If I understood the above correctly it is about having the client >> (browser, etc.) perform loop detection instead of doing it on the >> server side. > > Correct. My point is that all likely clients already do loop breaking > at the http level, so there's no point in trying to do it again. +1 No need for face time about this in Orlando. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From sm@resistor.net Fri Mar 1 03:09:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7CD21F8A25 for ; Fri, 1 Mar 2013 03:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdZJvnmRrMTz for ; Fri, 1 Mar 2013 03:09:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886A21F89FB for ; Fri, 1 Mar 2013 03:09:41 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r21B9K1L018352; Fri, 1 Mar 2013 03:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362136171; bh=8NCkB6OSd2caCi4lVfNhgEOL/42XS9UiEOFsyanXcuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0G/xOxzw3dyN+jFW2ORJPOkMWBmSVJnp1lubXYWCHRjHMhBf9unHufqxWG9Y4wN7D 931Mtp91p0Ga247GXwJBy9KDMG6OVJurJnE+GofQxvbv1j51zAfwwZDOZUJRFsWniL GVTQUiFAlN4/8hjaO+emiBVGHuimzADVTSC0shX8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362136171; i=@resistor.net; bh=8NCkB6OSd2caCi4lVfNhgEOL/42XS9UiEOFsyanXcuI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dcb6MbMQ8nXg1YhYmlywls1BUFvqyvgsAUBwEEvnIqonyEBmMq1sBHoq2NTtLNeKu j3L7cpdhxncJBSkSjlOUKdTAUYg2I7AHr0eiWygAVen/pQ90JhHBmXz5q2L02iZbaN dsLZrosE67zBfNiDKc3uWaA8h+PcbtX0EaWs7nCo= Message-Id: <6.2.5.6.2.20130301024435.0be6c7c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Mar 2013 02:47:48 -0800 To: Andy Newton From: SM In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04D4@CHAXCH01.corp.ari n.net> References: <6.2.5.6.2.20130228234842.0ae30530@resistor.net> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04D4@CHAXCH01.corp.arin.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:09:43 -0000 Hi Andy, At 00:19 01-03-2013, Andy Newton wrote: >It is not meaningful information to anybody but the server operator. If If the information is only meaningful to the server operator it is better in my opinion to say less about it. Regards, -sm From sm@resistor.net Fri Mar 1 03:10:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C221F84D9 for ; Fri, 1 Mar 2013 03:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXKBOkR-83LA for ; Fri, 1 Mar 2013 03:10:10 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBA021F8507 for ; Fri, 1 Mar 2013 03:10:10 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r21B9K1J018352; Fri, 1 Mar 2013 03:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362136166; bh=DBzj5XLYb1SG2Tr4PQEWs6DjBYb/8X2Nd0UNqniWLCk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hhHPqhInB06NBXGQ2WSQYVqmboKhE+xd9crw+gZGY1SAouGMSIksmcVRHVIZIQaoX Rv2Lr36yIGcia6TP79RCOfC09zus88IUM7j8LgWjpxcrpTONuQL2ML8mWHMuxyd6sw Jq0VFeAJNW+YrU27QNbMjNwmVWTYciunNdeZul2k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362136166; i=@resistor.net; bh=DBzj5XLYb1SG2Tr4PQEWs6DjBYb/8X2Nd0UNqniWLCk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MyfD9ulu98H3a9BNl+LcPfFdNAJ+ahQNqM8bICdpjQIe55MrMFf9p9oHUCMIpP841 2IH94trkDD8TRY1qyia4xvbbjBGfFmCqV4oYAH6CAeCeEgqVC4NfZTQ3bYOjV54bOS HqLidSM04SzVyy9dIpinC8F/tzffKfeh1NKGsKM4= Message-Id: <6.2.5.6.2.20130301023454.0c1d6250@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Mar 2013 02:44:13 -0800 To: Ning Kong From: SM In-Reply-To: References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org, weirds@ietf.org Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:10:11 -0000 Hi Ning, At 02:16 01-03-2013, Ning Kong wrote: >Our goal is to make a protocol spec although it maybe looks more >like a requierments document now. Ok. >Security services in this document means authentication, >authorization, availability, and data confidentiality service for >the RDAP. You could find a description of each of these security >services in RFC 4949. As I mentioned previously security is not an add-on service. It would be better to look at the matter in terms of security properties provided by a protocol especially if the goal is to end up with a protocol specification. Regards, -sm From dk@hostmaster.ua Fri Mar 1 03:24:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1F21F8A09 for ; Fri, 1 Mar 2013 03:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNqudhJn3nNx for ; Fri, 1 Mar 2013 03:24:14 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3BE21F89B2 for ; Fri, 1 Mar 2013 03:24:14 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1D96820A0C; Fri, 1 Mar 2013 06:24:10 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 01 Mar 2013 06:24:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=Q4t dqn/H/vbidUUcYPmjtC8QloI=; b=A/pATl7hHZmo6/cb/mofG6HmklS+MBDNmVN hCXKuTFMbxFapGuSEn7yNU9HddoYUmOsoYt2+JVXlPjpAH8lt0TXdwLA4M+7Tmha eb2RxMypKPC0+uR6skGTilRZkJx3IazN92sQx5+pIqMOYT1S5L3FRv2BGmHRO+S5 7Lk9Lfv4= X-Sasl-enc: D86KbfBYIXCtmugeCTPBHNzapD/C6gHQbboRd/IGfdZJ 1362137049 Received: from [192.168.0.108] (unknown [95.135.25.32]) by mail.messagingengine.com (Postfix) with ESMTPA id E39C720112A; Fri, 1 Mar 2013 06:24:08 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B254B98-DF54-4BE2-9200-D74D979D25C0" From: Dmitry Kohmanyuk In-Reply-To: Date: Fri, 1 Mar 2013 13:24:09 +0200 Message-Id: References: To: James Mitchell X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:24:15 -0000 --Apple-Mail=_3B254B98-DF54-4BE2-9200-D74D979D25C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 28, 2013, at 11:26 PM, James Mitchell = wrote: > Scott, >=20 > Perhaps contact objects and registrar objects share the same = identifier space in Verisign's system, however in ours they do not. What = object is identified by /entity/R-12345? My answer is both a contact and = a registrar; the role does not satisfy the outcome as they will have = different names, email addresses etc. >=20 > If I do not care about direct queries for contact/registrar objects = (URLs constructed by clients), and instead assume that links will always = be obtained in domain response, then I CAN generate identifiers that = separate the two identifier spaces (append C or R as appropriate) - = however having to work around this does not feel right to me. >=20 > I believe that registrars should be their own path segments at = /registrar/id. Does anyone else have this problem? I agree with separation of registrar object and contact object - but as = others pointed out there may be multiple types of contacts (registrant, administrative, technical, billing, registrar, reseller) = and to establish a namespace convention for each of them would require WEIRDS to specify now all kinds of contacts there can be (or establish a = registry for them with IANA, or both.) Contacts may reference each other (in EPP schema, person-registrant = contact is "owned" by registrar, but cannot be "owned" by admin-c.) Example (output contains UTF-8 strings in *-loc: fields): ; whois -h whois.ua farm.org.ua=20 % This is the Ukrainian Whois query server #B. % The Whois is subject to Terms of use % See https://hostmaster.ua/services/ % domain: farm.org.ua dom-public: NO registrant: frh-kpuh6om0dfxz admin-c: frh-il67tvusqjxy tech-c: frh-il67tvusqjxy mnt-by: ua.freehost nserver: ns-he.kolo.net nserver: ns.kolo.net status: clientTransferProhibited created: 2012-07-30 10:32:25+03 modified: 2013-02-19 18:30:05+02 expires: 2013-07-30 10:32:25+03 source: UAEPP % Registrar: % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D registrar: ua.freehost organization: Freehost organization-loc: =D0=9F=D0=9F "=D0=A4=D1=80=D1=96=D1=85=D0=BE=D1=81=D1=82= " url: http://www.freehost.ua city: Kyiv country: UA source: UAEPP % Registrant: % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D contact-id: frh-kpuh6om0dfxz person: not published e-mail: not published address: n/a mnt-by: ua.freehost status: ok status: linked created: 2013-02-19 18:30:03+02 source: UAEPP % Administrative Contacts: % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D contact-id: frh-il67tvusqjxy person: not published e-mail: not published address: n/a mnt-by: ua.freehost status: ok status: linked created: 2013-02-19 18:30:03+02 source: UAEPP % Technical Contacts: % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D contact-id: frh-il67tvusqjxy person: not published e-mail: not published address: n/a mnt-by: ua.freehost status: ok status: linked created: 2013-02-19 18:30:03+02 source: UAEPP % Query time: 16 msec --Apple-Mail=_3B254B98-DF54-4BE2-9200-D74D979D25C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 james.mitchell@ausregist= ry.com.au> wrote:
Scott,

Perhaps = contact objects and registrar objects share the same identifier = space in Verisign's system, however in ours they do not. What = object is identified by /entity/R-12345? My answer is both a contact and = a registrar; the role does not satisfy the outcome as they will have = different names, email addresses etc.

If I do = not care about direct queries for contact/registrar objects (URLs = constructed by clients), and instead assume that links will always be = obtained in domain response,  then I CAN generate identifiers that = separate the two identifier spaces (append C or R as appropriate) - = however having to work around this does not feel right to = me.

I believe that registrars should be their = own path segments at /registrar/id. Does anyone else have this = problem?

I agree with separation = of registrar object and contact object - but as others pointed out there = may be multiple types of contacts
(registrant, administrative, = technical, billing, registrar, reseller) and to establish a namespace = convention for each of them would require
WEIRDS to specify = now all kinds of contacts there can be (or establish a registry for them = with IANA, or both.)

Contacts may reference = each other (in EPP schema, person-registrant contact is "owned" by = registrar, but cannot be "owned" by = admin-c.)

Example (output contains UTF-8 = strings in *-loc: fields):

; whois -h whois.ua farm.org.ua 

% This is the Ukrainian Whois query server #B.
% The = Whois is subject to Terms of use

dom-public:   =     NO
registrant:       = frh-kpuh6om0dfxz
admin-c:         =  frh-il67tvusqjxy
tech-c:         =   frh-il67tvusqjxy
mnt-by:         =   ua.freehost
nserver:         =  ns-he.kolo.net
nserver: =          ns.kolo.net
status:   =         clientTransferProhibited
created: =          2012-07-30 = 10:32:25+03
modified:         2013-02-19 = 18:30:05+02
expires:         =  2013-07-30 10:32:25+03
source:       =     UAEPP

% Registrar:
% = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
registrar:       =  ua.freehost
organization:     = Freehost
organization-loc: =D0=9F=D0=9F = "=D0=A4=D1=80=D1=96=D1=85=D0=BE=D1=81=D1=82"
url:   =            http://www.freehost.ua
city:=             Kyiv
country: =          UA
source:     =       UAEPP

% = Registrant:
% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
contac= t-id:       frh-kpuh6om0dfxz
person:   =         not published
e-mail:   =         not published
address:   =        n/a
mnt-by:       =     ua.freehost
status:         =   ok
status:           = linked
created:          2013-02-19 = 18:30:03+02
source:           = UAEPP


% Administrative = Contacts:
% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
contact-id:       = frh-il67tvusqjxy
person:           = not published
e-mail:           not = published
address:         =  n/a
mnt-by:           = ua.freehost
status:           = ok
status:           = linked
created:          2013-02-19 = 18:30:03+02
source:           = UAEPP


% Technical = Contacts:
% =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
contact-id:       = frh-il67tvusqjxy
person:           = not published
e-mail:           not = published
address:         =  n/a
mnt-by:           = ua.freehost
status:           = ok
status:           = linked
created:          2013-02-19 = 18:30:03+02
source:           = UAEPP



% Query = time:     16 msec

= --Apple-Mail=_3B254B98-DF54-4BE2-9200-D74D979D25C0-- From shollenbeck@verisign.com Fri Mar 1 04:17:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75121F8AB2 for ; Fri, 1 Mar 2013 04:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP+CmAyIIo2X for ; Fri, 1 Mar 2013 04:17:28 -0800 (PST) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2A21F8AAC for ; Fri, 1 Mar 2013 04:17:24 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUTCcUyUKFeXR/LQMzr7rzuCtH9DrUMEV@postini.com; Fri, 01 Mar 2013 04:17:27 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r21CHJYu001765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 07:17:20 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 1 Mar 2013 07:17:18 -0500 From: "Hollenbeck, Scott" To: "james.mitchell@ausregistry.com.au" , "weirds@ietf.org" Thread-Topic: Entity "Objects" Thread-Index: Ac4V+kmNQNSbs+CDTbmTTuUvhpGo5gAe7Qiw Date: Fri, 1 Mar 2013 12:17:18 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24326044@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F24325839@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F24326044BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 12:17:30 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24326044BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please don't suggest any Verisign bias here. There is none. =D8 What object is identified by /entity/R-12345? Your answer will depend on the roles associated with that entity. There may= be more than one. Andy From: James Mitchell [mailto:james.mitchell@ausregistry.com.au] Sent: Thursday, February 28, 2013 4:27 PM To: Hollenbeck, Scott; weirds@ietf.org Subject: Re: Entity "Objects" Scott, Perhaps contact objects and registrar objects share the same identifier spa= ce in Verisign's system, however in ours they do not. What object is identi= fied by /entity/R-12345? My answer is both a contact and a registrar; the r= ole does not satisfy the outcome as they will have different names, email a= ddresses etc. If I do not care about direct queries for contact/registrar objects (URLs c= onstructed by clients), and instead assume that links will always be obtain= ed in domain response, then I CAN generate identifiers that separate the t= wo identifier spaces (append C or R as appropriate) - however having to wor= k around this does not feel right to me. I believe that registrars should be their own path segments at /registrar/i= d. Does anyone else have this problem? Regards, James From: , Scott > Date: Friday, 1 March 2013 12:17 AM To: James Mitchell >, "weirds@ietf.org" > Subject: RE: Entity "Objects" Entity objects can be identified by role. A registrar entity and a contact = entity (such as a registrant) would have distinct roles in the context of a= domain object. Scott From: weirds-bounces@ietf.org [mailto:weird= s-bounces@ietf.org] On Behalf Of James Mitchell Sent: Thursday, February 28, 2013 6:17 AM To: weirds@ietf.org Subject: [weirds] Entity "Objects" All, I am concerned regarding the use of the entity object as described in the r= dap query draft. It appears to me as though two separate objects, contacts = and registrars, have been pulled together because they share data. This is = problematic for me because - Contact objects and Registrar objects do not share the same identifier s= pace. - Contact objects and Registrar objects share very little data; one may th= ink of registrar objects as being composed of contact-like (not contact obj= ect) data, perhaps even several contact-like objects (registrar-contact obj= ects do not share the same identifier space as domain-contact objects) What is the motivation for shared query mechanism? Is it to avoid having on= e less path segment? How would one convey information about a registrar to = the client, for example IANA ID without using registry-specific extensions? Thanks, James --_000_831693C2CDA2E849A7D7A712B24E257F24326044BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please don’t sugges= t any Verisign bias here. There is none.

 <= /p>

=D8  What object is id= entified by /entity/R-12345?

 <= /p>

Your answer will depend o= n the roles associated with that entity. There may be more than one.

 <= /p>

Andy

 <= /p>

From: James Mi= tchell [mailto:james.mitchell@ausregistry.com.au]
Sent: Thursday, February 28, 2013 4:27 PM
To: Hollenbeck, Scott; weirds@ietf.org
Subject: Re: Entity "Objects"

 

Scott,

 

Perhaps contact objects and= registrar objects share the same identifier space in Verisign's syste= m, however in ours they do not. What object is identified by /entity/R-12345? My answer is both a contact and a registrar; the role doe= s not satisfy the outcome as they will have different names, email addresse= s etc.

 

If I do not care about dire= ct queries for contact/registrar objects (URLs constructed by clients), and= instead assume that links will always be obtained in domain response,  then I CAN generate identifiers that separate the two iden= tifier spaces (append C or R as appropriate) - however having to work aroun= d this does not feel right to me.

 

I believe that registrars s= hould be their own path segments at /registrar/id. Does anyone else have th= is problem?

 

Regards,<= /p>

James

 

From: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Date: Friday, 1 March 2013 12:17 AM
To: James Mitchell <james.mitchell@ausregistry.com.au>, "weirds@ietf.org" <weirds@ietf.org>
Subject: RE: Entity "Objects"

 

Entity objects can be ide= ntified by role. A registrar entity and a contact entity (such as a registr= ant) would have distinct roles in the context of a domain object.

 

Scott

 

From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of James Mitchell
Sent: Thursday, February 28, 2013 6:17 AM
To: weirds@ietf.org
Subject: [weirds] Entity "Objects"

 =

All,

 

I am concerned regarding th= e use of the entity object as described in the rdap query draft. It appears= to me as though two separate objects, contacts and registrars, have been pulled together because they share data. This is problemati= c for me because

 - Contact objects and Registrar objects do not share the s= ame identifier space.<= /span>

 - Contact objects and= Registrar objects share very little data; one may think of registrar objec= ts as being composed of contact-like (not contact object) data, perhaps even several contact-like objects (registrar-contact objects do no= t share the same identifier space as domain-contact objects)

 

What is the motivation for = shared query mechanism? Is it to avoid having one less path segment? How wo= uld one convey information about a registrar to the client, for example IANA ID without using registry-specific extensions?

 

Thanks,

James

--_000_831693C2CDA2E849A7D7A712B24E257F24326044BRN1WNEXMBX01vc_-- From shollenbeck@verisign.com Fri Mar 1 04:24:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B154521F8AD8 for ; Fri, 1 Mar 2013 04:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egJIYSerzKzh for ; Fri, 1 Mar 2013 04:24:27 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C821F8ABD for ; Fri, 1 Mar 2013 04:23:38 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUTCdyo68Tx2sZferKnAy9SdgtsmhiaTY@postini.com; Fri, 01 Mar 2013 04:24:27 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r21CNb5L001923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 07:23:37 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 1 Mar 2013 07:23:36 -0500 From: "Hollenbeck, Scott" To: Ning Kong , Marc Blanchet Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-sec Thread-Index: AQHOET0xZIaYDN1CSky+W3AfV+rdaJiQjzSAgAA8LWA= Date: Fri, 1 Mar 2013 12:23:36 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24326086@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> In-Reply-To: <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 12:24:27 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Ning Kong > Sent: Thursday, February 28, 2013 10:43 PM > To: Marc Blanchet > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds@ietf.org > Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec >=20 > Hi Marc and Jean-Philippe, >=20 > Thanks for your review. Below are my feedbacks. >=20 > 3.1. Authentication > > There is an IETF thread going on to update/obsolete these basic > schemes (see httpauth working group charter). Therefore, it should be > prudent to instead align with that. > > >=20 > I agree that we should follow the relative outputs of this proposed WG. I agree with this in principle, but only if adding a normative dependency d= oes not slow us down in any way. The current references are stable, impleme= nted, widely deployed, and already noted in Appendix A of draft-ietf-httpbi= s-authscheme-registrations. The current normative references are included i= n this appendix. What, exactly, would need to change? Scott From shollenbeck@verisign.com Fri Mar 1 04:31:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFA921F8AC8 for ; Fri, 1 Mar 2013 04:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5-ap2XmuxfM for ; Fri, 1 Mar 2013 04:31:43 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7421F8806 for ; Fri, 1 Mar 2013 04:30:49 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUTCfeY9dxQdlUMJK0njdFhFzjcFCw9q4@postini.com; Fri, 01 Mar 2013 04:31:41 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r21CUlM6002154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Mar 2013 07:30:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 1 Mar 2013 07:30:46 -0500 From: "Hollenbeck, Scott" To: SM , Ning Kong Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-sec Thread-Index: AQHOET0xZIaYDN1CSky+W3AfV+rdaJiQjzSAgAArUgCAABJMoA== Date: Fri, 1 Mar 2013 12:30:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243260A7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> In-Reply-To: <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-weirds-rdap-sec@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 12:31:43 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of SM > Sent: Friday, March 01, 2013 1:19 AM > To: Ning Kong > Cc: draft-ietf-weirds-rdap-sec@tools.ietf.org; weirds@ietf.org > Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-sec >=20 > Hi Ning, >=20 > I took a quick look at draft-ietf-weirds-rdap-sec-01. Is it a protocol > specification or a requirements document? This is spelled out in both the abstract and the introduction. It is neithe= r, exclusively, but it does include requirements. If you're trying to frame= the context in more familiar terms it could be considered an external secu= rity considerations section that is applicable to multiple WEIRDS specifica= tions. > What is the meaning of "security services"? The meaning is intended to be the same one described and used in RFC 4949. = I'm having a hard time trying to break it down into simpler terms that mean= the same thing as "services that provide elements of information security"= . Scott From simon.perreault@viagenie.ca Fri Mar 1 07:51:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5398721E8064 for ; Fri, 1 Mar 2013 07:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWpT6S-PKBzK for ; Fri, 1 Mar 2013 07:50:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id A12B721E8051 for ; Fri, 1 Mar 2013 07:50:54 -0800 (PST) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4EB37403ED for ; Fri, 1 Mar 2013 10:50:23 -0500 (EST) Message-ID: <5130CE3E.60503@viagenie.ca> Date: Fri, 01 Mar 2013 16:50:22 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: multipart/mixed; boundary="------------090607030806090409060405" Subject: [weirds] Comments on json-response-02 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:51:00 -0000 This is a multi-part message in MIME format. --------------090607030806090409060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See attached. My comments are marked with .... I have included all the necessary changes to switch to jCard. Hopefully this makes the editor's job easier. :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca --------------090607030806090409060405 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-weirds-json-response-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-weirds-json-response-02.txt" Network Working Group A. Newton Internet-Draft ARIN Intended status: Standards Track S. Hollenbeck Expires: July 7, 2013 Verisign Labs January 3, 2013 JSON Responses for the Registration Data Access Protocol (RDAP) draft-ietf-weirds-json-response-02 Abstract This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Newton & Hollenbeck Expires July 7, 2013 [Page 1] Internet-Draft RDAP JSON RESPONSES January 2013 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6 4. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Common Data Structures . . . . . . . . . . . . . . . . . . . . 10 5.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . 10 5.2. Notices . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Language Identifier . . . . . . . . . . . . . . . . . . . 11 5.4. An Example . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Object Class Links . . . . . . . . . . . . . . . . . . . . . . 13 7. The Entity Object Class . . . . . . . . . . . . . . . . . . . 14 7.1. The RIR Entity Object Class . . . . . . . . . . . . . . . 15 7.2. The DNR Entity Object Class . . . . . . . . . . . . . . . 16 8. The Nameserver Object Class . . . . . . . . . . . . . . . . . 19 9. The Domain Object Class . . . . . . . . . . . . . . . . . . . 21 9.1. The RIR Domain Object Class . . . . . . . . . . . . . . . 21 9.2. The DNR Domain Object Class . . . . . . . . . . . . . . . 24 10. The IP Network Object Class . . . . . . . . . . . . . . . . . 29 11. Autonomous System Number Entity Object Class . . . . . . . . . 32 12. Error Response Body . . . . . . . . . . . . . . . . . . . . . 35 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 14. Internationalization Considerations . . . . . . . . . . . . . 37 14.1. Character Encoding . . . . . . . . . . . . . . . . . . . . 37 14.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 37 14.3. Language Tags . . . . . . . . . . . . . . . . . . . . . . 37 14.4. Internationalized Domain Names . . . . . . . . . . . . . . 37 15. Contributing Authors and Acknowledgements . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . . 40 Appendix A. Suggested Values . . . . . . . . . . . . . . . . . . 41 A.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.3. Variant Relations . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Suggested Data Modeling with the Entity Object Class . . . . . . . . . . . . . . . . . . . . . . . . 43 B.1. Registrants and Contacts . . . . . . . . . . . . . . . . . 43 B.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix C. IDN Query and Response Model . . . . . . . . . . . . 46 Appendix D. Postal Addresses vs Location . . . . . . . . . . . . 47 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 48 Newton & Hollenbeck Expires July 7, 2013 [Page 2] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Newton & Hollenbeck Expires July 7, 2013 [Page 3] Internet-Draft RDAP JSON RESPONSES January 2013 1. Introduction This document describes responses in the JSON [RFC4627] format for the RESTful web queries as defined by UNIFIED-RDAP-QUERY [I-D.ietf-weirds-rdap-query]. The data model for the responses consists of two major categories: responses returned by Regional Internet Registries (RIRs) for registrations data related to IP addresses, reverse DNS names, and Autonomous System numbers; and responses returned by Domain Name Registries (DNRs) for registration data related to forward DNS names. The RIR object classes are a proper subset of the DNR object classes. The current division between RIR and DNR object classes is given to illustrate an expectation of what data may be expected from an RIR vs a DNR. However, implementers should be aware that RIRs are not limited to the data in the RIR object classes (as an example, some RIRs have a notion of "status" for entities as defined in the DNR entity object class and may at some point start publishing that data). Object classes defined in the document represent a minimal set of what a compliant client/server MUST understand to function correctly, however some deployments may want to include additional object classes to suit individual needs. Anticipating this need for extension, Section 4.2 of this document defines a mechanism for extending the JSON (objects) that are described in this document. Newton & Hollenbeck Expires July 7, 2013 [Page 4] Internet-Draft RDAP JSON RESPONSES January 2013 2. Terminology and Definitions The following list describes terminology and definitions used throughout this document: DNR: "Domain Name Registry". member: data found with in an object as defined by JSON [RFC4627]. object: a data structure as defined by JSON [RFC4627]. object class: the definition of members that may be found in JSON objects described in this document. object instance: an instantiation or specific instance of an object class. RDAP: "Registration Data Access Protocol". RIR: "Regional Internet Registry". Newton & Hollenbeck Expires July 7, 2013 [Page 5] Internet-Draft RDAP JSON RESPONSES January 2013 3. Common Data Types JSON [RFC4627] defines the data types of a number, character string, boolean, array, object and null. This section describes the semantics and/or syntax reference for data types used in this document derived from the JSON character string. 'handle': DNRs and RIRs have registry-unique identifiers that may be used to specifically reference an object instance. The semantics of this data type as found in this document is to be a registry-unique reference to the closest enclosing object where the value is found. The data type names 'registryId', 'roid', 'nic-handle', 'registrationNo', etc... are terms often synonymous with this data type. In this document, the term 'handle' is used. The term exposed to users by clients is a presentation issue beyond the scope of this document. IPv4 addresses: The representation of IPv4 addresses in this document uses the dotted-decimal notation described in [RFC1166]. An example of this textual representation is '192.0.2.0'. IPv6 addresses: The representation of IPv6 addresses in this document follow the forms outlined in [RFC5952]. An example of this textual representation is '2001:db8::1:0:0:1'. country codes: Where the identity of a geopolitical nation or country is needed, these identities are represented with the alpha-2 or 2 character country code designation as defined in [ISO.3166.1988]. The alpha-2 representation is used because it is freely available whereas the alpha-3 and numeric-3 standards are not. domain names: Textual representations of DNS names follow the rules set forth in [RFC4343], specifically the case insensitivity and character escaping rules. Trailing periods are optional for both input and output. email addresses: Textual representations of email addresses follow the syntax defined in [RFC5322]. dates and times: The syntax for values denoting dates and times is defined in [RFC3339]. URIs: The syntax for values denoting a Uniform Resource Identifier (URI) is defined by [RFC3986]. Add: jCards: JSON vCards, as defined in [I.D.kewisch-vcard-in-json], are used for contact information. Many of the object classes defined in this document contain values representing telephone numbers. Servers are encouraged to provide Newton & Hollenbeck Expires July 7, 2013 [Page 6] Internet-Draft RDAP JSON RESPONSES January 2013 those telephone numbers in [E164] format, however clients MUST be prepared for telephone numbers that do not adhere to the [E164] standard. Postal addresses also appear in some of the object classes. This document specifies no standard for postal addresses as many registries would have to undergo severe data cleanup efforts to meet such standards. Delete the above two paragraphs as these details are handled by jCard. Newton & Hollenbeck Expires July 7, 2013 [Page 7] Internet-Draft RDAP JSON RESPONSES January 2013 4. Use of JSON 4.1. Signaling Clients may signal their desire for JSON using the "application/json" media type or the more specific media type "application/rdap" as specified in Section 13. 4.2. Naming Clients processing JSON [RFC4627] responses SHOULD ignore values associated with unrecognized names. Servers MAY insert values signified by names into the JSON responses which are not specified in this document. Insertion of unspecified values into JSON responses SHOULD have names prefixed with a short identifier followed by an underscore followed by a meaningful name. The full JSON name, the prefix plus the underscore plus the meaningful name, SHOULD adhere to the character and name limitations of the prefix registry described in [I-D.ietf-weirds-using-http]. Consider the following JSON response with JSON names. "handle" and "remarks" are JSON names specified in this document. { "handle" : "ABC123", "remarks" : [ "she sells seas shells", "down by the seashore" ] } Figure 1 If The Registry of the Moon desires to express information not found in this specification, it might select "lunarNic" as its identifying prefix and insert, as an example, the name "lunarNic_beforeOneSmallStep" to signify registrations occuring before the first moon landing and the name "lunarNic_harshMistressNotes" containing other descriptive text. Newton & Hollenbeck Expires July 7, 2013 [Page 8] Internet-Draft RDAP JSON RESPONSES January 2013 Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning. { "handle" : "ABC123", "lunarNic_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ "she sells seas shells", "down by the seashore" ], "lunarNic_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] } Figure 2 Insertion of unrecognized names ignored by clients may also be used for future revisions to this specification. Clients processing JSON responses MUST be prepared for values specified in this document to be absent from a response as no JSON value listed is required to appear in a response. In other words, servers MAY remove values as is needed by the policies of the server operator. Finally, all JSON names specified in this document are case sensitive. Both servers and clients MUST transmit and process them according to the character casing specified. Newton & Hollenbeck Expires July 7, 2013 [Page 9] Internet-Draft RDAP JSON RESPONSES January 2013 5. Common Data Structures This section defines three common data structures to be used in respones. Each of these datatypes MAY appear within any object class of a response, but the intended purpose is that they will be mostly used in the top-most object class of a response. 5.1. RDAP Conformance The first data structure is named "rdapConformance" and is simply an array of strings, each providing a hint as to the specifications used in the construction of the response. An example rdapConformance data structure. "rdapConformance" : [ "rdap_level_0" ] Figure 3 The string literal "rdap_level_0" signifies conformance with this specification. When custom JSON values are inserted into responses, conformance to those custom specifications should use a string prefixed with the appropriate identifier from the IANA prefix identifier registry specified in [I-D.ietf-weirds-using-http]. For example, if the fictional Registry of the Moon want to signify that their JSON responses are conformant with their registered extensions, the string used might be "lunarNIC_level_0". Example rdapConformance structure with custom extensions noted. "rdapConformance" : [ "rdap_level_0", "lunarNic_level_0" ] Figure 4 5.2. Notices The second data structure is named "notices" and is an array of objects. Each object contains a "title" string representing the title of the notice object, an array of strings named "description" for the purposes of conveying any descriptive text about the notice, and an optional "links" object as described in Section 6. Newton & Hollenbeck Expires July 7, 2013 [Page 10] Internet-Draft RDAP JSON RESPONSES January 2013 An exmaple of the notices data structure. "notices" : [ { "title" : "Terms of Use", "description" : [ "This service is subject to The Registry of the Moons", "terms of service." ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/terms_of_use.html" } ] } ] Figure 5 5.3. Language Identifier The third data structure is a simple JSON name/value of "lang" with a string containing a language identifier as described by [RFC5646]. "lang" : "mn-Cyrl-MN" Figure 6 Newton & Hollenbeck Expires July 7, 2013 [Page 11] Internet-Draft RDAP JSON RESPONSES January 2013 5.4. An Example This is an example response with both rdapConformance and notices embedded. { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Content Redacted", "description" : [ "Without full authorization, content has been redacted.", "Sorry, dude!" ], "links" : [ { "value" : "http://example.net/ip/192.0.2.0/24", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/redaction_policy.html" } ] } ], "lang" : "en", "startAddress" : "192.0.2.0", "endAddress" : "192.0.2.255", "handle" : "XXXX-RIR", "ipVersion" : 4, "name": "NET-RTR-1", "description" : [ "A network used for example documentation" ], "parentHandle" : "YYYY-RIR", "remarks" : [ "she sells seas shells", "down by the seashore" ] } Figure 7 Newton & Hollenbeck Expires July 7, 2013 [Page 12] Internet-Draft RDAP JSON RESPONSES January 2013 6. Object Class Links Each object class defined in this document may have links to other resources on the Internet. The relationship of these links is defined by the IANA registry described by [RFC5988]. The following is an example of the link structure of object classes { "value" : "http://example.com/context_uri", "rel" : "self", "href" : "http://example.com/target_uri", "hreflang" : [ "en", "ch" ], "title" : [ "title1", "title2" ], "media" : "screen", "type" : "application/json" } Figure 8 The JSON name/values of "rel", "href", "hreflang", "title", "media", and "type" correspond to values found in Section 5 of [RFC5988]. The "value" JSON value is the context URI as described by [RFC5988]. The "value", "rel", and "href" JSON values MUST be specified. All other JSON values are optional. Within an object class, these structures are to be in an array named "links". This is an example of the "links" array as it might be found in an object class. "links" : [ { "value" : "http://example.com/ip/2001:db8::123", "rel" : "self", "href" : "http://example.com/ip/2001:db8::123" }, { "value" : "http://example.com/ip/2001:db8::123", "rel" : "up", "href" : "http://example.com/ip/2001:db8::/48" } ] Newton & Hollenbeck Expires July 7, 2013 [Page 13] Internet-Draft RDAP JSON RESPONSES January 2013 7. The Entity Object Class The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in UNIFIED- RDAP-QUERY [I-D.ietf-weirds-rdap-query]. This object class represents the information of organizations, corporations, governments, non-profits, clubs, individual persons, and informal groups of people. All of these representations are so similar that it is best to represent them in JSON [RFC4627] with one construct, the entity object class, to aid in the re-use of code by implementers. Many of the members of the entity object class are repeated in other object classes described later in this document. Newton & Hollenbeck Expires July 7, 2013 [Page 14] Internet-Draft RDAP JSON RESPONSES January 2013 7.1. The RIR Entity Object Class The following is an example of an RIR entity: { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "roles" : [ "registrant" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.com/entity/XXXX", "rel" : "self", "href" : "http://example.com/entity/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } Replace with: { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrant" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.com/entity/XXXX", "rel" : "self", "href" : "http://example.com/entity/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } This object as the following members. o handle -- a string representing an registry unique identifier of the entity Newton & Hollenbeck Expires July 7, 2013 [Page 15] Internet-Draft RDAP JSON RESPONSES January 2013 Add: o vCard -- a JSON vCard with the entity's contact information In the list below, remove entityNames, postalAddress, emails, and phones. o entityNames -- an array of strings, each signifying the name of the entity o roles -- an array of strings, each signifying the relationship an object would have with its closest containing object. o postalAddress -- an array of string, each representing a line in a postal address. o emails -- an array of strings, each containing an email address for the entity o phones -- an object containing telephone information associated with the entity, with the following members: * office -- an array of strings, each being a telephone number * fax -- an array of strings, each being a telephone number * mobile -- an array of strings, each being a telephone number o remarks -- an array of strings, each containing comments about the entity o links -- see Section 6 o registrationDate -- a string containing the date the entity was registered o lastChangedDate -- a string containing the date of last change made to the entity o lastChangedBy -- a string containing an identifier of the party responsible for the last change made to the entity registration 7.2. The DNR Entity Object Class The DNR entity object class is a superset of the RIR entity object class (Section 7.1). It has the following additional members: o registrationBy -- a string containing an identifier of the party responsible for the registration of the entity o sponsoredBy -- a string containing an identifier of the party through which the registration was made, such as an IANA approved registrar Newton & Hollenbeck Expires July 7, 2013 [Page 16] Internet-Draft RDAP JSON RESPONSES January 2013 o resoldBy -- a string containing an identifier of the party originating the registration of the entity. o status -- an array of strings indicating the state of the entity o port43 -- a string containing the fully-qualified host name of the WHOIS [RFC3912] server where the object instance may be found. Newton & Hollenbeck Expires July 7, 2013 [Page 17] Internet-Draft RDAP JSON RESPONSES January 2013 The following is an example of a DNR entity: { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "status" : [ "validated", "locked" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.com/entity/XXXX", "rel" : "self", "href" : "http://example.com/entity/XXXX" } ], "port43" : "whois.example.net", "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } Replace with: { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "status" : [ "validated", "locked" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.com/entity/XXXX", "rel" : "self", "href" : "http://example.com/entity/XXXX" } ], "port43" : "whois.example.net", "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } Newton & Hollenbeck Expires July 7, 2013 [Page 18] Internet-Draft RDAP JSON RESPONSES January 2013 8. The Nameserver Object Class The nameserver object class is used by both RIRs and DNRs. Unlike other object classes used by both registries where the RIR object class is a subset of the DNR object class, a clear delineation is not made with the nameserver object class because some DNRs have the same or a similar registration model as the RIRs. RIRs and some DNRs register or expose nameserver information as an attribute of a domain name, while other DNRs model nameservers as "first class objects". The nameserver object class accommodates both models and degrees of variation in between. The following is an example of a nameserver object. { "handle" : "XXXX", "name" : "ns1.example.com", "status" : [ "active" ], "ipAddresses" : [ "192.0.2.1", "192.0.2.2" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/nameserver/xxxx", "rel" : "self", "href" : "http://example.net/nameserver/xxxx" } ], "port43" : "whois.example.net", "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } Figure 9 Figure 9 is an example of a nameserver object with all values given. Registries using a first-class nameserver data model would embed this Newton & Hollenbeck Expires July 7, 2013 [Page 19] Internet-Draft RDAP JSON RESPONSES January 2013 in domain objects as well as allowing references to it with the /nameserver query type (all depending on the registry operators policy). Other registries may pare back the information as needed. Figure 10 is an example of a nameserver object as would be found in RIRs and some DNRs, while Figure 11 is an example of a nameserver object as would be found in other DNRs. The following is an example of the simplest nameserver object. { "name" : "ns1.example.com" } Figure 10 The following is an example of a simple nameserver object that might be commonly used by DNRs. { "name" : "ns1.example.com", "ipAddresses" : [ "2001:db8::123", "2001:db8::124" ] } Figure 11 The nameserver object class has the following members: o handle -- a string representing an registry unique identifier of the nameserver o name -- a string containing the DNS name of the nameserver o ipAddresses -- an array of strings containing IPv4 and/or IPv6 addresses of the nameserver The members "status", "remarks", "links", "port43", "sponsoredBy", "resoldBy", "registrationBy", "registrationDate", "lastChangedDate", and "lastChangedBy" take the same form of the members of the same name of the entity object (Section 7). Newton & Hollenbeck Expires July 7, 2013 [Page 20] Internet-Draft RDAP JSON RESPONSES January 2013 9. The Domain Object Class The domain object class represents a DNS name and point of delegation. For RIRs these delegation points are in the reverse DNS tree, whereas for DNRs these delegation points are in the forward DNS tree. The RIR domain object class is a subset of the DNR object class. In both cases, the high level structure of the domain object class consists of information about the domain registration, nameserver information related to the domain name, and entities related to the domain name (e.g. registrant information, contacts, etc...). The following is an elided example of the domain object showing the high level structure. { "handle" : "XXX", "name" : "blah.example.com", ... "nameServers" : [ ... ], ... "entities" : [ ... ] } 9.1. The RIR Domain Object Class The following is an example of a JSON object representing a reverse DNS delegation point or the RIR domain object class. { "handle" : "XXXX", "name" : "192.in-addr.arpa", "nameServers" : [ { "name" : "ns1.rir.net" }, { "name" : "ns2.rir.net" } ], "delegationKeys" : Newton & Hollenbeck Expires July 7, 2013 [Page 21] Internet-Draft RDAP JSON RESPONSES January 2013 [ { "algorithm": 7, "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", "digestType" : 1, "keyTag" : 53814 } ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value": "http://example.net/domain/XXXX", "rel" : "self", "href" : "http://example.net/domain/XXXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com", "entities" : [ { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "roles" : [ "registrant" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", Newton & Hollenbeck Expires July 7, 2013 [Page 22] Internet-Draft RDAP JSON RESPONSES January 2013 "down by the seashore" ], "links" : [ { "value": "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] } Replace "entities" with: "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrant" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value": "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] The following is a description of the members of this object: o handle -- a string representing a registry unique identifier of the domain object instance o name -- a string denoting the DNS zone name, which is a domain name o nameservers -- an array of nameserver objects as defined by Section 8 o delegationKeys -- an array of objects, each with the following members: * algorithm -- an integer as specified by the algorithm field of a DNS DS record as specified by RFC 4034 [RFC4034] in presentation format * digest -- an string as specified by the digest field of a DNS DS record as specified by RFC 4034 in presentation format * digestType -- an integer as specified by the digest type field of a DNS DS record as specified by RFC 4034 in presentation format * keyTag -- an integer as specified by the key tag field of a DNS DS record as specified by RFC 4034 in presentation format Newton & Hollenbeck Expires July 7, 2013 [Page 23] Internet-Draft RDAP JSON RESPONSES January 2013 o entities -- an array of entity objects as defined by Section 7.1. The members "remarks", "links", "registrationDate", "lastChangedDate", and "lastChangedBy" take the same form of the members of the same name of the entity object (Section 7). 9.2. The DNR Domain Object Class The DNR domain object class is a superset of the RIR domain object class (Section 9.1) and has the following additional members. o variants -- an array of objects, each containing the following values: * relation -- an array of strings, with each string denoting the relationship between the variants and the containing domain object. * variantNames -- an array of strings, each being a variant domain of the containing domain object. o expirationDate -- a string containing the date and time this domain name registration will expire o registrationBy -- a string containing an identifier of the party responsible for the registration of the domain name o sponsoredBy -- a string containing an identifier of the party through which the registration was made, such as an IANA approved registrar o resoldBy -- a string containing an identifier of the party originating the registration of the domain name o status -- an array of strings indicating the state of the domain name o transferDate -- a string containing the date and time this domain name was transferred o port43 -- a string containing the fully-qualified host name of the WHOIS [RFC3912] server where the object instance may be found. The following is an example of a JSON object representing a forward DNS delegation point or the DNR domain object class. { Newton & Hollenbeck Expires July 7, 2013 [Page 24] Internet-Draft RDAP JSON RESPONSES January 2013 "handle" : "XXXX", "name" : "blah.example.com", "variants" : [ { "relation" : [ "registered", "conjoined" ], "variantNames" : [ "blah2.example.com", "blah3.example.com" ] }, { "relation" : [ "unregistered", "restrictedRegistration" ], "variantNames" : [ "blah3.example.com", "blah4.example.com" ] } ], "status" : [ "locked", "transferProhibited" ], "nameServers" : [ { "handle" : "XXXX", "name" : "ns1.example.com", "status" : [ "active" ], "ipAddresses" : [ "2001:db8::123", "2001:db8::124", "192.0.2.1", "192.0.2.2" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/nameserver/XXXX". "rel" : "self", "href" : "http://example.net/nameserver/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" }, { "handle" : "XXXX", "name" : "ns2.example.com", Newton & Hollenbeck Expires July 7, 2013 [Page 25] Internet-Draft RDAP JSON RESPONSES January 2013 "status" : [ "active" ], "ipAddresses" : [ "2001:db8::125", "2001:db8::126", "192.0.2.3", "192.0.2.4" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/nameserver/XXXX", "rel" : "self", "href" : "http://example.net/nameserver/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } ], "delegationKeys" : [ { "algorithm": 7, "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C", "digestType" : 1, "keyTag" : 53814 } ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value": "http://example.net/domain/XXXX", "rel" : "self", "href" : "http://example.net/domain/XXXX" } Newton & Hollenbeck Expires July 7, 2013 [Page 26] Internet-Draft RDAP JSON RESPONSES January 2013 ], "port43" : "whois.example.net", "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ", "expirationDate" : "2016-12-31T23:59:60Z", "transferDate" : "1990-12-31T23:59:60Z", "entities" : [ { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "status" : [ "validated", "locked" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", Newton & Hollenbeck Expires July 7, 2013 [Page 27] Internet-Draft RDAP JSON RESPONSES January 2013 "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } ] } Replace "entities" with: "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "status" : [ "validated", "locked" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } ] Newton & Hollenbeck Expires July 7, 2013 [Page 28] Internet-Draft RDAP JSON RESPONSES January 2013 10. The IP Network Object Class The IP Network object class models IP network registrations found in RIRs and is the expected response for the /ip query as defined by [I-D.ietf-weirds-rdap-query]. There is no equivalent object class for DNRs. The high level structure of the IP network object class consists of information about the network registration and entities related to the IP network (e.g. registrant information, contacts, etc...). The following is an elided example of the IP network object type showing the high level structure. { "handle" : "XXX", ... "entities" : [ ... ] } The following is an example of the JSON object for the network registration information { "handle" : "XXXX-RIR", "startAddress" : "2001:db8::0", "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", "ipVersion" : 6, "name": "NET-RTR-1", "description" : [ "A network used for routing" ], "type" : "DIRECT ALLOCATION", "country" : "AU", "parentHandle" : "YYYY-RIR", "status" : [ "allocated" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.ent/ip/2001:db8::/48", Newton & Hollenbeck Expires July 7, 2013 [Page 29] Internet-Draft RDAP JSON RESPONSES January 2013 "rel" : "self", "href" : "http://example.net/ip/2001:db8::/48" }, { "value" : "http://example.net/ip/2001:db8::/48", "rel" : "up", "href" : "http://example.net/ip/2001:C00::/23" } ], "registrationDate" : "20110509", "lastChangedDate" : "20110509", "lastChangedBy" : "joe@bob.com", "entities" : [ { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "roles" : [ "registrant" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", Newton & Hollenbeck Expires July 7, 2013 [Page 30] Internet-Draft RDAP JSON RESPONSES January 2013 "lastChangedBy" : "joe@bob.com" } ] } Replace "entities" with: "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrant" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] The following is a description of the members of this object: o handle -- a string representing an RIR unique identifier of the network registration o startAddress -- the starting IP address of the network, either IPv4 or IPv6 o endAddress -- the ending IP address of the network, either IPv4 or IPv6 o ipVersion -- an integer signifying the IP protocol version of the network: 4 signifying an IPv4 network, 6 signifying an IPv6 network o name -- an identifier assigned to the network registration by the registration holder o description -- an array of strings containing descriptive text about the network registration o type -- a string containing an RIR specific classification of the network o country -- a string containing the name of the 2 character country code of the network o parentHandle -- a string containing an RIR unique identifier of the parent network of this network registration o status -- an array of strings indicating the state of the IP network o entities -- an array of entity objects as defined by Section 7.1. The members "remarks", "links", "registrationDate", "lastChangedDate", and "lastChangedBy" take the same form of the members of the same name of the entity object (Section 7.1). Newton & Hollenbeck Expires July 7, 2013 [Page 31] Internet-Draft RDAP JSON RESPONSES January 2013 11. Autonomous System Number Entity Object Class The Autonomous System Number (autnum) object class models Autonomous System Number registrations found in RIRs and represents the expected response to an /autnum query as defined by [I-D.ietf-weirds-rdap-query]. There is no equivalent object class for DNRs. The high level structure of the autnum object class consists of information about the network registration and entities related to the autnum registration (e.g. registrant information, contacts, etc...), and is similar to the IP Network entity object class. The following is an example of a JSON object representing an autnum. { "handle" : "XXXX-RIR", "startAutnum" : "10", "endAutnum" : "15", "name": "AS-RTR-1", "description" : [ "AS for Exchange" ], "type" : "DIRECT ALLOCATION", "country": "AU", "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/autnum/xxxx", "rel" : "self", "href" : "http://example.net/autnum/xxxx" } ], "registrationDate" : "20110509", "lastChangedDate" : "20110509", "lastChangedBy" : "joe@bob.com", "entities" : [ { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "roles" : [ "registrant" ], "postalAddress" : [ "123 Maple Ave", Newton & Hollenbeck Expires July 7, 2013 [Page 32] Internet-Draft RDAP JSON RESPONSES January 2013 "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "self", "href" : "http://example.net/entity/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] } Replace "entities" with: "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrant" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "self", "href" : "http://example.net/entity/XXXX" } ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] The following is a description of the members of this object: o handle -- a string representing an RIR unique identifier of the autnum registration o startAutnum -- the starting number [RFC5396] in the block of autonomous system numbers o endAutnum -- the ending number [RFC5396] in the block of autonomous system numbers o name -- an identifier assigned to the autnum registration by the registration holder Newton & Hollenbeck Expires July 7, 2013 [Page 33] Internet-Draft RDAP JSON RESPONSES January 2013 o description -- an array of strings containing descriptive text about the autnum registration o type -- a string containing an RIR specific classification of the autnum o country -- a string containing the name of the 2 character country code of the autnum The members "remarks", "links", "registrationDate", "lastChangedDate", and "lastChangedBy" take the same form of the members of the same name of the entity object (Section 7.1). Newton & Hollenbeck Expires July 7, 2013 [Page 34] Internet-Draft RDAP JSON RESPONSES January 2013 12. Error Response Body Some non-answer responses may return entity bodies with information that could be more descriptive. The basic structure of that response is an object class containing an error code number (corresponding to the HTTP response code) followed by a string named "title" followed by an array of strings named "description". This is an example of the JSON version of the common response body. { "errorCode": 418, "title": "Your beverage choice is not available", "description": [ "I know coffee has more ummppphhh.", "But I cannot provide." ] } Figure 12 A client MAY simply use the HTTP response code as the server is not required to include error data in the response body. However, if a client wishes to parse the error data, it SHOULD first check that the Content-Type header contains the appropriate media type. Newton & Hollenbeck Expires July 7, 2013 [Page 35] Internet-Draft RDAP JSON RESPONSES January 2013 13. IANA Considerations This specification registers the "application/rdap" media type. Type name: application Subtype name: rdap Required parameters: n/a Encoding considerations: n/a Security considerations: n/a Interoperability considerations: n/a Published specification: [[ this document ]] Applications that use this media type: RDAP Additional information: n/a Person & email address to contact for further information: Andy Newton &andy@hxr.us& Intended usage: COMMON Restrictions on usage: none Author: Andy Newton Change controller: IETF Newton & Hollenbeck Expires July 7, 2013 [Page 36] Internet-Draft RDAP JSON RESPONSES January 2013 14. Internationalization Considerations 14.1. Character Encoding The default text encoding for JSON and XML responses in RDAP is UTF-8, and all servers and clients MUST support UTF-8. Servers and clients MAY optionally support other character encodings. Note that plain vCard (not jCard) only supports UTF-8. I don't think there's any implication here, but I'm mentioning it in case someone else thinks there might be. 14.2. URIs and IRIs [I-D.ietf-weirds-using-http] defines the use of URIs and IRIs in RDAP. 14.3. Language Tags Section 5.3 defines the use of language tags in the JSON responses defined in this document. 14.4. Internationalized Domain Names Appendix C illustrates the model for query and response regarding internationalized domain names (IDNs). Newton & Hollenbeck Expires July 7, 2013 [Page 37] Internet-Draft RDAP JSON RESPONSES January 2013 15. Contributing Authors and Acknowledgements This document is derived from original work on RIR response in JSON by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. Additionally, this document incorporates word on DNR responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean Shen of CNNIC. The components of the DNR object classes are derived from a categorization of WHOIS response formats created by Ning Kong, Linlin Zhou, and Guangqing Deng of CNNIC, Steve Sheng and Francisco Arias of ICANN, Ray Bellis of Nominet, and Frederico Neves of NIC.BR. Ed Lewis of Neustar contributed significant review comments and provided clarifying text. Newton & Hollenbeck Expires July 7, 2013 [Page 38] Internet-Draft RDAP JSON RESPONSES January 2013 16. References 16.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, December 2008. [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", Newton & Hollenbeck Expires July 7, 2013 [Page 39] Internet-Draft RDAP JSON RESPONSES January 2013 ISO Standard 3166, August 1988. [I-D.ietf-weirds-rdap-query] Newton, A. and S. Hollenbeck, "RDAP Query Format", draft-ietf-weirds-rdap-query-00 (work in progress), September 2011. [I-D.ietf-weirds-using-http] Newton, A., Ellacott, B., and N. Kong, "Using HTTP for RESTful Whois Services by Internet Registries", draft-ietf-weirds-using-http-01 (work in progress), May 2012. [E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. 16.2. Informative References [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004. [JSON_acendancy] MacVittie, "The Stealthy Ascendancy of JSON", 04 2011. [JSON_performance_study] Montana State University - Bozeman, Montana State University - Bozeman, Montana State University - Bozeman, and Montana State University - Bozeman, "Comparison of JSON and XML Data Interchange Formats: A Case Study", 2009. Newton & Hollenbeck Expires July 7, 2013 [Page 40] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix A. Suggested Values Due to the wide variation between the hundreds of registry operators and the on-going policy refinement by registry communities, values of some data cannot be formally standardized. This section lists suggested values for such data but is not nor will ever be a complete list of values and their meanings. A.1. Status Many of the object classes have a member named 'status'. This member is an array of strings, with each string denoting a status associated with the containing object. The following is a list of suggested values to use in the 'status' array: o 'validated' -- Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information. o 'update prohibited' -- Updates to the object instance are forbidden. o 'transfer prohibited' -- Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names. o 'delete prohibited' -- Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names. A.2. Roles Entity object classes have a member named 'roles'. This member is an array of strings, with each string indicating the role or relationship the entity object instance has with a containing object, such as a domain name or IP network. An entity object instance can have more than one type of relationship with a containing object. The following is a list of suggested values to use in the 'roles' array: o 'registrant' -- The entity object instance is the registrant of the registration. o 'tech' -- The entity object instance is a technical contact for the registration. Newton & Hollenbeck Expires July 7, 2013 [Page 41] Internet-Draft RDAP JSON RESPONSES January 2013 o 'admin' -- The entity object instance is an administrative contact for the registration. o 'abuse' -- The entity object instance handles network abuse issues on behalf of the registrant of the registration. o 'billing' -- The entity object instance handles payment and billing issues on behalf of the registrant of the registration. o 'registrar' -- The entity object instance represents the authority responsible for the registration in the registry. A.3. Variant Relations Section 9.2 describes a structure for noting variants of domain names and the relationship those variants have with a registered domain name. The following is a list of suggested values to use as the variant relation values: o 'registered' -- the variant names are registered in the registry. o 'unregistered' -- the variant names are not found in the registry. o 'restrictedRegistration' -- registration of the variant names is restricted to certain parties or within certain rules. o 'openRegistration' -- registration of the variant names is available to generally qualified registrants. o 'conjoined' -- registration of the variant names is conjoined with the registration of the containing domain registration. Newton & Hollenbeck Expires July 7, 2013 [Page 42] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix B. Suggested Data Modeling with the Entity Object Class B.1. Registrants and Contacts This document does not provide specific object classes for registrants and contacts. Instead the entity object class may be used to represent a registrant or contact. When the entity object is embedded inside a containing object such as a domain name or IP network, the 'roles' string array can be used to signify the relationship. It is recommended that the values from Appendix A.2 be used. The following is an example of an elided containing object with an embedded entity that is both a registrant and admin contact: { ... "entities" : [ { "handle" : "XXXX", "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "roles" : [ "registrant", "admin" ], "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } Newton & Hollenbeck Expires July 7, 2013 [Page 43] Internet-Draft RDAP JSON RESPONSES January 2013 ] } Replace with: { ... "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe Bob, Inc."], ["fn", {}, "text", "Bobby Joe Shopping"], ["label", {}, "text", "123 Maple Ave\n" "Suite 90001\n" "Vancouver\n" "BC\n" "1239\n"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrant", "admin" ], "remarks" : [ "she sells seas shells", "down by the seashore" ], "registrationDate" : "1990-12-31T23:59:60Z", "lastChangedDate" : "1990-12-31T23:59:60Z", "lastChangedBy" : "joe@bob.com" } ] } B.2. Registrars This document does not provide a specific object class for registrars, but like registrants and contacts (see Appendix B.1) the 'roles' string array maybe used. Newton & Hollenbeck Expires July 7, 2013 [Page 44] Internet-Draft RDAP JSON RESPONSES January 2013 The following is an example of an elided containing object with an embedded entity that is a registrar: { ... "entities" : [ { "handle" : "XXXX", "names": [ "RegistrarsRUS" ], "roles" : [ "registrar" ], "postalAddress" : [ "1212 Tulip Ave", "Suite 1", "Marina Del Rey", "CA", "12393-2193" ], "emails" : [ "joe@bob.com", "bob@joe.com" ], "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, "remarks" : [ "we registrar for less!" ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com" } ] } ] } Replace with: { ... "entities" : [ { "handle" : "XXXX", "vCard" : [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "RegistrarsRUS"], ["label", {}, "text", "1212 Tulip Ave\n" "Suite 1\n" "Marina Del Rey\n" "CA\n" "12393-2193"], ["email", {}, "text", "joe@bob.com"], ["email", {}, "text", "bob@joe.com"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4321"], ["tel", { "type": "work" }, "uri", "tel:+1-958-555-4322"], ["tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323"], ["tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324"], ], "roles" : [ "registrar" ], "remarks" : [ "we registrar for less!" ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com" } ] } ] } Newton & Hollenbeck Expires July 7, 2013 [Page 45] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix C. IDN Query and Response Model Internationalized Domain Names (IDNs) differ from other types of domain names because multiple domain names as would be represented by a name in Master File format (see [RFC4343]) may be registered by a single IDN. IDNs are based on Unicode, and Unicode can have multiple means for encoding the same word depending on the character set and language being used. And the rules for determining which IDN encoding maps to a "wire-format" domain name vary from DNR to DNR. When an IDN maps to multiple domain names, the various mappings are called variants. The DNR Domain object class (Section 9.2) represents the variants using a string array. The following is an example of an elided DNR domain object with variants. { "handle" : "XXXX", "name" : "blah.example.com", "variants" : [ "blah2.example.com", "blah3.example.com" ], ... } Because IDNs can have multiple targets in a mapping and due to the variance in DNR mapping rules, it is up to the client to reduce an IDN to a domain name in Master File format so as to narrow the lookup of the domain name to the proper subset. A query of a DNR using the IDN itself might map across multiple registrations depending on the mapping rules of the DNR. Newton & Hollenbeck Expires July 7, 2013 [Page 46] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix D. Postal Addresses vs Location The postal address data listed in the entity object class (Section 7) does not necessarily represent location. The intent of this information is to provide a means to send postal mail to an entity. While in some cases it may also be the location of the entity, there is no guarantee that the two are the same. Additionally, the postal address data represented in this document does not follow any specific standard for postal addresses because many registries do not keep postal address data in an internationalized standard form. Publication of such data in a format that suggests an internationalized standard form when such data is not known to be well-formed for that purpose would be misleading. I think this appendix can be deleted now. Newton & Hollenbeck Expires July 7, 2013 [Page 47] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix E. Motivations for Using JSON This section addresses a common question regarding the use of JSON over other data formats, most notably XML. It is often pointed out that many DNRs and one RIR support the EPP [RFC3730] standard, which is an XML serialized protocol. The logic is that since EPP is a common protocol in the industry it follows that XML would be a more natural choice. While EPP does enfluence this specification quite a bit, EPP serves a different purpose which is the provisioning of Internet resources between registries and accredited registrars and serves a much narrower audience than that envisioned for RDAP. By contrast, RDAP has a broader audience and is designed for public consumption of data. Experience from RIRs with first generation RESTful web services for Whois indicate a large percentage of clients operate within browsers and other platforms where full-blown XML stacks are not readily available and where JSON is a better fit. Additionally, while EPP is used in much of the DNR community it is not a unversial constant in that industry. And finally, EPP's use of XML predates the specification of JSON. If EPP had been defined today, it may very well have used JSON instead of XML. Beyond the specific DNR and RIR communities, the trend in the broader Internet industry is also switching to JSON over XML, especially in the area of RESTful web services (see [JSON_acendancy]). Studies have also found that JSON is generally less bulky and consequently faster to parse (see [JSON_performance_study]). Newton & Hollenbeck Expires July 7, 2013 [Page 48] Internet-Draft RDAP JSON RESPONSES January 2013 Appendix F. Changelog Initial -00 Adopted as working group document 2012-September-18. -01 Minor spelling corrections. Changed "Registry Data" to "Registration Data" for the sake of consistency. Transitioned to RFC 5988 links and relationshipt types from our own custom "uris" structure. Some examples had 'status' as a string. Those have been corrected as 'status' is always an array of strings. Domain variants can now have a multi-valued relationship with domain registrations. "names" in the entity object class was changed to "entityNames". Some IP address examples change to IPv6. Change phone number examples and added reference to E.164. Added section on motivations for using JSON. Added error response body section. Added JSON naming section. Added common data structures section. Added the IANA Considerations section and the media type registration. Added 'lang' name/value. Added internationalization considerations section. -02 Removed level from media type registration. Textual changes as given by Ed Lewis. Newton & Hollenbeck Expires July 7, 2013 [Page 49] Internet-Draft RDAP JSON RESPONSES January 2013 Fixed objectclass linking example noted by Francisco Obispo Fixed a lot of other examples called out by Alex Sergeyev Added a note that JSON names are case sensitive Added 'status' to IP networks as suggested by Alex Sergeyev Newton & Hollenbeck Expires July 7, 2013 [Page 50] Internet-Draft RDAP JSON RESPONSES January 2013 Authors' Addresses Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 US Email: andy@arin.net URI: http://www.arin.net Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Newton & Hollenbeck Expires July 7, 2013 [Page 51] --------------090607030806090409060405-- From simon.perreault@viagenie.ca Fri Mar 1 08:05:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3221F8CEB for ; Fri, 1 Mar 2013 08:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5vFtGhqKKLu for ; Fri, 1 Mar 2013 08:05:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 587D421F8CDA for ; Fri, 1 Mar 2013 08:05:02 -0800 (PST) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ACCAC403E7 for ; Fri, 1 Mar 2013 11:05:01 -0500 (EST) Message-ID: <5130D1AC.5010309@viagenie.ca> Date: Fri, 01 Mar 2013 17:05:00 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] Comments on redirects-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:05:03 -0000 I have two comments: Section "2.1. The REST Approach to Web Services" says: As WHOIS is a read-only service only the GET verb is implemented. [...] As all requests are to be performed employing HTTP GETs [...] --> Shouldn't HEAD also be supported? Section "2.4. Loops in Redirection" --> As previously discussed, I think this section should be removed entirely, or significantly shortened so as to simply refer to existing client-side mechanisms. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From steve.sheng@icann.org Fri Mar 1 08:17:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC721F922B for ; Fri, 1 Mar 2013 08:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.369 X-Spam-Level: X-Spam-Status: No, score=-4.369 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqTuTAatqozA for ; Fri, 1 Mar 2013 08:17:12 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8231921F9229 for ; Fri, 1 Mar 2013 08:17:12 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 1 Mar 2013 08:17:11 -0800 From: Steve Sheng To: "Murray S. Kucherawy" , John R Levine Date: Fri, 1 Mar 2013 08:17:12 -0800 Thread-Topic: [weirds] Preliminary agenda Thread-Index: Ac4WmDq/DL/I+PtmRli5gYkE/SGuMQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3444970632_1896404" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:17:13 -0000 --B_3444970632_1896404 Content-type: multipart/alternative; boundary="B_3444970632_1900229" --B_3444970632_1900229 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Murray, I can try to prepare a draft, but not certain I will be able to deliver in time for sufficient review. In the mean time, how about I produce a slide deck and send it to the WG. Then the chairs can decide whether there is useful enough contribution for a presentation. John and Peter, would that address your concern? Kind regards, Steve From: "Murray S. Kucherawy" Date: Thursday, February 28, 2013 2:46 PM To: John R Levine Cc: "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda > Also, having a document that the WG can review ahead of time would be really > helpful. Steve, could you produce such a thing? We're past the I-D deadline, > so sending it to the list is fine. > > > On Thu, Feb 28, 2013 at 2:34 PM, Murray S. Kucherawy > wrote: >> I haven't pinged Olaf for his opinion yet, but I imagine we can slot this >> into AOB rather than a dedicated slot. >> >> -MSK >> >> >> On Wed, Feb 27, 2013 at 8:52 PM, John R Levine wrote: >>>>> If this is important for WG participants to know, write it up as as an >>>>> I-D or at least if you have materials, send them around to the list. >>>> >>>> Actually, I'd like to hear it. Scott and I have been looking into I18N >>>> issues, especially as it relates to search, and we seem to have more >>>> questions than answers. If ICANN has answers, that would be valuable. >>> >>> I'm not disagreeing that it sounds interesting. But background >>> presentations are not what in-person WG meetings are for. I've played >>> junior chair enough already, if Olaf and Murray see it as an issue, I'm sure >>> they can handle it. >>> >>> R's, >>> John >>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >>> >> > --B_3444970632_1900229 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Thanks Murray, I can try to = prepare  a draft, but not certain I will be able to deliver in time for= sufficient review. 

In the mean time,  h= ow about I produce a slide deck and send it to the WG. Then the chairs can d= ecide whether there is useful enough contribution for a presentation. <= /div>

John and Peter, would that address your concern?&nb= sp;

Kind regards, 
Steve
<= br>
From: "Murray S. Kucherawy" <= ;superuser@gmail.com>
Date: Thursday, February 28, 2013 2:46 PMTo: John R Levine <johnl@taugh.com>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Preliminary agenda
Also,= having a document that the WG can review ahead of time would be really help= ful.  Steve, could you produce such a thing?  We're past the I-D d= eadline, so sending it to the list is fine.


On Thu, Feb 28, 2013 at 2:34 PM, Murray S= . Kucherawy <superuser@gmail.co= m> wrote:
I h= aven't pinged Olaf for his opinion yet, but I imagine we can slot this into = AOB rather than a dedicated slot.=

-MSK<= br>


On Wed, Feb 27, 2013 at 8:52 PM, Jo= hn R Levine <johnl@taugh.com>= ; wrote:
=
If this is important for WG participants to know, write it up as as an
I-D or at least if you have materials, send them around to the list.

Actually, I'd like to hear it. Scott and I have been looking into I18N
issues, especially as it relates to search, and we seem to have more
questions than answers. If ICANN has answers, that would be valuable.

I'm not disagreeing that it sounds interesting.  But background presen= tations are not what in-person WG meetings are for.  I've played junior= chair enough already, if Olaf and Murray see it as an issue, I'm sure they = can handle it.

R's,
John

_______________________________________________
weirds mailing list
wei= rds@ietf.org
https://www.ietf.org/mailman/listinfo/weirds


 --B_3444970632_1900229-- --B_3444970632_1896404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFJuVj18s7nCq1IqqQYVlSx2l7DBBMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwMTE2MTcxMlowDQYJ KoZIhvcNAQEBBQAEggEAssdgv5i3J2JCDzDCwppaBfEPihQAno+pIXmlpd3s789kosoXZxvV DXc8LDDxmNJI8kY8V+QR58x+wbPcGALdEKcQDMrdNnQiYsiYdquLfYKh6ziMmT+zys8nai/d bt46rVaBpobn3HY21X1QUojezkp7t9fS/6uLAbOqnKqhChxL4R11XS7GulXkv/9RtMUl3qYd WSuNr8A6P32AadMA2c88+0XQXZhuGCyVs/cbTO1N731d6vDze/b3KtQN7KQHc9H0tdqkPw72 zuCGQe8FcBr7VSRRdmeCph6aAYOkLuwxl9FrEFUgyR0xOtKiQMfYdparWkY3q1XkVNpmdx2f jQ== --B_3444970632_1896404-- From johnl@iecc.com Fri Mar 1 08:20:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FB21F938B for ; Fri, 1 Mar 2013 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.092 X-Spam-Level: X-Spam-Status: No, score=-111.092 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NKnCyjpl9Ex for ; Fri, 1 Mar 2013 08:20:43 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF1921F9386 for ; Fri, 1 Mar 2013 08:20:43 -0800 (PST) Received: (qmail 15065 invoked from network); 1 Mar 2013 16:20:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Mar 2013 16:20:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5130d55a.xn--hew.k1303; i=johnl@user.iecc.com; bh=oJc52ElTMqfR738BHiUkCogQ+6xiDNAoDRWQWj5i428=; b=xo/SwjeT64jypNkiazUfdXeWf95BFaEF3fNDHw+PhnyRuqNgjJ98eQ+tXsyBdWiNrSZC9rtsXwWfNAqUnojTuGihr9poVxmgJ11eDVI1QcwTYV7F4Zt7EzpK2dBJwo0y+YVZiVM4iqYC+lMX9ObCQSVc5HahTNOfWiwAygJv0pE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5130d55a.xn--hew.k1303; olt=johnl@user.iecc.com; bh=oJc52ElTMqfR738BHiUkCogQ+6xiDNAoDRWQWj5i428=; b=Ju6nbD+mt5LgM8OPRXpE+f/n27cK4w9Jr/8MLskP1PvnGx948avA9za6tIKwO27FvzlPSVO1Hr6y8z538MM7x4LdRK0DQ3mokJZcdWLiZ1Mb11LvaC5goAckKNZmney95sJ6a44PKaF+oDrDN5hsE5GmvP/bhKJfiutYHjfo+Z0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Mar 2013 16:20:20 -0000 Message-ID: <20130301162020.73313.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Preliminary agenda X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:20:44 -0000 >In the mean time, how about I produce a slide deck and send it to the WG. >Then the chairs can decide whether there is useful enough contribution for a >presentation. > >John and Peter, would that address your concern? Yes. In case there's any misunderstanding, I don't doubt that the ICANN i18n work is interesting and probably relevant. But if it's not part of the process of turning I-Ds into RFCs, it's not what a WG meeting is for. From superuser@gmail.com Fri Mar 1 10:19:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB821F934D for ; Fri, 1 Mar 2013 10:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnAPy+w8Ef3H for ; Fri, 1 Mar 2013 10:19:34 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 880E621F9339 for ; Fri, 1 Mar 2013 10:19:19 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so2685263wge.10 for ; Fri, 01 Mar 2013 10:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EqiabRhxy77Z4GohPYaflLWazEfXpKp68ou8QNgmpRo=; b=SubQ9pddBzE+lBBET+mIzZy50gsKVP/5A5rXExgFQWH85vOSKVuUTpTMRyHgylL6QF QAgGN0aEBoOnLSKT/6C1i8NCRS6ZPbQJCdiB/tcGeWEvTxUtrT8qz+4R555D/Q/1MRW0 SQSAOxaiwnAcnVT/cVlBBR/B1/mcLFHiX+SNrKBMGW9R/Xf0gjRVlXoaBBfzufatNJ91 wJEIiFAMmAHtUVzxKrVwUxg58oW4lJBJjs/0Rhe/ywvx/Pbdb0ckzo00n+GI63IkhVLh 5YepGLNi33VO7TDukwmJ5HJNq5hxcNuvs7xZcB4O3dL6HFUs0SSIHO1z2jxFxDWeXyF0 PqGg== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr19288773wjq.51.1362161958739; Fri, 01 Mar 2013 10:19:18 -0800 (PST) Received: by 10.180.163.70 with HTTP; Fri, 1 Mar 2013 10:19:18 -0800 (PST) In-Reply-To: <20130301162020.73313.qmail@joyce.lan> References: <20130301162020.73313.qmail@joyce.lan> Date: Fri, 1 Mar 2013 10:19:18 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7b86cea4ad6b8604d6e10bdb Cc: "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:19:36 -0000 --047d7b86cea4ad6b8604d6e10bdb Content-Type: text/plain; charset=ISO-8859-1 While generally I agree, I'm not quite as strict as how that was stated. I-D development is the priority, to be sure, but not to the point of exclusion of all else. Since we haven't completely filled the agenda with I-D work, I don't mind assigning some time at the end to material like this. I certainly think it's likely to be information we should be aware of as we develop our I18N solutions. Steve, yes, it would be ideal if you had something you could circulate to the WG beforehand so we're prepared to use the time well. We're past the point of being able to submit a new draft, and I'm not sure that's the right path for what you want to talk about anyway, so sending some material to the list prior to our meeting on the 12th would be dandy. -MSK, co-chairin' On Fri, Mar 1, 2013 at 8:20 AM, John Levine wrote: > >In the mean time, how about I produce a slide deck and send it to the WG. > >Then the chairs can decide whether there is useful enough contribution > for a > >presentation. > > > >John and Peter, would that address your concern? > > Yes. In case there's any misunderstanding, I don't doubt that the > ICANN i18n work is interesting and probably relevant. But if it's not > part of the process of turning I-Ds into RFCs, it's not what a WG > meeting is for. > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b86cea4ad6b8604d6e10bdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While generally I agree, I'm not quite as strict = as how that was stated.=A0 I-D development is the priority, to be sure, but= not to the point of exclusion of all else.

Since we haven't com= pletely filled the agenda with I-D work, I don't mind assigning some ti= me at the end to material like this.=A0 I certainly think it's likely t= o be information we should be aware of as we develop our I18N solutions.
Steve, yes, it would be ideal if you had something you could= circulate to the WG beforehand so we're prepared to use the time well.= =A0 We're past the point of being able to submit a new draft, and I'= ;m not sure that's the right path for what you want to talk about anywa= y, so sending some material to the list prior to our meeting on the 12th wo= uld be dandy.

-MSK, co-chairin'


On Fri, Mar 1, 2013 at 8:20 AM, John= Levine <johnl@taugh.com> wrote:
>In the mean time, =A0h= ow about I produce a slide deck and send it to the WG.
>Then the chairs can decide whether there is useful enough contribution = for a
>presentation.
>
>John and Peter, would that address your concern?

Yes. =A0In case there's any misunderstanding, I don't doubt t= hat the
ICANN i18n work is interesting and probably relevant. =A0But if it's no= t
part of the process of turning I-Ds into RFCs, it's not what a WG
meeting is for.


_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--047d7b86cea4ad6b8604d6e10bdb-- From superuser@gmail.com Fri Mar 1 10:21:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7221C21F8FA9 for ; Fri, 1 Mar 2013 10:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c2iizizEKlp for ; Fri, 1 Mar 2013 10:21:39 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C801421F8F3A for ; Fri, 1 Mar 2013 10:21:38 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so2824313wey.0 for ; Fri, 01 Mar 2013 10:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=MW9BaX2K7q/snXTQMpcengQ35ON25Zo14kQn6JNiGcI=; b=SqdwDw0Mx5aT5IE2utsv9llVMLkBfI7PHrDyWl99j+Yyt+0bunu5ZclBUGd8903W7O m9/uLHzfYRr8W9jmNc+ZaMcl1veYNRtTCCJ9l7R3wmaHCKGse6kpnKvX8ebu8W1yxW5o 3fZkVTCl1r/Bln0U5aCZYH0C8xBkfniR3g9OtOrEcl1B2yUPjgih+7z9fbbtjnmqToAh AV/q9F4CULNsKPmdX+/FFcMCBwuM8OAdGpCdUdb61R2oR9KYzL+PdnvgMdCct4F5k64p 9TwI8AXTDSOMh/fuZ2ZIoYpN3tApzI71VfmKWyWucxw0euCbfk3UEVoRQsIk9gyyl9ZG RWtw== MIME-Version: 1.0 X-Received: by 10.180.86.136 with SMTP id p8mr5637554wiz.21.1362162097792; Fri, 01 Mar 2013 10:21:37 -0800 (PST) Received: by 10.180.163.70 with HTTP; Fri, 1 Mar 2013 10:21:37 -0800 (PST) Date: Fri, 1 Mar 2013 10:21:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d044286cef7301d04d6e1135a Subject: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:21:39 -0000 --f46d044286cef7301d04d6e1135a Content-Type: text/plain; charset=ISO-8859-1 The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room Boca 1 for implementation demos. We only have that one hour before other sessions begin, so please come prepared! -MSK --f46d044286cef7301d04d6e1135a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The Secretariat has assigned us 8am-9am on Tuesday, M= arch 12, in room Boca 1 for implementation demos.=A0 We only have that one = hour before other sessions begin, so please come prepared!

-MS= K
--f46d044286cef7301d04d6e1135a-- From carlosm3011@gmail.com Fri Mar 1 10:30:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F5921F8F41 for ; Fri, 1 Mar 2013 10:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWJ7p82M4Kaj for ; Fri, 1 Mar 2013 10:30:20 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 91B4221F8ED8 for ; Fri, 1 Mar 2013 10:30:17 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id q12so494546yhf.7 for ; Fri, 01 Mar 2013 10:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LIy8aoZfgMWTi4q+SgXANu7rVB9Nh5hBeUXlrwjIT14=; b=opIJlw93aikAUtb+K5owr4JRdHUgwS98DKc2ULFZAYP2JJkMJa/wOnPr0A7vDgYwa3 0jwtMhxAKGSu8WgEGrKQupTLbLwiwlnyBZE7OXvWsJz5jZo7Wj5Kt+YJyHhg/KZYg/BD f30ExBYc7z9DA++Z0rfO9sV1QagEt/QuHau7a68CuAesFOwlbkaxuQ6xn1q38ACm186J ri4UhSf7V5i/m4OYC3c0zpfHVBgKeWO420o5FY0Kh6QbnZCmdIFc9LBhZgHvu2gQTJTE OP+ghHlL2n9DqdBhazHX0i0X1XEG2FGnpSa78Kot38tjIRBxdIAc4NUm9q5fTXHuJf+A CF/w== X-Received: by 10.236.193.102 with SMTP id j66mr7871736yhn.195.1362162614119; Fri, 01 Mar 2013 10:30:14 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:5128:c17d:6ecc:698d:1162? ([2001:13c7:7001:5128:c17d:6ecc:698d:1162]) by mx.google.com with ESMTPS id w7sm20314216yhj.0.2013.03.01.10.30.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 10:30:12 -0800 (PST) Message-ID: <5130F3B1.4080909@gmail.com> Date: Fri, 01 Mar 2013 16:30:09 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:30:21 -0000 Unless we write a detailed plan of what we are going to do, I don't think it will be enough. In any case, I think we can continue in the term room. Or in the hallways :D regards Carlos On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room > Boca 1 for implementation demos. We only have that one hour before > other sessions begin, so please come prepared! > > -MSK > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From superuser@gmail.com Fri Mar 1 11:51:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4921F8A53 for ; Fri, 1 Mar 2013 11:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7I3MBojA3TT for ; Fri, 1 Mar 2013 11:51:41 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 21D8521F8A4E for ; Fri, 1 Mar 2013 11:51:39 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so9549056wie.2 for ; Fri, 01 Mar 2013 11:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gMmPBr8CF1K3HcB6i/24hioHXOdF0/cyIqFaN9VgBGs=; b=DAKM6oWYe/axifr7Gz5qzkeH3EGUokVMjhuqBSVdVulHWLxJAb2FR2T+ahVRWWZGKt vivPzjeww1GIQz2GcAMdPjlBQkesbNLHy/RUmk46WZwLil+C9H0GEahuQHGT3Djbw9DO 1ENMSox4hoJTyNMNjf7JRA73mznkRkAzRjHZy6quW0i3a+1UokEsktxz6HqaQx89vrJC BUa2jgCVYzKSuph37S7vR8XLxUCQCigkJYTkkHhH3YinwYirezp1gzUuYLPf5lIpXaFz JBoH4uswqPH1MvTn3SCHosX9ReRzQhONOQu5PXkvdl+suK1N05XDocuRreDhc7F+GnVv 1Nwg== MIME-Version: 1.0 X-Received: by 10.180.93.168 with SMTP id cv8mr5994192wib.5.1362167499365; Fri, 01 Mar 2013 11:51:39 -0800 (PST) Received: by 10.180.163.70 with HTTP; Fri, 1 Mar 2013 11:51:39 -0800 (PST) In-Reply-To: <5130F3B1.4080909@gmail.com> References: <5130F3B1.4080909@gmail.com> Date: Fri, 1 Mar 2013 11:51:39 -0800 Message-ID: From: "Murray S. Kucherawy" To: Carlos Martinez Content-Type: multipart/alternative; boundary=f46d043c7fbaeca64804d6e25561 Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:51:42 -0000 --f46d043c7fbaeca64804d6e25561 Content-Type: text/plain; charset=ISO-8859-1 Do we have a lot of people planning to do demos? Are the demos going to be complicated? I don't understand how an hour would not be enough, unless there's a large number of implementations I haven't heard of yet. Who's got something to show (or will by then), and how long do you need? -MSK On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez wrote: > Unless we write a detailed plan of what we are going to do, I don't > think it will be enough. > > In any case, I think we can continue in the term room. Or in the hallways > :D > > regards > > Carlos > > On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room > > Boca 1 for implementation demos. We only have that one hour before > > other sessions begin, so please come prepared! > > > > -MSK > > > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > --f46d043c7fbaeca64804d6e25561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do we have a lot of people planning to do demos?=A0 A= re the demos going to be complicated?

I don't underst= and how an hour would not be enough, unless there's a large number of i= mplementations I haven't heard of yet.

Who's got something to show (or will by then), and how l= ong do you need?

-MSK

=
On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. M= artinez <carlosm3011@gmail.com> wrote:
Unless we write a detailed plan of what we a= re going to do, I don't
think it will be enough.

In any case, I think we can continue in the term room. Or in the hallways := D

regards

Carlos

On 3/1/13 4:21 PM, Murray S. Kucherawy wrote:
> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room<= br> > Boca 1 for implementation demos. =A0We only have that one hour before<= br> > other sessions begin, so please come prepared!
>
> -MSK
>
>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>

--f46d043c7fbaeca64804d6e25561-- From carlosm3011@gmail.com Fri Mar 1 11:59:19 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB921F8B81 for ; Fri, 1 Mar 2013 11:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-2hUqT4aHMz for ; Fri, 1 Mar 2013 11:59:19 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 14CDC21F8B77 for ; Fri, 1 Mar 2013 11:59:19 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id 24so518128yhr.18 for ; Fri, 01 Mar 2013 11:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o/pQux3Zl+d6eCR/JSFuvUPEyGYRT5CL7LQMF0gGTPs=; b=bh+L7bguhN1bylgF5AmjzwDuCjyzEJrfDQ2jVkiRl1+mk7p8rAqz+N9G7fuX7RGZ8h 82mfcbXTuoaO+Nsv8rh+BwJ2PO4BfDWnrSeddJE2A5lzWyQ/UnlhLcCroBAQ4kvH9PK4 6kAykP1bf/TKTq4Uj0JO08fueWqQ1MR/CdIuLLJiuLOKNGiJRk8FL8gBq5nkURL6sQd4 lAwTbGuvDxvbWPu336ISjzAV1Kzjk6iU2rysN/XsXsyA51y65nv6BaRD4aFQVEY9aRwi WBc7rK+C+5Ris3ulnpuCcrnLZUxY1x8yOxymluOq+o++tsgRy2kYn7LtiJZNR2U7eGpi nIpw== X-Received: by 10.236.159.229 with SMTP id s65mr8109557yhk.159.1362167958636; Fri, 01 Mar 2013 11:59:18 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:5128:c17d:6ecc:698d:1162? ([2001:13c7:7001:5128:c17d:6ecc:698d:1162]) by mx.google.com with ESMTPS id s34sm20736039yhe.9.2013.03.01.11.59.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 11:59:17 -0800 (PST) Message-ID: <51310890.5030208@gmail.com> Date: Fri, 01 Mar 2013 17:59:12 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5130F3B1.4080909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:59:19 -0000 You're absolutely right. Depends on how many we are. Starting the roll call: We'll be presenting our server implementation. ~C. On 3/1/13 5:51 PM, Murray S. Kucherawy wrote: > Do we have a lot of people planning to do demos? Are the demos going to > be complicated? > > I don't understand how an hour would not be enough, unless there's a > large number of implementations I haven't heard of yet. > > Who's got something to show (or will by then), and how long do you need? > > -MSK > > > On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > > wrote: > > Unless we write a detailed plan of what we are going to do, I don't > think it will be enough. > > In any case, I think we can continue in the term room. Or in the > hallways :D > > regards > > Carlos > > On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room > > Boca 1 for implementation demos. We only have that one hour before > > other sessions begin, so please come prepared! > > > > -MSK > > > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From shollenbeck@verisign.com Mon Mar 4 07:58:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4DB21F8A54 for ; Mon, 4 Mar 2013 07:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZxlvKo-DdE6 for ; Mon, 4 Mar 2013 07:58:17 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 0811E21F89EF for ; Mon, 4 Mar 2013 07:58:11 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUTTEjtpX8PcgSFaKNjOMKC4N9ecsBMvL@postini.com; Mon, 04 Mar 2013 07:58:17 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r24Fw27m027451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 10:58:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Mar 2013 10:58:02 -0500 From: "Hollenbeck, Scott" To: Andy Newton , Marc Blanchet Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: AQHOET0PFQ20NbuCSUaNrOSM0jodlpiMBPoAgAFMK4CAABfygIAIVfzg Date: Mon, 4 Mar 2013 15:58:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24327A6C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF80F@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF80F@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:58:18 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Andy Newton > Sent: Tuesday, February 26, 2013 10:38 PM > To: Marc Blanchet > Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org > Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >=20 > On 2/27/13 10:12 AM, "Marc Blanchet" wrote: >=20 > >minor comment. you may ignore it. one ref could be > >wikipedia:http://en.wikipedia.org/wiki/Representational_state_transfer >=20 > Marc, >=20 > Let me think about this. We had a somewhat amusing discussion on this > list over this very topic without much of a conclusion. I don't like the idea of including a reference to a Wikipedia document that= can changed by anyone, but don't mind adding text that explains the REST a= cronym and attempts to explain RESTful in generic terms. Scott From marc.blanchet@viagenie.ca Mon Mar 4 08:04:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD1121F86C9 for ; Mon, 4 Mar 2013 08:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV27Ot9OufKf for ; Mon, 4 Mar 2013 08:04:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6021F8634 for ; Mon, 4 Mar 2013 08:04:13 -0800 (PST) Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7AA0740436; Mon, 4 Mar 2013 11:04:12 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24327A6C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 4 Mar 2013 11:04:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF03D50-5EE5-4F9E-9D65-00979456110D@viagenie.ca> References: <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF80F@CHAXCH01.corp.arin.net> <831693C2CDA2E849A7D7A712B24E257F24327A6C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:04:14 -0000 Le 2013-03-04 =E0 10:58, "Hollenbeck, Scott" = a =E9crit : >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Andy Newton >> Sent: Tuesday, February 26, 2013 10:38 PM >> To: Marc Blanchet >> Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org >> Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >>=20 >> On 2/27/13 10:12 AM, "Marc Blanchet" = wrote: >>=20 >>> minor comment. you may ignore it. one ref could be >>> = wikipedia:http://en.wikipedia.org/wiki/Representational_state_transfer >>=20 >> Marc, >>=20 >> Let me think about this. We had a somewhat amusing discussion on this >> list over this very topic without much of a conclusion. >=20 > I don't like the idea of including a reference to a Wikipedia document = that can changed by anyone, but don't mind adding text that explains the = REST acronym and attempts to explain RESTful in generic terms. My comment is minor. However, given that the whole document is based on = the RESTful assumption, then it would be good to have something. You are = right that wikipedia is a moving target. Maybe Fielding thesis/paper?=20= Since we are really using the RESTful approach in many of our protocols, = it may be time for the apps area to write something about it and have it = everybody referenced. I've been trying to find this with no luck yet. Marc. >=20 > Scott From steve.sheng@icann.org Mon Mar 4 08:12:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD8221F85F5 for ; Mon, 4 Mar 2013 08:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBLZS1mj1oBr for ; Mon, 4 Mar 2013 08:12:17 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05F21F85A1 for ; Mon, 4 Mar 2013 08:12:17 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 4 Mar 2013 08:12:16 -0800 From: Steve Sheng To: "Hollenbeck, Scott" , Andy Newton , Marc Blanchet Date: Mon, 4 Mar 2013 08:12:27 -0800 Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: Ac4Y8wmgocHsWw7ITUuTuOMMMrvHvw== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24327A6C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3445229547_2446898" MIME-Version: 1.0 Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:12:21 -0000 --B_3445229547_2446898 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit -----Original Message----- From: , Scott Date: Monday, March 4, 2013 7:58 AM To: Andy Newton , Marc Blanchet Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Andy Newton >> Sent: Tuesday, February 26, 2013 10:38 PM >> To: Marc Blanchet >> Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org >> Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >> >> On 2/27/13 10:12 AM, "Marc Blanchet" wrote: >> >> >minor comment. you may ignore it. one ref could be >> >wikipedia:http://en.wikipedia.org/wiki/Representational_state_transfer >> >> Marc, >> >> Let me think about this. We had a somewhat amusing discussion on this >> list over this very topic without much of a conclusion. > >I don't like the idea of including a reference to a Wikipedia document >that can changed by anyone, but don't mind adding text that explains the >REST acronym and attempts to explain RESTful in generic terms. How about this? [REST] Fielding, R. and R. Taylor, "Principled Design of the Modern Web Architecture", ACM Transactions on Internet Technology Vol. 2, No. 2, May 2002. This is the paper that Roy Fielding introduces the REST architectural style. > >Scott >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds --B_3445229547_2446898 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFIbiXTajJeCaNxDtK6gSAX3DnoREMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwNDE2MTIyN1owDQYJ KoZIhvcNAQEBBQAEggEAmgykAz0vKvqKW4zdksxZSlMlRm7NpNqL82yogS3BqVswq4uWWUW6 uYGPNv29ClZvEo2vyO930qKrCb5FEWUx7P6TzChshGwvLkIU1kCmjPyyvEURHtwvU0JdKtLB S8QBNvF/iyO23qLVraOoNiboJhfBODr+ZPJPHOBb/5bT1JbnRP7+wOS/AVVK2LOlR9ER5cgL 8ENjPfO1mlrDwQeCOG876dCYX1BPaAuG/AuZa0v3BnsAoV9TiDC8XSAxjWNZdzdmr6/JF3W3 sBE9E87du5yHfc5ccOgp7bt8Ll1u/0hXKeIaiWe0VSzFf+Xn/pl+hb8OLhfthuwteOWwYKkH Ag== --B_3445229547_2446898-- From shollenbeck@verisign.com Mon Mar 4 08:12:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AA21F84FF for ; Mon, 4 Mar 2013 08:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckCLyzHw70hS for ; Mon, 4 Mar 2013 08:12:55 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 420C821F84E8 for ; Mon, 4 Mar 2013 08:12:51 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUTTIAIMMRjybw7ZNW8wA8sVZEiv3CKLk@postini.com; Mon, 04 Mar 2013 08:12:55 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r24GClES027972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 11:12:47 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Mar 2013 11:12:47 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: AQHOET0PFQ20NbuCSUaNrOSM0jodlpiMBPoAgAFMK4CAABfygIAIVfzggABWFYD//656QA== Date: Mon, 4 Mar 2013 16:12:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24327A8D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF80F@CHAXCH01.corp.arin.net> <831693C2CDA2E849A7D7A712B24E257F24327A6C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6AF03D50-5EE5-4F9E-9D65-00979456110D@viagenie.ca> In-Reply-To: <6AF03D50-5EE5-4F9E-9D65-00979456110D@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:12:56 -0000 > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Sent: Monday, March 04, 2013 11:04 AM > To: Hollenbeck, Scott > Cc: Andy Newton; weirds@ietf.org; draft-ietf-weirds-rdap- > query@tools.ietf.org > Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >=20 >=20 > Le 2013-03-04 =E0 10:58, "Hollenbeck, Scott" a > =E9crit : >=20 > >> -----Original Message----- > >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > >> Behalf Of Andy Newton > >> Sent: Tuesday, February 26, 2013 10:38 PM > >> To: Marc Blanchet > >> Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org > >> Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap- > query > >> > >> On 2/27/13 10:12 AM, "Marc Blanchet" > wrote: > >> > >>> minor comment. you may ignore it. one ref could be > >>> > wikipedia:http://en.wikipedia.org/wiki/Representational_state_transf > >>> er > >> > >> Marc, > >> > >> Let me think about this. We had a somewhat amusing discussion on > this > >> list over this very topic without much of a conclusion. > > > > I don't like the idea of including a reference to a Wikipedia > document that can changed by anyone, but don't mind adding text that > explains the REST acronym and attempts to explain RESTful in generic > terms. >=20 > My comment is minor. However, given that the whole document is based on > the RESTful assumption, then it would be good to have something. You > are right that wikipedia is a moving target. Maybe Fielding > thesis/paper? That's exactly what I'm looking at right now... Scott From shollenbeck@verisign.com Mon Mar 4 09:15:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAABC21F851F for ; Mon, 4 Mar 2013 09:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qp3ffVYA7i1 for ; Mon, 4 Mar 2013 09:15:43 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id D615C21F8A98 for ; Mon, 4 Mar 2013 09:15:40 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUTTWuQ5XG4UUeqfwZq9MECC9wyyG6IDA@postini.com; Mon, 04 Mar 2013 09:15:42 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r24HFX5f002157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 12:15:33 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Mar 2013 12:15:33 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet , Andy Newton Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: AQHOET0PFQ20NbuCSUaNrOSM0jodlpiMBPoAgAFMK4CACIOuUA== Date: Mon, 4 Mar 2013 17:15:32 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24327B25@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF388@CHAXCH01.corp.arin.net> <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> In-Reply-To: <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:15:44 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Tuesday, February 26, 2013 9:13 PM > To: Andy Newton > Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org > Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >=20 >=20 > Le 2013-02-26 =E0 01:23, Andy Newton a =E9crit : [snip] > >> If we are going to have multiple queries specified in multiple > >> RFCs, we may better setup an IANA registry for > these, so they are > >> all listed in the same place. Moreover, different from > >> draft-ief-weirds-using-http, I think we > should not only register > >> extensions, but all defined queries, therefore the ones in this > >> document. And this document should be the creator of the registry. > >> Here is a suggested > >> contribution: > > > > The IANA registry specified in draft-ietf-weirds-using-http is used > by > > draft-ietf-weirds-rdap-query and draft-ietf-weirds-json-response. > > Moving it to rdap-query doesn't really help that dependency. >=20 > I don't really care about which document creates the registry. I just > found more natural to be in the one that defines the semantics. >=20 > > > > While registering the IETF specified queries is doable, >=20 > I think we should. >=20 > > do we conversely > > register the IETF specified JSON names? That would be a big > registration. >=20 > good question. Let me think about it. Have you reached any conclusions, Marc? Scott From marc.blanchet@viagenie.ca Mon Mar 4 09:18:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9760D21F8CEF for ; Mon, 4 Mar 2013 09:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd2lZodVE1eV for ; Mon, 4 Mar 2013 09:18:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 170EB21F8CEE for ; Mon, 4 Mar 2013 09:18:02 -0800 (PST) Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5442E40167; Mon, 4 Mar 2013 12:18:01 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24327B25@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 4 Mar 2013 12:18:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF388@CHAXCH01.corp.arin.net> <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F24327B25@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" , "draft-ietf-weirds-rdap-query@tools.ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:18:02 -0000 Le 2013-03-04 =E0 12:15, "Hollenbeck, Scott" = a =E9crit : >=20 >=20 >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Marc Blanchet >> Sent: Tuesday, February 26, 2013 9:13 PM >> To: Andy Newton >> Cc: weirds@ietf.org; draft-ietf-weirds-rdap-query@tools.ietf.org >> Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-query >>=20 >>=20 >> Le 2013-02-26 =E0 01:23, Andy Newton a =E9crit : >=20 > [snip] >=20 >>>> If we are going to have multiple queries specified in multiple >>>> RFCs, we may better setup an IANA registry for > these, so they are >>>> all listed in the same place. Moreover, different from >>>> draft-ief-weirds-using-http, I think we > should not only register >>>> extensions, but all defined queries, therefore the ones in this >>>> document. And this document should be the creator of the registry. >>>> Here is a suggested >>>> contribution: >>>=20 >>> The IANA registry specified in draft-ietf-weirds-using-http is used >> by >>> draft-ietf-weirds-rdap-query and draft-ietf-weirds-json-response. >>> Moving it to rdap-query doesn't really help that dependency. >>=20 >> I don't really care about which document creates the registry. I just >> found more natural to be in the one that defines the semantics. >>=20 >>>=20 >>> While registering the IETF specified queries is doable, >>=20 >> I think we should. >>=20 >>> do we conversely >>> register the IETF specified JSON names? That would be a big >> registration. >>=20 >> good question. Let me think about it. >=20 > Have you reached any conclusions, Marc? sorry. have not taken the time. don't wait for me... Marc. >=20 > Scott From bje@apnic.net Mon Mar 4 21:29:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6657321F871D for ; Mon, 4 Mar 2013 21:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJiNPBGekFNg for ; Mon, 4 Mar 2013 21:29:28 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 3D2AB21F874F for ; Mon, 4 Mar 2013 21:29:27 -0800 (PST) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 5 Mar 2013 15:28:50 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 5 Mar 2013 15:29:23 +1000 Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Tue, 5 Mar 2013 15:29:22 +1000 From: Byron Ellacott To: "carlos@lacnic.net" , "Murray S. Kucherawy" Thread-Topic: [weirds] WEIRDS implementation demo Thread-Index: AQHOFqmgIFUbuPReoECjeC7clURQO5iQgKSAgAAWxYCAAAIcAIAF/e0A Date: Tue, 5 Mar 2013 05:29:22 +0000 Message-ID: In-Reply-To: <51310890.5030208@gmail.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:29:29 -0000 Hi all, APNIC's pilot server is now several revisions behind the drafts, but I'm happy to volunteer (someone else from APNIC :-) to be there to show it working in its current state. http://rdap.apnic.net/ip/ Byron On 2/03/13 5:59 AM, "Carlos M. Martinez" wrote: >You're absolutely right. Depends on how many we are. > >Starting the roll call: We'll be presenting our server implementation. > >~C. > >On 3/1/13 5:51 PM, Murray S. Kucherawy wrote: >> Do we have a lot of people planning to do demos? Are the demos going to >> be complicated? >>=20 >> I don't understand how an hour would not be enough, unless there's a >> large number of implementations I haven't heard of yet. >>=20 >> Who's got something to show (or will by then), and how long do you need? >>=20 >> -MSK >>=20 >>=20 >> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez >> > wrote: >>=20 >> Unless we write a detailed plan of what we are going to do, I don't >> think it will be enough. >>=20 >> In any case, I think we can continue in the term room. Or in the >> hallways :D >>=20 >> regards >>=20 >> Carlos >>=20 >> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: >> > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >>room >> > Boca 1 for implementation demos. We only have that one hour >>before >> > other sessions begin, so please come prepared! >> > >> > -MSK >> > >> > >> > _______________________________________________ >> > weirds mailing list >> > weirds@ietf.org >> > https://www.ietf.org/mailman/listinfo/weirds >> > >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From alexander.mayrhofer@nic.at Tue Mar 5 01:27:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ABE21F86F8 for ; Tue, 5 Mar 2013 01:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUaDXxbh2NhG for ; Tue, 5 Mar 2013 01:27:28 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9821F853D for ; Tue, 5 Mar 2013 01:27:26 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Tue, 5 Mar 2013 10:27:24 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Tue, 5 Mar 2013 10:27:20 +0100 From: Alexander Mayrhofer To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Comments on redirects-01 Thread-Index: AQHOFpacH4plgr0MTUuAunTiOnMVuJiW2euw Date: Tue, 5 Mar 2013 09:27:19 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750981356A@NICS-EXCH.sbg.nic.at> References: <5130D1AC.5010309@viagenie.ca> In-Reply-To: <5130D1AC.5010309@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: Re: [weirds] Comments on redirects-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:27:28 -0000 > As all requests are to be performed employing HTTP GETs [...] >=20 > --> Shouldn't HEAD also be supported? [Alexander Mayrhofer]=20 And OPTIONS probably as well. Alex From james.mitchell@ausregistry.com.au Tue Mar 5 03:58:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E4821F88A0 for ; Tue, 5 Mar 2013 03:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuuliWCGvJNs for ; Tue, 5 Mar 2013 03:58:25 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3321F888C for ; Tue, 5 Mar 2013 03:58:14 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 05 Mar 2013 22:58:11 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 5 Mar 2013 22:58:05 +1100 From: James Mitchell To: "Hollenbeck, Scott" , "weirds@ietf.org" Date: Tue, 5 Mar 2013 22:58:07 +1100 Thread-Topic: Entity Path Segments, was Entity "Objects" Thread-Index: Ac4ZmLGyqQnnE3PKSq6+SLjCPEUB7w== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24326044@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD5C19F05AFC0jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [weirds] Entity Path Segments, was Entity "Objects" X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 11:58:26 -0000 --_000_CD5C19F05AFC0jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Apologies if I have probably confused the problem(s). I do have issue with = the protocol's support for non-standard information, such as attributes bel= onging only to registrar "entities", however I will post such issues in ano= ther thread. I'll repurpose this thread to better explain my issues with the entity path= segment. According to the specifications, the path segment /entity/R-12345= matches entities. My issue here is that I do not model "entity" objects. I= may have a domain contact that is identified by the string "R-12345", and = a registrar that is identified by the string "R-12345" because domain conta= cts and registrars do not share identifier space. What response is returned= to such a query? The protocol does not allow me to return two objects, eac= h with completely different information! Andy suggested I could prefix identifiers with "contact_R-12345" and "regis= trar-R-12345", however end users will not be able to construct URLs without= knowing the internals of the system they are querying; acceptance of the p= refix solution would contradict the definition of URLs within the specifica= tion. My preference would be provide mechanisms for the client to to determine th= e appropriate path segment in "negotiation" with the server (we can define = a mandatory domain path segment if people get too nervous). Failing this, I= would prefer separate /contact/R-12345 and /registrar/R-12345 path segment= s that can both return entity objects, and failing that I would accept it i= f the /entity/ path segment was explicitly declared OPTIONAL. I do not see = a great need for contacts/registrars being an entry point into the system (= I'm not running a contact object registry) and I can therefore use a path s= egment of my choosing in response to domain queries. Additionally, I have a few comments regarding the example DNR Domain Object= in draft-weirds-json-response. 1. the entity in the DNR Domain Object example response should include it= s role(s). I cannot tell whether the entity is a registrant, admin, billing= , tech, or registrar, or all of the above. 2. The use of the sponsoredBy attribute is inconsistent with the use of d= omain contacts; apparently both registrar and domain contacts are entities = however both are treated completely differently in the response. I would ex= pect registrars and domain contacts are either attributes of domain objects= (with full information either available inline or through links) or the sp= onsoring registrar included in the entities section (both illustrated below= ). I am leaning towards the use of attributes, however recall some resistan= ce duplicating data for domain contact taking multiple roles. Regardless an= y method that allows me to return only links would suffice. 3. Extending point #2, I would assume that one could lookup a registrar b= y taking the value of the sponsoredBy attribute and constructing a URL /ent= ity/SponsorXYZ. I would also assume the same could be done for the resoldBy= attribute. Refer to this whole email why this does not work, noting that I= believe that "sponsoredBy":"registrar_SponsorXYZ" is not acceptable given = clients do not have to lookup the registrar information and my current WHOI= S server does not impose this hack. Example with attributes: { name:"abc.example", =85 sponsoredBy:{handle:"SponsorXYZ", link:"http://example.net/registrar/Sponso= rXYZ" }, registrant:{handle:"XXXX", link:"http://example.net/contact/XXXX"}, -- or -- registrant:{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopp= ing" ], role:"registrant", =85}, =85 } Example with entities: { name:"abc.example", =85 entities: [ {handle:"SponsorXYZ", name:"Registrar 123", role:"registrar", =85}, {handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], rol= e:"registrant", =85} ] =85 } Regards, James From: , Scott > Date: Friday, 1 March 2013 11:17 PM To: James Mitchell >, "weirds@ietf.org" > Subject: RE: Entity "Objects" Please don=92t suggest any Verisign bias here. There is none. =D8 What object is identified by /entity/R-12345? Your answer will depend on the roles associated with that entity. There may= be more than one. Andy From: James Mitchell [mailto:james.mitchell@ausregistry.com.au] Sent: Thursday, February 28, 2013 4:27 PM To: Hollenbeck, Scott; weirds@ietf.org Subject: Re: Entity "Objects" Scott, Perhaps contact objects and registrar objects share the same identifier spa= ce in Verisign's system, however in ours they do not. What object is identi= fied by /entity/R-12345? My answer is both a contact and a registrar; the r= ole does not satisfy the outcome as they will have different names, email a= ddresses etc. If I do not care about direct queries for contact/registrar objects (URLs c= onstructed by clients), and instead assume that links will always be obtain= ed in domain response, then I CAN generate identifiers that separate the t= wo identifier spaces (append C or R as appropriate) - however having to wor= k around this does not feel right to me. I believe that registrars should be their own path segments at /registrar/i= d. Does anyone else have this problem? Regards, James From: , Scott > Date: Friday, 1 March 2013 12:17 AM To: James Mitchell >, "weirds@ietf.org" > Subject: RE: Entity "Objects" Entity objects can be identified by role. A registrar entity and a contact = entity (such as a registrant) would have distinct roles in the context of a= domain object. Scott From:weirds-bounces@ietf.org [mailto:weirds= -bounces@ietf.org] On Behalf Of James Mitchell Sent: Thursday, February 28, 2013 6:17 AM To: weirds@ietf.org Subject: [weirds] Entity "Objects" All, I am concerned regarding the use of the entity object as described in the r= dap query draft. It appears to me as though two separate objects, contacts = and registrars, have been pulled together because they share data. This is = problematic for me because - Contact objects and Registrar objects do not share the same identifier s= pace. - Contact objects and Registrar objects share very little data; one may th= ink of registrar objects as being composed of contact-like (not contact obj= ect) data, perhaps even several contact-like objects (registrar-contact obj= ects do not share the same identifier space as domain-contact objects) What is the motivation for shared query mechanism? Is it to avoid having on= e less path segment? How would one convey information about a registrar to = the client, for example IANA ID without using registry-specific extensions? Thanks, James --_000_CD5C19F05AFC0jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Apologies if I have = probably confused the problem(s). I do have issue with the protocol's = support for non-standard information, such as attributes belonging only to = registrar "entities", however I will post such issues in another = thread.

I'll repurpose this thread= to better explain my issues with the entity path segment. According to the= specifications, the path segment /entity/R-12345 matches entities. My issu= e here is that I do not model "entity" objects. I may have a doma= in contact that is identified by the string "R-12345", and a regi= strar that is identified by the string "R-12345" because domain c= ontacts and registrars do not share identifier space. What response is retu= rned to such a query? The protocol does not allow me to return two objects,= each with completely different information!

Andy suggested I could prefix identifiers with "contact_R-1= 2345" and "registrar-R-12345", however end users will not be= able to construct URLs without knowing the internals of the system th= ey are querying; acceptance of the prefix solution would contradict the def= inition of URLs within the specification.

My preference would be provide mechanisms for the client to to dete= rmine the appropriate path segment in "negotiation" with the serv= er (we can define a mandatory domain path segment if people get too nervous= ). Failing this, I would prefer separate /contact/R-12345 and /registrar/R-= 12345 path segments that can both return entity objects, and failing that I= would accept it if the /entity/ path segment was explicitly declared OPTIO= NAL. I do not see a great need for contacts/registrars being an entry point= into the system (I'm not running a contact object registry) and I can ther= efore use a path segment of my choosing in response to domain queries.

Additionally, I have a few commen= ts regarding the example DNR Domain Object in draft-weirds-json-respon= se.
  1. the entity in the DNR Domain Object example respon= se should include its role(s). I cannot tell whether the entity is a r= egistrant, admin, billing, tech, or registrar, or all of the above.
  2. The use of the sponsoredBy attribute is inconsistent with the= use of domain contacts; apparently both registrar and domain contacts= are entities however both are treated completely differently in the r= esponse. I would expect registrars and domain contacts are either attribute= s of domain objects (with full information either available inline or throu= gh links) or the sponsoring registrar included in the entities section= (both illustrated below). I am leaning towards the use of attributes, howe= ver recall some resistance duplicating data for domain contact taking multi= ple roles. Regardless any method that allows me to return only links would = suffice.
  3. Extending point #2, I would assume that one could lookup a registrar by = taking the value of the sponsoredBy attribute and constructing a URL /entit= y/SponsorXYZ. I would also assume the same could be done for the resoldBy a= ttribute. Refer to this whole email why this does not work, noting that I b= elieve that "sponsoredBy":"registrar_SponsorXYZ" is not= acceptable given clients do not have to lookup the registrar information a= nd my current WHOIS server does not impose this hack.=

Example with attributes= :
{
name:"abc.example",
=85
sponsoredBy:{handle:"SponsorXYZ", link:"http://example.= net/registrar/SponsorXYZ" },
registrant:{handle:"XXXX&quo= t;, link:"http://example.net/contact/XXXX"}, 
-- or = --
registrant:{handle:"XXXX", entityNames: [ "Joe Bo= b, Inc.", "Bobby Joe Shopping" ], role:"registrant"= ;, =85},
=85
}

Example with entities:
{
name:"abc.ex= ample",
=85
entities:
[
{handl= e:"SponsorXYZ", name:"Registrar 123", role:"regist= rar", =85},
{handle:"XXXX", entityNames: [ "Jo= e Bob, Inc.", "Bobby Joe Shopping" ], role:"registrant&= quot;, =85}
]
=85
}
Regards,
James

=
From: <Holle= nbeck>, Scott <shollenbec= k@verisign.com>
Date: Fr= iday, 1 March 2013 11:17 PM
To: = James Mitchell <ja= mes.mitchell@ausregistry.com.au>, "weirds@ietf.org" <wei= rds@ietf.org>
Subject: R= E: Entity "Objects"

Please don=92t suggest any Verisign bias here. There is none.

 

=D8  What object is identif= ied by /entity/R-12345?

 

Your answer will depend on the roles associated with that entity. Th= ere may be more than one.

 

Andy

<= o:p> 

<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">From: = James Mitchell [mailto= :james.mitchell@ausregistry.com.au]
Sent: Thursday, February 28, 2013 4:27 PM
To: Hollenbe= ck, Scott; weirds@ietf.org
Sub= ject: Re: Entity "Objects"

<= p class=3D"MsoNormal"> 

Scott,

 

Pe= rhaps contact objects and registrar objects share the same identifier space=  in Verisign's system, however in ours they do not. What object i= s identified by /entity/R-12345? My answer is both a contact and a registrar; the role doe= s not satisfy the outcome as they will have different names, email addresse= s etc.

 

If I d= o not care about direct queries for contact/registrar objects (URLs constru= cted by clients), and instead assume that links will always be obtained in = domain response,  then I CAN generate identifiers that separate the two iden= tifier spaces (append C or R as appropriate) - however having to work aroun= d this does not feel right to me.

 

I believe that registrars should be their own path segm= ents at /registrar/id. Does anyone else have this problem?

 

Regards,

<= /div>

James

=

 

From: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Date: Friday, 1= March 2013 12:17 AM
To: James Mitchell <james.mitchell@ausregistry.com.au>, = "weirds@ietf.org" <weirds@ietf.org>
Subject: R= E: Entity "Objects"

 

Entity objects can be identified by role. A re= gistrar entity and a contact entity (such as a registrant) would have disti= nct roles in the context of a domain object.

 <= o:p>

Scott<= span style=3D"color:black">

 <= /p>

 

All,

 

I am concerned regarding the use of the entity object as described i= n the rdap query draft. It appears to me as though two separate objects, co= ntacts and registrars, have been pulled together because they share data. This is problemati= c for me because

 - Contact objects and Registrar objects do not share the same ide= ntifier space.<= /p>

 - Contact objects and R= egistrar objects share very little data; one may think of registrar objects= as being composed of contact-like (not contact object) data, perhaps even several contact-like objects (registrar-contact objects do no= t share the same identifier space as domain-contact objects)

 

What is the motivation for shared = query mechanism? Is it to avoid having one less path segment? How would one= convey information about a registrar to the client, for example IANA ID without using registry-specific extensions?

 

Thanks,

--_000_CD5C19F05AFC0jamesmitchellausregistrycomau_-- From james.mitchell@ausregistry.com.au Tue Mar 5 05:04:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B312721F8554 for ; Tue, 5 Mar 2013 05:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQfvZNbkI+TR for ; Tue, 5 Mar 2013 05:04:21 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 486AC21F851E for ; Tue, 5 Mar 2013 05:04:19 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 00:04:17 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 00:04:11 +1100 From: James Mitchell To: "weirds@ietf.org" Date: Wed, 6 Mar 2013 00:04:10 +1100 Thread-Topic: Client handling of unknown attributes/names. Thread-Index: Ac4Zoe2LDq9dFkPjTE6f0OYUJ+8+WA== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD5C387A5B5E3jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 13:04:21 -0000 --_000_CD5C387A5B5E3jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I have been stewing on this one awhile and have come to the belief that the= current approach will result in a protocol that I would not recommend as a= cceptable for deployment with the .au ccTLD. Let me explain why. Section 4.2 of draft-ietf-weirds-json-response-02 says that "Clients proces= sing JSON [RFC4627] responses SHOULD ignore values associated with unrecogn= ized names". I do not want any client ignoring .au specific whois data in the response, = instead (generic) clients that are acting on behalf of (people) users SHOUL= D present this information to the user. The distinction is the end consumer= of the information; I don't care that automated service trying to identify= a spam score will ignore such information. This however introduces a probl= em, how would the client know how to display "au_registrant_id"? Assuming a= text-based output, it could be displayed as: -- begin rendering of response -- Name: ausregistry.com.au Last Updated: 2011-10-14 =85 Additional au_registrant_id: OTHER 092 242 209 -- end rendering of response -- Gah that looks ugly! Either the client should have mappings from the "au_re= gistrant_id" name into a nice presentation format, or the server has to pro= vide this meta-information. I'm going to assume the latter since the goal i= s to reduce client complexity. Possible solutions could include the client = asking the server for rendering information (internationalization achieved = using information in HTTP headers if required =96 HTTP caching also if requ= ired): GET /definition/(domain/)au (a possible use for the prefix?!) Response: { au_registrant_id:{display-name:"Registrant ID", description: "ID number ass= ociated with the registrant entity, if any (eg. ACN for company)"} =85 } Alternatively, servers could include this information in the response direc= tly: GET /domain/ausregistry.com.au { name:"ausregistry.com.au" =85 au_registrant_id:{value:"OTHER 092 242 209", display-name:"Registrant ID", = description: "ID number associated with the registrant entity, if any (eg. = ACN for company)"} } Do other registries, having custom fields in their WHOIS responses, and who= intend to adopt WEIRDS also share this concern? Regards, James --_000_CD5C387A5B5E3jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,

I= have been stewing on this one awhile and have come to the belief that the = current approach will result in a protocol that I would not recommend as ac= ceptable for deployment with the .au ccTLD. Let me explain why.
<= br>
Section 4.2 of draft-ietf-weirds-json-response-02 says t= hat "Clients processing JSON [RFC4627] responses SHOULD ignore values&= nbsp;associated with unrecognized names".

I d= o not want any client ignoring .au specific whois data in the response, ins= tead (generic) clients that are acting on behalf of (people) users S= HOULD present this information to the user. The distinction is the end cons= umer of the information; I don't care that automated service trying to iden= tify a spam score will ignore such information. This however introduces a p= roblem, how would the client know how to display "au_registrant_id&quo= t;? Assuming a text-based output, it could be displayed as:

<= /div>
-- begin rendering of response --
Name: ausregistry.com= .au
Last Updated: 2011-10-14
=85
Additional
au_registrant_id: OTHER 092 242 209
-- end renderin= g of response --

Gah that looks ugly! Either the c= lient should have mappings from the "au_registrant_id" name into = a nice presentation format, or the server has to provide this meta-informat= ion. I'm going to assume the latter since the goal is to reduce client comp= lexity. Possible solutions could include the client asking the server for r= endering information (internationalization achieved using information in HT= TP headers if required =96 HTTP caching also if required):

GET /definition/(domain/)au (a possible use for the prefix?!)
Response:
{
au_registrant_id:{display-name:"Registran= t ID", description: "ID number associated with the registrant ent= ity, if any (eg. ACN for company)"}
=85
}

Alternatively, servers could include this information in the respons= e directly:
GET /domain/ausregistry.com.au
{
= name:"= ;ausregistry.com.au"
=85
au_registrant_id:{value:"OTHER 092 242 2= 09", display-name:"Registrant ID", description: "ID num= ber associated with the registrant entity, if any (eg. ACN for company)&quo= t;}
}

Do other registries, having custom= fields in their WHOIS responses, and who intend to adopt WEIRDS also share= this concern?

Regards,
James
--_000_CD5C387A5B5E3jamesmitchellausregistrycomau_-- From james.mitchell@ausregistry.com.au Tue Mar 5 06:02:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C809721F893E for ; Tue, 5 Mar 2013 06:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAbZsM74-Sad for ; Tue, 5 Mar 2013 06:02:22 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0749D21F8937 for ; Tue, 5 Mar 2013 06:02:20 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 01:02:19 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 01:02:13 +1100 From: James Mitchell To: "weirds@ietf.org" Date: Wed, 6 Mar 2013 01:02:15 +1100 Thread-Topic: Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtA== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD5C46175B89Djamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:02:22 -0000 --_000_CD5C46175B89Djamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, This email introduces a concern that is subtly different to my earlier emai= l regarding client handling of unknown attributes/names. Instead, this emai= l focuses on the approach taken thus far of decoupling data elements from t= heir description. Again, similar to my previous email, I would currently (d= epending on behaviour of WERIDS clients) hesitate to recommend deployment o= f a WEIRDS service for the .au ccTLD. My existing WHOIS service allows me to describe data as I see fit. This is = of great value, especially when fields take on a slightly different meaning= when compared between registries. Consider the extract of a whois response= for ausregistry.com.au below. Registrant: AUSREGISTRY PTY LTD Registrant ID: OTHER 092 242 209 =85 Registrant Contact ID: Z131819709674630 Registrant Contact Name: Registrant Contact Email: Visit whois.ausregistry.com.au for Web bas= ed WhoIs Those with (EPP) registry knowledge may recognise the last three fields as = attributes of the contact object (RFC 5733). What works in this WHOIS respo= nse is that the server can describe the information being returned; informa= tion belonging to the contact object is clearly identified as the "registra= nt contact", additional (non-standard) information is identified as the ser= ver sees fit. auDA's published WHOIS policy clarifies the description of th= e information displayed above, stating that the Registrant is the "Legal na= me of the registrant entity (eg. company name)" whereas the Registrant Cont= act Name is the "Name of a contact person for the registrant". Compare this to a whois response for a .info or .biz domain, where the dom= ain's registrant contact's name (Registrant Contact Name above) is identifi= ed as the "Registrant Name". My concern is that a WEIRDS client will descri= be the registrant contact for a .au domain as the "(legal) registrant", thu= s mislabelling the information. I feel that one of the goals, to improve consumption from automated systems= , is being delivered at the expense of a human consumer. Decoupling data fr= om its meta-information is appropriate when both producers and consumers ha= ve common (exact) understanding of the information exchanged. Unfortunately= I don't think this is the case with domain name registries (information wi= ll be mapped differently to the response objects). Instead, servers could provide information to clients as it should be displ= ayed to consumers, with meta information allowing parsers to identify the i= nformation they care about. An example is below: { [ { key:"Last Modified", value:"2011-10-14Txx:xx:xxZ", meta:"lastChangedDate"= }, { key:"Registrant", value:"AUSREGISTRY PTY LTD"}, { key:"Registrant Contact Email", value:"noreply@ausregistry.com.au", meta:= "registrant-email"} ] } An alternative would be for clients to query field names from the server (u= sing HTTP caching, and header information for internationalization). An exa= mple is as follows: GET /description/domain Response: { name:"Domain Name", lastChangedDate:"Last Modified", =85 } Comments? Regards, James --_000_CD5C46175B89Djamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,
This email introduces a concern that is subtly di= fferent to my earlier email regarding client handling of unknown attributes= /names. Instead, this email focuses on the approach taken thus far of decou= pling data elements from their description. Again, similar to my previous e= mail, I would currently (depending on behaviour of WERIDS clients) hesitate= to recommend deployment of a WEIRDS service for the .au ccTLD.

My existing WHOIS service allows me to descri= be data as I see fit. This is of great value, especially when fields take o= n a slightly different meaning when compared between registries. Consider t= he extract of a whois response for ausregistry.com.au below.

Registrant:           &= nbsp;          AUSREGISTRY PTY LTD
=85
Regist= rant Contact ID:           Z131819709674630
<= div>Registrant Contact Name:         <withheld from = this email>
Registrant Contact Email:   &nb= sp;    Visit whois.ausregistry.com.au for Web based WhoIs

Those with (EPP) registry knowledge may r= ecognise the last three fields as attributes of the contact object (RFC 573= 3). What works in this WHOIS response is that the server can describe = the information being returned; information belonging to the contact object= is clearly identified as the "registrant contact", additional (n= on-standard) information is identified as the server sees fit. auDA's publi= shed WHOIS policy clarifies the description of the information displayed ab= ove, stating that the Registrant is the "Legal name of the registrant = entity (eg. company name)" whereas the Registrant Contact Name is the = "Name of a contact person for the registrant".
=
Compare this to a whois response for a .info  o= r .biz domain, where the domain's registrant contact's name (Registrant Con= tact Name above) is identified as the "Registrant Name". My conce= rn is that a WEIRDS client will describe the registrant contact for a .au d= omain as the "(legal) registrant", thus mislabelling the informat= ion.

I feel that one of the goals,= to improve consumption from automated systems, is being delivered at the e= xpense of a human consumer. Decoupling data from its meta-information is ap= propriate when both producers and consumers have common (exact) understandi= ng of the information exchanged. Unfortunately I don't think this is the ca= se with domain name registries (information will be mapped differently to t= he response objects).

Instead, ser= vers could provide information to clients as it should be displayed to cons= umers, with meta information allowing parsers to identify the information t= hey care about. An example is below:
{
= [
{ key:"Last Modi= fied", value:"2011-10-14Txx:xx:xxZ", meta:"lastChangedD= ate"},
{ key:"Registrant", value:"AUS= REGISTRY PTY LTD"},
{ key:"Registrant Contact Email"= ;, value:"noreply@ausregistry.com.au", meta:"registrant-emai= l"}
]
}

An alternative would be for clients to query field names from the serv= er (using HTTP caching, and header information for internationalization). A= n example is as follows:
GET /description/domain
Response:
{
name:"Domain Name"= ;,
lastChanged= Date:"Last Modified",
=85
}

Comments?

=
Regards,<= /font>
James

--_000_CD5C46175B89Djamesmitchellausregistrycomau_-- From simon.perreault@viagenie.ca Tue Mar 5 06:09:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7221F86B2 for ; Tue, 5 Mar 2013 06:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNqCRNqHR54w for ; Tue, 5 Mar 2013 06:09:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3E21F8648 for ; Tue, 5 Mar 2013 06:09:58 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:89ce:677:fab:b4b1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D000440413 for ; Tue, 5 Mar 2013 09:09:53 -0500 (EST) Message-ID: <5135FCEA.40800@viagenie.ca> Date: Tue, 05 Mar 2013 15:10:50 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:09:59 -0000 James, Replying to the core idea of your last two mails... We must absolutely keep presentation data separate from actual data. If this was XML, I'd say "keep the actual data in XML, put the presentation information in an XSLT style sheet". What's the equivalent in JSON? Can we use that? Simon From andy@arin.net Tue Mar 5 11:55:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338C11E80EF for ; Tue, 5 Mar 2013 11:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l41bYnhlF2gU for ; Tue, 5 Mar 2013 11:55:05 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0411E80D3 for ; Tue, 5 Mar 2013 11:55:05 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 494941651DD; Tue, 5 Mar 2013 14:55:03 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id CA5181650F3; Tue, 5 Mar 2013 14:55:02 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 5 Mar 2013 14:54:23 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 5 Mar 2013 14:54:59 -0500 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Comments on json-response-02 Thread-Index: AQHOFpSaZhesgqmhME6zgg8bEeB9VpiXiXaA Date: Tue, 5 Mar 2013 19:54:59 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF13D8@CHAXCH01.corp.arin.net> In-Reply-To: <5130CE3E.60503@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on json-response-02 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:55:06 -0000 On 3/1/13 11:50 PM, "Simon Perreault" wrote: >See attached. My comments are marked with .... > >I have included all the necessary changes to switch to jCard. Hopefully >this makes the editor's job easier. :) Outstanding! Thanks Simon. -andy From andy@arin.net Tue Mar 5 12:00:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5F011E8177 for ; Tue, 5 Mar 2013 12:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otH3qqo4d34J for ; Tue, 5 Mar 2013 12:00:44 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0E11E812F for ; Tue, 5 Mar 2013 12:00:40 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id C7F2F1651DD; Tue, 5 Mar 2013 15:00:39 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 68B271650F4; Tue, 5 Mar 2013 15:00:39 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 5 Mar 2013 15:00:24 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 5 Mar 2013 15:00:32 -0500 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754A= Date: Tue, 5 Mar 2013 20:00:32 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1407@CHAXCH01.corp.arin.net> In-Reply-To: <5135FCEA.40800@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:00:44 -0000 On 3/5/13 9:10 AM, "Simon Perreault" wrote: >We must absolutely keep presentation data separate from actual data. +1 > >If this was XML, I'd say "keep the actual data in XML, put the >presentation information in an XSLT style sheet". > >What's the equivalent in JSON? >Can we use that? It's called code. :) -andy From johnl@iecc.com Tue Mar 5 13:27:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1356311E810B for ; Tue, 5 Mar 2013 13:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrB6V1KiEH1I for ; Tue, 5 Mar 2013 13:27:07 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 35EFB11E80D3 for ; Tue, 5 Mar 2013 13:27:07 -0800 (PST) Received: (qmail 64558 invoked from network); 5 Mar 2013 21:27:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Mar 2013 21:27:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5136632a.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=2nDx4mvvrXpUMK7EvGBeIj8RRp0gMZDP8hVY1PmjuEo=; b=ICgs9ZdohBjVvdU2yzFW5VAZwtfWnL/92dNfIruXNr94SO0U1rb/Ze2cJ/XGGjkzgJVNF/aJPG+2A1GZcEAj7uVxbbn3CpG4AyAHcnAXNsd0ekwuUmAZV7x0cJuhUEjK1KaJL9m22ARNQX/H7/cmkj3V2kr90jpZITI0R+CaOiI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5136632a.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=2nDx4mvvrXpUMK7EvGBeIj8RRp0gMZDP8hVY1PmjuEo=; b=c36vHr2+VPXVPZ2TUOO0uK/xftB6gWMdc1YAEEQVB4aTAS/p2TsApWMw8el8qvqc3V7xwf77XwC1CB2tjnqKRpq8iLMPNwwEO2/MO3DlGIGyWOSCXWyqdG5T20aRQdJ64cJPkMrqPt+2Cc7kweelZ/pEyYJpc3A0NdK8C1ch7oU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Mar 2013 21:26:44 -0000 Message-ID: <20130305212644.18407.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:27:08 -0000 >Section 4.2 of draft-ietf-weirds-json-response-02 says that "Clients processing JSON [RFC4627] >responses SHOULD ignore values associated with unrecognized names". > >I do not want any client ignoring .au specific whois data in the response, instead (generic) >clients that are acting on behalf of (people) users SHOULD present this information to the user. You're misunderstanding what that means. It's saying that client software should be able to skip over fields it doesn't understand, rather than stopping and failing. It doesn't say anything about user interface. As a bit of background, the IETF is famously, awesomely bad at anything related to user interface, and we have learned to stay away from it. While I agree that there are plenty of situations where it would make sense to format unknown fields in some generic way and dump them to the screen for the user to see, there are also plenty of situations where it doesn't. Perhaps the screen is really small (an iWatch or something) and there isn't room to show more than a small fraction of what comes back. Or perhaps a field is a base64 encoded PNG of a person's photo, and if a client doesn't happen to know how to decode it, the user will see a big block of random uninformative text, which in that case is worse than nothing. There's no generally useful advice we can give other than to avoid doing stupid things, but anyone who needs that advice is unlikely to be able to follow it. Our job is to tell clients and servers how to interoperate, not to tell clients what to do with the data once it's decoded it. R's, John PS: If a typical WEIRDS lookup returns a lot of fields that a typical client doesn't understand, we won't done our job very well, either. From edainow@afilias.info Tue Mar 5 14:01:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2211E811B for ; Tue, 5 Mar 2013 14:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEtHnJyl3NPR for ; Tue, 5 Mar 2013 14:01:19 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7E511E80AD for ; Tue, 5 Mar 2013 14:01:19 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UCzvB-0006YF-5h for weirds@ietf.org; Tue, 05 Mar 2013 22:01:17 +0000 Received: from mail-wg0-f69.google.com ([74.125.82.69]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UCzvB-0002ag-4q for weirds@ietf.org; Tue, 05 Mar 2013 22:01:17 +0000 Received: by mail-wg0-f69.google.com with SMTP id fn15so8625356wgb.8 for ; Tue, 05 Mar 2013 14:01:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=i9dc5M+4jY90gFJkM2CnlmyXCH5txX2ILKHIRdUje9c=; b=h17JO8F6PHLTIOzx9ubQShlioPYNvY81yDkLxqO0uCEmgHanjLvm8xa2k6OMW6IATp zgcY0eET5WU1wIKQA3G/HIYeOY+W7qPj8lTofsEvBtHNBTMDHxvMUSQjE5Y/y33i/gmb mklTllB5uQKp6ifEnHBKgwKBqR5KWBXCEQqyJmjONGFZ4EY5dgZUSYWPQvYFQ4X1XFHV HPadtPOmKKJ5BMp6LmHxk+2i3RqJ+8xRkEShTMfdTpThhyKeoXm/YB+qv6mHVHi1kQNQ 5MQmcqF5b2utlJ2QIFWiLAKUDVlnTQzn2G+1YkRU5wlavTOPqLqmZzyrst9NfluCav+H jwMA== X-Received: by 10.14.207.200 with SMTP id n48mr75107013eeo.4.1362520871454; Tue, 05 Mar 2013 14:01:11 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.207.200 with SMTP id n48mr75106970eeo.4.1362520871108; Tue, 05 Mar 2013 14:01:11 -0800 (PST) Received: by 10.14.123.131 with HTTP; Tue, 5 Mar 2013 14:01:11 -0800 (PST) In-Reply-To: References: <51310890.5030208@gmail.com> Date: Tue, 5 Mar 2013 17:01:11 -0500 Message-ID: From: Ernie Dainow To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=047d7b343b1c86854804d7349cd1 X-Gm-Message-State: ALoCoQnMuYzeFT9WPC69/hlWjn29rFa+zmEjD6cYKc2uShSLEsMuDnKYO2rqf5tN6QSAmC5kJB+6VOFN8bBbX+h4npZQXg55MggR3pnoRUZAr6tAq62YsTrkB33LHI1uQR5VyxkEdDmA Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:01:20 -0000 --047d7b343b1c86854804d7349cd1 Content-Type: text/plain; charset=ISO-8859-1 We would like to demo our Domain Name Registry test server. It returns live data for all domains in .info. It implements the latest RDAP drafts (excluding search). I won't be in Orlando but Jim Galvin will be there to do this and answer questions. Will there be any remote participation? Some other sessions have WebEx or Meetecho scheduled. -Ernie On Tue, Mar 5, 2013 at 12:29 AM, Byron Ellacott wrote: > Hi all, > > APNIC's pilot server is now several revisions behind the drafts, but I'm > happy to volunteer (someone else from APNIC :-) to be there to show it > working in its current state. > > http://rdap.apnic.net/ip/ > > > Byron > > On 2/03/13 5:59 AM, "Carlos M. Martinez" wrote: > > >You're absolutely right. Depends on how many we are. > > > >Starting the roll call: We'll be presenting our server implementation. > > > >~C. > > > >On 3/1/13 5:51 PM, Murray S. Kucherawy wrote: > >> Do we have a lot of people planning to do demos? Are the demos going to > >> be complicated? > >> > >> I don't understand how an hour would not be enough, unless there's a > >> large number of implementations I haven't heard of yet. > >> > >> Who's got something to show (or will by then), and how long do you need? > >> > >> -MSK > >> > >> > >> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > >> > wrote: > >> > >> Unless we write a detailed plan of what we are going to do, I don't > >> think it will be enough. > >> > >> In any case, I think we can continue in the term room. Or in the > >> hallways :D > >> > >> regards > >> > >> Carlos > >> > >> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > >> > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in > >>room > >> > Boca 1 for implementation demos. We only have that one hour > >>before > >> > other sessions begin, so please come prepared! > >> > > >> > -MSK > >> > > >> > > >> > _______________________________________________ > >> > weirds mailing list > >> > weirds@ietf.org > >> > https://www.ietf.org/mailman/listinfo/weirds > >> > > >> > >> > >> > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >> > >_______________________________________________ > >weirds mailing list > >weirds@ietf.org > >https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b343b1c86854804d7349cd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We would like to demo= our Domain Name Registry test server. It returns live data for all domains= in .info. It implements the latest RDAP drafts (excluding search).

I won't be in Orlando but Jim Galvin will be there to do this and answe= r questions. Will there be any remote participation? Some other sessions ha= ve WebEx or Meetecho scheduled.

-Ernie


On Tue, Mar 5, 2013 at 12:29 AM, B= yron Ellacott <bje@apnic.net> wrote:
Hi all,

APNIC's pilot server is now several revisions behind the drafts, but I&= #39;m
happy to volunteer (someone else from APNIC :-) to be there to show it
working in its current state.

http://rdap.apnic.n= et/ip/


=A0 Byron

On 2/03/13 5:59 AM, "Carlos M. Martinez" <carlosm3011@gmail.com> wrote:=

>You're absolutely right. Depends on how many we are.
>
>Starting the roll call: We'll be presenting our server implementati= on.
>
>~C.
>
>On 3/1/13 5:51 PM, Murray S. Kucherawy wrote:
>> Do we have a lot of people planning to do demos? =A0Are the demos = going to
>> be complicated?
>>
>> I don't understand how an hour would not be enough, unless the= re's a
>> large number of implementations I haven't heard of yet.
>>
>> Who's got something to show (or will by then), and how long do= you need?
>>
>> -MSK
>>
>>
>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez
>> <car= losm3011@gmail.com <mailto:carlosm3011@gmail.com>> wrote:
>>
>> =A0 =A0 Unless we write a detailed plan of what we are going to do= , I don't
>> =A0 =A0 think it will be enough.
>>
>> =A0 =A0 In any case, I think we can continue in the term room. Or = in the
>> =A0 =A0 hallways :D
>>
>> =A0 =A0 regards
>>
>> =A0 =A0 Carlos
>>
>> =A0 =A0 On 3/1/13 4:21 PM, Murray S. Kucherawy wrote:
>> =A0 =A0 > The Secretariat has assigned us 8am-9am on Tuesday, M= arch 12, in
>>room
>> =A0 =A0 > Boca 1 for implementation demos. =A0We only have that= one hour
>>before
>> =A0 =A0 > other sessions begin, so please come prepared!
>> =A0 =A0 >
>> =A0 =A0 > -MSK
>> =A0 =A0 >
>> =A0 =A0 >
>> =A0 =A0 > _______________________________________________
>> =A0 =A0 > weirds mailing list
>> =A0 =A0 > = weirds@ietf.org <mailto:weirds@ietf.org>
>> =A0 =A0 > https://www.ietf.org/mailman/listinfo/weirds
>> =A0 =A0 >
>>
>>
>>
>>
>> _______________________________________________
>> weirds mailing list
>> weirds@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/weirds
>>
>_______________________________________________
>weirds mailing list
>weirds@ietf.org
>https://www.ietf.org/mailman/listinfo/weirds

_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds

--047d7b343b1c86854804d7349cd1-- From chris@ausregistry.com.au Tue Mar 5 14:54:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8921F84B2 for ; Tue, 5 Mar 2013 14:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCYV2-HR0z1j for ; Tue, 5 Mar 2013 14:54:06 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 77CB221F8494 for ; Tue, 5 Mar 2013 14:54:06 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 09:54:03 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 09:53:57 +1100 From: Chris Wright To: Andy Newton , Simon Perreault , "weirds@ietf.org" Date: Wed, 6 Mar 2013 09:54:00 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMA== Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AD1E@off-win2003-01.ausregistrygroup.local> References: <5135FCEA.40800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1407@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1407@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:54:07 -0000 Andy, Your response is not very helpful. We have a legitimate issue that will pre= vent us from deploying WEIRDS as it stands, I think we have been clear on i= t for a while (we tried to raise it way back at the start and even voiced t= he concern at the session in Vancouver). We cannot rely on clients (being e= xternal parties who write the code) knowing that the registrant contact is = not the registrant in our TLD. Code is extremely different to XSLT, if we w= ere using XML, my server could return the XML and the XSLT, unless you are = suggesting we return snippets of java, C (and every other language we want = to support) code as part of our WEIRDS responses code is NOT an acceptable = answer. I understand the goal of separating presentation from data, and honestly I = don't see including "data labels" as 'presentation' it says nothing of the = layout or anything else (and can be ignored by the clients). Since everyone seems against it, can someone who is clearly smarter than us= , please explain how we are to address our concern, to date everyone seems = to say no to our suggestions, but doesn't offer viable alternatives. Thanks Chris -----Original Message----- From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Andy Newton Sent: Wednesday, 6 March 2013 7:01 AM To: Simon Perreault; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names On 3/5/13 9:10 AM, "Simon Perreault" wrote: >We must absolutely keep presentation data separate from actual data. +1 > >If this was XML, I'd say "keep the actual data in XML, put the=20 >presentation information in an XSLT style sheet". > >What's the equivalent in JSON? >Can we use that? It's called code. :) -andy _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds From ajs@anvilwalrusden.com Tue Mar 5 15:12:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1A11E8102 for ; Tue, 5 Mar 2013 15:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb+K0BFmok4h for ; Tue, 5 Mar 2013 15:12:58 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0603011E80FA for ; Tue, 5 Mar 2013 15:12:57 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 18FE88A031 for ; Tue, 5 Mar 2013 23:12:57 +0000 (UTC) Date: Tue, 5 Mar 2013 18:12:55 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130305231255.GH18073@mx1.yitter.info> References: <5135FCEA.40800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1407@CHAXCH01.corp.arin.net> <8CEF048B9EC83748B1517DC64EA130FB76EE44AD1E@off-win2003-01.ausregistrygroup.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AD1E@off-win2003-01.ausregistrygroup.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 23:12:58 -0000 On Wed, Mar 06, 2013 at 09:54:00AM +1100, Chris Wright wrote: > > I understand the goal of separating presentation from data, and honestly I don't see including "data labels" as 'presentation' it says nothing of the layout or anything else (and can be ignored by the clients). > This is a poorly-thought-out suggestion, so feel free to throw rocks. What if we created classes of "unknown" types that would allow free-form use? This would solve the problem that John Levine quite correctly mentioned, where every kind of unknown field with encoded data and so on would get dumped on clients. The idea here is to give these unknown fields types, like (say) free-form text. Then a client could handle the different unknown types differently. A client could display only types it knows, or fields of a given type, or whatever. Does that seem like it might help? A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Mar 5 20:18:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DCF21F85D8 for ; Tue, 5 Mar 2013 20:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.079 X-Spam-Level: X-Spam-Status: No, score=-110.079 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QVvKHKW6cU2 for ; Tue, 5 Mar 2013 20:18:22 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5274011E80A5 for ; Tue, 5 Mar 2013 20:18:22 -0800 (PST) Received: (qmail 37766 invoked from network); 6 Mar 2013 04:18:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2013 04:18:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5136c38d.xn--3zv.k1303; i=johnl@user.iecc.com; bh=o0RF6x9Q52bUuB9PeA+Mlgiscygn/7V72X9JNGrToQg=; b=ubiEh7+HPNMXZ2IE/qHjOqdkX/9RAK9r3sScA24aBn5LbQ+4U/u61UUyU3HsL4chxsK6LEkd4GUReUyU9YxdDNNxEW1TiSkOL7vvLAHEZCKdKHeQaFrlPWDEpIEQjJHebo60dxfKOu1tBrkBIlk/E+3u0iqWIMKXjvIMhJHHRWk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5136c38d.xn--3zv.k1303; olt=johnl@user.iecc.com; bh=o0RF6x9Q52bUuB9PeA+Mlgiscygn/7V72X9JNGrToQg=; b=XxqFW2u0gqx0PGPp7VxU15cdGPSw+95dSm4JqmXd0N/Ati6gIiQmcqgKmMPpOVx1GNrh3/Kht9qFkJtleQNKrmFSo88AeVvY6XWVs8CSyTNkLJOQW2Zvu2FthxabCY7cF/6DWkLHPpllytmrSY0EHfEtzr/HchAH3IYd/gw+aSM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2013 04:17:59 -0000 Message-ID: <20130306041759.7920.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20130305231255.GH18073@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 04:18:23 -0000 >This is a poorly-thought-out suggestion, so feel free to throw rocks. >What if we created classes of "unknown" types that would allow >free-form use? I think it's time for the names registries to get to work and define a common vocabulary adequate to handle all of the important bits of WHOIS name queries. This might require that some of the registries do some adaptation to fit their data to the vocabularies. This is the place where all previous son-of-WHOIS attempts failed, and when the names crowd muscled in here they swore it wouldn't happen again. Time, as we say in the U.S., to fish or cut bait. If it only ends up being adequate for gTLD WHOIS and some of the ccTLDs will not or cannot use it, it's still better than nothing. R's, John From bje@apnic.net Tue Mar 5 21:43:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B631C11E812A for ; Tue, 5 Mar 2013 21:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WqHywL-qk+9 for ; Tue, 5 Mar 2013 21:43:38 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 91DE411E80A5 for ; Tue, 5 Mar 2013 21:43:35 -0800 (PST) Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 6 Mar 2013 15:42:55 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802::11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 6 Mar 2013 15:42:33 +1000 Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Wed, 6 Mar 2013 15:43:29 +1000 From: Byron Ellacott To: James Mitchell , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAg30MA Date: Wed, 6 Mar 2013 05:43:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.199] Content-Type: multipart/alternative; boundary="_000_CD5D14411CE28bjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:43:39 -0000 --_000_CD5D14411CE28bjeapnicnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi James, If I understand your example correctly, you have two pieces of data about t= he party responsible for registration, namely a descriptive label and an ID= . You also have several pieces of data about a human contact for that part= y. Does it seem like I've understood your example? If so, would this abridged JSON structure reflect it accurately: { } From: James Mitchell > Date: Wednesday, 6 March 2013 12:02 AM To: "weirds@ietf.org" > Subject: [weirds] Client handling of known attributes/names All, This email introduces a concern that is subtly different to my earlier emai= l regarding client handling of unknown attributes/names. Instead, this emai= l focuses on the approach taken thus far of decoupling data elements from t= heir description. Again, similar to my previous email, I would currently (d= epending on behaviour of WERIDS clients) hesitate to recommend deployment o= f a WEIRDS service for the .au ccTLD. My existing WHOIS service allows me to describe data as I see fit. This is = of great value, especially when fields take on a slightly different meaning= when compared between registries. Consider the extract of a whois response= for ausregistry.com.au below. Registrant: AUSREGISTRY PTY LTD Registrant ID: OTHER 092 242 209 =85 Registrant Contact ID: Z131819709674630 Registrant Contact Name: Registrant Contact Email: Visit whois.ausregistry.com.au for Web bas= ed WhoIs Those with (EPP) registry knowledge may recognise the last three fields as = attributes of the contact object (RFC 5733). What works in this WHOIS respo= nse is that the server can describe the information being returned; informa= tion belonging to the contact object is clearly identified as the "registra= nt contact", additional (non-standard) information is identified as the ser= ver sees fit. auDA's published WHOIS policy clarifies the description of th= e information displayed above, stating that the Registrant is the "Legal na= me of the registrant entity (eg. company name)" whereas the Registrant Cont= act Name is the "Name of a contact person for the registrant". Compare this to a whois response for a .info or .biz domain, where the dom= ain's registrant contact's name (Registrant Contact Name above) is identifi= ed as the "Registrant Name". My concern is that a WEIRDS client will descri= be the registrant contact for a .au domain as the "(legal) registrant", thu= s mislabelling the information. I feel that one of the goals, to improve consumption from automated systems= , is being delivered at the expense of a human consumer. Decoupling data fr= om its meta-information is appropriate when both producers and consumers ha= ve common (exact) understanding of the information exchanged. Unfortunately= I don't think this is the case with domain name registries (information wi= ll be mapped differently to the response objects). Instead, servers could provide information to clients as it should be displ= ayed to consumers, with meta information allowing parsers to identify the i= nformation they care about. An example is below: { [ { key:"Last Modified", value:"2011-10-14Txx:xx:xxZ", meta:"lastChangedDate"= }, { key:"Registrant", value:"AUSREGISTRY PTY LTD"}, { key:"Registrant Contact Email", value:"noreply@ausregistry.com.au", meta:"registrant-email"} ] } An alternative would be for clients to query field names from the server (u= sing HTTP caching, and header information for internationalization). An exa= mple is as follows: GET /description/domain Response: { name:"Domain Name", lastChangedDate:"Last Modified", =85 } Comments? Regards, James --_000_CD5D14411CE28bjeapnicnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B2DFD4AD07B424DBDE3FB3616AB8230@apnic.net> Content-Transfer-Encoding: quoted-printable
Hi James,

If I understand your example correctly, you have two pieces of data ab= out the party responsible for registration, namely a descriptive label and = an ID.  You also have several pieces of data about a human contact for= that party.  Does it seem like I've understood your example?

If so, would this abridged JSON structure reflect it accurately:

{
}

From: James Mitchell <james.mitchell@ausregistry.com.a= u>
Date: Wednesday, 6 March 2013 12:02= AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Client handling o= f known attributes/names

All,

This email introduces a concern that is subtly different to my earlier emai= l regarding client handling of unknown attributes/names. Instead, this emai= l focuses on the approach taken thus far of decoupling data elements from t= heir description. Again, similar to my previous email, I would currently (depending on behaviour of WERIDS = clients) hesitate to recommend deployment of a WEIRDS service for the .au c= cTLD.

My existing WHOIS service allows me to describe data as I see fit. This is = of great value, especially when fields take on a slightly different meaning= when compared between registries. Consider the extract of a whois response= for ausregistry.com.au below.

Registrant:                   =    AUSREGISTRY PTY LTD
Registrant ID:                 &nbs= p; OTHER 092 242 209
=85
Registrant Contact ID:           Z13181970967= 4630
Registrant Contact Name:         <withheld from= this email>
Registrant Contact Email:        Visit whois.ausregistr= y.com.au for Web based WhoIs

Those with (EPP) registry knowledge may recognise the last three fields as = attributes of the contact object (RFC 5733). What works in this WHOIS = response is that the server can describe the information being returned; in= formation belonging to the contact object is clearly identified as the "registrant contact", additional (n= on-standard) information is identified as the server sees fit. auDA's publi= shed WHOIS policy clarifies the description of the information displayed ab= ove, stating that the Registrant is the "Legal name of the registrant entity (eg. company name)" whereas the Registr= ant Contact Name is the "Name of a contact person for the registrant&q= uot;.

Compare this to a whois response for a .info  or .biz domain, where th= e domain's registrant contact's name (Registrant Contact Name above) is ide= ntified as the "Registrant Name". My concern is that a WEIRDS cli= ent will describe the registrant contact for a .au domain as the "(legal) registrant", thus mislabelling the in= formation.

I feel that one of the goals, to improve consumption from automated systems= , is being delivered at the expense of a human consumer. Decoupling data fr= om its meta-information is appropriate when both producers and consumers ha= ve common (exact) understanding of the information exchanged. Unfortunately I don't think this is the case= with domain name registries (information will be mapped differently to the= response objects).

Instead, servers could provide information to clients as it should be displ= ayed to consumers, with meta information allowing parsers to identify the i= nformation they care about. An example is below:
{
[
{ key:"Last Mod= ified", value:"2011-10-14Txx:xx:xxZ", meta:"lastChanged= Date"},
{ key:"= ;Registrant", value:"AUSREGISTRY PTY LTD"},
{ key:"= ;Registrant Contact Email", value:"noreply@ausregistry.com.au", meta:"registrant= -email"}
]
}

An alternative would be for clients to query field names from the server (u= sing HTTP caching, and header information for internationalization). An exa= mple is as follows:
GET /description/domain
Response:
{
name:"= Domain Name",
lastChangedDate:&quo= t;Last Modified",
=85
}<= /div>

Comments?=

Regards,<= /font>
James

--_000_CD5D14411CE28bjeapnicnet_-- From bje@apnic.net Tue Mar 5 21:49:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6708B21F8581 for ; Tue, 5 Mar 2013 21:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLCPyI+VVDyd for ; Tue, 5 Mar 2013 21:49:47 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 2619C21F8533 for ; Tue, 5 Mar 2013 21:49:45 -0800 (PST) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 6 Mar 2013 15:49:04 +1000 (EST) Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67%18]) with mapi id 14.01.0218.012; Wed, 6 Mar 2013 15:48:44 +1000 From: Byron Ellacott To: Byron Ellacott , James Mitchell , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAg30MAAAA3SYA= Date: Wed, 6 Mar 2013 05:49:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.199] Content-Type: multipart/alternative; boundary="_000_CD5D14B81CE2Ebjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:49:49 -0000 --_000_CD5D14B81CE2Ebjeapnicnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ugh. Don't accidentally hit the send button half way through compose. THI= S structure: { "registrationBy" : "AUSREGISTRY PTY LTD", "entities" : [ { "handle": "Z131819709674630", "entityNames": [ "" ], "emails": [ "Visit whois.ausregistry.com.au for Web based WhoIs" ], "roles" : [ "registrant contact" ] } ] } As in, the registrant contact is a contact of role "registrant contact", an= d the registrationBy contains information about the registrant party. This= does not include registrant ID: the registrationBy field may need some wor= k to support the difference between the registrant name (?) and ID. Byron From: Byron Ellacott > Date: Wednesday, 6 March 2013 3:43 PM To: James Mitchell >, "weirds@ietf.org" > Subject: Re: [weirds] Client handling of known attributes/names Hi James, If I understand your example correctly, you have two pieces of data about t= he party responsible for registration, namely a descriptive label and an ID= . You also have several pieces of data about a human contact for that part= y. Does it seem like I've understood your example? If so, would this abridged JSON structure reflect it accurately: { } From: James Mitchell > Date: Wednesday, 6 March 2013 12:02 AM To: "weirds@ietf.org" > Subject: [weirds] Client handling of known attributes/names All, This email introduces a concern that is subtly different to my earlier emai= l regarding client handling of unknown attributes/names. Instead, this emai= l focuses on the approach taken thus far of decoupling data elements from t= heir description. Again, similar to my previous email, I would currently (d= epending on behaviour of WERIDS clients) hesitate to recommend deployment o= f a WEIRDS service for the .au ccTLD. My existing WHOIS service allows me to describe data as I see fit. This is = of great value, especially when fields take on a slightly different meaning= when compared between registries. Consider the extract of a whois response= for ausregistry.com.au below. Registrant: AUSREGISTRY PTY LTD Registrant ID: OTHER 092 242 209 =85 Registrant Contact ID: Z131819709674630 Registrant Contact Name: Registrant Contact Email: Visit whois.ausregistry.com.au for Web bas= ed WhoIs Those with (EPP) registry knowledge may recognise the last three fields as = attributes of the contact object (RFC 5733). What works in this WHOIS respo= nse is that the server can describe the information being returned; informa= tion belonging to the contact object is clearly identified as the "registra= nt contact", additional (non-standard) information is identified as the ser= ver sees fit. auDA's published WHOIS policy clarifies the description of th= e information displayed above, stating that the Registrant is the "Legal na= me of the registrant entity (eg. company name)" whereas the Registrant Cont= act Name is the "Name of a contact person for the registrant". Compare this to a whois response for a .info or .biz domain, where the dom= ain's registrant contact's name (Registrant Contact Name above) is identifi= ed as the "Registrant Name". My concern is that a WEIRDS client will descri= be the registrant contact for a .au domain as the "(legal) registrant", thu= s mislabelling the information. I feel that one of the goals, to improve consumption from automated systems= , is being delivered at the expense of a human consumer. Decoupling data fr= om its meta-information is appropriate when both producers and consumers ha= ve common (exact) understanding of the information exchanged. Unfortunately= I don't think this is the case with domain name registries (information wi= ll be mapped differently to the response objects). Instead, servers could provide information to clients as it should be displ= ayed to consumers, with meta information allowing parsers to identify the i= nformation they care about. An example is below: { [ { key:"Last Modified", value:"2011-10-14Txx:xx:xxZ", meta:"lastChangedDate"= }, { key:"Registrant", value:"AUSREGISTRY PTY LTD"}, { key:"Registrant Contact Email", value:"noreply@ausregistry.com.au", meta:"registrant-email"} ] } An alternative would be for clients to query field names from the server (u= sing HTTP caching, and header information for internationalization). An exa= mple is as follows: GET /description/domain Response: { name:"Domain Name", lastChangedDate:"Last Modified", =85 } Comments? Regards, James --_000_CD5D14B81CE2Ebjeapnicnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Ugh.  Don't accidentally hit the send= button half way through compose.  THIS structure:

{
"registrationBy" : "AUSREGISTRY PTY LT= D", 
"entities" : [
{
"handle": "Z131819709674630",
"= entityNames": [ "<withheld from this email, too>" ],
"= emails": [ "Visit whois.ausregistry.com.au for Web based WhoIs&qu= ot; ],
"= roles" : [ "registrant contact" ]
}
]
}

As in, the registrant contact is a contact= of role "registrant contact", and the registrationBy contains in= formation about the registrant party.  This does not include registran= t ID: the registrationBy field may need some work to support the difference between the registrant name (?) and ID.

  Byron

From: Byron Ellacott <bje@apnic.net>
Date: Wednesday, 6 March 2013 3:43 = PM
To: James Mitchell <james.mitchell@ausregistry.com.au<= /a>>, "weirds@ietf.org"= <weirds@ietf.org>
Subject: Re: [weirds] Client handli= ng of known attributes/names

Hi James,

If I understand your example correctly, you have two pieces of data ab= out the party responsible for registration, namely a descriptive label and = an ID.  You also have several pieces of data about a human contact for= that party.  Does it seem like I've understood your example?

If so, would this abridged JSON structure reflect it accurately:

{
}

From: James Mitchell <james.mitchell@ausregistry.com.a= u>
Date: Wednesday, 6 March 2013 12:02= AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Client handling o= f known attributes/names

All,

This email introduces a concern that is subtly different to my earlier emai= l regarding client handling of unknown attributes/names. Instead, this emai= l focuses on the approach taken thus far of decoupling data elements from t= heir description. Again, similar to my previous email, I would currently (depending on behaviour of WERIDS = clients) hesitate to recommend deployment of a WEIRDS service for the .au c= cTLD.

My existing WHOIS service allows me to describe data as I see fit. This is = of great value, especially when fields take on a slightly different meaning= when compared between registries. Consider the extract of a whois response= for ausregistry.com.au below.

Registrant:                   =    AUSREGISTRY PTY LTD
Registrant ID:                 &nbs= p; OTHER 092 242 209
=85
Registrant Contact ID:           Z13181970967= 4630
Registrant Contact Name:         <withheld from= this email>
Registrant Contact Email:        Visit whois.ausregistr= y.com.au for Web based WhoIs

Those with (EPP) registry knowledge may recognise the last three fields as = attributes of the contact object (RFC 5733). What works in this WHOIS = response is that the server can describe the information being returned; in= formation belonging to the contact object is clearly identified as the "registrant contact", additional (n= on-standard) information is identified as the server sees fit. auDA's publi= shed WHOIS policy clarifies the description of the information displayed ab= ove, stating that the Registrant is the "Legal name of the registrant entity (eg. company name)" whereas the Registr= ant Contact Name is the "Name of a contact person for the registrant&q= uot;.

Compare this to a whois response for a .info  or .biz domain, where th= e domain's registrant contact's name (Registrant Contact Name above) is ide= ntified as the "Registrant Name". My concern is that a WEIRDS cli= ent will describe the registrant contact for a .au domain as the "(legal) registrant", thus mislabelling the in= formation.

I feel that one of the goals, to improve consumption from automated systems= , is being delivered at the expense of a human consumer. Decoupling data fr= om its meta-information is appropriate when both producers and consumers ha= ve common (exact) understanding of the information exchanged. Unfortunately I don't think this is the case= with domain name registries (information will be mapped differently to the= response objects).

Instead, servers could provide information to clients as it should be displ= ayed to consumers, with meta information allowing parsers to identify the i= nformation they care about. An example is below:
{
[
{ key:"Last Mod= ified", value:"2011-10-14Txx:xx:xxZ", meta:"lastChanged= Date"},
{ key:"= ;Registrant", value:"AUSREGISTRY PTY LTD"},
{ key:"= ;Registrant Contact Email", value:"noreply@ausregistry.com.au", meta:"registrant= -email"}
]
}

An alternative would be for clients to query field names from the server (u= sing HTTP caching, and header information for internationalization). An exa= mple is as follows:
GET /description/domain
Response:
{
name:"= Domain Name",
lastChangedDate:&quo= t;Last Modified",
=85
}<= /div>

Comments?=

Regards,<= /font>
James

--_000_CD5D14B81CE2Ebjeapnicnet_-- From andy@arin.net Wed Mar 6 03:37:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93121F87C4 for ; Wed, 6 Mar 2013 03:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA9SzmyQcMGH for ; Wed, 6 Mar 2013 03:37:11 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 8656721F87D2 for ; Wed, 6 Mar 2013 03:37:11 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 314391650E7; Wed, 6 Mar 2013 06:37:11 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 32D6F1650A8; Wed, 6 Mar 2013 06:37:10 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 6 Mar 2013 06:36:20 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 06:37:00 -0500 From: Andy Newton To: Chris Wright , Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYA Date: Wed, 6 Mar 2013 11:36:59 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1631@CHAXCH01.corp.arin.net> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AD1E@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <123A89B9BB6B6E4AB6D9A9F233399F41@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 11:37:12 -0000 Chris, While I may have used an emoticon, that was a serious comment. The analogous web rendering technology to XSLT for JSON is code, specifically Javascript. That being said, I'm not convinced that your issue lies in the presentation layer or with known vs. unknown tags. As Byron pointed out, your issue appears to be with the data model. If I have it right, your use case is not that much different than a proxy and/or private registration allowed by many domain registries. And perhaps we need to better address those concepts. Byron's suggestion of a "legal registrant" role appears to be the right direction, though I'd generalize it to "proxy registrant". We may also want to add a suggested status of "privacy protected". -andy On 3/5/13 5:54 PM, "Chris Wright" wrote: >Andy, > >Your response is not very helpful. We have a legitimate issue that will >prevent us from deploying WEIRDS as it stands, I think we have been clear >on it for a while (we tried to raise it way back at the start and even >voiced the concern at the session in Vancouver). We cannot rely on >clients (being external parties who write the code) knowing that the >registrant contact is not the registrant in our TLD. Code is extremely >different to XSLT, if we were using XML, my server could return the XML >and the XSLT, unless you are suggesting we return snippets of java, C >(and every other language we want to support) code as part of our WEIRDS >responses code is NOT an acceptable answer. > >I understand the goal of separating presentation from data, and honestly >I don't see including "data labels" as 'presentation' it says nothing of >the layout or anything else (and can be ignored by the clients). > >Since everyone seems against it, can someone who is clearly smarter than >us, please explain how we are to address our concern, to date everyone >seems to say no to our suggestions, but doesn't offer viable alternatives. > >Thanks > >Chris > > >-----Original Message----- >From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf >Of Andy Newton >Sent: Wednesday, 6 March 2013 7:01 AM >To: Simon Perreault; weirds@ietf.org >Subject: Re: [weirds] Client handling of known attributes/names > >On 3/5/13 9:10 AM, "Simon Perreault" wrote: > >>We must absolutely keep presentation data separate from actual data. > >+1 > >> >>If this was XML, I'd say "keep the actual data in XML, put the >>presentation information in an XSLT style sheet". >> >>What's the equivalent in JSON? >>Can we use that? > >It's called code. :) > >-andy > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From james.mitchell@ausregistry.com.au Wed Mar 6 04:16:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6377621F87E4 for ; Wed, 6 Mar 2013 04:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-nRUiofX2aY for ; Wed, 6 Mar 2013 04:16:47 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCD121F87C4 for ; Wed, 6 Mar 2013 04:16:44 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 23:16:42 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 23:16:35 +1100 From: James Mitchell To: John Levine , "weirds@ietf.org" Date: Wed, 6 Mar 2013 23:16:37 +1100 Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4aZHHVlvHnWon5TyGNEyTZ41nLlA== Message-ID: In-Reply-To: <20130305212644.18407.qmail@joyce.lan> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:16:48 -0000 Response below. On 6/03/13 8:26 AM, "John Levine" wrote: >>Section 4.2 of draft-ietf-weirds-json-response-02 says that "Clients >>processing JSON [RFC4627] >>responses SHOULD ignore values associated with unrecognized names". >> >>I do not want any client ignoring .au specific whois data in the >>response, instead (generic) >>clients that are acting on behalf of (people) users SHOULD present this >>information to the user. > >You're misunderstanding what that means. It's saying that client >software should be able to skip over fields it doesn't understand, >rather than stopping and failing. It doesn't say anything about user >interface. I don't quite agree with your comment, as later in that section is "Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning". This bugs me, as with the current WHOIS protocol servers define the meaning of all fields, and thus there is no (human) client that will not have knowledge of the meaning. How, after deployment of WEIRDS, does the client now obtain knowledge of the meaning of each field? Perhaps the text could instead say: "Clients processing JSON [RFC4627] responses SHOULD NOT treat the existence of values associated with unrecognised names as an error". And "Consider the following JSON response with JSON names, some of which are not specified in this document." If I misinterpreted the existing text then someone else may do as well? >As a bit of background, the IETF is famously, awesomely bad at >anything related to user interface, and we have learned to stay away >from it. While I agree that there are plenty of situations where it >would make sense to format unknown fields in some generic way and dump >them to the screen for the user to see, there are also plenty of >situations where it doesn't. The problem is that we are replacing WHOIS, which commingles data and its presentation, with one that is only data. I don't want another IDNA2008, where mapping was removed from the protocol only for implementers to raise their hands and fall back to IDNA2003 compatible mappings. I agree with your latter email regarding common terminology, and we can work together to get a few "extended attributes" ironed out, however there will probably be a few name registries that have something different, so what about them? There still feels like a gap in the protocol, see comment above. > >Perhaps the screen is really small (an iWatch or something) and there >isn't room to show more than a small fraction of what comes back. Or >perhaps a field is a base64 encoded PNG of a person's photo, and if a >client doesn't happen to know how to decode it, the user will see a >big block of random uninformative text, which in that case is worse >than nothing. There's no generally useful advice we can give other >than to avoid doing stupid things, but anyone who needs that advice is >unlikely to be able to follow it. I'll make sure our WEIRDS server will include base64 encoded PNGs containing an IVC that clients must decode and include in their next query ;) > >Our job is to tell clients and servers how to interoperate, not to >tell clients what to do with the data once it's decoded it. > >R's, >John > >PS: If a typical WEIRDS lookup returns a lot of fields that a typical >client doesn't understand, we won't done our job very well, either. Thanks, James > From simon.perreault@viagenie.ca Wed Mar 6 04:26:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB921F883A for ; Wed, 6 Mar 2013 04:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi09eqG4H4fB for ; Wed, 6 Mar 2013 04:26:06 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E49CF21F86F8 for ; Wed, 6 Mar 2013 04:26:05 -0800 (PST) Received: from [127.0.0.1] (unknown [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 380F340401 for ; Wed, 6 Mar 2013 07:26:05 -0500 (EST) Message-ID: <51373614.8050806@viagenie.ca> Date: Wed, 06 Mar 2013 13:27:00 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:26:06 -0000 Le 2013-03-06 13:16, James Mitchell a écrit : > How, after deployment of WEIRDS, does the client > now obtain knowledge of the meaning of each field? The same question could be asked about a ton of other protocols that allow extensibility. For example, SMTP/HTTP/SIP/... with their "X-" headers, or vCard with its "VND-" properties. The answer is always: code has to be added to the client. There's just no other way. Simon From james.mitchell@ausregistry.com.au Wed Mar 6 04:32:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921B521F8867 for ; Wed, 6 Mar 2013 04:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL9oFp+UGw8h for ; Wed, 6 Mar 2013 04:32:48 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id D9BE221F884C for ; Wed, 6 Mar 2013 04:32:47 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 23:32:46 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 23:32:39 +1100 From: James Mitchell To: Simon Perreault , "weirds@ietf.org" Date: Wed, 6 Mar 2013 23:32:40 +1100 Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4aZrBLpHWfHyugQ5SWugcEs6D7Pw== Message-ID: In-Reply-To: <51373614.8050806@viagenie.ca> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:32:49 -0000 WHOIS clients get this meaning/knowledge now writing custom code. We are suggesting a replacement to WHOIS correct? James On 6/03/13 11:27 PM, "Simon Perreault" wrote: >Le 2013-03-06 13:16, James Mitchell a =E9crit : >> How, after deployment of WEIRDS, does the client >> now obtain knowledge of the meaning of each field? > >The same question could be asked about a ton of other protocols that >allow extensibility. For example, SMTP/HTTP/SIP/... with their "X-" >headers, or vCard with its "VND-" properties. > >The answer is always: code has to be added to the client. There's just >no other way. > >Simon >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From aservin@lacnic.net Wed Mar 6 04:36:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D1021F85E7 for ; Wed, 6 Mar 2013 04:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j97qL2TAjZ61 for ; Wed, 6 Mar 2013 04:36:10 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2122721F85BB for ; Wed, 6 Mar 2013 04:36:10 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:2590:6a9d:3df:5035]) by mail.lacnic.net.uy (Postfix) with ESMTP id E4C65308427 for ; Wed, 6 Mar 2013 10:35:53 -0200 (UYST) Message-ID: <51373830.9090904@lacnic.net> Date: Wed, 06 Mar 2013 10:36:00 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:36:11 -0000 AFAIK the original idea was: "Be liberal in what you accept, and conservative in what you send." So, if the text says otherwise I think we should change it as James comments. Regards. as On 06/03/2013 10:16, James Mitchell wrote: > Response below. > > On 6/03/13 8:26 AM, "John Levine" wrote: > >>> Section 4.2 of draft-ietf-weirds-json-response-02 says that "Clients >>> processing JSON [RFC4627] >>> responses SHOULD ignore values associated with unrecognized names". >>> >>> I do not want any client ignoring .au specific whois data in the >>> response, instead (generic) >>> clients that are acting on behalf of (people) users SHOULD present this >>> information to the user. >> >> You're misunderstanding what that means. It's saying that client >> software should be able to skip over fields it doesn't understand, >> rather than stopping and failing. It doesn't say anything about user >> interface. > > I don't quite agree with your comment, as later in that section is > "Consider the following JSON response with JSON names, some of which > should be ignored by clients without knowledge of their meaning". This > bugs me, as with the current WHOIS protocol servers define the meaning of > all fields, and thus there is no (human) client that will not have > knowledge of the meaning. How, after deployment of WEIRDS, does the client > now obtain knowledge of the meaning of each field? > > Perhaps the text could instead say: > > "Clients processing JSON [RFC4627] responses SHOULD NOT treat the > existence of values associated with unrecognised names as an error". > And > "Consider the following JSON response with JSON names, some of which are > not specified in this document." > > If I misinterpreted the existing text then someone else may do as well? > > > >> As a bit of background, the IETF is famously, awesomely bad at >> anything related to user interface, and we have learned to stay away >>from it. While I agree that there are plenty of situations where it >> would make sense to format unknown fields in some generic way and dump >> them to the screen for the user to see, there are also plenty of >> situations where it doesn't. > > The problem is that we are replacing WHOIS, which commingles data and its > presentation, with one that is only data. I don't want another IDNA2008, > where mapping was removed from the protocol only for implementers to raise > their hands and fall back to IDNA2003 compatible mappings. I agree with > your latter email regarding common terminology, and we can work together > to get a few "extended attributes" ironed out, however there will probably > be a few name registries that have something different, so what about > them? There still feels like a gap in the protocol, see comment above. > >> >> Perhaps the screen is really small (an iWatch or something) and there >> isn't room to show more than a small fraction of what comes back. Or >> perhaps a field is a base64 encoded PNG of a person's photo, and if a >> client doesn't happen to know how to decode it, the user will see a >> big block of random uninformative text, which in that case is worse >> than nothing. There's no generally useful advice we can give other >> than to avoid doing stupid things, but anyone who needs that advice is >> unlikely to be able to follow it. > > I'll make sure our WEIRDS server will include base64 encoded PNGs > containing an IVC that clients must decode and include in their next query > ;) > >> >> Our job is to tell clients and servers how to interoperate, not to >> tell clients what to do with the data once it's decoded it. >> >> R's, >> John >> >> PS: If a typical WEIRDS lookup returns a lot of fields that a typical >> client doesn't understand, we won't done our job very well, either. > > Thanks, > James > > >> > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From carlosm3011@gmail.com Wed Mar 6 04:43:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513D121F84B6 for ; Wed, 6 Mar 2013 04:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5+jhuY8UJ7U for ; Wed, 6 Mar 2013 04:43:54 -0800 (PST) Received: from mail-ye0-f170.google.com (mail-ye0-f170.google.com [209.85.213.170]) by ietfa.amsl.com (Postfix) with ESMTP id C0CEE21F849A for ; Wed, 6 Mar 2013 04:43:54 -0800 (PST) Received: by mail-ye0-f170.google.com with SMTP id m15so1185296yen.29 for ; Wed, 06 Mar 2013 04:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NVEzUtsGH5tksLATu64PDpr+P81QASJTP5z+wv6xgMc=; b=UMUxjaHFQ5kV8GNnI33lXjE23E3qYlYGRiP+RNja+EF8ZWtYm5wv8cbKRpgUDP+b1W gb94rxWnuNdkh7iknex5qx7FyPMI/B7xyWPToRenzC9Rg6lcR7mt9QrpvWfVVOe5T3zF c68MElqrNHwxuqePrtctP9PlsYSvc78T7HU0mOxMeDM9iEpjiWz/pdwcIHz5zSxGks0+ b/e0J+2VTLpji0hmj8hYY6eHIa5Fm3pAZCNO2OnGETiWeW2GeNG3lHbk1lvnRMoEX0IA EqENqvN7FFh12pjz9ZF7U/XE4vaEwtiBeBqKI34s37ZXUDlvDD7x+Bs69SFAvN3ctiBF +aQw== X-Received: by 10.236.192.202 with SMTP id i50mr20632496yhn.136.1362573834371; Wed, 06 Mar 2013 04:43:54 -0800 (PST) Received: from [200.7.85.156] ([200.7.85.156]) by mx.google.com with ESMTPS id g69sm12191369yhh.17.2013.03.06.04.43.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 04:43:47 -0800 (PST) Message-ID: <51373A02.8060007@gmail.com> Date: Wed, 06 Mar 2013 10:43:46 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "weirds@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:43:56 -0000 Hi, On 3/6/13 10:32 AM, James Mitchell wrote: > WHOIS clients get this meaning/knowledge now writing custom code. We are > suggesting a replacement to WHOIS correct? Right, but I don't see how this can change. If you want all clients to understand all possible fields, then all possible fields have to be inventoried, defined, etc. If, on the other hand, we want the data model to be extensible, we are creating a situation where some clients might not be able to make sense of extended fields. This is no different than the X-* headers in several protocols. The requirement here should be something along the lines of 'first, do no harm'. If your software doesn't understand a given field, then at the very least it should not crash and burn, and, going one step further, it could provide some sort of hook where code can be inserted to deal with the unknown fields. I don't see much of a middle ground here. Either you create an inventory and standardize _every_ _possible_ _someone might want_ field (bad idea IMO), or you allow extensibility and cater for the unknown (the way to go, IMO) As far as I understand the drafts, this expected behaviour for dealing with the unknown is already well stated. regards, ~Carlos > > James > > On 6/03/13 11:27 PM, "Simon Perreault" wrote: > >> Le 2013-03-06 13:16, James Mitchell a écrit : >>> How, after deployment of WEIRDS, does the client >>> now obtain knowledge of the meaning of each field? >> >> The same question could be asked about a ton of other protocols that >> allow extensibility. For example, SMTP/HTTP/SIP/... with their "X-" >> headers, or vCard with its "VND-" properties. >> >> The answer is always: code has to be added to the client. There's just >> no other way. >> >> Simon >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From simon.perreault@viagenie.ca Wed Mar 6 04:53:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4E121F8952 for ; Wed, 6 Mar 2013 04:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od4mOLzACwzC for ; Wed, 6 Mar 2013 04:53:07 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09721F8936 for ; Wed, 6 Mar 2013 04:53:07 -0800 (PST) Received: from [127.0.0.1] (unknown [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BCFD440401; Wed, 6 Mar 2013 07:53:06 -0500 (EST) Message-ID: <51373C6B.5030802@viagenie.ca> Date: Wed, 06 Mar 2013 13:54:03 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: James Mitchell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:53:08 -0000 Le 2013-03-06 13:32, James Mitchell a écrit : > WHOIS clients get this meaning/knowledge now writing custom code. We are > suggesting a replacement to WHOIS correct? You misunderstood my point. Suppose we go with your proposal and add "field name" and "field description" strings to all non-standard element. The one day somebody defines a field with semantics such as: "When this field is present, the client shall retry its query with the ZORGLUB flag set to true." These semantics are completely new. No existing WEIRDS client could implement them. So they need extra code to understand the new extensions. There's just no other way. Simon > On 6/03/13 11:27 PM, "Simon Perreault" wrote: > >> Le 2013-03-06 13:16, James Mitchell a écrit : >>> How, after deployment of WEIRDS, does the client >>> now obtain knowledge of the meaning of each field? >> >> The same question could be asked about a ton of other protocols that >> allow extensibility. For example, SMTP/HTTP/SIP/... with their "X-" >> headers, or vCard with its "VND-" properties. >> >> The answer is always: code has to be added to the client. There's just >> no other way. >> >> Simon >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > From chris@ausregistry.com.au Wed Mar 6 04:59:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0121F86AF for ; Wed, 6 Mar 2013 04:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+fOmVDuBGwg for ; Wed, 6 Mar 2013 04:59:16 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 77EFE21F862E for ; Wed, 6 Mar 2013 04:59:12 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2013 23:59:10 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 6 Mar 2013 23:59:05 +1100 From: Chris Wright To: Andy Newton , Simon Perreault , "weirds@ietf.org" Date: Wed, 6 Mar 2013 23:59:10 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8A= Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF25@off-win2003-01.ausregistrygroup.local> References: <8CEF048B9EC83748B1517DC64EA130FB76EE44AD1E@off-win2003-01.ausregistrygroup.local> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1631@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1631@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:59:17 -0000 Thanks Andy, I think you are right, our problems are with the data model... Let me side step and discuss EPP for a moment.. EPP describes a protocol, that has inherently built into it a data model th= at its designers believed a domain name registry would use (or at least be = able to 'map to'), i.e. domain, host and contacts and the various propertie= s and relationships of/between those objects. That data model is effectively described in a mixture of the RFCs and XML S= chemas There are many examples of Registries who, for reasons that are kind of not= important to the discussion, needed to add to the data model described in = EPP, and add customer fields, or could indeed add other objects. The mechan= ism for doing this is very well defined in EPP, there is even an RFC which = describes how to extend EPP to support these changes to the data model (and= other things like new command or object mappings etc). We are searching for the similar mechanism in WEIRDS. I am certainly not ex= pecting the working group to design mappings that suit my data model, and t= hat would be silly as there are other registries with other models. What I = am looking for is explanations on how to 'extend' WEIRDS the way we can EPP= . So we need to write a draft that explains our extension and gives meaning= to the new field names that we introduce, no problem with that, but it see= ms extensibility isn't built in (or not as explicit as it is in EPP perhaps= ).=20 So Id like to see a mechanism where the base 'dictionary' is defined, and t= hen simply a 'how to' for how a 'good' implementer should describe their ad= ditional elements they add to the dictionary. I would suggest to speed thin= gs up, the base dictionary for domain names simply me based off the EPP fie= lds. Then we get to those that implement clients... a base client will understan= d the base data model defined in the WEIRDS RFCs - that's a given, then eac= h client can add the 'extensions' that they which to support (by getting ac= cess to the documentation that follows the format etc described in the 'how= to extend' part of the WEIRDS specification). So that's great :) So then we get to the behaviour when a client encounters fields it doesn't = understand - currently we say ignore them and move on.. in EPP we actually = require users to tell us which extensions they can understand when they log= in.. so we don't have these issues.. what we do have here with WEIRDS thoug= h is a single client looking to connect to many different server implementa= tions, all of which may have their own 'extensions'. We are looking for a w= ay to be able to programmatically tell the client about the extensions, so = that we don't have to rely on the offline process. Obviously that is probab= ly difficult, so the compromise we are suggesting is that if you include wi= th every data field, aside from its field-code and its value, a human reada= ble description of the field then.. it means a client can choose to: 1. implement the extensions it wants to understand as it sees fit thus sema= ntically understand each field and do with it as it pleases, based on its u= nderstanding 2. ignore fields it doesn't understand 'or' if in the case where It is simp= ly querying the data to display it to a user, display it to a user using th= e human readable description (what WhoIs does now) - this means a single si= mple implementation can work (for the purpose of human uses looking up whoi= s information) with all servers regardless of the extensions to the base da= ta model it defines Of course this doesn't help people wanting to programmatically use the data= , as they need to understand the semantic meaning of the field and would ha= ve to be 'custom' programed anyway... so not an issue Clients that don't care about the human readable description of the field c= an simply ignore that part of the response, and if we are worried about ove= rhead, put a flag in the request to specify if you want the human readable = description returned or not and default it to no.. As an aside, servers, could be given the option of honouring the request ac= cept language header and returning the human readable description of the fi= eld in the language of the client if they want to.. This solves our issue, of not requiring every WERIDS client that needs to q= uery our WEIRDS server having to read and implement our extension document,= unless of course they want to machine parse the response to do something '= useful' with it, at which point they would have to write code anyway.. The alternative, as I have said above, is we come up with a way that the pr= otocol allows servers to communicate 'extensions' to the data model to the = client, however I'm not really sure that is possible as you couldn't send '= semantic' meaning in the context of the objects registry. So really all the= extension would communicate is 'field-name', 'field human readable descrip= tor' anyway. This seems to make the most sense to me, and is the most 'compatible' solut= ion, and frankly I don't understand the arguments against doing it - it cer= tainly isn't presentation. Thanks Chris -----Original Message----- From: Andy Newton [mailto:andy@arin.net]=20 Sent: Wednesday, 6 March 2013 10:37 PM To: Chris Wright; Simon Perreault; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names Chris, While I may have used an emoticon, that was a serious comment. The analogou= s web rendering technology to XSLT for JSON is code, specifically Javascrip= t. That being said, I'm not convinced that your issue lies in the presentation= layer or with known vs. unknown tags. As Byron pointed out, your issue app= ears to be with the data model. If I have it right, your use case is not th= at much different than a proxy and/or private registration allowed by many = domain registries. And perhaps we need to better address those concepts. Byron's suggestion of a "legal registrant" role appears to be the right dir= ection, though I'd generalize it to "proxy registrant". We may also want to= add a suggested status of "privacy protected". -andy On 3/5/13 5:54 PM, "Chris Wright" wrote: >Andy, > >Your response is not very helpful. We have a legitimate issue that will=20 >prevent us from deploying WEIRDS as it stands, I think we have been=20 >clear on it for a while (we tried to raise it way back at the start and=20 >even voiced the concern at the session in Vancouver). We cannot rely on=20 >clients (being external parties who write the code) knowing that the=20 >registrant contact is not the registrant in our TLD. Code is extremely=20 >different to XSLT, if we were using XML, my server could return the XML=20 >and the XSLT, unless you are suggesting we return snippets of java, C=20 >(and every other language we want to support) code as part of our=20 >WEIRDS responses code is NOT an acceptable answer. > >I understand the goal of separating presentation from data, and=20 >honestly I don't see including "data labels" as 'presentation' it says=20 >nothing of the layout or anything else (and can be ignored by the clients)= . > >Since everyone seems against it, can someone who is clearly smarter=20 >than us, please explain how we are to address our concern, to date=20 >everyone seems to say no to our suggestions, but doesn't offer viable alte= rnatives. > >Thanks > >Chris > > >-----Original Message----- >From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On=20 >Behalf Of Andy Newton >Sent: Wednesday, 6 March 2013 7:01 AM >To: Simon Perreault; weirds@ietf.org >Subject: Re: [weirds] Client handling of known attributes/names > >On 3/5/13 9:10 AM, "Simon Perreault" wrote: > >>We must absolutely keep presentation data separate from actual data. > >+1 > >> >>If this was XML, I'd say "keep the actual data in XML, put the=20 >>presentation information in an XSLT style sheet". >> >>What's the equivalent in JSON? >>Can we use that? > >It's called code. :) > >-andy > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From james.mitchell@ausregistry.com.au Wed Mar 6 05:20:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190F21F86A6 for ; Wed, 6 Mar 2013 05:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOoCqYyujqdr for ; Wed, 6 Mar 2013 05:20:34 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2016E21F84DC for ; Wed, 6 Mar 2013 05:20:32 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 00:20:28 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 00:20:22 +1100 From: James Mitchell To: Andy Newton , Chris Wright , Simon Perreault , "weirds@ietf.org" Date: Thu, 7 Mar 2013 00:20:24 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4abVqIgIk1tKIfTvSPoT4l0OsKdg== Message-ID: In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1631@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:20:35 -0000 Andy, Byron, I'm feeling better about where this is going. So in our case we would use the registrant contact as the proxy (as this contact is acting on behalf of the legal registrant to authorise transfers etc) and our "Registrant" field would represent the name of the (legal) registrant. I'd have to check with our policy guys how they would feel about the change in terminology but it should work. Confusion of the registrant name however was only one concern. Secondary to this is our current WHOIS output identifies how the the legal registrant claims they are eligible for the domain name. This information may include (depending on the registration): { - Registrant: Legal name of the registrant entity (eg. company name) - Registrant ID: ID number associated with the registrant entity, if any (eg. ACN for company) - Eligibility Type: Registrant's eligibility type (eg. "Company") - Eligibility Name: Name used by the registrant to establish eligibility, if different from their own legal name (eg. registered business name or trademark) - Eligibility ID: ID number associated with the name used by the registrant to establish eligibility (eg. BN for registered business name, TM number for registered trademark) } However, eligibility information will probably vary from registry to registry, from business numbers to trademarks, or professional accreditation identifiers, or to no eligibility requirements. Obviously the consumer of this information is no "ordinary" person; they'd need the contextual information that identifies the (fictitious) number 123456789 as an Australian Business Number, and they'd have to know how that tied in with the registry's eligibility policy. However this information SHOULD be available to the layperson, and I'm concerned they won't get it through generic WEIRDS clients, at least those without "hooks" for every registry. I still think there is room for clients to obtain this descriptive information from servers, not for the core fields, in the absence of specific client side knowledge. I'm still happy with GET /description/ Response: { _field:{display_name:"Eligibility Name", description:"Name used by the registrant to establish eligibility, if different from their own legal name (eg. registered business name or trademark)"} } Do people still have reservations for this approach? Thanks, James On 6/03/13 10:36 PM, "Andy Newton" wrote: >Chris, > >While I may have used an emoticon, that was a serious comment. The >analogous web rendering technology to XSLT for JSON is code, specifically >Javascript. > >That being said, I'm not convinced that your issue lies in the >presentation layer or with known vs. unknown tags. As Byron pointed out, >your issue appears to be with the data model. If I have it right, your use >case is not that much different than a proxy and/or private registration >allowed by many domain registries. And perhaps we need to better address >those concepts. > >Byron's suggestion of a "legal registrant" role appears to be the right >direction, though I'd generalize it to "proxy registrant". We may also >want to add a suggested status of "privacy protected". > >-andy > >On 3/5/13 5:54 PM, "Chris Wright" wrote: > >>Andy, >> >>Your response is not very helpful. We have a legitimate issue that will >>prevent us from deploying WEIRDS as it stands, I think we have been clear >>on it for a while (we tried to raise it way back at the start and even >>voiced the concern at the session in Vancouver). We cannot rely on >>clients (being external parties who write the code) knowing that the >>registrant contact is not the registrant in our TLD. Code is extremely >>different to XSLT, if we were using XML, my server could return the XML >>and the XSLT, unless you are suggesting we return snippets of java, C >>(and every other language we want to support) code as part of our WEIRDS >>responses code is NOT an acceptable answer. >> >>I understand the goal of separating presentation from data, and honestly >>I don't see including "data labels" as 'presentation' it says nothing of >>the layout or anything else (and can be ignored by the clients). >> >>Since everyone seems against it, can someone who is clearly smarter than >>us, please explain how we are to address our concern, to date everyone >>seems to say no to our suggestions, but doesn't offer viable >>alternatives. >> >>Thanks >> >>Chris >> >> >>-----Original Message----- >>From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf >>Of Andy Newton >>Sent: Wednesday, 6 March 2013 7:01 AM >>To: Simon Perreault; weirds@ietf.org >>Subject: Re: [weirds] Client handling of known attributes/names >> >>On 3/5/13 9:10 AM, "Simon Perreault" wrote: >> >>>We must absolutely keep presentation data separate from actual data. >> >>+1 >> >>> >>>If this was XML, I'd say "keep the actual data in XML, put the >>>presentation information in an XSLT style sheet". >>> >>>What's the equivalent in JSON? >>>Can we use that? >> >>It's called code. :) >> >>-andy >> >>_______________________________________________ >>weirds mailing list >>weirds@ietf.org >>https://www.ietf.org/mailman/listinfo/weirds >> > > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From james.mitchell@ausregistry.com.au Wed Mar 6 05:26:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991C921F88C1 for ; Wed, 6 Mar 2013 05:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7ZD0F260HN9 for ; Wed, 6 Mar 2013 05:26:04 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id B65A421F88B1 for ; Wed, 6 Mar 2013 05:26:03 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 00:26:02 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 00:25:56 +1100 From: James Mitchell To: "carlos@lacnic.net" , "weirds@ietf.org" Date: Thu, 7 Mar 2013 00:25:58 +1100 Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4abiHh+cgVb+I4Q3e6PeGfzHWtHg== Message-ID: In-Reply-To: <51373A02.8060007@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:26:04 -0000 Carlos, On 6/03/13 11:43 PM, "Carlos M. Martinez" wrote: >Hi, > >On 3/6/13 10:32 AM, James Mitchell wrote: >> WHOIS clients get this meaning/knowledge now writing custom code. We are >> suggesting a replacement to WHOIS correct? > >Right, but I don't see how this can change. If you want all clients to >understand all possible fields, then all possible fields have to be >inventoried, defined, etc. > >If, on the other hand, we want the data model to be extensible, we are >creating a situation where some clients might not be able to make sense >of extended fields. > >This is no different than the X-* headers in several protocols. The >requirement here should be something along the lines of 'first, do no >harm'. If your software doesn't understand a given field, then at the >very least it should not crash and burn, and, going one step further, it >could provide some sort of hook where code can be inserted to deal with >the unknown fields. > >I don't see much of a middle ground here. Either you create an inventory >and standardize _every_ _possible_ _someone might want_ field (bad idea >IMO), or you allow extensibility and cater for the unknown (the way to >go, IMO) I completely agree that we do not want to standardise every possible field. However we have two very distinct classes of clients, software-centric (e.g. determine spam score) and human-centric (e.g. present to a user). A software-centric client will parse and pick out the pieces it wants; if it wants a field specific to my registry then it already knows its meaning. I am confident that the approach taken to date will work for 100% of software clients. However humans generally don't prefer X- headers, looking at XML, or JSON names. Sure they'll eventually get used to it but is that what we want? Why do the human-centric clients have to write custom mappings/hooks/code to correctly present the response to their users? Sure, some human users may only care about the creation date, but some will care about the information for which there is no hook defined. If we want client software to have a hook for each registry then lets do it, however I think this is a bad idea. I'd rather generics client are able to be more generic, and servers are able to be more specific if possible. Refer to my email in response to Andy/Byron. > >As far as I understand the drafts, this expected behaviour for dealing >with the unknown is already well stated. > >regards, > >~Carlos Regards, James From james.mitchell@ausregistry.com.au Wed Mar 6 05:29:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B47E21F84E7 for ; Wed, 6 Mar 2013 05:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ZaEUdg0qN9 for ; Wed, 6 Mar 2013 05:29:16 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E021F84E6 for ; Wed, 6 Mar 2013 05:29:15 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 00:29:12 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 00:29:06 +1100 From: James Mitchell To: Simon Perreault Date: Thu, 7 Mar 2013 00:29:09 +1100 Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4abpNT0HhdidxISzCEvd49gAg57A== Message-ID: In-Reply-To: <51373C6B.5030802@viagenie.ca> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:29:16 -0000 If that was your point then we are in agreement :) Thanks, James On 6/03/13 11:54 PM, "Simon Perreault" wrote: >Le 2013-03-06 13:32, James Mitchell a =E9crit : >> WHOIS clients get this meaning/knowledge now writing custom code. We are >> suggesting a replacement to WHOIS correct? > >You misunderstood my point. > >Suppose we go with your proposal and add "field name" and "field >description" strings to all non-standard element. > >The one day somebody defines a field with semantics such as: "When this >field is present, the client shall retry its query with the ZORGLUB flag >set to true." > >These semantics are completely new. No existing WEIRDS client could >implement them. So they need extra code to understand the new >extensions. There's just no other way. > >Simon > >> On 6/03/13 11:27 PM, "Simon Perreault" >>wrote: >> >>> Le 2013-03-06 13:16, James Mitchell a =E9crit : >>>> How, after deployment of WEIRDS, does the client >>>> now obtain knowledge of the meaning of each field? >>> >>> The same question could be asked about a ton of other protocols that >>> allow extensibility. For example, SMTP/HTTP/SIP/... with their "X-" >>> headers, or vCard with its "VND-" properties. >>> >>> The answer is always: code has to be added to the client. There's just >>> no other way. >>> >>> Simon >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >> > From andy@arin.net Wed Mar 6 05:37:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B667821F8754 for ; Wed, 6 Mar 2013 05:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFbyf9Hu1vCW for ; Wed, 6 Mar 2013 05:37:37 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id CE08221F871F for ; Wed, 6 Mar 2013 05:37:36 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 733F6165247; Wed, 6 Mar 2013 08:37:36 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9DD4716523C; Wed, 6 Mar 2013 08:37:35 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 6 Mar 2013 08:37:23 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 08:37:33 -0500 From: Andy Newton To: Chris Wright , Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8AAAm0nAA== Date: Wed, 6 Mar 2013 13:37:29 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF16C1@CHAXCH01.corp.arin.net> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF25@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <434D8FDC7335134894F3A8CDE3A27BEE@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:37:37 -0000 Chris, I strenuously disagree with your assertion that extensibility is not built into RDAP. There is a mechanism for including custom JSON values, adding custom URL paths, registering customizations in an IANA registry, and noting the extensions by id in the root object of the JSON response. What you are asking for is not extensibility of the protocol but extensibility of the clients. While admirable, I think such an endeavor is beyond the scope of this working group. Client understanding is not just about a display descriptions, especially for rich data. As many have already said, clients need to be updated. -andy On 3/6/13 7:59 AM, "Chris Wright" wrote: >Thanks Andy, > >I think you are right, our problems are with the data model... > >Let me side step and discuss EPP for a moment.. > >EPP describes a protocol, that has inherently built into it a data model >that its designers believed a domain name registry would use (or at least >be able to 'map to'), i.e. domain, host and contacts and the various >properties and relationships of/between those objects. > >That data model is effectively described in a mixture of the RFCs and XML >Schemas > >There are many examples of Registries who, for reasons that are kind of >not important to the discussion, needed to add to the data model >described in EPP, and add customer fields, or could indeed add other >objects. The mechanism for doing this is very well defined in EPP, there >is even an RFC which describes how to extend EPP to support these changes >to the data model (and other things like new command or object mappings >etc). > >We are searching for the similar mechanism in WEIRDS. I am certainly not >expecting the working group to design mappings that suit my data model, >and that would be silly as there are other registries with other models. >What I am looking for is explanations on how to 'extend' WEIRDS the way >we can EPP. So we need to write a draft that explains our extension and >gives meaning to the new field names that we introduce, no problem with >that, but it seems extensibility isn't built in (or not as explicit as it >is in EPP perhaps). > >So Id like to see a mechanism where the base 'dictionary' is defined, and >then simply a 'how to' for how a 'good' implementer should describe their >additional elements they add to the dictionary. I would suggest to speed >things up, the base dictionary for domain names simply me based off the >EPP fields. > >Then we get to those that implement clients... a base client will >understand the base data model defined in the WEIRDS RFCs - that's a >given, then each client can add the 'extensions' that they which to >support (by getting access to the documentation that follows the format >etc described in the 'how to extend' part of the WEIRDS specification). >So that's great :) > >So then we get to the behaviour when a client encounters fields it >doesn't understand - currently we say ignore them and move on.. in EPP we >actually require users to tell us which extensions they can understand >when they login.. so we don't have these issues.. what we do have here >with WEIRDS though is a single client looking to connect to many >different server implementations, all of which may have their own >'extensions'. We are looking for a way to be able to programmatically >tell the client about the extensions, so that we don't have to rely on >the offline process. Obviously that is probably difficult, so the >compromise we are suggesting is that if you include with every data >field, aside from its field-code and its value, a human readable >description of the field then.. it means a client can choose to: > >1. implement the extensions it wants to understand as it sees fit thus >semantically understand each field and do with it as it pleases, based on >its understanding >2. ignore fields it doesn't understand 'or' if in the case where It is >simply querying the data to display it to a user, display it to a user >using the human readable description (what WhoIs does now) - this means a >single simple implementation can work (for the purpose of human uses >looking up whois information) with all servers regardless of the >extensions to the base data model it defines > >Of course this doesn't help people wanting to programmatically use the >data, as they need to understand the semantic meaning of the field and >would have to be 'custom' programed anyway... so not an issue > >Clients that don't care about the human readable description of the field >can simply ignore that part of the response, and if we are worried about >overhead, put a flag in the request to specify if you want the human >readable description returned or not and default it to no.. > >As an aside, servers, could be given the option of honouring the request >accept language header and returning the human readable description of >the field in the language of the client if they want to.. > >This solves our issue, of not requiring every WERIDS client that needs to >query our WEIRDS server having to read and implement our extension >document, unless of course they want to machine parse the response to do >something 'useful' with it, at which point they would have to write code >anyway.. > >The alternative, as I have said above, is we come up with a way that the >protocol allows servers to communicate 'extensions' to the data model to >the client, however I'm not really sure that is possible as you couldn't >send 'semantic' meaning in the context of the objects registry. So really >all the extension would communicate is 'field-name', 'field human >readable descriptor' anyway. > >This seems to make the most sense to me, and is the most 'compatible' >solution, and frankly I don't understand the arguments against doing it - >it certainly isn't presentation. > >Thanks > >Chris From simon.perreault@viagenie.ca Wed Mar 6 05:42:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9119D21F897F for ; Wed, 6 Mar 2013 05:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzzrJZtJjdB7 for ; Wed, 6 Mar 2013 05:42:23 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 748B321F8934 for ; Wed, 6 Mar 2013 05:42:19 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:89ce:677:fab:b4b1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 52BD240401; Wed, 6 Mar 2013 08:41:48 -0500 (EST) Message-ID: <513747D3.3060208@viagenie.ca> Date: Wed, 06 Mar 2013 14:42:43 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: James Mitchell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:42:23 -0000 James, Chris, I feel like we're talking past each other. So I'll only ask questions this time. Le 2013-03-06 14:20, James Mitchell a écrit : > I'm still happy with > GET /description/ > Response: > { > _field:{display_name:"Eligibility Name", description:"Name used > by the registrant to establish eligibility, if different from their own > legal name (eg. registered business name or trademark)"} > } Suppose you define "au_foobar". It gets popular and other registries implement it. You and other registries get together and write an RFC to standardize "foobar" (no prefix). The RFC gets published, everyone's happy. Now, I suppose "foobar" would no longer have "display_name" or "description" since it's a standard field. Right? In that case, what is a WEIRDS client that has not yet implemented your RFC supposed to do when it receives that unknown "foobar" field? Is your proposal related to only _something fields, or does it concern everything except the fields defined in the base spec? Simon From chris@ausregistry.com.au Wed Mar 6 05:51:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF321F89C0 for ; Wed, 6 Mar 2013 05:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXVS3Z2XRzJ6 for ; Wed, 6 Mar 2013 05:51:59 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 097E121F89E2 for ; Wed, 6 Mar 2013 05:51:57 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 00:51:56 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 00:51:50 +1100 From: Chris Wright To: Andy Newton , Simon Perreault , "weirds@ietf.org" Date: Thu, 7 Mar 2013 00:51:55 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8AAAm0nAAAAIiNw Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF30@off-win2003-01.ausregistrygroup.local> References: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF25@off-win2003-01.ausregistrygroup.local> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF16C1@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF16C1@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:51:59 -0000 Sorry Andy, I retract that it isn't built in... bad use of wording on my pa= rt for the first part of the email... > Client understanding is not just about a display descriptions, especially= for rich data. As many have already said, clients need to be updated. I agree that clients that are trying to 'do' something programmatically wit= h the data, of course have to be updated, but clients that simply 'display'= the data shouldn't need to be updated, they don't need to be updated with = WhoIs right now.. it's a backwards step from that perspective...=20 It feels like we are not designing a replacement for WhoIs but rather somet= hing that achieves an entirely different purpose, something that is to be u= sed alongside it.. maybe that was the goal from the start and I have misgui= ded myself..=20 Thanks Chris -----Original Message----- From: Andy Newton [mailto:andy@arin.net]=20 Sent: Thursday, 7 March 2013 12:37 AM To: Chris Wright; Simon Perreault; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names Chris, I strenuously disagree with your assertion that extensibility is not built = into RDAP. There is a mechanism for including custom JSON values, adding cu= stom URL paths, registering customizations in an IANA registry, and noting = the extensions by id in the root object of the JSON response. What you are asking for is not extensibility of the protocol but extensibil= ity of the clients. While admirable, I think such an endeavor is beyond the= scope of this working group. Client understanding is not just about a disp= lay descriptions, especially for rich data. As many have already said, clie= nts need to be updated. -andy On 3/6/13 7:59 AM, "Chris Wright" wrote: >Thanks Andy, > >I think you are right, our problems are with the data model... > >Let me side step and discuss EPP for a moment.. > >EPP describes a protocol, that has inherently built into it a data=20 >model that its designers believed a domain name registry would use (or=20 >at least be able to 'map to'), i.e. domain, host and contacts and the=20 >various properties and relationships of/between those objects. > >That data model is effectively described in a mixture of the RFCs and=20 >XML Schemas > >There are many examples of Registries who, for reasons that are kind of=20 >not important to the discussion, needed to add to the data model=20 >described in EPP, and add customer fields, or could indeed add other=20 >objects. The mechanism for doing this is very well defined in EPP,=20 >there is even an RFC which describes how to extend EPP to support these=20 >changes to the data model (and other things like new command or object=20 >mappings etc). > >We are searching for the similar mechanism in WEIRDS. I am certainly=20 >not expecting the working group to design mappings that suit my data=20 >model, and that would be silly as there are other registries with other mo= dels. >What I am looking for is explanations on how to 'extend' WEIRDS the way=20 >we can EPP. So we need to write a draft that explains our extension and=20 >gives meaning to the new field names that we introduce, no problem with=20 >that, but it seems extensibility isn't built in (or not as explicit as=20 >it is in EPP perhaps). > >So Id like to see a mechanism where the base 'dictionary' is defined,=20 >and then simply a 'how to' for how a 'good' implementer should describe=20 >their additional elements they add to the dictionary. I would suggest=20 >to speed things up, the base dictionary for domain names simply me=20 >based off the EPP fields. > >Then we get to those that implement clients... a base client will=20 >understand the base data model defined in the WEIRDS RFCs - that's a=20 >given, then each client can add the 'extensions' that they which to=20 >support (by getting access to the documentation that follows the format=20 >etc described in the 'how to extend' part of the WEIRDS specification). >So that's great :) > >So then we get to the behaviour when a client encounters fields it=20 >doesn't understand - currently we say ignore them and move on.. in EPP=20 >we actually require users to tell us which extensions they can=20 >understand when they login.. so we don't have these issues.. what we do=20 >have here with WEIRDS though is a single client looking to connect to=20 >many different server implementations, all of which may have their own=20 >'extensions'. We are looking for a way to be able to programmatically=20 >tell the client about the extensions, so that we don't have to rely on=20 >the offline process. Obviously that is probably difficult, so the=20 >compromise we are suggesting is that if you include with every data=20 >field, aside from its field-code and its value, a human readable=20 >description of the field then.. it means a client can choose to: > >1. implement the extensions it wants to understand as it sees fit thus=20 >semantically understand each field and do with it as it pleases, based=20 >on its understanding 2. ignore fields it doesn't understand 'or' if in=20 >the case where It is simply querying the data to display it to a user,=20 >display it to a user using the human readable description (what WhoIs=20 >does now) - this means a single simple implementation can work (for the=20 >purpose of human uses looking up whois information) with all servers=20 >regardless of the extensions to the base data model it defines > >Of course this doesn't help people wanting to programmatically use the=20 >data, as they need to understand the semantic meaning of the field and=20 >would have to be 'custom' programed anyway... so not an issue > >Clients that don't care about the human readable description of the=20 >field can simply ignore that part of the response, and if we are=20 >worried about overhead, put a flag in the request to specify if you=20 >want the human readable description returned or not and default it to no.. > >As an aside, servers, could be given the option of honouring the=20 >request accept language header and returning the human readable=20 >description of the field in the language of the client if they want to.. > >This solves our issue, of not requiring every WERIDS client that needs=20 >to query our WEIRDS server having to read and implement our extension=20 >document, unless of course they want to machine parse the response to=20 >do something 'useful' with it, at which point they would have to write=20 >code anyway.. > >The alternative, as I have said above, is we come up with a way that=20 >the protocol allows servers to communicate 'extensions' to the data=20 >model to the client, however I'm not really sure that is possible as=20 >you couldn't send 'semantic' meaning in the context of the objects=20 >registry. So really all the extension would communicate is=20 >'field-name', 'field human readable descriptor' anyway. > >This seems to make the most sense to me, and is the most 'compatible' >solution, and frankly I don't understand the arguments against doing it=20 >- it certainly isn't presentation. > >Thanks > >Chris From chris@ausregistry.com.au Wed Mar 6 05:55:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B4D21F8740 for ; Wed, 6 Mar 2013 05:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtWyfphez774 for ; Wed, 6 Mar 2013 05:55:56 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6718F21F8726 for ; Wed, 6 Mar 2013 05:55:56 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 00:55:55 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 00:55:49 +1100 From: Chris Wright To: Simon Perreault , James Mitchell Date: Thu, 7 Mar 2013 00:55:54 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4acFg4dzJd4jAhRjS/7rDF2mqn3gAAYUng Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF31@off-win2003-01.ausregistrygroup.local> References: <513747D3.3060208@viagenie.ca> In-Reply-To: <513747D3.3060208@viagenie.ca> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:55:57 -0000 I have two possible solutions... One is everything except the base spec... The second is, why not everything.. What if instead of putting the information in the object response, every se= rver had a dictionary URL... (or some other word which describes it better)= . Something like... http://weirds.server/weirds/dictionary and that returned a JSON structure something like.... { fields: { field: { code: "domain-name", name: "Domain Name", description: "The nam= e of the domain name"}, field: { code: "registrant-contact", name: "Registrant Contact Name", de= scription: "the registrant contact name"}, etc the rest of the base protocol fields that this server uses } extensions-fields: { field: { code:"elgibility-id", name: "Elgibility ID", description: "The = ABN/CAN of the blah blah" }, etc } } Where fields array contains the base protocol fields... and then the extens= ion fields are the fields of extensions supported by the server? Thanks Chris -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Sent: Thursday, 7 March 2013 12:43 AM To: James Mitchell Cc: Andy Newton; Chris Wright; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names James, Chris, I feel like we're talking past each other. So I'll only ask questions this = time. Le 2013-03-06 14:20, James Mitchell a =E9crit : > I'm still happy with > GET /description/ > Response: > { > _field:{display_name:"Eligibility Name", description:"Name=20 > used by the registrant to establish eligibility, if different from=20 > their own legal name (eg. registered business name or trademark)"} } Suppose you define "au_foobar". It gets popular and other registries implem= ent it. You and other registries get together and write an RFC to standardi= ze "foobar" (no prefix). The RFC gets published, everyone's happy. Now, I suppose "foobar" would no longer have "display_name" or "description= " since it's a standard field. Right? In that case, what is a WEIRDS client that has not yet implemented your RFC= supposed to do when it receives that unknown "foobar" field? Is your proposal related to only _something fields, or does it conc= ern everything except the fields defined in the base spec? Simon From andy@arin.net Wed Mar 6 06:01:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08221F868B for ; Wed, 6 Mar 2013 06:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1-L9iLP69zW for ; Wed, 6 Mar 2013 06:01:34 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9621F85FC for ; Wed, 6 Mar 2013 06:01:25 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 84E77165263; Wed, 6 Mar 2013 09:01:25 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 4F4BC16523C; Wed, 6 Mar 2013 09:01:24 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 6 Mar 2013 09:00:41 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 09:01:22 -0500 From: Andy Newton To: James Mitchell , Chris Wright , Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAA4W+QD//7ebAA== Date: Wed, 6 Mar 2013 14:01:21 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF16EF@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:01:35 -0000 James, My comments are in-line: On 3/6/13 8:20 AM, "James Mitchell" wrote: >Confusion of the registrant name however was only one concern. Secondary >to this is our current WHOIS output identifies how the the legal >registrant claims they are eligible for the domain name. This information >may include (depending on the registration): >{ >- Registrant: Legal name of the registrant entity (eg. company name) >- Registrant ID: ID number associated with the registrant entity, if any >(eg. ACN for company) >- Eligibility Type: Registrant's eligibility type (eg. "Company") >- Eligibility Name: Name used by the registrant to establish eligibility, >if different from their own legal name (eg. registered business name or >trademark) >- Eligibility ID: ID number associated with the name used by the >registrant to establish eligibility (eg. BN for registered business name, >TM number for registered trademark) >} > >However, eligibility information will probably vary from registry to >registry, from business numbers to trademarks, or professional >accreditation identifiers, or to no eligibility requirements. Obviously >the consumer of this information is no "ordinary" person; they'd need the >contextual information that identifies the (fictitious) number 123456789 >as an Australian Business Number, and they'd have to know how that tied in >with the registry's eligibility policy. However this information SHOULD be >available to the layperson, and I'm concerned they won't get it through >generic WEIRDS clients, at least those without "hooks" for every registry. >I still think there is room for clients to obtain this descriptive >information from servers, not for the core fields, in the absence of >specific client side knowledge. I would agree that eligibility information would be different from one registry to another. There are three approaches that I see: 1) implement custom values for your registry, 2) develop a unified eligibility / rights-holding data model for all registries, or 3) use a link relationship to link to a web page specific to your registry. For #2, if you did this you could develop the model and publish it as an IETF standard that could be added on to RDAP. The mechanics of that seem easy. The hard part would be getting everybody to agree on the data model for expressing the holding of rights to internet resources. For #3, you could use the link relationship of terms-of-service (see http://tools.ietf.org/html/draft-ietf-weirds-json-response-02#section-6) or perhaps register your own link relationship with the IANA. >I'm still happy with >GET /description/ >Response: >{ > _field:{display_name:"Eligibility Name", description:"Name used >by the registrant to establish eligibility, if different from their own >legal name (eg. registered business name or trademark)"} >} > >Do people still have reservations for this approach? In my opinion, you'll end up replicating all the presentation layer semantics of a web page if you go down this path. Its easier just to use a web page vs. replicating those features. This fits into the link relationship mentioned above. -andy From chris@ausregistry.com.au Wed Mar 6 06:03:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8700A21F88E2 for ; Wed, 6 Mar 2013 06:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4IkQPaUgZJe for ; Wed, 6 Mar 2013 06:03:24 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id B0BF421F88BF for ; Wed, 6 Mar 2013 06:03:23 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 01:03:21 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 01:03:15 +1100 From: Chris Wright To: Chris Wright , Simon Perreault , James Mitchell Date: Thu, 7 Mar 2013 01:03:20 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4acFg4dzJd4jAhRjS/7rDF2mqn3gAAYUngAABOoyA= Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF33@off-win2003-01.ausregistrygroup.local> References: <513747D3.3060208@viagenie.ca> <8CEF048B9EC83748B1517DC64EA130FB76EE44AF31@off-win2003-01.ausregistrygroup.local> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF31@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:03:24 -0000 Just to expand on this.. there may need to be a dictionary per object.. or = something else.. the idea needs to be expanded more... and could be the sub= ject of another draft (which we would be more than happy to volunteer to au= thor)... It could be cached and clients could use standard http mechanisms like If-m= odified etc to make sure they have latest versions and so forth.. Thanks Chris -----Original Message----- From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Chris Wright Sent: Thursday, 7 March 2013 12:56 AM To: Simon Perreault; James Mitchell Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names I have two possible solutions... One is everything except the base spec... The second is, why not everything.. What if instead of putting the information in the object response, every se= rver had a dictionary URL... (or some other word which describes it better)= . Something like... http://weirds.server/weirds/dictionary and that returned a JSON structure something like.... { fields: { field: { code: "domain-name", name: "Domain Name", description: "The nam= e of the domain name"}, field: { code: "registrant-contact", name: "Registrant Contact Name", de= scription: "the registrant contact name"}, etc the rest of the base protocol fields that this server uses } extensions-fields: { field: { code:"elgibility-id", name: "Elgibility ID", description: "The = ABN/CAN of the blah blah" }, etc } } Where fields array contains the base protocol fields... and then the extens= ion fields are the fields of extensions supported by the server? Thanks Chris -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca] Sent: Thursday, 7 March 2013 12:43 AM To: James Mitchell Cc: Andy Newton; Chris Wright; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names James, Chris, I feel like we're talking past each other. So I'll only ask questions this = time. Le 2013-03-06 14:20, James Mitchell a =E9crit : > I'm still happy with > GET /description/ > Response: > { > _field:{display_name:"Eligibility Name", description:"Name=20 > used by the registrant to establish eligibility, if different from=20 > their own legal name (eg. registered business name or trademark)"} } Suppose you define "au_foobar". It gets popular and other registries implem= ent it. You and other registries get together and write an RFC to standardi= ze "foobar" (no prefix). The RFC gets published, everyone's happy. Now, I suppose "foobar" would no longer have "display_name" or "description= " since it's a standard field. Right? In that case, what is a WEIRDS client that has not yet implemented your RFC= supposed to do when it receives that unknown "foobar" field? Is your proposal related to only _something fields, or does it conc= ern everything except the fields defined in the base spec? Simon _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Wed Mar 6 06:24:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF121F8622 for ; Wed, 6 Mar 2013 06:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qShRh1RMQyd for ; Wed, 6 Mar 2013 06:24:23 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2AA21F852A for ; Wed, 6 Mar 2013 06:24:18 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id E16D1165278; Wed, 6 Mar 2013 09:24:17 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 7950C165271; Wed, 6 Mar 2013 09:24:17 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 6 Mar 2013 09:23:34 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 09:24:15 -0500 From: Andy Newton To: Chris Wright , Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8AAAm0nAAAAIiNwAAF/14A= Date: Wed, 6 Mar 2013 14:24:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1717@CHAXCH01.corp.arin.net> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF30@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <30A8300329A2664D9245044265C12AA9@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:24:24 -0000 On 3/6/13 8:51 AM, "Chris Wright" wrote: >I agree that clients that are trying to 'do' something programmatically >with the data, of course have to be updated, but clients that simply >'display' the data shouldn't need to be updated, they don't need to be >updated with WhoIs right now.. it's a backwards step from that >perspective... Display can mean a lot of things. As was mentioned earlier in the thread, what about a base64 encoded PNG? More realistically, what about JSON values that arrays or nested objects? Simple display descriptions don't help there. Not to mention that your idea of a display string might not be very useful to anybody who doesn't speak your language. >It feels like we are not designing a replacement for WhoIs but rather >something that achieves an entirely different purpose, something that is >to be used alongside it.. maybe that was the goal from the start and I >have misguided myself.. Well, we have no plans to shut down our port 43 service even though it receives less traffic than our RESTful service (imagine how much more RESTful traffic we'll get when we become RDAP compatible). Right now our port 43 service is simply a presentation of our RESTful service as it is a simple proxy. I anticipate a lot of registries will head down that path. -andy From chris@ausregistry.com.au Wed Mar 6 06:51:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD911E80FD for ; Wed, 6 Mar 2013 06:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwZy1xIuDhjh for ; Wed, 6 Mar 2013 06:51:30 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BA21F8AA0 for ; Wed, 6 Mar 2013 06:51:21 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 07 Mar 2013 01:51:20 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 7 Mar 2013 01:51:14 +1100 From: Chris Wright To: Andy Newton , Simon Perreault , "weirds@ietf.org" Date: Thu, 7 Mar 2013 01:51:19 +1100 Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8AAAm0nAAAAIiNwAAF/14AAAGEnYA== Message-ID: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF35@off-win2003-01.ausregistrygroup.local> References: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF30@off-win2003-01.ausregistrygroup.local> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1717@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1717@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:51:30 -0000 -----Original Message----- From: Andy Newton [mailto:andy@arin.net]=20 Sent: Thursday, 7 March 2013 1:24 AM To: Chris Wright; Simon Perreault; weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names >On 3/6/13 8:51 AM, "Chris Wright" wrote: >>I agree that clients that are trying to 'do' something programmatically=20 >>with the data, of course have to be updated, but clients that simply=20 >>'display' the data shouldn't need to be updated, they don't need to be=20 >>updated with WhoIs right now.. it's a backwards step from that=20 >>perspective... >Display can mean a lot of things. As was mentioned earlier in the thread, = what about a base64 encoded PNG? More realistically, what about JSON values= that arrays or nested objects? Simple display descriptions don't help ther= e. Not to mention that your idea of a display string might not be very usef= ul to anybody who doesn't speak your language. Wouldn't this then mean that putting the descriptor information inline with= the object response is the way to go then? (of course that assumes you agr= ee that the descriptor information is required in the first place) If we were using XML, then the 'dictionary' could just return the XSLT and = we wouldn't have a problem with arrays and nested objects... (though dictio= nary would be a really bad name for it at that point) So another suggestions are allowing a text mime type to be supported where = we would return text documents that provide the information in the format s= imilar to the current WhoIs, so a 'generic' WEIRDS client can just do text = mime queries - I think we have suggested this before.. Also, on languages, HTTP already has a mechanism for specifying languages y= ou want (And languages server supports) so multi lingual isn't a problem - = the only concern would be if a server didn't support the language you neede= d, but in that case you are no worse off than you would be if we didn't do = any of this at all (And for most cases you are in a better position than yo= u were with the current WhoIs protocol). >>It feels like we are not designing a replacement for WhoIs but rather=20 >>something that achieves an entirely different purpose, something that=20 >>is to be used alongside it.. maybe that was the goal from the start and=20 >>I have misguided myself.. >Well, we have no plans to shut down our port 43 service even though it rec= eives less traffic than our RESTful service (imagine how much more RESTful = traffic we'll get when we become RDAP compatible). Right now our port 43 se= rvice is simply a presentation of our RESTful service as it is a simple pro= xy. I anticipate a lot of registries will head down that path. I expect that port 43 will be around for a while yet too, and intuitively i= t makes sense to me that an IP address registry has seen a huge reduction i= n the WhoIs queries with many people moving over to the 'machine parseable'= RESTful service... Im not sure the same will be true of Domain Name Regist= ries - Im still wondering if we are supposed to be designing a replacement = for WhoIs or not though, is the ultimate goal to eventually retire WhoIs? >-andy From andy@arin.net Wed Mar 6 07:20:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E5611E8130 for ; Wed, 6 Mar 2013 07:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGjnBAL4cdfT for ; Wed, 6 Mar 2013 07:20:34 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0B11E80FD for ; Wed, 6 Mar 2013 07:20:33 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id A27FC21369B; Wed, 6 Mar 2013 10:20:31 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id A2F7A21366F; Wed, 6 Mar 2013 10:20:30 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 6 Mar 2013 10:20:12 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 10:20:23 -0500 From: Andy Newton To: Chris Wright , Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtAAKx2EAAAG754AABdwbMAAa2LYAAAHIM8AAAm0nAAAAIiNwAAF/14AAAGEnYAABlN8A Date: Wed, 6 Mar 2013 15:20:22 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF17A8@CHAXCH01.corp.arin.net> In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF35@off-win2003-01.ausregistrygroup.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:20:34 -0000 On 3/6/13 9:51 AM, "Chris Wright" wrote: >So another suggestions are allowing a text mime type to be supported >where we would return text documents that provide the information in the >format similar to the current WhoIs, so a 'generic' WEIRDS client can >just do text mime queries - I think we have suggested this before.. You are free to provide plain text output. Our RESTful service does. However, I don't see it solving any of the issues you've brought up. Even a generic client may want to change the presentation of the data. >Also, on languages, HTTP already has a mechanism for specifying languages >you want (And languages server supports) so multi lingual isn't a problem >- the only concern would be if a server didn't support the language you >needed, but in that case you are no worse off than you would be if we >didn't do any of this at all (And for most cases you are in a better >position than you were with the current WhoIs protocol). We've been told by our I18N experts that this in fact an incorrect usage of that header. >I expect that port 43 will be around for a while yet too, and intuitively >it makes sense to me that an IP address registry has seen a huge >reduction in the WhoIs queries with many people moving over to the >'machine parseable' RESTful service... Im not sure the same will be true >of Domain Name Registries - Im still wondering if we are supposed to be >designing a replacement for WhoIs or not though, is the ultimate goal to >eventually retire WhoIs? I've yet to meet a Whois operator who didn't believe the majority of their queries were from automation. As to the ultimate goal, that is in the charter and is to produce a better protocol than Whois. If Whois/port 43 gets replaced in the process, that's just a side affect. -andy From johnl@iecc.com Wed Mar 6 09:43:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1E21F8D02 for ; Wed, 6 Mar 2013 09:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.266 X-Spam-Level: X-Spam-Status: No, score=-110.266 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWKa+0N-yqOD for ; Wed, 6 Mar 2013 09:43:18 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3F21F8CFA for ; Wed, 6 Mar 2013 09:43:15 -0800 (PST) Received: (qmail 12388 invoked from network); 6 Mar 2013 17:43:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Mar 2013 17:43:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51378032.xn--hew.k1303; i=johnl@user.iecc.com; bh=qlEfFm8Q76/ug9wjEOzU8V7kWalInkjAMcNbdZYqiL4=; b=v52w+NNDQizMy+N6f9rfWmuyge+5EbqSenXh/WU4K6KjTITB7WJd1L+s7o8FA0YxsuYj4FiHKo9HP+XRVtlm79Wkg3/0ouEtBfkF3+UZ9zkPy+LA4eKmnaGzaVt4oimShugAuGOKbBFs0NjuGadmEuS4Yp60FAHlvVRZHDRqvpk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51378032.xn--hew.k1303; olt=johnl@user.iecc.com; bh=qlEfFm8Q76/ug9wjEOzU8V7kWalInkjAMcNbdZYqiL4=; b=hXtLHSsys2ZII+ixNIL7RuXmL50MvYafTYbKaX6mpPxOGsJ7RYjfIX2L3L1w8b+bq00iApeDwuiOFB6AEYLWWgC2CtGoG6h2EdCpZ2jRqRu0VcAO6zuBmBse6iPC2coP3wEg19264eisGUW09FgEGG8rmiW4A54i555fkFavrdw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Mar 2013 17:42:52 -0000 Message-ID: <20130306174252.15108.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Human clients aren't the issue, was Client handling X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:43:24 -0000 In article you write: >WHOIS clients get this meaning/knowledge now writing custom code. We are >suggesting a replacement to WHOIS correct? We are designing a replacement for WHOIS for the modern Internet, where WHOIS is overwhelmingly a machine to machine service, not machine to human. Fortunately for those worried about backward compatibility, most of the the human users are likely be easy to recognize because they use clients that ask for html rather than json, in which case you can use the full glory of html to return whatever you want, extensions, PNG images, and all. When the client asks for json, it's a machine, and the response needs to be something that a machine can use. I suppose there might hypothetically be users who use clients that ask for json and then render it, and urgently need to render every possible extension, but I think they're few enough that they can take care of themselves. But to back up a little, although the various names registries vary somewhat in the way they describe domains and contacts, they're not THAT different. If you can't come up with a common vocabulary that describes 95% of what's asked for and what's returned, leaving only exotica in extensions, you really need to go away and think about it until you can. Otherwise we're going to end up reinventing kludges that pattern match all the fields looking for strings that appear to be e-mail addresses or phone numbers, which would be an admission of complete failure. R's, John From stpeter@stpeter.im Wed Mar 6 10:06:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0D621F88DB for ; Wed, 6 Mar 2013 10:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl3twnkVMM-K for ; Wed, 6 Mar 2013 10:06:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3847C21F88BE for ; Wed, 6 Mar 2013 10:06:35 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CF3A54004E for ; Wed, 6 Mar 2013 11:14:48 -0700 (MST) Message-ID: <513785AC.5080700@stpeter.im> Date: Wed, 06 Mar 2013 11:06:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [weirds] JCARDCAL WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:06:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, in case you missed it, we've formed a JCARDCAL Working Group to define JSON representations of both vCard and iCalendar information: https://datatracker.ietf.org/wg/jcardcal/charter/ Given past discussions in the WEIRDS WG, I figure that some people here might be interested in this initiative. If so, please join the jcardcal@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/jcardcal The working group aims to complete its work in the next few months, so your timely participation would be very much appreciated. :-) Thanks! Peter, co-chair - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRN4WsAAoJEOoGpJErxa2p8NoP/3JfJuBKYPty79AnFjD1Ovpo a00Zx2CeBsi4wnFpxPh1LQXuI0lQRFk+pUGv711RzfgFx0Vphj4HpWnpZMUjodTv suskDmtEEyV6DK0o/LZCwROaKLIPQfNkW+8E+cFzgtmBXTRoehRF9FNr+lZ3cR3J xFJWvLvNoDc5tDsFne35YNzdSuQBcr2cO8XffHsimmcZLeGP1kpomMi30MNleezA sj1SATW0R01W2ni/UU5+V00OFABdsevKqhUXuoAqaPV0vz2DgokIxxcMHm9aj435 e34zu3Ezn9nr0hsYJlTx9T4XS2TFCJq2WNWzeCiqi3DcbhE4aQgj5GI9PwRx5WKG SXRmFXS0FVt9yHQ1YsBjP1cNDl8WMY8lQle9gMyFgiO07S49/8gLvJHeMcFiqhKO M8l8b81vjHz8kfdl6j7Db+/gifse8QUWI8ivajAq0W0uYoe93LOa7gw1xA8sBI1w w+JF7cbT/0sD36sU7XZ2rJAb47VUIUTZlxA+Hb4UcJj0F0Gtkm/sIcozW3RulWuK lGp7SukqVJdn1O1TgUb+atZWek6QO9Cizw36Um0n5EYif26T2lD19HCNouSxr4wR dGzGUDwTSUEPWXmvzFoOHVi7cNHmjXCUfY7GK83fqO7t+dU5JiZN8zXicDteIl9e WlxmvxfVSTHtu1YhfCGD =LppO -----END PGP SIGNATURE----- From edainow@afilias.info Wed Mar 6 14:11:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4A311E8182 for ; Wed, 6 Mar 2013 14:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+TnxKzZhDbo for ; Wed, 6 Mar 2013 14:11:57 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3E11E819A for ; Wed, 6 Mar 2013 14:11:21 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UDMYT-0004iX-3V for weirds@ietf.org; Wed, 06 Mar 2013 22:11:21 +0000 Received: from mail-ee0-f71.google.com ([74.125.83.71]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UDMYS-0002My-6F for weirds@ietf.org; Wed, 06 Mar 2013 22:11:21 +0000 Received: by mail-ee0-f71.google.com with SMTP id t10so12208454eei.6 for ; Wed, 06 Mar 2013 14:11:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=VOitw5G4M/Zj9QQGw5YVx7L3DS+b4Qw+8Tm9gDmiD4w=; b=C7PbP34yIR2O5VvmpX58S2IvWMkW8d+0Y3auBIYj8QzI82k4Ef0ERu3SfQl8oCnos4 PALii1UsC1JOa4Yp3nUn1b2eUFbCSmZsDDRKKFh5tqXi32/+MPSo9IluVr/K6yceQxEg 5HDz53uhDtq/+AUoQQxwfwwg7gYR/Jdmfq3u0LaitIm5nYmfWIUf4uOdDrZHeYVlQu3F LIln4o+jl6KN5Tie3iUi8H5eBFNFF4HOv/G0JePxTX7ie+url2gNt6lY85PMh8A34iLZ Ervv66jEmdzl5kxbt/fRiQjumOsV24ljwukmBrZ7D/c5yRre0Br5+OPN6WEM4jqSO+ki RgBg== X-Received: by 10.152.108.1 with SMTP id hg1mr26028424lab.12.1362607874755; Wed, 06 Mar 2013 14:11:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.108.1 with SMTP id hg1mr26028418lab.12.1362607874617; Wed, 06 Mar 2013 14:11:14 -0800 (PST) Received: by 10.112.13.235 with HTTP; Wed, 6 Mar 2013 14:11:14 -0800 (PST) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF13D8@CHAXCH01.corp.arin.net> References: <5130CE3E.60503@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF13D8@CHAXCH01.corp.arin.net> Date: Wed, 6 Mar 2013 17:11:14 -0500 Message-ID: From: Ernie Dainow To: Andy Newton Content-Type: multipart/alternative; boundary=bcaec54ee22455cdff04d748de2f X-Gm-Message-State: ALoCoQnJ2p6NJBRx6WkZmv+OSX+wOo/nMLUrnh9kn3+PvHN2yh2h8FujLL7pMmmrAdS0RoDidczmcgifHhf8gzkUCsfYUVyCNcwHGE0OSqUzHI7FCUo1Vuq9kOe+b0hcINsqbBwwLRM/ Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on json-response-02 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:11:57 -0000 --bcaec54ee22455cdff04d748de2f Content-Type: text/plain; charset=ISO-8859-1 One of the main arguments for jCard/vCard was that it could support either structured or unstructured data. All these examples are unstructured. It would be worth adding some comments in the text about this and an example showing structured data. -Ernie On Tue, Mar 5, 2013 at 2:54 PM, Andy Newton wrote: > On 3/1/13 11:50 PM, "Simon Perreault" wrote: > > >See attached. My comments are marked with .... > > > >I have included all the necessary changes to switch to jCard. Hopefully > >this makes the editor's job easier. :) > > Outstanding! Thanks Simon. > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --bcaec54ee22455cdff04d748de2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the main arguments for jCard/vCard was that it could support either = structured or unstructured data. All these examples are unstructured. It wo= uld be worth adding some comments in the text about this and an example sho= wing structured data.

-Ernie


On Tue, Mar 5, 2013 at 2:54 PM, Andy Newton <andy@arin.net> w= rote:
On 3/1/13 11:50 PM, "Simon Perreau= lt" <simon.perreault@viagenie.ca> wrote:

>See attached. My comments are marked with <SP>...</SP>.
>
>I have included all the necessary changes to switch to jCard. Hopefully=
>this makes the editor's job easier. :)

Outstanding! Thanks Simon.

-andy

_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds

--bcaec54ee22455cdff04d748de2f-- From bje@apnic.net Wed Mar 6 16:19:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6311E80D9 for ; Wed, 6 Mar 2013 16:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pryg3q39Jeks for ; Wed, 6 Mar 2013 16:19:23 -0800 (PST) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 5E42D11E80E4 for ; Wed, 6 Mar 2013 16:19:22 -0800 (PST) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 7 Mar 2013 10:18:47 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852:f9ce:d66e:c64d:3db2) with Microsoft SMTP Server (TLS) id 14.1.421.2; Thu, 7 Mar 2013 10:19:17 +1000 Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Thu, 7 Mar 2013 10:19:17 +1000 From: Byron Ellacott To: Chris Wright , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of known attributes/names Thread-Index: Ac4Zqgiw+UJ++XHCShKFhT2a6irAtP//WsYAgABhtACAADB3AIAA1S2AgAAW9gCAAAq1gIAABAiAgAAJCACAAAeRgIABRk+A Date: Thu, 7 Mar 2013 00:19:16 +0000 Message-ID: In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF35@off-win2003-01.ausregistrygroup.local> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <1497772C7C5FB549B3B88BD83F504647@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:19:24 -0000 Hi Chris, On 7/03/13 12:51 AM, "Chris Wright" wrote: >If we were using XML, then the 'dictionary' could just return the XSLT >and we wouldn't have a problem with arrays and nested objects... (though >dictionary would be a really bad name for it at that point) You could certainly use XSLT to provide one particular transformation of structured data into, presumably, unstructured text, but a client would be under no obligation to use it. If you intended that all clients MUST use that transform, why bother with the structured data in the first place? (Answer: because most consumers of registration data don't want unstructured text, they want something structured so they can pull out the information that's most relevant to their present need. See Also: data consumers having a desire for structured addresses :-) If your goal is to ensure that human consumers of weirds data have access to specific information, there's a few mechanisms already in the data model, and of course the potential to highlight where those mechanisms are insufficient and add more: - server-level notices include description and descriptive link fields - every object has a remarks field for unstructured text data Do you have a rough map for how you'd translate your current data model into the current RDAP data model? Identifying where that translation breaks down, specifically, might let us as a working group look at where the RDAP data model is weak, or where you might need a registry specific extension, or where the translation might be tweaked to avoid the problem. Byron From fobispo@isc.org Wed Mar 6 16:27:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C021F86D2 for ; Wed, 6 Mar 2013 16:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAGLOzba5XOM for ; Wed, 6 Mar 2013 16:27:10 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5208421F868E for ; Wed, 6 Mar 2013 16:27:10 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 0EA97C9424; Thu, 7 Mar 2013 00:27:01 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362616027; bh=mvOaaSeLrf03xmsZ6+HWW2Ls5rXDi2qL8gtNgYyrphU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EpNPHPXHfOVBcLewdptdWYLyqfwXHf7cGOsBqAz+3yv7gI6w4fA1j2FOVUPdxqgGn 1oxv64iz1upAjlcQYSHkfmXX+Gha1MX3Cf35Qqfqte8aUXH0cTAMxr7BdIJXN8jwM6 LoUUZxUAc0/gf3s8zZby8cSGMlIXkgnsYafMeef8= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 7 Mar 2013 00:27:01 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:849c:77c6:2c30:c3ba] (unknown [IPv6:2001:4f8:3:64:849c:77c6:2c30:c3ba]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0261E216C3B; Thu, 7 Mar 2013 00:27:01 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF35@off-win2003-01.ausregistrygroup.local> Date: Wed, 6 Mar 2013 16:27:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CEF048B9EC83748B1517DC64EA130FB76EE44AF30@off-win2003-01.ausregistrygroup.local> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1717@CHAXCH01.corp.arin.net> <8CEF048B9EC83748B1517DC64EA130FB76EE44AF35@off-win2003-01.ausregistrygroup.local> To: Chris Wright X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: "weirds@ietf.org" Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:27:10 -0000 I really wanted this protocol to be based on XML, not only because of = the things you've mentioned, but because clients such as web browsers = now need Javascript to fetch/format the data.=20 Even though I agree that JSON is really simple to implement, it does = bring some other issues that I've already highlighted several times, for = which XML is very mature. We (ISC) are implementing a RESTful whois that will use XML, XSLT for = transformations, etc, and of course we will add the JSON support to make = it compatible with WEIRDS spec.. Francisco On Mar 6, 2013, at 6:51 AM, Chris Wright = wrote: > If we were using XML, then the 'dictionary' could just return the XSLT = and we wouldn't have a problem with arrays and nested objects... (though = dictionary would be a really bad name for it at that point) Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From bje@apnic.net Wed Mar 6 16:28:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A721F868E for ; Wed, 6 Mar 2013 16:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji-rO+9p7T6R for ; Wed, 6 Mar 2013 16:28:21 -0800 (PST) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id A00E821F84F7 for ; Wed, 6 Mar 2013 16:28:20 -0800 (PST) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 7 Mar 2013 10:27:47 +1000 (EST) Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67%18]) with mapi id 14.01.0218.012; Thu, 7 Mar 2013 10:28:17 +1000 From: Byron Ellacott To: James Mitchell , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4Zoe2LDq9dFkPjTE6f0OYUJ+8+WP//5MYAgAD4oYCAAXQNAA== Date: Thu, 7 Mar 2013 00:28:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.210] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:28:21 -0000 On 6/03/13 10:16 PM, "James Mitchell" wrote: >Perhaps the text could instead say: > >"Clients processing JSON [RFC4627] responses SHOULD NOT treat the >existence of values associated with unrecognised names as an error". I am generally speaking in favour of this approach, but wonder if it could be strengthened slightly: --- snip --- Clients processing JSON [RFC4627] responses SHOULD make available to end users any values associated with unrecognised names, and MUST NOT treat the existence of such values as an error. --- snip --- If a client is presenting data to a user, I'd expect to be shown that there were fields the client couldn't interpret, but which it can display as unstructured text. If a client is instead extracting specific data, I'd expect to only see that specific data and nothing else. And as John suggested, if the user-agent requests HTML, transform the data to whatever visual format you prefer :-) Byron From sm@resistor.net Wed Mar 6 17:00:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0927321F8754 for ; Wed, 6 Mar 2013 17:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFTyedvlmxGF for ; Wed, 6 Mar 2013 17:00:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4421F8615 for ; Wed, 6 Mar 2013 17:00:28 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2710GYo024439; Wed, 6 Mar 2013 17:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362618021; bh=OXexTPkPi1rzgQHst+wK11XqIEIDzPKrvdbGqnJZpWo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T4UVE2ZUrgX9yYnafst2bsrO9/AclL3C3x3coJZo4SJe200WRVI5Gk2aBiibUz9FQ l4pwmWXO3dUFjJgnLHXWOqVhsj2jppmdcOYbs88qwchRzw3+xzubisvKd2vGXc9Hbs DQOrElI4rfsk3yAtElVz2xegbvXhywl1VGExr9Ws= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362618021; i=@resistor.net; bh=OXexTPkPi1rzgQHst+wK11XqIEIDzPKrvdbGqnJZpWo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3v+V5wHtntxpytaWB5jQcGgdxBUwwkd1E3VsYQrHMMM5SrpoV5aL/pY4DNUKC9mKd ZYsB9RwE3XEpLKVSH3FoTuFPT6TXNHRFfP41WMTVma7uL6dOmsbO1oLFVqr/JFt8Lj pT8aVKMF0glzAqyIpgtGpCe7SvOPOaOC55zY3DpA= Message-Id: <6.2.5.6.2.20130306163104.0c774330@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Mar 2013 16:54:43 -0800 To: James Mitchell From: SM In-Reply-To: References: <20130305212644.18407.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 01:00:29 -0000 Hi James, At 04:16 06-03-2013, James Mitchell wrote: >Perhaps the text could instead say: > >"Clients processing JSON [RFC4627] responses SHOULD NOT treat the >existence of values associated with unrecognised names as an error". An issue will be raised about the above text. If you send me data and I cannot process it, I can either ignore it or fail. I guess that what's missing is text about what to do with unrecognised "data". Regards, -sm From carlosm3011@gmail.com Wed Mar 6 17:38:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02DD1F041A for ; Wed, 6 Mar 2013 17:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07WbnIgjS6jT for ; Wed, 6 Mar 2013 17:38:10 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF6E21F868B for ; Wed, 6 Mar 2013 17:38:10 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id q11so1353963yhf.17 for ; Wed, 06 Mar 2013 17:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JbZZKmrpjik6BhDJI3L+WIL/GeAwKbf8371N/5HNfZI=; b=vy0uNhYiHF9YsJUb/Vn0IZXR5IusuToilcFSZNGJzut+gPcmZEsrIjCWdY9aR0UU7I yQijvX+u58bnYjzDTOD4iujXY4/KvAyiorAJcw0awlLZUCfD0itNFjVmlBM7CPmR6mFV y+dYSd9BHYjMU91bGcmTi3d+Gomu7iWuuPbXYHChvM8M1bem1V/+WBA3r6iL1ZRaOd7k 2gjdC8nqEMvdTjWnQGis1S1D+OD6sO76xdYYDJs+a2wWzjFaebL9fO/EajX3ZwJ8SBTa WOStV/kK3B56j6+KWE4ePQtkA82SeR5otXMa3vwY2pViEby4vEuIAEm62fmdlHRV8rJn MfPw== X-Received: by 10.236.158.138 with SMTP id q10mr23094746yhk.59.1362620289742; Wed, 06 Mar 2013 17:38:09 -0800 (PST) Received: from erebus.local ([2001:470:d815:fe0:319d:f5ca:5a29:8564]) by mx.google.com with ESMTPS id x16sm15926824yhj.6.2013.03.06.17.38.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 17:38:08 -0800 (PST) Message-ID: <5137EF92.9040901@gmail.com> Date: Wed, 06 Mar 2013 23:38:26 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: SM References: <20130305212644.18407.qmail@joyce.lan> <6.2.5.6.2.20130306163104.0c774330@resistor.net> In-Reply-To: <6.2.5.6.2.20130306163104.0c774330@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 01:38:10 -0000 IMO, you do the same thing other servers do today with unknown data: either ignore (if you are and endpoint in the communication flow) or pass on (if you are in the middle) ~Carlos On 3/6/13 10:54 PM, SM wrote: > Hi James, > At 04:16 06-03-2013, James Mitchell wrote: >> Perhaps the text could instead say: >> >> "Clients processing JSON [RFC4627] responses SHOULD NOT treat the >> existence of values associated with unrecognised names as an error". > > An issue will be raised about the above text. If you send me data and I > cannot process it, I can either ignore it or fail. I guess that what's > missing is text about what to do with unrecognised "data". > > Regards, > -sm > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Wed Mar 6 18:12:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047011E80E4 for ; Wed, 6 Mar 2013 18:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jCIE9BXn+vV for ; Wed, 6 Mar 2013 18:12:19 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E7A7D11E80C5 for ; Wed, 6 Mar 2013 18:12:13 -0800 (PST) Received: (qmail 30216 invoked from network); 7 Mar 2013 02:12:12 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Mar 2013 02:12:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5137f77c.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=hhuDW7cSQHYZO0TsmwaMQMxJhM4HH9cb8O7zrx+eD1A=; b=aGQ8gK3OqUkIfBibu2/Oq7LUS44Lv1+3ww0b8hPMzW+uoFwNvosipwUcsA58ahnkyAf2Fc3iVgeXsTcpXxz0mdbwmObosIC5iv0PucweIWZxFqDxh3gx/KkgOqemdXUwsuqXyvwFcfdWcWAUQH/bEeMZVDDD3q3FSUG6HQP2ONo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5137f77c.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=hhuDW7cSQHYZO0TsmwaMQMxJhM4HH9cb8O7zrx+eD1A=; b=Ac7jh4lDaJlX7uaKeWbI6Go1ceSHC57yZPvbm6nRNpVTkffUZZXJ3z+fzIjAQzgEsZGIXrDP9tEfMTWuyNKAViYzNaZmaneuAVs6m9CKRrrdxw7fhpUaDhSbo3h8WaeXEVZaU6Yh3wMMG4yVMZ9iBMEkzuyHt3DoMCdzGdOnO8U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2013 02:11:49 -0000 Message-ID: <20130307021149.18341.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:12:20 -0000 In article you write: >I really wanted this protocol to be based on XML, not only because of the things you've >mentioned, but because clients such as web browsers now need Javascript to fetch/format the >data. No, they don't. There are JSON libraries in all sorts of languages. I do my JSON work in python, but that's a matter of taste. By the way, how do you write a PNG or JPEG renderer in xslt? From johnl@iecc.com Wed Mar 6 18:21:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7F21F85DC for ; Wed, 6 Mar 2013 18:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh3RAu07vWTa for ; Wed, 6 Mar 2013 18:21:38 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7738D21F84E7 for ; Wed, 6 Mar 2013 18:21:38 -0800 (PST) Received: (qmail 32653 invoked from network); 7 Mar 2013 02:21:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Mar 2013 02:21:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5137f9b1.xn--9vv.k1303; i=johnl@user.iecc.com; bh=RxZBiv2UuO9SgjPU9t7Nbw/Qint4twDbIUOyFXjN3mo=; b=gkYXIoZRvWbNUJIj3MP9QyR728dJS3zkPx/+kCc18alNvR29s9k3DPQQKpAGdCWf3ae7pYXvwzUlLNExOi/CNr36BDOOOizTDh6O+8SxkfI10U061qUmXTjTjI5jL5080m0dWdrFEGVrBU7ohX6+0V6oIGS6RCadCpkWZy+qYDc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5137f9b1.xn--9vv.k1303; olt=johnl@user.iecc.com; bh=RxZBiv2UuO9SgjPU9t7Nbw/Qint4twDbIUOyFXjN3mo=; b=Xdj4IP1nZmwujrSdL8RHGzCxLZnza0/gopCKXmMj51fvmdu0MJjSdLv/1KwIeAvOaUdjDnde0FgEVdcjQ/Z02jv2TtnruYCGS6vCw6PPNqn9t7G+hrgsMO+6KaInOLn7ERrQ8ktiC/KTa3SrPmwERbL5Elc+aJBOygS5aamYHdQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2013 02:21:15 -0000 Message-ID: <20130307022115.18368.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:21:39 -0000 >Clients processing JSON [RFC4627] responses SHOULD make available to end >users any values associated with unrecognised names, and MUST NOT treat >the existence of such values as an error. My clients don't make anything available to end users. Does this mean that I'm not allowed to use WEIRDS? More to the point, this is the kind of bad user interface design for which the IETF is infamous. It has nothing to do with making protocol engines interoperate, and makes many unwarranted assumptions about what client software does. The original language said (perhaps not as clearly as it could have) that if a client sees fields it can't handle, it should skip them rather than barfing. Please leave it at that. From fobispo@isc.org Wed Mar 6 18:27:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED05111E80EA for ; Wed, 6 Mar 2013 18:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMydfMFIkn2x for ; Wed, 6 Mar 2013 18:27:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA211E80E9 for ; Wed, 6 Mar 2013 18:27:03 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3066BC9563; Thu, 7 Mar 2013 02:26:55 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362623223; bh=sxwvcBM3oVZ8V07e4S1OiVR23fwzXh1Pt/zwsHXeL/I=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=s87PQoW0MWUP+/iF8gWw4WMykYhkLzJxJi/5YS1rXI9i5guiPrnXc79+4pTT3+acS ujeondylZmHYRg0GisXk0QKjVhBQwRtAHK0JCCF5zMk4ywcahAMGSJZX1qfHQ46rL4 N0Cp6Lw3+dWB1WGY1XXoBDkE1HK1WNv9k3hIjfAo= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 7 Mar 2013 02:26:55 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:849c:77c6:2c30:c3ba] (unknown [IPv6:2001:4f8:3:64:849c:77c6:2c30:c3ba]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 24E80216C43; Thu, 7 Mar 2013 02:26:55 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <20130307021149.18341.qmail@joyce.lan> Date: Wed, 6 Mar 2013 18:26:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130307021149.18341.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:27:04 -0000 On Mar 6, 2013, at 6:11 PM, "John Levine" wrote: > No, they don't. There are JSON libraries in all sorts of languages. > I do my JSON work in python, but that's a matter of taste. >=20 Yes, but a plain browser would have to execute a program in order to be = able to parse/convert the data into something useful for the user, while = XML doesn't have that issue.=20 Browsers support XML and XSL natively, they don't need to execute = external programs.=20 > By the way, how do you write a PNG or JPEG renderer in xslt? Why do you need that? in any case I guess you could use XSL-FO [1] [1] http://en.wikipedia.org/wiki/XSL_Formatting_Objects Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From johnl@iecc.com Wed Mar 6 18:59:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D1811E80E4 for ; Wed, 6 Mar 2013 18:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.577 X-Spam-Level: X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN3X+tJ2ebME for ; Wed, 6 Mar 2013 18:59:16 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C97A11E80E3 for ; Wed, 6 Mar 2013 18:59:16 -0800 (PST) Received: (qmail 40817 invoked from network); 7 Mar 2013 02:59:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Mar 2013 02:59:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51380281.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=t/wyDjuhXpdya1uixKJKSM8Lje3KCMO6PCNTMf1GbGw=; b=c5QspzgtQSChrHhw+J/grW7uu4ajO3CuTngIbQ0CuVKRMkhjF4zyn/9P1KGGkbVzCeN/Q1Cs7+OWStSffvATXKeWVWJ5NlYjzAG2BeLRdPgrCXqke189Fue1x6vRE6TwqedPInXfKpfADVdzWXkpj7fBTQWSHsRLPMYlmz8/GLU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51380281.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=t/wyDjuhXpdya1uixKJKSM8Lje3KCMO6PCNTMf1GbGw=; b=b73CuRZUrMtbj1KJADTsHCSvu8sZIwgdXOL4+6gGtMgMuChR9zCN8Vzc8sBcXa/QkoXWkVTbs0drRIPReoiUn+aHhL6zIxGN3lHsu7JCPzNvdt9TRJ/VlBTRcitn3uIjdNyKhHwI0JaH/+k0XRykVw1Z8MKH/vbUbKlOm5XKUuo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Mar 2013 02:58:51 -0000 Message-ID: <20130307025851.18556.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:59:17 -0000 >> No, they don't. There are JSON libraries in all sorts of languages. >> I do my JSON work in python, but that's a matter of taste. > >Yes, but a plain browser would have to execute a program in order to be able to >parse/convert the data into something useful for the user, while XML doesn't have that >issue. This is a total red herring. If the client is a person sitting at a browser, the http requests will accept text/html rather than application/json and the server can send back something in HTML if it wants to support direct queries from people. This should be obvious. Please remember that the vast majority of WHOIS queries are machine to machine, not human to machine, and that's what WEIRDS is designed for. In most cases, there is no human directly involved, and no human waiting to look at random semi-formatted output. R's, John From fobispo@isc.org Wed Mar 6 19:24:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0C611E80D9 for ; Wed, 6 Mar 2013 19:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxo+zI5fENxw for ; Wed, 6 Mar 2013 19:24:15 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5A11E80D2 for ; Wed, 6 Mar 2013 19:24:15 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id D394B5F9842; Thu, 7 Mar 2013 03:24:06 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362626654; bh=JMv8J7KkqAWkX2yEbmGLVmvmhB+yZFy1L8Ovz4akkD4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rNtsdF5ApybqjnrdWGhhMycvSPak9aeFCW0v/dzahXOmWh6Ujgf4vLgq0yTlBsTSL CJAbohP8Tqd300iNipQuXzEf10xu9uj444NAkzqpVrA2VzzPEvCEcpuU7LB95PRvUE r9dYB/3km+AHFs2R/wfRNE2XFpSJ3S9NcZrK4a2Y= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1DDA5216C3B; Thu, 7 Mar 2013 03:24:05 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <20130307025851.18556.qmail@joyce.lan> Date: Wed, 6 Mar 2013 19:24:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> References: <20130307025851.18556.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:24:16 -0000 On Mar 6, 2013, at 6:58 PM, "John Levine" wrote: > This is a total red herring. If the client is a person sitting at a > browser, the http requests will accept text/html rather than > application/json and the server can send back something in HTML if it > wants to support direct queries from people. This should be obvious. >=20 Which assumes that you have a server that is running a script capable of = looking at the accept header. (or a special setup in the web server to = deliver content based on that). But every single argument will have a counter-argument at this point, I = believe XML was a better solution than JSON for RDAP, the complexities = of XML as some call it, address some real life issues that will have to = be addressed in JSON somehow. That's why we decided to implement it in XML with XSL and XSD, the XML = can easily be transformed in to anything we need it to, even JSON. > Please remember that the vast majority of WHOIS queries are machine to > machine, not human to machine, and that's what WEIRDS is designed for. > In most cases, there is no human directly involved, and no human > waiting to look at random semi-formatted output Whois will still be consumed by human beings, the fact that a computer = can query faster than a human is no argument for making the protocol = less readable. Being able to consume it by both humans and computers is = something I consider necessary. Specially since non-programmers will be = looking at the data. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From michael@mwyoung.ca Wed Mar 6 19:36:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DCD21F8441 for ; Wed, 6 Mar 2013 19:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.128 X-Spam-Level: *** X-Spam-Status: No, score=3.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_EQ_CPE=0.979, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A4w3FdXc-CE for ; Wed, 6 Mar 2013 19:36:01 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 374A411E80A3 for ; Wed, 6 Mar 2013 19:36:01 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so21419iea.35 for ; Wed, 06 Mar 2013 19:36:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=FBCkGeKHUZstQ8BeDCluBCapFLR5O4SRZLfneDO/n6M=; b=DYGsS2vzeMj7wK7xeUFD1Xna2FkG5I8SKbE4iuxKnlD67uWxctMjtk/dKA2Bh8WT7u +1enYMb/u4vXCLj9GDrz6/0+m5xBKsL3tivh25W/sNPRGiXM1LxJe19QHs2z5ci41SSx vzcuj6qbqXS9DKPVmdceah9GuQwRSXelUpPa83MNwEBhj7I3Ts8x05nIlsDQQme3jsQR JaimGkmaopBT3NIsSwm2nG57ZBXfiGIzUuvxyAZdAjuQ5VqJJzJeoBjJEJmiy2mzyvwe VRBPGXKH4RVvFgoUaqjXB43D1Sc1fkct4TOYWtY1XeVAwC/KvA+uKVSsiQsaFKPKHIEF SapQ== X-Received: by 10.43.88.134 with SMTP id ba6mr32745023icc.18.1362627360785; Wed, 06 Mar 2013 19:36:00 -0800 (PST) Received: from [172.16.1.22] (CPEf87b8c0c1175-CM78cd8ece2635.cpe.net.cable.rogers.com. [99.225.219.53]) by mx.google.com with ESMTPS id xe9sm25546673igb.7.2013.03.06.19.35.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 19:35:59 -0800 (PST) References: <20130307025851.18556.qmail@joyce.lan> <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Wed, 6 Mar 2013 22:35:57 -0500 To: Francisco Obispo X-Gm-Message-State: ALoCoQmqxXdJXn8sfHunlQJpaNenOEHg1JqASBP79e0773TvLXXs6dvRAFwEJ+lwQoc8Ty3YjVjz Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:36:02 -0000 Non-programmers use applications, be that a browser or otherwise, to do a Wh= ois lookup. That said, I think JSON is great for the simple case, and XML is better for d= ifferent namespace schemas. I'm on the fence really on this one,....support f= or both would be ideal probably. Michael Young M:647-289-1220 On 2013-03-06, at 22:24, Francisco Obispo wrote: >=20 > On Mar 6, 2013, at 6:58 PM, "John Levine" wrote: >=20 >> This is a total red herring. If the client is a person sitting at a >> browser, the http requests will accept text/html rather than >> application/json and the server can send back something in HTML if it >> wants to support direct queries from people. This should be obvious. >=20 > Which assumes that you have a server that is running a script capable of l= ooking at the accept header. (or a special setup in the web server to delive= r content based on that). >=20 > But every single argument will have a counter-argument at this point, I be= lieve XML was a better solution than JSON for RDAP, the complexities of XML a= s some call it, address some real life issues that will have to be addressed= in JSON somehow. >=20 > That's why we decided to implement it in XML with XSL and XSD, the XML can= easily be transformed in to anything we need it to, even JSON. >=20 >=20 >> Please remember that the vast majority of WHOIS queries are machine to >> machine, not human to machine, and that's what WEIRDS is designed for. >> In most cases, there is no human directly involved, and no human >> waiting to look at random semi-formatted output >=20 > Whois will still be consumed by human beings, the fact that a computer can= query faster than a human is no argument for making the protocol less reada= ble. Being able to consume it by both humans and computers is something I co= nsider necessary. Specially since non-programmers will be looking at the dat= a. >=20 >=20 > Francisco Obispo=20 > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Wed Mar 6 19:47:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5421F8765 for ; Wed, 6 Mar 2013 19:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syEWL9620PnM for ; Wed, 6 Mar 2013 19:47:28 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DC54021F8758 for ; Wed, 6 Mar 2013 19:47:27 -0800 (PST) Received: (qmail 51703 invoked from network); 7 Mar 2013 03:47:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c9f6.51380dce.k1303; bh=5aGtQKC1ExXCJXlPl9fA95AEYJEM0jsBAJBNshfGCao=; b=UrE+UP6s6CN69ByZP0vs2LcthYhNtrvSBI+0tma+lHmPl0+GmNDfx1vWNDbMXjEWbEyiE0Iv5LF7quL2vuew2pr2yEbmKW0X6a6y1nVmrTtmg9qSXWG4uQ6ebpGf47FtJmEVIOFUO1XJNupMwepsykkBOalWrfAYK0FuTb8b8r8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c9f6.51380dce.k1303; bh=5aGtQKC1ExXCJXlPl9fA95AEYJEM0jsBAJBNshfGCao=; b=gG+eOR2nxSOhnHUnx0qoMEc7UJmVHJGbo8jHcBv2LnqZ0IFfAdzU+yjaX5Pguto6IjNWiEltxZ9dqDkUXiLeaSzf5CNyVR/PaGquVrmKfxumt10f+4LXkHaAjHQi1oCMPdz26FLAoMsm795dB/EUMYT6xgikkBGy0ZLw7AkS64Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 7 Mar 2013 03:47:04 -0000 Date: 6 Mar 2013 22:47:25 -0500 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> References: <20130307025851.18556.qmail@joyce.lan> <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:47:28 -0000 >> This is a total red herring. If the client is a person sitting at a >> browser, the http requests will accept text/html rather than >> application/json and the server can send back something in HTML if it >> wants to support direct queries from people. This should be obvious. > > Which assumes that you have a server that is running a script capable of > looking at the accept header. (or a special setup in the web server to > deliver content based on that). That's content negotiation. It has been a part of standard http since 1996. Is there some reason you believe that it is unusual or difficult to implement? > That's why we decided to implement it in XML with XSL and XSD, the XML > can easily be transformed in to anything we need it to, even JSON. Is there some reason you believe it is productive to rehash arguments that were settled months ago? R's, John From fobispo@isc.org Wed Mar 6 19:56:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1023421F8833 for ; Wed, 6 Mar 2013 19:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu08e7tgeIp0 for ; Wed, 6 Mar 2013 19:56:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8321F882F for ; Wed, 6 Mar 2013 19:56:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2796B5F9899; Thu, 7 Mar 2013 03:56:36 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362628604; bh=0vuYXTxfZg7fXeknj8gETEoAvfOAKZHMPSVgwZWKkx8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=G9Uu6V38UjT4MCyQdgm95uoufRrLVrJ7BjjX64jxJNuxrthdmE3R06VhS7ZjPWhJG q8H0KpP3rracaNq83XG0Y+kfXhWC07M2ZMVhd9kAOyMwUYQ9FvAdvUEHTTi5VdmELs K9VqNatI93/Uuz3hefbFS4R41cMFGA0pLlqrnSCY= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7D432216C43; Thu, 7 Mar 2013 03:56:34 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Wed, 6 Mar 2013 19:56:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130307025851.18556.qmail@joyce.lan> <8FACE57F-8F43-4A0D-8D75-F303F17878D3@isc.org> To: "John R Levine" X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Client handling of known attributes/names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:56:46 -0000 I don't think it's productive, since it's already 'settled' and there's = just too much religion into JSON to leave room for anything else. We = will use JSON even if we need to make it fit with a sledgehammer, and = since I have the option to implement XML, I am, and will provide an = interface in JSON adjusted to the specs discussed in this mailing list. The whole issue on Namespaces was my first argument, I wanted to define = a base protocol format that could be used to 'transport' the various = objects. How to treat them required the concept of namespaces. The = format evolved from the first draft to incorporating 'object' responses, = which I still think it's a positive change. For the rest, we will debate if JSON is better than XML and viceversa, = you missed my point on HTTP and return objects, if you don't have the = data, the web server won't generate it for you, it's not a content = negotiation issue, its a content generation and delivery issue. On Mar 6, 2013, at 7:47 PM, "John R Levine" wrote: > Is there some reason you believe it is productive to rehash arguments = that were settled months ago? Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From aservin@lacnic.net Thu Mar 7 04:20:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2321F8D59 for ; Thu, 7 Mar 2013 04:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH2txI+byaJT for ; Thu, 7 Mar 2013 04:20:23 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 77EBE21F8D98 for ; Thu, 7 Mar 2013 04:20:23 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c85a:651:aff8:d731]) by mail.lacnic.net.uy (Postfix) with ESMTP id 1C50F308498 for ; Thu, 7 Mar 2013 10:20:13 -0200 (UYST) Message-ID: <51388604.70308@lacnic.net> Date: Thu, 07 Mar 2013 10:20:20 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <20130305212644.18407.qmail@joyce.lan> <6.2.5.6.2.20130306163104.0c774330@resistor.net> In-Reply-To: <6.2.5.6.2.20130306163104.0c774330@resistor.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 12:20:24 -0000 I liked the approch that Andrew Sullivan suggested [1] A special field to fill up with whatever is not yet defined but the WEIRDS operator wants to generate. [1] http://www.ietf.org/mail-archive/web/weirds/current/msg02179.html Regards as On 06/03/2013 22:54, SM wrote: > Hi James, > At 04:16 06-03-2013, James Mitchell wrote: >> Perhaps the text could instead say: >> >> "Clients processing JSON [RFC4627] responses SHOULD NOT treat the >> existence of values associated with unrecognised names as an error". > > An issue will be raised about the above text. If you send me data and I > cannot process it, I can either ignore it or fail. I guess that what's > missing is text about what to do with unrecognised "data". > > Regards, > -sm > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Thu Mar 7 06:15:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791EE21F8CCB for ; Thu, 7 Mar 2013 06:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRd+p9REgShE for ; Thu, 7 Mar 2013 06:15:10 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7521F8CC8 for ; Thu, 7 Mar 2013 06:15:09 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 9EA011652AB; Thu, 7 Mar 2013 09:15:09 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id CD97916529B; Thu, 7 Mar 2013 09:15:08 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 7 Mar 2013 09:14:53 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 7 Mar 2013 09:15:06 -0500 From: Andy Newton To: Arturo Servin , "weirds@ietf.org" Thread-Topic: [weirds] Client handling of unknown attributes/names. Thread-Index: Ac4Zoe2LDq9dFkPjTE6f0OYUJ+8+WAAcB2oAAB8ULYAAGnnxgAAX8eQA///MPwA= Date: Thu, 7 Mar 2013 14:15:05 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF1BE4@CHAXCH01.corp.arin.net> In-Reply-To: <51388604.70308@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <588057568E196849B7B88627888F7C08@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Client handling of unknown attributes/names. X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:15:10 -0000 On 3/7/13 7:20 AM, "Arturo Servin" wrote: > > I liked the approch that Andrew Sullivan suggested [1] > > A special field to fill up with whatever is not yet defined but the >WEIRDS operator wants to generate. I'm certainly not getting this. Are you and Andrew talking about a beefed up remarks section? Why isn't this good enough? { . . . "remarks" : [ "Eligibility Type: Company", "Eligibility Name: Widgets R Us", "Eligibility ID: 334113" ] . . . } The only thing I can think of is to have multiple remarks objects so each one can have a different 'lang' value and/or maybe a title value (e.g. "title" : "AU Registry Eligibility Criteria"). -andy From superuser@gmail.com Thu Mar 7 12:32:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67321F8CCA for ; Thu, 7 Mar 2013 12:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB7sS8tdpF2O for ; Thu, 7 Mar 2013 12:32:25 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D504621F89FD for ; Thu, 7 Mar 2013 12:32:21 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hi8so1092545wib.13 for ; Thu, 07 Mar 2013 12:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=cxizrlbdap60L1saPD3QkQkldaul2y3hFHtpIqh8ABw=; b=wL0oH3yfngH1aWwx1n88iKh4Ga01TS55iB2O0X7beIK/8KXlD/0VcSJhWnPqjrkm/z vSut7E3d5voQsbBXtuvMD/MUJg2Vy14Y9yxEw9FqnJy71Xz5fWbEzB4qBumM7N8Rdqhb z42lS+zibw3y11tMEX4JD98t4j5EShYqnH7CnnlKWVfAtyNqNFl5lnfLzy7MXbSQWgYA aktnbEqHWor2lSQpDKIO8RVTXHQDOCXDcXoA/lb0jzWjlOWF7LYJ5LxyCuMzbGZjJU7K FxVUjRJx7Y5I1n8kXQWy0sSVwuoKM9/IMhcs/Jo2Oba1A5327bIl2+pVp13ivKNqqjox 7NuQ== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr35351558wic.33.1362688341070; Thu, 07 Mar 2013 12:32:21 -0800 (PST) Received: by 10.180.189.6 with HTTP; Thu, 7 Mar 2013 12:32:20 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Mar 2013 12:32:20 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c22574825c9304d75b9a73 Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:32:25 -0000 --001a11c22574825c9304d75b9a73 Content-Type: text/plain; charset=ISO-8859-1 Change of location: Now in Caribbean 4. Still on Tuesday morning at 8am. -MSK, WEIRDS co-chair On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy wrote: > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room Boca > 1 for implementation demos. We only have that one hour before other > sessions begin, so please come prepared! > > -MSK > --001a11c22574825c9304d75b9a73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Change of location: Now in Caribbean 4.=A0 Still on T= uesday morning at 8am.

-MSK, WEIRDS co-chair


On Fri, Mar 1, 2013 a= t 10:21 AM, Murray S. Kucherawy <superuser@gmail.com> wrot= e:
The Secretariat has as= signed us 8am-9am on Tuesday, March 12, in room Boca 1 for implementation d= emos.=A0 We only have that one hour before other sessions begin, so please = come prepared!

-MSK=

--001a11c22574825c9304d75b9a73-- From superuser@gmail.com Thu Mar 7 16:27:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71921F86BE for ; Thu, 7 Mar 2013 16:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZrLuRuUzJxC for ; Thu, 7 Mar 2013 16:27:56 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFD721F869C for ; Thu, 7 Mar 2013 16:27:56 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so353247wer.8 for ; Thu, 07 Mar 2013 16:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=rlws+3vEgvd0FJsFJVoxHasLyIF9ZvVAYwLt7pFnILI=; b=Inm5jO4toAB1Z47jY8H9ctXFMDvh7vNnqMJJZ3yUbhfP+2n7MBE6UWgyUBXMEQWnon i5smKpb3aPqmkppjdEhmuCePkJKbS4xIcTBdF9pByx0Add2+DCAegsbdqgIoauJlE4go z3s+3cODWiRyjLCj7wyKNa9OyU5HzdWhp0RUrruaWTxSub9WgDqoD1+Ve3cfZ7l/nLKz e5cLJy0FzqO3VXsWekv//r0PErg8lGrQLWdGLFEfur+gDBjdkOSqU5VAyaajM77/2gVu JKp55m/TirgI4f3Ibzef/Gi3zeZ58PTqq8YHOY3axx2Q887kXfkI9avS1rOM8+tX23ed /mVQ== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr289102wjq.51.1362702475379; Thu, 07 Mar 2013 16:27:55 -0800 (PST) Received: by 10.180.189.6 with HTTP; Thu, 7 Mar 2013 16:27:55 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Mar 2013 16:27:55 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86cea4faca9604d75ee47c Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 00:27:57 -0000 --047d7b86cea4faca9604d75ee47c Content-Type: text/plain; charset=ISO-8859-1 Colleagues, I'm wondering about structure for the demos on Tuesday morning. For example, do we need to set up an agenda for the bake-off, or do people just want to set up their demos in corners and let people wander among them, try, and comment? Should we appoint someone to report to the working group later that day, or should that also be done organically? On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy wrote: > Change of location: Now in Caribbean 4. Still on Tuesday morning at 8am. > > -MSK, WEIRDS co-chair > > > On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy wrote: > >> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room >> Boca 1 for implementation demos. We only have that one hour before other >> sessions begin, so please come prepared! >> >> -MSK >> > > --047d7b86cea4faca9604d75ee47c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

I'm wondering about structure = for the demos on Tuesday morning.=A0 For example, do we need to set up an a= genda for the bake-off, or do people just want to set up their demos in cor= ners and let people wander among them, try, and comment?

Should we appoint someone to report to the working group later th= at day, or should that also be done organically?


On Thu, Mar 7, 2013 at 12:32 P= M, Murray S. Kucherawy <superuser@gmail.com> wrote:
Change of location: No= w in Caribbean 4.=A0 Still on Tuesday morning at 8am.

-MSK, WE= IRDS co-chair

On Fri, Mar 1, 2013 at 10:21 AM, Murray S.= Kucherawy <superuser@gmail.com> wrote:
The Secretariat has as= signed us 8am-9am on Tuesday, March 12, in room Boca 1 for implementation d= emos.=A0 We only have that one hour before other sessions begin, so please = come prepared!

-MSK


--047d7b86cea4faca9604d75ee47c-- From carlosm3011@gmail.com Thu Mar 7 17:55:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EFD21F8767 for ; Thu, 7 Mar 2013 17:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TQ027iuLi1P for ; Thu, 7 Mar 2013 17:55:29 -0800 (PST) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id E5BFA21F8759 for ; Thu, 7 Mar 2013 17:55:27 -0800 (PST) Received: by mail-ye0-f182.google.com with SMTP id r9so193882yen.27 for ; Thu, 07 Mar 2013 17:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zf4ezZEGYiOJqOR4HQRgT+KCK3FzfPtuN1jDlgKldeo=; b=YjbqcWNot0NbwgDzkY0zzwRC8NKMiOYYKfwhyPhT2ouEALG454h5A+HOt0yiv12TRA tWTCP0g8jJVKlykh/bdCkHAzXgjpQZIQ8V1fYq2LooSD4uFgxavCuJj0vIYCNL/J1lHb PTImbXEN9t1GljZ1eeYdl/JEEIHfJDcFWK1env+g8yYJ29AV5B6vYeDTeKuw+NIMyZOg rXU/JNqYOJ1FbPq1YIlWDxmx/YPnrc+YSgX41H/lTd5dgD8QLTnneNTh56LvFVrpofdm 5FV5X561p5wmNdehtzGym9dQ3s/7h60UQqAYhTOubI54Z5jrfLzra2rNnEQ3sjYLKnt+ dJGQ== X-Received: by 10.236.171.201 with SMTP id r49mr352226yhl.148.1362707727482; Thu, 07 Mar 2013 17:55:27 -0800 (PST) Received: from bonaire.local ([2001:470:d815:fe0:a8c2:d7ea:5baf:cbc2]) by mx.google.com with ESMTPS id u41sm5428794yhb.20.2013.03.07.17.55.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 17:55:26 -0800 (PST) Message-ID: <51394528.5020702@gmail.com> Date: Thu, 07 Mar 2013 23:55:52 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 01:55:30 -0000 I think we should have a basic testing protocol in place. On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: > Colleagues, > > I'm wondering about structure for the demos on Tuesday morning. For > example, do we need to set up an agenda for the bake-off, or do people > just want to set up their demos in corners and let people wander among > them, try, and comment? > > Should we appoint someone to report to the working group later that day, > or should that also be done organically? > > > On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy > > wrote: > > Change of location: Now in Caribbean 4. Still on Tuesday morning at > 8am. > > -MSK, WEIRDS co-chair > > > On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy > > wrote: > > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in > room Boca 1 for implementation demos. We only have that one > hour before other sessions begin, so please come prepared! > > -MSK > > > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From marc.blanchet@viagenie.ca Thu Mar 7 18:01:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857A521F867A for ; Thu, 7 Mar 2013 18:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7jxGMzwCSmW for ; Thu, 7 Mar 2013 18:01:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 051A921F8675 for ; Thu, 7 Mar 2013 18:01:30 -0800 (PST) Received: from [192.168.64.186] (unknown [207.239.114.206]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0ADD140391; Thu, 7 Mar 2013 21:01:28 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <51394528.5020702@gmail.com> Date: Thu, 7 Mar 2013 18:00:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51394528.5020702@gmail.com> To: "Carlos M. martinez" , "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 02:01:30 -0000 - we have been preparing a test plan and test scripts. We will be able = to do some testing on the different implementations during the tuesday = session. My colleague Jean-Philippe could drive that testing and report = results to the wg. Regards, Marc. Le 2013-03-07 =E0 17:55, "Carlos M. martinez" a = =E9crit : > I think we should have a basic testing protocol in place. >=20 > On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: >> Colleagues, >>=20 >> I'm wondering about structure for the demos on Tuesday morning. For >> example, do we need to set up an agenda for the bake-off, or do = people >> just want to set up their demos in corners and let people wander = among >> them, try, and comment? >>=20 >> Should we appoint someone to report to the working group later that = day, >> or should that also be done organically? >>=20 >>=20 >> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy >> > wrote: >>=20 >> Change of location: Now in Caribbean 4. Still on Tuesday morning = at >> 8am. >>=20 >> -MSK, WEIRDS co-chair >>=20 >>=20 >> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >> > wrote: >>=20 >> The Secretariat has assigned us 8am-9am on Tuesday, March 12, = in >> room Boca 1 for implementation demos. We only have that one >> hour before other sessions begin, so please come prepared! >>=20 >> -MSK >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From carlosm3011@gmail.com Thu Mar 7 18:16:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0B321F871D for ; Thu, 7 Mar 2013 18:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYgwCnA-xlJw for ; Thu, 7 Mar 2013 18:16:31 -0800 (PST) Received: from mail-gg0-x229.google.com (mail-gg0-x229.google.com [IPv6:2607:f8b0:4002:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D734821F870A for ; Thu, 7 Mar 2013 18:16:30 -0800 (PST) Received: by mail-gg0-f169.google.com with SMTP id j5so190349ggn.28 for ; Thu, 07 Mar 2013 18:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GweC7/q4+WfqcyMmm0MvNT9/a4bxpyipR2tV1CYNbTE=; b=z2Mxkqjml/Us0M/SHtOgG03rDg7gsR0u0F6rGrqvADnNJT9Q8BAfszrdmCy0NHjRxt W1fZzchGIYLdtvg8FTLzFTtfqzco3Vu4ArIDL3HZUJVLV2AfabkRzespkW6rA6BhSj/2 SOl3Iu3o47bCjOsnWqly31K+/ZlFoINW9bbDxftNBCF72wGF9Cv33jd7Vkm3Gu0K0ekv EPlC58pSKMpLLFNa/LOX+bPHAuxfsHBZdWd2RKTeKpo+kGL8nKFszag1rmv8XZ9DqRFy V9pmQBZxuul2Pds2VsKZ4GQvu5pqM01Dsn7wx7oGqtniB2G39fsaMrzR6yzD1zzMcohU Oojw== X-Received: by 10.236.118.178 with SMTP id l38mr462338yhh.31.1362708990434; Thu, 07 Mar 2013 18:16:30 -0800 (PST) Received: from bonaire.local ([2001:470:d815:fe0:a8c2:d7ea:5baf:cbc2]) by mx.google.com with ESMTPS id b62sm5514774yhe.24.2013.03.07.18.16.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 18:16:28 -0800 (PST) Message-ID: <51394A15.5000608@gmail.com> Date: Fri, 08 Mar 2013 00:16:53 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Marc Blanchet References: <51394528.5020702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 02:16:31 -0000 I'm willing to collaborate with him and others. I like the idea of preparing a report to the WG. cheers ~Carlos On 3/8/13 12:00 AM, Marc Blanchet wrote: > - we have been preparing a test plan and test scripts. We will be able to do some testing on the different implementations during the tuesday session. My colleague Jean-Philippe could drive that testing and report results to the wg. > > Regards, Marc. > > Le 2013-03-07 à 17:55, "Carlos M. martinez" a écrit : > >> I think we should have a basic testing protocol in place. >> >> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: >>> Colleagues, >>> >>> I'm wondering about structure for the demos on Tuesday morning. For >>> example, do we need to set up an agenda for the bake-off, or do people >>> just want to set up their demos in corners and let people wander among >>> them, try, and comment? >>> >>> Should we appoint someone to report to the working group later that day, >>> or should that also be done organically? >>> >>> >>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy >>> > wrote: >>> >>> Change of location: Now in Caribbean 4. Still on Tuesday morning at >>> 8am. >>> >>> -MSK, WEIRDS co-chair >>> >>> >>> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >>> > wrote: >>> >>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >>> room Boca 1 for implementation demos. We only have that one >>> hour before other sessions begin, so please come prepared! >>> >>> -MSK >>> >>> >>> >>> >>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >>> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > From jean-philippe.dionne@viagenie.ca Fri Mar 8 08:02:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71BF21F85CB for ; Fri, 8 Mar 2013 08:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ub8CoPId9Nw for ; Fri, 8 Mar 2013 08:02:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E525321F87DF for ; Fri, 8 Mar 2013 08:02:31 -0800 (PST) Received: from JPD.local (modemcable151.71-82-70.mc.videotron.ca [70.82.71.151]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 15B9E46F53; Fri, 8 Mar 2013 11:02:31 -0500 (EST) Message-ID: <513A0B96.2060002@viagenie.ca> Date: Fri, 08 Mar 2013 11:02:30 -0500 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Marc Blanchet References: <51394528.5020702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:02:38 -0000 Hi, Could you share here pointers to your client or server implementations prior to the demo? It will help us to find some common ground for testing. I'd like to establish what resources servers make available to clients, what can be queried and what cannot. Up to now, my sources are the servers listed at rdap.org and the 'rdapper' client. Thank you Jean-Philippe On 2013-03-07 21:00, Marc Blanchet wrote: > - we have been preparing a test plan and test scripts. We will be able to do some testing on the different implementations during the tuesday session. My colleague Jean-Philippe could drive that testing and report results to the wg. > > Regards, Marc. > > Le 2013-03-07 à 17:55, "Carlos M. martinez" a écrit : > >> I think we should have a basic testing protocol in place. >> >> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: >>> Colleagues, >>> >>> I'm wondering about structure for the demos on Tuesday morning. For >>> example, do we need to set up an agenda for the bake-off, or do people >>> just want to set up their demos in corners and let people wander among >>> them, try, and comment? >>> >>> Should we appoint someone to report to the working group later that day, >>> or should that also be done organically? >>> >>> >>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy >>> > wrote: >>> >>> Change of location: Now in Caribbean 4. Still on Tuesday morning at >>> 8am. >>> >>> -MSK, WEIRDS co-chair >>> >>> >>> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >>> > wrote: >>> >>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >>> room Boca 1 for implementation demos. We only have that one >>> hour before other sessions begin, so please come prepared! >>> >>> -MSK >>> >>> >>> >>> >>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >>> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds From aservin@lacnic.net Fri Mar 8 08:23:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0921F879D for ; Fri, 8 Mar 2013 08:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QapHDlu7albN for ; Fri, 8 Mar 2013 08:23:25 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C921F8801 for ; Fri, 8 Mar 2013 08:23:23 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:11be:367:61d9:b287]) by mail.lacnic.net.uy (Postfix) with ESMTP id E086A30844E for ; Fri, 8 Mar 2013 14:23:04 -0200 (UYST) Message-ID: <513A106F.4000207@lacnic.net> Date: Fri, 08 Mar 2013 14:23:11 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <51394528.5020702@gmail.com> <513A0B96.2060002@viagenie.ca> In-Reply-To: <513A0B96.2060002@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:23:30 -0000 Ours (it is already listed in rdap.org): http://restfulwhoisv2.labs.lacnic.net/restfulwhois/ examples http://restfulwhoisv2.labs.lacnic.net/restfulwhois/ip/200.7.84.0/23/ http://restfulwhoisv2.labs.lacnic.net/restfulwhois/entity/UY-LACN-LACNIC/ Any bugs, comments or complaints with Carlos or me. We both will be in Orlando. Regards, as On 08/03/2013 14:02, Jean-Philippe Dionne wrote: > Hi, > > Could you share here pointers to your client or server implementations > prior to the demo? It will help us to find some common ground for > testing. > > I'd like to establish what resources servers make available to clients, > what can be queried and what cannot. > > Up to now, my sources are the servers listed at rdap.org and the > 'rdapper' client. > > Thank you > Jean-Philippe > > On 2013-03-07 21:00, Marc Blanchet wrote: >> - we have been preparing a test plan and test scripts. We will be able to do some testing on the different implementations during the tuesday session. My colleague Jean-Philippe could drive that testing and report results to the wg. >> >> Regards, Marc. >> >> Le 2013-03-07 à 17:55, "Carlos M. martinez" a écrit : >> >>> I think we should have a basic testing protocol in place. >>> >>> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: >>>> Colleagues, >>>> >>>> I'm wondering about structure for the demos on Tuesday morning. For >>>> example, do we need to set up an agenda for the bake-off, or do people >>>> just want to set up their demos in corners and let people wander among >>>> them, try, and comment? >>>> >>>> Should we appoint someone to report to the working group later that day, >>>> or should that also be done organically? >>>> >>>> >>>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy >>>> > wrote: >>>> >>>> Change of location: Now in Caribbean 4. Still on Tuesday morning at >>>> 8am. >>>> >>>> -MSK, WEIRDS co-chair >>>> >>>> >>>> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >>>> > wrote: >>>> >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >>>> room Boca 1 for implementation demos. We only have that one >>>> hour before other sessions begin, so please come prepared! >>>> >>>> -MSK >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >>>> >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From edainow@afilias.info Fri Mar 8 14:00:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFF21F8569 for ; Fri, 8 Mar 2013 14:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71W5Ym9nwrOM for ; Fri, 8 Mar 2013 14:00:36 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id B350421F8168 for ; Fri, 8 Mar 2013 14:00:36 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UE5L9-00069g-61 for weirds@ietf.org; Fri, 08 Mar 2013 22:00:35 +0000 Received: from mail-wg0-f69.google.com ([74.125.82.69]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UE5L9-0004x7-5B for weirds@ietf.org; Fri, 08 Mar 2013 22:00:35 +0000 Received: by mail-wg0-f69.google.com with SMTP id fn15so3527813wgb.8 for ; Fri, 08 Mar 2013 14:00:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=bHWdywxjHaYUjoj5sg2rII8hu+OvUvCYtX7pVg7Z64o=; b=aUwCyp800oSvQnqozDaFobReKP+/s9BdmxyPP6hfOyFLCwVDgW1PZ0M6gg1GhQd1iB fv0EWIzyjCPvFNWg+eSVYlnHJiapdi3KX3IH66YbaKK8EZHu2gHTF39mH57prG02jqdj YksUl5iu0+jaaynTy2yjnig/ytTKX+k+zJeenfx97528xhMWZkWlzFL/wWbZGDx6YmpE 9uQ85c7NeFjFxsEWdvjayOr2ZxxC667/UsiDt1nB/+vHSCvR1ha1zoQBuI4GMD17I0QO J/AV09I2qMImJ1En5JKd+1gTMObP2jh6jugJSeJjwCLGukzl53pDX2t3LZ3ZmPgrgmBF m/PQ== X-Received: by 10.152.132.138 with SMTP id ou10mr3367384lab.56.1362780029380; Fri, 08 Mar 2013 14:00:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.132.138 with SMTP id ou10mr3367371lab.56.1362780029192; Fri, 08 Mar 2013 14:00:29 -0800 (PST) Received: by 10.112.13.235 with HTTP; Fri, 8 Mar 2013 14:00:28 -0800 (PST) In-Reply-To: <513A0B96.2060002@viagenie.ca> References: <51394528.5020702@gmail.com> <513A0B96.2060002@viagenie.ca> Date: Fri, 8 Mar 2013 17:00:28 -0500 Message-ID: From: Ernie Dainow To: Jean-Philippe Dionne Content-Type: multipart/alternative; boundary=f46d042d051c8c1f8904d770f3fa X-Gm-Message-State: ALoCoQnOijE7znT6a5yv7HtIoNwuJwOhuXc2UKPxTOZoU6akDKv3U/dsSF79PaLLj/ncZlZ2Aar3ykkQlTNo+0diVM3nxWBVcHxqp49O+OOHn9Jz+UZO36Mh76RuJ0Lw4uO9en9dPOoE Cc: weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 22:00:37 -0000 --f46d042d051c8c1f8904d770f3fa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You can get all the information for our server at http://rdg.afilias.info/rdap/help -Ernie On Fri, Mar 8, 2013 at 11:02 AM, Jean-Philippe Dionne < jean-philippe.dionne@viagenie.ca> wrote: > Hi, > > Could you share here pointers to your client or server implementations > prior to the demo? It will help us to find some common ground for > testing. > > I'd like to establish what resources servers make available to clients, > what can be queried and what cannot. > > Up to now, my sources are the servers listed at rdap.org and the > 'rdapper' client. > > Thank you > Jean-Philippe > > On 2013-03-07 21:00, Marc Blanchet wrote: > > - we have been preparing a test plan and test scripts. We will be able > to do some testing on the different implementations during the tuesday > session. My colleague Jean-Philippe could drive that testing and report > results to the wg. > > > > Regards, Marc. > > > > Le 2013-03-07 =E0 17:55, "Carlos M. martinez" a > =E9crit : > > > >> I think we should have a basic testing protocol in place. > >> > >> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: > >>> Colleagues, > >>> > >>> I'm wondering about structure for the demos on Tuesday morning. For > >>> example, do we need to set up an agenda for the bake-off, or do peopl= e > >>> just want to set up their demos in corners and let people wander amon= g > >>> them, try, and comment? > >>> > >>> Should we appoint someone to report to the working group later that > day, > >>> or should that also be done organically? > >>> > >>> > >>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy > >>> > wrote: > >>> > >>> Change of location: Now in Caribbean 4. Still on Tuesday morning = at > >>> 8am. > >>> > >>> -MSK, WEIRDS co-chair > >>> > >>> > >>> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy > >>> > wrote: > >>> > >>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, = in > >>> room Boca 1 for implementation demos. We only have that one > >>> hour before other sessions begin, so please come prepared! > >>> > >>> -MSK > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> weirds mailing list > >>> weirds@ietf.org > >>> https://www.ietf.org/mailman/listinfo/weirds > >>> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --f46d042d051c8c1f8904d770f3fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You can get all the information for our server at
http://rdg.afilias.info/rdap/help

-Ernie


On Fri, Mar 8, 201= 3 at 11:02 AM, Jean-Philippe Dionne <jean-philippe.dionne@v= iagenie.ca> wrote:
Hi,

Could you share here pointers to your client or server implementations
prior to the demo? =A0It will help us to find some common ground for
testing.

I'd like to establish what resources servers make available to clients,=
what can be queried and what cannot.

Up to now, my sources are the servers listed at rdap.org and the
'rdapper' client.

Thank you
Jean-Philippe

On 2013-03-07 21:00, Marc Blanchet wrote:
> - we have been preparing a test plan and test scripts. We will be able= to do some testing on the different implementations during the tuesday ses= sion. My colleague Jean-Philippe could drive that testing and report result= s to the wg.
>
> Regards, Marc.
>
> Le 2013-03-07 =E0 17:55, "Carlos M. martinez" <carlosm3011@gmail.com> a =E9crit : >
>> I think we should have a basic testing protocol in place.
>>
>> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote:
>>> Colleagues,
>>>
>>> I'm wondering about structure for the demos on Tuesday mor= ning. =A0For
>>> example, do we need to set up an agenda for the bake-off, or d= o people
>>> just want to set up their demos in corners and let people wand= er among
>>> them, try, and comment?
>>>
>>> Should we appoint someone to report to the working group later= that day,
>>> or should that also be done organically?
>>>
>>>
>>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy
>>> <superuser@gmail.com= <mailto:superuser@gmail.com<= /a>>> wrote:
>>>
>>> =A0 =A0Change of location: Now in Caribbean 4. =A0Still on Tue= sday morning at
>>> =A0 =A08am.
>>>
>>> =A0 =A0-MSK, WEIRDS co-chair
>>>
>>>
>>> =A0 =A0On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >>> =A0 =A0<superuser@gm= ail.com <mailto:superuser@gma= il.com>> wrote:
>>>
>>> =A0 =A0 =A0 =A0The Secretariat has assigned us 8am-9am on Tues= day, March 12, in
>>> =A0 =A0 =A0 =A0room Boca 1 for implementation demos. =A0We onl= y have that one
>>> =A0 =A0 =A0 =A0hour before other sessions begin, so please com= e prepared!
>>>
>>> =A0 =A0 =A0 =A0-MSK
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> weirds mailing list
>>> weirds@ietf.org
>>> https://www.ietf.org/mailman/listinfo/weirds
>>>
>> _______________________________________________
>> weirds mailing list
>> weirds@ietf.org
>> https://www.ietf.org/mailman/listinfo/weirds

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--f46d042d051c8c1f8904d770f3fa-- From carlosm3011@gmail.com Fri Mar 8 16:03:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADB221F85BB for ; Fri, 8 Mar 2013 16:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8475k9-vvht8 for ; Fri, 8 Mar 2013 16:03:13 -0800 (PST) Received: from mail-ye0-f176.google.com (mail-ye0-f176.google.com [209.85.213.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2121F85B4 for ; Fri, 8 Mar 2013 16:03:13 -0800 (PST) Received: by mail-ye0-f176.google.com with SMTP id m9so367138yen.7 for ; Fri, 08 Mar 2013 16:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=t/dMwUQIlHZnvzWW6Mtt1v6AUsOFxarhdwF7U6AdtmI=; b=Ei+baTscfhifwqFCiPpPYaoZ65bBPNB7ed/4uRWL5G/kNls7CpdNcGwgg+Nnr/kLdW PRdkJom0kT+a+DkZ9aV3gZe0LjFKIGcXnVhFpyU5lasumb2qC5PQO69LlX+S8rpg112w oDf8NVCfCI6km617T0sAT7897YSXEuU5wt3Rjgb3wc0esf9D9Nl7tvDCcm2u60WnoP1c vqmYYOE9NpduJQjKKvDsMGP/wXdAaPvnj3/UMopPWKi7QamSAYhdSaHcL97kaaLLK21J 1AmYOcO12LMw9adnR5Xnx4pRO+0L4m19p522+tdPyHD7D6GyWqqo7dSCOLfTwfcXv/o/ AdwA== X-Received: by 10.236.183.200 with SMTP id q48mr3502362yhm.21.1362787389197; Fri, 08 Mar 2013 16:03:09 -0800 (PST) Received: from [192.168.189.203] (r190-135-10-231.dialup.adsl.anteldata.net.uy. [190.135.10.231]) by mx.google.com with ESMTPS id g27sm10818244yhm.21.2013.03.08.16.03.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 16:03:07 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Carlos M. Martinez (ML)" In-Reply-To: <513A0B96.2060002@viagenie.ca> Date: Fri, 8 Mar 2013 22:03:23 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <041B737B-E498-4B82-8920-A4CE145BFB57@gmail.com> References: <51394528.5020702@gmail.com> <513A0B96.2060002@viagenie.ca> To: Jean-Philippe Dionne X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:03:14 -0000 Sure. We have an online demo at = http://restfulwhoisv2.labs.lacnic.net/restfulwhois you can look at. However, I'll be running the server in a VM for testing. regards Carlos On Mar 8, 2013, at 2:02 PM, Jean-Philippe Dionne = wrote: > Hi, >=20 > Could you share here pointers to your client or server implementations > prior to the demo? It will help us to find some common ground for > testing. >=20 > I'd like to establish what resources servers make available to = clients, > what can be queried and what cannot. >=20 > Up to now, my sources are the servers listed at rdap.org and the > 'rdapper' client. >=20 > Thank you > Jean-Philippe >=20 > On 2013-03-07 21:00, Marc Blanchet wrote: >> - we have been preparing a test plan and test scripts. We will be = able to do some testing on the different implementations during the = tuesday session. My colleague Jean-Philippe could drive that testing and = report results to the wg. >>=20 >> Regards, Marc. >>=20 >> Le 2013-03-07 =E0 17:55, "Carlos M. martinez" = a =E9crit : >>=20 >>> I think we should have a basic testing protocol in place. >>>=20 >>> On 3/7/13 10:27 PM, Murray S. Kucherawy wrote: >>>> Colleagues, >>>>=20 >>>> I'm wondering about structure for the demos on Tuesday morning. = For >>>> example, do we need to set up an agenda for the bake-off, or do = people >>>> just want to set up their demos in corners and let people wander = among >>>> them, try, and comment? >>>>=20 >>>> Should we appoint someone to report to the working group later that = day, >>>> or should that also be done organically? >>>>=20 >>>>=20 >>>> On Thu, Mar 7, 2013 at 12:32 PM, Murray S. Kucherawy >>>> > wrote: >>>>=20 >>>> Change of location: Now in Caribbean 4. Still on Tuesday morning = at >>>> 8am. >>>>=20 >>>> -MSK, WEIRDS co-chair >>>>=20 >>>>=20 >>>> On Fri, Mar 1, 2013 at 10:21 AM, Murray S. Kucherawy >>>> > wrote: >>>>=20 >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, = in >>>> room Boca 1 for implementation demos. We only have that one >>>> hour before other sessions begin, so please come prepared! >>>>=20 >>>> -MSK >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >>>>=20 >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >=20 From steve.sheng@icann.org Mon Mar 11 13:04:19 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0193F21F8E4D for ; Mon, 11 Mar 2013 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKJCql9+fnXK for ; Mon, 11 Mar 2013 13:04:17 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEF621F8E4B for ; Mon, 11 Mar 2013 13:04:17 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 11 Mar 2013 13:04:17 -0700 From: Steve Sheng To: "Murray S. Kucherawy" , John Levine Date: Mon, 11 Mar 2013 13:04:16 -0700 Thread-Topic: [weirds] Preliminary agenda Thread-Index: Ac4ek5vDwB63xBt5SRy01siOiWgF4A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3445862652_4002163" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:04:19 -0000 --B_3445862652_4002163 Content-type: multipart/mixed; boundary="B_3445862652_3991529" --B_3445862652_3991529 Content-type: multipart/alternative; boundary="B_3445862652_4042526" --B_3445862652_4042526 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thank you Murray, attached please find a slide deck summarizing some recent ICANN work related to internationalized registration data. If there is no time to discuss it tomorrow, I am happy to answer questions either on or off the list. Steve From: "Murray S. Kucherawy" Date: Friday, March 1, 2013 10:19 AM To: John Levine Cc: "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda > While generally I agree, I'm not quite as strict as how that was stated. I-D > development is the priority, to be sure, but not to the point of exclusion of > all else. > > Since we haven't completely filled the agenda with I-D work, I don't mind > assigning some time at the end to material like this. I certainly think it's > likely to be information we should be aware of as we develop our I18N > solutions. > > Steve, yes, it would be ideal if you had something you could circulate to the > WG beforehand so we're prepared to use the time well. We're past the point of > being able to submit a new draft, and I'm not sure that's the right path for > what you want to talk about anyway, so sending some material to the list prior > to our meeting on the 12th would be dandy. > > -MSK, co-chairin' > > > On Fri, Mar 1, 2013 at 8:20 AM, John Levine wrote: >>> >In the mean time, how about I produce a slide deck and send it to the WG. >>> >Then the chairs can decide whether there is useful enough contribution for >>> a >>> >presentation. >>> > >>> >John and Peter, would that address your concern? >> >> Yes. In case there's any misunderstanding, I don't doubt that the >> ICANN i18n work is interesting and probably relevant. But if it's not >> part of the process of turning I-Ds into RFCs, it's not what a WG >> meeting is for. >> >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > --B_3445862652_4042526 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Thank you Murray, attached p= lease find a slide deck summarizing some recent ICANN work related to intern= ationalized registration data. 

If there is no= time to discuss it tomorrow, I am happy to answer questions either on or of= f the list. 

Steve

From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Friday, March 1, 2013 10:19 AM
To: John Levine <john= l@taugh.com>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Preliminary agenda

While generally I agree= , I'm not quite as strict as how that was stated.  I-D development is t= he priority, to be sure, but not to the point of exclusion of all else.
<= br> Since we haven't completely filled the agenda with I-D work, I don't mind a= ssigning some time at the end to material like this.  I certainly think= it's likely to be information we should be aware of as we develop our I18N = solutions.

Steve, yes, it would be ideal if you had someth= ing you could circulate to the WG beforehand so we're prepared to use the ti= me well.  We're past the point of being able to submit a new draft, and= I'm not sure that's the right path for what you want to talk about anyway, so sending some material to the list prior to our meeting on= the 12th would be dandy.

-MSK, co-chairin'


On Fri, Mar 1, 20= 13 at 8:20 AM, John Levine <johnl@taugh.com>= ; wrote:
>In the mean= time,  how about I produce a slide deck and send it to the WG.
>Then the chairs can decide whether there is useful enough contribution = for a
>presentation.
>
>John and Peter, would that address your concern?

Yes.  In case there's any misunderstanding, I don't doubt that the
= ICANN i18n work is interesting and probably relevant.  But if it's not=
part of the process of turning I-Ds into RFCs, it's not what a WG
meeting is for.


_______________________________________________
weirds mailing list
weirds@ietf.org=
h= ttps://www.ietf.org/mailman/listinfo/weirds
=

--B_3445862652_4042526-- --B_3445862652_3991529 Content-type: application/pdf; name="ICANN-IRD Work.pdf" Content-disposition: attachment; filename="ICANN-IRD Work.pdf" Content-transfer-encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAF1U01PwzAMvfdXmI+xFFhWJ03S8s0GF25IlTgA p4mJw4Y09v8lnBB7G2VtJTuNn/3y7KzgGVZgPX26osdAwFa39ICrK/j+gBf4gvF0jTBbA6Z3 PYsAF9xv3BKC+3UL+beQf5zYwmKrTFx9wvw0ZjYxc5VeyryiEnGB0AaNiYhtG22DK2ZLmHRA rOJLhigb662FES26JYy7DnWk2M3hFdTBYQmVrkEdRYugeH1cFqO0MTgpgTzaGr6p5BpQb2WG nUbrQLGV4LO4QZHnCWILNcoIna1E5ghQxymUuMjWcMwFOX+VaBEZiUGBmS38O3RP8NilxvW1 ctW/WqHTaE2De7QaSqUBq8SHErXQJhJEsH8srNMeqeXY8Zxoi3vUnfDSmRAFs1ugiksMuPz+ qsVGKNESB0jqbRSiBtpgXN3GVva8nXFDh9RU472u86RZkyaNDHqnGx8MjGjRn7SGzyzitflg h2WRJk1aKqEXCUMTwTJJB1iUnYNsrkXmaZp/eIZG+7qpa+LZah/iLe6zvYzcaHyvss3cCnWN LDrfGCEp/Bl0k8Gc7PZvsjuBDO/TUanNE3amLJgEPWT8426eeBmKTTuffwBL29wSCmVuZHN0 cmVhbQplbmRvYmoKNSAwIG9iago0NTYKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFC b3ggWzAgMCA3OTIgNjEyXQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwKL1RUMS4xIDEwIDAgUiA+PiA+PgplbmRvYmoKMTEgMCBvYmoKPDwgL0xlbmd0aCAxMiAw IFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZk VMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTC dFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Am c9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mY lybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFs iTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TDTeGI eEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s 7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r 6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyf wBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMD JG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMECEpAH dKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6C NnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQ kkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4 FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6k G7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92 CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U 74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5 xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+S P1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV 65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1 xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo 5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pM VW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoa vhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3RPqTd qz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItB m8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8M a+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTq sPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O 99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKRLmQu jF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS 92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkS BXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtI j8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps 4grj7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5Lnxivn jfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNC JWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2Wf ylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I 2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1Ysvi iuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5W YVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/ yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax43HH b/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2pDZpe0x7 3+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2usK7e y4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV9 5/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t /dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pj hb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/9oH9oftj 9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoK MjYxMgplbmRvYmoKOCAwIG9iagpbIC9JQ0NCYXNlZCAxMSAwIFIgXQplbmRvYmoKMTMgMCBv YmoKPDwgL0xlbmd0aCAxNCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVXfb9tUFD6Jb1KkFj8gWEeHisWvVVNbuRsa rcYGSZOl7UoWpenYKiTkOjeJqRsH2+m2qk97gTcG/AFA2QMPSDwhDQZie9n2wLRJU4cqqklI e+jEDyEm7QVV4bt2YidTxFz1+ss53znnO+de20Q9X2m1mhlViJarrp3PJJWTpxaUnk2K0rPU SwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O9iO/eovc0YkiT8BuFR19GfgMUczUa7ZLFL8H +/hptwbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7QKusVrQi8Bjy82GYvt2FfAxjIk+FVbhu6 ImaRs62SYXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J3iv2VL6JP9e19BzwS7Bfr7lJYX8F +I/60nwCeB9R9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7HBix0fUl65jIIzjXdWcSs6QX gO9W+LTYY+iRqMhTaeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+nzeSAB4A/tK28qAXN0jo3 M6IW8ktXa26uqUHarppZUQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR6SZ/rWZ6ZxHa2AW7 nhfakJ/d0ux0Bhh52D+8Oi/mBhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4ylMS9RjY8JTLI hIXDy2ExIk/SEmzdeTmP48eEjLIXvS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOksDfYm+wI S8E6wQ4FCnJtOhUq030o9fO8T3VUFjpOUPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0W+0T IAcTaHU30j6na2s/7A48yga7+M7tvmtrdPxx843di23HNrBuxrbC+NivsS38bVICO2B6ipah yvB2wgl4Ix09XAHTJQ3rb+BZ0NpS2rGjper5gdAjJsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztq hBk7piR9Kn0r/Sh9J30v/UyKdFm6Iv0kXZW+kS4FObvvvZ8l2HuvX2ET3YpdaNVrnzUnU07K e+QX5ZT8vPyyPBuwFLlfHpOn5L3w7An2zQz9Hb0YdAqzak21ey3xBBg0DyUGnQbXxlTFhKt0 Flnbn5OmUjbIxtj0I6d2XJzllop4Op6KJ0iJ74tPxMfiMwK3nrz4XvgmsKYD9f6TEzA6OuBt LEwlyDPinTpxVkX0CnSb0M1dfgbfDqJJq3bWNsoVV9mvqq8pCXzKuDJd1UeHFc00Fc/lKDZ3 uL3Ci6MkvoMijuhB3vu+RXbdDG3uW0SH/8I761ZoW6gTfe0Q9b8a2obwTnzmM6KLB/W6veLn o0jkBpFTOrDf+x3pS+LddLfReID3Vc8nRDsfNxr/rjcaO18i/xbRZfM/WQBxeAplbmRzdHJl YW0KZW5kb2JqCjE0IDAgb2JqCjEwNDcKZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQgMTMg MCBSIF0KZW5kb2JqCjE2IDAgb2JqCjw8IC9MZW5ndGggMTcgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AaVW227TQBB936+YhqaxW7zxXuyNeaQCSrmpkiUeKE8RFUIN Usg39X/4JGYvM143bkohqeLL7s7ZOefsTLdwBVswLf7JGj8anOpkhx9obA2/vsFn+AnL852C 9Q5U+O7WfkHjmjhvA66Jt4Lf3fI7CmzgNoPxT9/h5tRH1j5yHb4YeYsQ/kGB66SKGzGNdM52 Yr2Blz1YGybgRbdOGr1SUOFDv4Fl3yvp99jfwBcoXpdQ42PxvISqlgYKZcNdA0VdCnyFYycl fIX+El71gYg9bGtbaSECGx2Aw6XC34ioZS0CYnFXQv8jRiLCDqU1HVopqWujNCCCiAiGciqO RgiPEpch+HRRXtwoisd5aJdEH9LJCXxTNUgYsjS7GHgS3jAHeYpQyE8O1TVyhVJZn9egVWQO tTqbJahKR8j6n4RRKy1tY9ARzF6eEGYRZX/rrWEHi/AAe+U4TMUpaUgUVVozS1c2E73o/IC3 Ga+dc9zFdRECaiiuy1IE8FM/H81IV5585gdwJm+GoGWCxpnJtSM1lGpwma1XbFm9CpYNl8pY 6Yh7dG08J8Xv5CmMdMC1h0IjauO0dkh6QhB4Ep/q2kMIWssmFKeIkM5Fruxi4JzkINJ4RBmS n4k9DnUAVR5Kg/dhkKWlQN6RQTAW6IiGXJI8LRJYWJLD5gQ/iXo/4DIsQ8nVXCUUUZBJebcU kmzAW+UUaT+DQXxZw1MWS6oyDg1i2gcMgjZ5uIpGcDGY8pJoeUc3zM95eIPW3t/hQPQJ1WBm kwPtZewP0lSdjqYx6DubusMTHI/UPOr46dD7jve9568cL4bimW0+dZhh8/ccP6HLYhn4Q8/s 1Y/3JIgix7AOWW1iq7LhPoR1sSuO6+QLisjKcMQ8zFRR4jauO1RpspV2snX+Pw5uqKk03ZXi KQ11GiBrqAnnf9tqhiMme+k4n1GZ4lpCFYSPrqHjcBG4Rl0/DtU+qsGcf0oNgg8M96I0RRTP /BSU8lD5yaWLCIzNOlepWfHZZkzyFk+d8x2B84u0P0HdFBt+SoGnUDgqbqMTf/UH/TgLjgpl bmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjc5MQplbmRvYmoKMTUgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE4IDAgUiAvQ29udGVudHMgMTYgMCBS IC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagoxOCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIg Pj4gL0ZvbnQgPDwKL1RUMi4wIDE5IDAgUiAvVFQzLjEgMjEgMCBSIC9UVDEuMSAxMCAwIFIg Pj4gPj4KZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AY1Ry07DMBC8+yuGR8EpJHEejpUriAu3SpZ6oJwiKg4NUsj/ S6wd76btCTvK2vuYHc9O2GFC09FXGFo1XNUXPS3Y1uD3C3v8oHydKwwzqrjnIRRYZ5e8Ec4u RyW+k/gYuMHprE24feO4Dch1QDaFbVxt2349qdVHHSdqbWgTBWMK4yyaqscw4sUH3BCKJqe/ H1F63xaBrj/iQ+mbjHBb6Ntk74JtoO8z5DGwiQe7ZjykjEfOOOhYqwSDMw5ZAt0m+8RYgv6c InmMVNBFCildsourTcilFKYozLjfNSPmrLTAV0yaaxiM75T5Cf+ONx/nfy1t7Tr1P2mh69iL tEwCQQvjZnnTKpk8Vpi2sbo+KxIYm0TrLsVT2rFUPE1+lUxC4FlnaEYR+E2maPQ0cdbmQpPd H9gDkScKZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iagozMTIKZW5kb2JqCjIyIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNSAwIFIgL0NvbnRlbnRz IDIzIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKMjUgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA4IDAgUiAvQ3Mx IDcgMCBSID4+IC9Gb250IDw8Ci9UVDQuMSAyNyAwIFIgPj4gPj4KZW5kb2JqCjI5IDAgb2Jq Cjw8IC9MZW5ndGggMzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1X 227TQBB9368YCmmdQrZeX+KYFyQoEhQJKFjiAfEQqhSCklRtwifxn8xe5qwTu22oSKpku5c5 M2fOzDrXdE7XlI/5T6f8yqgyta75RWWR0s2MvtCKTl6tDV2sybj3+sIeKKvS71tSVfqhwtwC c2I4p0ULxv73ky6PreXMWk51UU/SvM7iSMU5Rrxm6JTfhsaVNt7BstAFXSzpZcOn2PmcGnaN TfDbfY34s1nSSdOUOlWGmkv6Ssnb9ZDNJDTfkB/9nm+m3xcz2lyFhdVmduOGq+lm7idX08Xc 757R6dWQjSXL6XxFQ/pGzRm9bhyRXR/NGD7e79n7IY1SnVEydYOCMdyAwWYyw4i8J6fk05CK VJetpR/zofLn2VNnZ+M28x4Oxx2CYazM3RbG5DiZcUpWHkklQDoVyO5pzLzYhwjlkxWJyIta l8W4pq1McXY4Uxa/+eWZtRlNaUsG2SRnpoqC+Q1ms4nb5b5G/Okzn2krGmvvT7Qngv5Hu7We pFmVFxTN59oWhTX/aMu8VzXcZr1YLEMttzvSjQHYxLpqjEAmAClW8McDp870sJ/0gGFySC9a TpnqQle2LhTXxQPZ6TUd2XEIyvO/J0FMzRZBvQiRljaCMGNr+xEz41RcBcGXUgGpG3AlDUZh i3nilc5TqSscXmRGuYJ48FzWTB0siWVsGWDPzpJKBALo4g6ODKKZZw6KKxpT5wJ+MLRd0K30 tZk8szWQV7ckGjXgGFK++32w4XC5AxUsYKZw8Nw14D72+DhUciYeGmzmfuTaEaJ4GpAQM8w9 tiuOZNuvfHyedmxBumCul+4WKyixwEpe98t/m5VwJ0gGP7u4jEreSYCyIj4PTO739FEIZ6O2 MietdoydDMCgSO12CGVF0goaZROCTsu9g1ZJS2a+aLqZQuIz4QMhHp24KZbSsVUpy6Wdsz4f fV/Kqqzfx3ZNP6wv9Zv+n32pH+H+vnQU6/0OiaOqQPsoNABRoQHHqFbsNcgnalKOhaSpZIBj yGM0CdvwQ6S6Y4cSLntbupx0YMEgIN6IQHipTw9es1lu7rnC2w2+2wXER8SobXfhggMxcEg6 UtdVadhY8eWukljIWBIyYH8gMx0rbW/36OSmnvSXxnbPCp1c0ARd7piuwOKVh1YTOFGRJcSH UjcDg0kYRdRYCgpocyWuQEhGZsRZaI3N3K4NM+ZH/Dsf79raQJ7btHsteK5c9/QXTdzSk+G4 KO4ifCH9UJ4YoH+gy00Rr8Zdqrh+QGP3Rt2lCqe3qMJvsfjLqJyMdUXjXNdZmWaBNg7XPUny TyPjH5D5yxSFnlQVjXjsH9PAY9IwjDx3n/8FOSCu9gplbmRzdHJlYW0KZW5kb2JqCjMwIDAg b2JqCjEwMDcKZW5kb2JqCjI4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIg L1Jlc291cmNlcyAzMSAwIFIgL0NvbnRlbnRzIDI5IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIg NjEyXSA+PgplbmRvYmoKMzEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMiA4IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDUuMCAz MiAwIFIgL1RUMy4xIDIxIDAgUiAvVFQyLjAgMTkgMCBSIC9UVDEuMSAxMCAwIFIgPj4gPj4K ZW5kb2JqCjM0IDAgb2JqCjw8IC9MZW5ndGggMzUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AeVZbW8ctxH+zl9BKz35Tq3WJJfcl+ZDEBtBggRoY+jSJI3yQbGVWoGk wD4F+ft9OOQMuXt7qmR9rGVoydnhM+9DcvVev9bvddvhf2Pwz+nejs2Ifzp4oz9c6u/1rX7x amf1m5229LN7ExeEPiS+G92HNFRCuxYaA7f6uhITZ+/0rycR2UVk0/hxMO3oykgVGiS+h2iD H6u7vrFJweAbr9/c6JdbrILyVm+hGiDwQ49T/N7e6BfbbWiMwutf9U96/ee7izv99uLuQl9e X95c3t7pq53e/XF1d/HL9aW++30DIWv9y6Xe6J/19mv9xZacxPKt6Rung+0aryrhkHSPcEAm 4Ve3d5cfSMLtxd1VknV7cX21u3yrjzWptru7uH178WEDhddvd5/piR4SguKQMHRNr7u2GV1A AJNOp+QRUsoOyXODtt43Q9/rUzuo5BfbRECotv7ueKO3vyVjX3yJeP9nJ3E3TWsoPPBzMGEY nMeo99b2XVCIjoVcHzp9o1tjmz70HU0RcpnaHnSEnVh5QjlQeEKnbrT3XWNt22eEMuVFhZ8p BFMYSZHeGRVVQio6oz2zFi6m0GLTDDZ0Q9fCrsH30UaMxmz17o2q1K6NZBDRqe3Hhs3k8cRK lVWpDWUUUY5X7sFOLC1QExPjhAH2ELO1IxzsQog2uhFxHFBtY3SA63WOZ4KojGXMopS3jRNj efJOoa4LD/mjMpZRima8sKxhCkEVxgxV20djZi+cTJnGFjYuxZZSsk1LanMZpOhlYt+KmdCa VuUOVt4ywr4ahUIIZQlNZ1YyzMQ0mhD3DGsazxjFFM8Y2Vk8sbw2b6qK63ypzzTZt5AQZgrI VBDEPKHMLCSYYlEcCes+3MNjmEEqIwW26OQ6rk/l8pgkFI7kiSplBaUol1fyoilUYWOoiYk0 yQCFlXWJ1YPYzetzP55J+9rYuVJ2GEp9ymRmLS2qjZ1rlhYiGdhYPYWamYDjQIxnRoljYWdO JZRpbGHjwfrMSypzE2WiVzC5Pi2NppYKAquxpBitK4YWmPmiZKYYQnYSNzOqSofYMuK01n4q aRybDicY7i/VNBqhJhpVwUoyWKSulsmKikZQwpwUKorHUcUsfBWNHGpdb4z+U1v1m8ZBweWD gtOvzuicYfTZKxzX6Pxh+qH3xmKfwU86kgiJdlRs0DivuNB2o3PqtGs9Tp8+HiQyDaeA1nVt DOwZjmHp+PMoAfGQ5tveOO91LYBpUwHtYMm6hxsQ8TPuOGg/hB4nYwsL+iH4EWEWUjYh++9j JYy9DcFMJAgpSfhYZOtD32JDL6oz5Ym4o2+jVyvcTHkarvNuGHCoLLhMeSLuaH1H5cohdJny NNzWG+Mn/mXKE3EHnNsm/m0z5WNwY+G63nYm4KJQFWRNn9bM4/KtH/yAXjfBZtpTcEsNQtPg u2lmFNrH+KRg++A6N9S5zJSEyxfa1KgmF1drRlwcwS4Xx3IzgzswSXcyz3cy3FX7kw06qdfr v2xi/8TgfJMpf6OnWpv4xFXxdPm62poBJ0G6kEHw5Hbo45V1pkO+F9Y6PDv6JEqHiFV6HB0/ T4Pz9dHx+ebkr2mWmYY0O92opdszIty06XZX1Imphb1vX5viEbm9j4Fuz5/Q745+15TTv1ev caWF1kf0G+7COFLUepUmZuKyuEWZePl5D8Y4RAhTxCy8EbLnlt0l12iE7AXsNwj0GkIwaPX6 nzFCIFgoCkqoogl9QIFiJxuc3fHGMjO0pngjvIkDrEsOLfGt1ATW/R6tFf42OcgcEFAiRgLy N4+ZH3Kgatgvc16KG1YIDUxBDmerVUnmf9Er+MjTIDriNXOzJ+SVOM1KVbiNmkDr9ffZf49F jj5We598YuW28YvXchosmE+FG9R+QEX7WCgUczYQ6UjuGeMTeTOlK3ZbTBYwPClZyJb689U9 1VcH9aG5UuP/P6ZK2zfdgZaxkCs5E9T6G855KRrJcOkD8orTZb+r9LGZIIEk1Z5xKvU5tWSN wK4YzvIAq5eKQRpOWxuJTEbHCYd7OLJIevjJD7AzdeOlliYdZyJhlkbzD5jovFzyUlhS+7Jp yqvzNbkaHef58+PlrSp1f4f7D2+bMxUWIvmS+lBVu9K0OAISYumGElCJdeJV6x9Zx694YM9o dNh3Ep1a7xwcdXCDrUv8JEqFgPNNToD5B3AJD4l48H7w/CWpDt9wnP5NBOwH+U3V4T5nXknh T2PmIlxf5Oc2Pw8omYPXwbLwYBVFKm/CZcfOcSQVl3K2+J1E5m3ivm1Y4c8S4vf1t58PsIQ/ wJcjSHF2jTtLxIVaePaKPIhNomS6+JJ9+F324Wf5+WnsG/Dx/T517iHboEp/73hU52lJZ+Te vCSqzJAKXtnV15xA0sUOaF6iE5XP+fCQloVDYLJjuSrUUqAe5p+My23hjBoHTLc42dKJcCXh krT8Kb5CvfBTOMR+cko+CglR2HBQp/hK62Hp3PJ5LivsN3ywkr4lHU32ENa4HNmEpwJc2ktS ldrBP2a3zAdsHK1WDF+bem91TkSVBMAXyXTkj49yE5PyxOaynADVZUEqNcl4cNO5t1JTZao1 Vyg/z89zKBGpJYOzY/GntAN710LLkDSTfUjqcfWPnHmSGNURNPWMpVDAwTGjBc9xvd6vtQty Q04hWrqoLmy+55soABLz4/Qo5gXue/TAeTo/D0iXJoGvP+K2gx187sD/3cFr2Fm+zcGQbz+z r6QXSplJdUk0hAJf5+rnk570SMuUvUjJMUPKKIlS8ZsCNRwpdekCK+GdePP1fwHreFhpCmVu ZHN0cmVhbQplbmRvYmoKMzUgMCBvYmoKMjA5MgplbmRvYmoKMzMgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM2IDAgUiAvQ29udGVudHMgMzQgMCBS IC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagozNiAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIg Pj4gL0V4dEdTdGF0ZQo8PCAvR3MyIDM3IDAgUiAvR3MxIDM4IDAgUiA+PiAvRm9udCA8PCAv VFQ1LjAgMzIgMCBSIC9UVDQuMSAyNyAwIFIgL1RUMS4xCjEwIDAgUiA+PiA+PgplbmRvYmoK MzcgMCBvYmoKPDwgL1R5cGUgL0V4dEdTdGF0ZSAvQUFQTDpBQSB0cnVlID4+CmVuZG9iagoz OCAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9BQVBMOkFBIGZhbHNlID4+CmVuZG9iago0 MCAwIG9iago8PCAvTGVuZ3RoIDQxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGlWNtuFEcQfe+vKDtsNGvY8fRcdmZ4iZQIRJwHy2IkkBIgsIBJZDuxDZ/Ef6b6ck73 eowvwba87e66nlNV0+NzOZJzadb6U1b6VUtvx3LUL+naSi4+yAs5k/1fLq1sLsX678uNU+j6 LsidSt+FpeHeCfdguJGTzI3765N83HOWa2e5KttxqJqxTiuT9tTjubqu9NvKui9tCLAZyt5F ujmVnyepBy/gP1b6ezqV/WnqStUx00f5XYrnn5ayUqtS/LN0fqT4go0Tt2GleO83dCF+0Uix wU7QMcUZdD77RSfFW+xQlkc0Q8MU/rw0GkyuTuF38PkBlnlEyxcuYo0v2sviunQntRTIKfPo 0lePNMuo9uGIUV2xLynvq/b/8rrqkLFF+6aYGbkqso34K5kO5Mnka3JOd9WVg7mVawlcM6g5 XSCSmBIg7iDFuZVjoEoMxfOoTOCE5uj6mHXGs+NM37Gi+pEDk2oPYbCugCfj+heVQmB/AhuM S7NKwLoeqmSrofqhbKph7KXVhhrWY3N9Q5nQULVrKAdy8XUp09+BLgyIO1o3W+06lkNV900r qWsb7cXgZGfLSZgVd0hhVietFr6fb8mJhRMdDX8UgG03joYHfkNnxGK1dKNICtv6Le2fH/1C p0SHnQo7XBz4HVWDwdfesEnKR5BIhi29/uCk1QO06XLxGGq7MS4eURlK+KyhwuioA4+moBDP EIP9DfqWMTNzgsKdxjdEFvvc6yNvUGv+mV/o7FCnqUjTsLfWFecorWt+Lc0Zr1VWNTmhOUyK pPLAtGLEpmAUTJTJUHgVywFQ9u5vDZzZxuSMq5PgCJBq6dDMQ3emaVItxUcZbJk56bczSytM KkKbFRwcXFNVb8ADqaadBVJ/4HlVJBsvrASnwv0T+hrHTTw2vb0fj8CbzDCuWIomi4IgsPlY ekgCJFGU9p759EIp6kDW9BJepI32qM+2sQubkjfuWoVHGAdsc8OAbdqyr+OlJZ+x5j4z9psO 0oz1fuIs/99jNvOzPcvTmM3zyRtzB0yg6UjAoZtniv9h7BUIsvgJNcF3iAeunjol5WzPfeqI HjybungJCYrOySSrrBv4ZndTGwUEiXnDQGKhD/vtyRM9m4IpsbmgxOCAAh1bpj86u34GxRsk oERM1KE1ZqhHN/VnPfb3688F6aNTIhJyyuZsCjxeRJnSLHL2e5qmvasPTZskWQyHmXZSogeG R0qB2gx6JpDm94K+ciRD6XUoNbJKX7/GCuAzm2hdy4yzl8HFRBeMKG3dRuS6/W4iAWvMSyct H/+kBzJMmRESKIgA58rjpb1KHaKSXwcCuOQvjNewmRedawE3q2E9Uc8AGKxlu81d45bHkztZ JI20jKLf8nVjyzWVZ+r6W7c+EYy+xuYTND2WgCxmBTPGATMPnZduFpTUdFNw7tJtt18OumFd 9rJuyrHu9L8D4fVLIXd3aTNtxIa3bv2wrVZc38tK1+FVgUEXT9QNnmNH/wGCAwR4CmVuZHN0 cmVhbQplbmRvYmoKNDEgMCBvYmoKMTEyNQplbmRvYmoKMzkgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDQyIDAgUiAvQ29udGVudHMgNDAgMCBSIC9N ZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iago0MiAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIgPj4g L0ZvbnQgPDwKL1RUNS4wIDMyIDAgUiAvVFQzLjEgMjEgMCBSIC9UVDIuMCAxOSAwIFIgL1RU MS4xIDEwIDAgUiA+PiA+PgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0NSAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBpVfpTttAEP6/TzE9gtaFGK+POGn5RVWp BYmKylIPRKU2gEqVUC71jfqenT3mW8c2gVKC4s0ec33fzKyv6JCuqJjwf5rxX061maUz/qOq zOj6lD7SBW2/vjE0vyHjPjdze6CqK79vSXXlhwpzC8yJ4IIWLTX21w86e2El51ZylpazaVbM 8jhScY41XrHqjD+GJnVqxMC0spbOl7Tb8EG2v6DGWWe3spEZjfm7WartpqlSe7o5oyPS75aX i/P5t9vzXwnP6Ysb96Az9/Bz137q0j/93O2vRPH2uf+1oJPT327X6cLPXC5PL24poWNq9uhN w7G1dmS0Yv80T6tJOSmpLCdpqbzxhd/oHmP+bpbEJpvURtybvJvQOEsL0uPExoi0ee5meJS5 gVG6dIOK1wo/RXrLDfgYdm/0lkQiVkbjxEZ/QAdFHZUoGz0NFomcnnYVtX8Ne6HrmZ3goO45 caxTpMhTpAcHlB7BzYOusBAJ0vAfezGA5ipRHFGOVjs0EbrIuIiYsVEZREz1EcvFI/FgZs1l KOQ3TAJI+/6I0u/t1jxuhYkjmL8ZtkQcXopC7Nl3LnJQoQERwgDnD+U47OrEl0MPFeIDVL11 p9lkqIIYDLC0afnFe6Eb/tUhRpCLMyDISCgTlvrR6pGMpQ0COwmpWNSlA1ZxHWFOuELIhSS3 FSTzj3GRp3lhy00Haf3qS0LNT5/vUikz1c/7rjJbtKIGLrt1aXLDFWtVUZEaLjpcBPSTFT2+ bg7Ul/V6Sqa88w96Bqj7yYHJWQlcgGGHE62CsOXIxvwWfAwOAeeJ8AbJAaAxY0ZmI1Hr8Spq JOJ9eHXd0ztDeK2LY1SmHoaXL9rr8WJMLUUMTYFX1NPiRR+vLgGPlD6W1EW2PBYDWxJt4bcY 2FRgDnzHiPvCHb2nRQOp/ipWArAIkj5LtcDMetmhUoNH9/ecFndZR4tNA4HPYlmPANu7w2om oh1rlugyXtnbE4CUxp5PcrBztbHXXPR8+cjlNqL/RFmoHgNsXC+cG1OV5bOCbWYdgfJcOR7C xLUOqOgArohOR4+FpKcOVG6oQj5J9oC/0kYIBCBBWBBhJ/Q1TGAvWhaXB09N9AQsiUpUk76Y LhuVXKBavavbfyFFXJPnrvOZi15IQaW3hdqwiQ+3+DcQbq79w9eKiGWfL3y7fBBfovAWlqt8 CVg+ni9WR+8mey9f0GVw8wghU7giCV/k6iTFpQUV4Ox1fb6thHImrACM0Cgrc8FRJkQzjmRC OlQqsE/IMMKMnBZpXTquvUoZ7MagKw/cglV3kMyYqbvjkKn5bWP47hpT2V80+AUJaYlAnXQD BKc/2ITlrEek5JYYYcSSxMPAAWS3LImrOBN2cMi6U3j1aSnv30N7As2e8GIEPyXhI8HEPygF 7v/95tXufkOVIYLG3b+fWLYzDb0i3m0g2rOKV+5/baG+4gK3g/CKiAnIk1By4KJzh38BoRgN /QplbmRzdHJlYW0KZW5kb2JqCjQ1IDAgb2JqCjExMDcKZW5kb2JqCjQzIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0NiAwIFIgL0NvbnRlbnRzIDQ0 IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNDYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA4IDAgUiAvQ3MxIDcg MCBSID4+IC9Gb250IDw8Ci9UVDUuMCAzMiAwIFIgL1RUMy4xIDIxIDAgUiAvVFQyLjAgMTkg MCBSIC9UVDEuMSAxMCAwIFIgPj4gPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9MZW5ndGggNDkg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AU1QwQ6CMAy98xVPjQSJzG4w J1EvGi/eTJZ4UE9E4gFMkP9P7BiC7dJ273Xtyxpc0CBd8xHEpmBkLnI26IzweeKKN1bHVqJo ITtvC/dAG+37ahjty2DAqgH7DU5R/a1xtxfK2E1WbjIJnRqls3ysghHjjQ2vJnaWQCTIaCgW sEFR42CRMESUwXbSXB8rJCQcbY2VtZmQgYQtcUM0kQskEtE28XnnUzj3OQ6nM+qpcLrsK+XJ /T2KmQwesGecLP/e5QvqUUFBCmVuZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoKMTk5CmVuZG9i ago0NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNTAg MCBSIC9Db250ZW50cyA0OCAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2Jq CjUwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9D czIgOCAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQ0LjEgMjcgMCBSID4+ID4+CmVu ZG9iago1MyAwIG9iago8PCAvTGVuZ3RoIDU0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAG1V21P1EAQ/r6/YgCBHvFKd9teqcYvGhNFgrmkiUbFD15AJGCC/Cb/jz/J 2Zd5uu2W8zDKEdrbl5lnZp55drmlJd1SueDfvOAfQ41u85Z/qK4K+nFO7+g7Hb6407S6I+0+ dyu7oW5qv+6Gmtq/KoxdY0wMl3QdubHfLuniwFo21nLhPmz5ll3YL5qaNtceSFnnTVO1anVD zzuqKreAH6ao8rZsaprzl+6GDrtO5xZjd0EfKds/nNG8yA1lBzMq8pqyPTegKTuZKZ6pKNNz O8UvtZviNfqRe+Oh3UKW874z6o7pZefSlSCsqkVeBXilcfDcY85/PS6T25AYV/ZzRt2VtyRp XRf8tGmtc1OU2lDvoZTIs62Bh1F61TR48rntwZsm8KH3EOf2xCdJbZ5Azjcn/q1NN1dEn4a8 oyRLKUlSERSksXvKqIwau99I0UJBGZiRIZRW9gsI7EahnyR7zmdq6POVW8IhPHYvDEcAw9zr ENvFe7eEw94/cm+1shScopLWNaelKo6Yi74U5sjxyD3mZZU3Yyqp7Neg0K5DJ6i0zjR7rRtj GuaR9aA8WTekEjp1nQdj8trpysBDTKWngRJI31e8JVOVT6NNvm1gTj6qkI8JdezWch+DG7B7 +Q2v3oWri2do7/1ZLwUJW+E2Kb7dFcQl2dXbXheZFa0+MpVtFtkUqyCh5YKJNSlQbb5orNo/ SKZSEXEOEhGJZGroJ2aYiuRwJFZg2DCQxE8kVsFPYHLMs0+zwJAd++SmLKU7WzvAGd8eU8hP PFjkxB5k5YNQcc9Rg30vZSRidKi7wJOyCyroWeCuysTPxoeYZzjvnyKL7+KSG1aY8kcJogdJ 0LTpkQQFIsYEic/LAUFUf1mIwCf6OZKgiZvC1rZVeZYKyT3aW44KeUoxcCahKhp0gjZhEYjw ecywq8BFiJU4EF05DcggWICGgwhTvV71QxJRQBeRZldcIQTs2ohYzOVJGpUNn2TmSE+fZMyp 9KZWSFvg/EWUSAwaJYUrufIBqWwXm2QGlUCIuBRgCvmE73nIvRQ/LnFoVuyGYeyGvTDFuBCe pB67pEx9CWEHLgB5x+JiEdHICexgRENhxBemsPgLv52p9F6rfQmrey4jkyUM4FQGuKhThNsL b59HLJarGbC1NkbW5LXahtVS5yRWcaX6iwJ8oitRFiCNrwyTJHfXNaOr/6WV06b/pVY6D3+h lVeBfOgxybnUILn1gMnjjnD/bIW70r2lRJXGfkSkZNzItQumZMVmHIKjQIeIMogVPQRyw1nS b5jh/1JskNywEJKVO/6jK4ckjzdN8s11pG7u4dtkR65JewgjihD6gwgBX6BJnqVV0Swhcaxv sjShAPoJoOAHZgRCcuINcrL8DTM5GMAKZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagoxMDQw CmVuZG9iago1MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUyIDAgUiAvUmVzb3Vy Y2VzIDU1IDAgUiAvQ29udGVudHMgNTMgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+ CmVuZG9iago1NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFj ZSA8PCAvQ3MyIDggMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwKL1RUMi4wIDE5IDAgUiAv VFQzLjEgMjEgMCBSIC9UVDEuMSAxMCAwIFIgPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5 cGUgL1BhZ2VzIC9QYXJlbnQgNTYgMCBSIC9Db3VudCA4IC9LaWRzIFsgMiAwIFIgMTUgMCBS IDIyIDAgUiAyOCAwIFIKMzMgMCBSIDM5IDAgUiA0MyAwIFIgNDcgMCBSIF0gPj4KZW5kb2Jq CjUyIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDU2IDAgUiAvQ291bnQgMSAvS2lk cyBbIDUxIDAgUiBdID4+CmVuZG9iago1NiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlh Qm94IFswIDAgNzkyIDYxMl0gL0NvdW50IDkgL0tpZHMgWyAzIDAgUiA1MiAwIFIgXSA+Pgpl bmRvYmoKNTcgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDU2IDAgUiA+PgplbmRv YmoKMjcgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9u dCAvVFhSS1hBK0NhbGlicmktQm9sZCAvRm9udERlc2NyaXB0b3IKNTggMCBSIC9Ub1VuaWNv ZGUgNTkgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDYxIC9XaWR0aHMgWyAyNjcgNTM3 IDM0Nwo1MDMgMzU1IDQ5NCA1ODUgNTM4IDI0NiAyNDYgMzk3IDUzNyAyMjYgNTYzIDQ3NCAz OTkgNjMwIDkwNiA0ODAgNjM3IDUzNyA1MzcKNDU5IDQ2MyA2NzYgNDczIDY1OSA1OTEgNTM3 IF0gPj4KZW5kb2JqCjU5IDAgb2JqCjw8IC9MZW5ndGggNjAgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AV2Sy4rbMBSG934KLaeLwYqVOBMwhjJlIIteaNoHsKXjjKGR jeIs8vb9jmKm0MUv+HQu0i+d8vX45RjHxZQ/0uRPsphhjCHJdbolL6aX8xiLTWXC6JeV8p6/ dHNRUny6Xxe5HOMwmaYpjCl/UnJd0t08fQ5TL59073sKksZ4Nk+/X09553Sb5z9ykbgYW7St CTLQ7ms3f+suYspc+nwMxMfl/kzVv4xf91kMN6Ji87iSn4Jc585L6uJZisbatnl7awuJ4b/Q WtAP/r1LRVOFlmR7MCyBpbIsnc2Va061f5zRD2vzatM2Kmu3h5YWFYisrUXRgcja/VZxCyKi O8UdiIhWijWIiG4UX0AEDooHEIFesQMRmM/tQUSrTqMeRETzuQIia3f5oAFERPckO95HRa1T xI0KR1rrcKOiNifjxmVHda9R3KhIzlHcuIcjNehwo6Izr9i4PYhIrhUxp7LWqUGHORXRjJhz 2eAu3wpzLhvc6sM6zKm4VW7Fz7n8e/XL+l2P/9E/19n8mCV/S4kxygOcJ0wnZ4zyMePzNOuk ZP0FYrHSmgplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjQyMgplbmRvYmoKNTggMCBvYmoK PDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVFhSS1hBK0NhbGlicmktQm9s ZCAvRmxhZ3MgNCAvRm9udEJCb3gKWy01MTkgLTMwNiAxMjQwIDk3MV0gL0l0YWxpY0FuZ2xl IDAgL0FzY2VudCA5NTIgL0Rlc2NlbnQgLTI2OSAvQ2FwSGVpZ2h0IDYzMgovU3RlbVYgMCAv WEhlaWdodCA0NjkgL0F2Z1dpZHRoIDUzNiAvTWF4V2lkdGggMTMyOCAvRm9udEZpbGUyIDYx IDAgUiA+PgplbmRvYmoKNjEgMCBvYmoKPDwgL0xlbmd0aCA2MiAwIFIgL0xlbmd0aDEgMTg3 MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB5Zt5YFTV9fjvfW+WzD6T2TOZ zEwmM1kmmcm+kJC8hCRkJetoAgQSwupSEIgIimLrGkWtilatYq2tWlQmA+IgKlSprVW0tVSt W7XSVlpTcasVSfI9952ZEFC7/fr99o/fkDOfd9d37zn3nnfvfcP6tSPLiIpsITzJHz53aA0R P/4bAN3D5693Y9jyCSGypOVrVpyL4dQThCiMK87ZuBzDmVmEeB5buWxoKYYJpJPSlRCBYVoM zFh57voLMOzXA7ecs3o4nu4/AuG6c4cuiN+fvAFh9zeGzl2G+ZtYetaatcvi6bSPEPN3dxdv kGB64ntLTeKKEi0hFEJu6iZ68gSREw4YIoOEqIdpLZFAKkuX3hUr/ORs5WJd1afEngQRhOz7 80XPM/70yvuv+eK1ia2K9+U/gbwKqAE/UE5+18RrhCjv/uK141co3hdriieKcI8p+Bj3eTTN 6Ypxf4umBQCfRdNyAX9FfIr4BNM+xtBHiA8RxxAfIP6COccR72PknxF/QhxFvIf4I+IPiN8j jkTTFNCIdzH0O8Q7UWcyRL4dddoBv406Q4C3EG8i3kC8jllew9BvEK8iXkG8jPg14jDiV4iX EL9E/ALxIuIFbMQhxPOI5xA/x9s+izl/hvgp4hnETxAHEU8jnkL8GHEAsR/rfBLxBEY+jtiH eAyxFxFDPIrYg3gEsRuxCxFFjEVTC0GDEcTOaGoRhB5GPIR4ELED8aNoagFkeQBxP5a7D/FD xA8Q9yK+j7gHi38PcTdiO+IuxJ2I72LVdyBux+K3Ib6DuBVxC2IblrsZcRPiRsS3ETcgrkdc h1VvxeLXIq5BjCKuRlyFBa5EXIG4HHEZ4luIb0YdxaCXSxFbEJcgLkZsRlyEuBCxCbERcQFi A+J8xAhiPWIdYi3iPMQaxOpoSgk04huIcxHnIM5GnIVYhViJWIFYjliGWIoYRixBDCEGEYsR ixADiIWIBYj5iP6ovQxa1oc4E3EGIozoRfQguhFdiE5EB2Ieoh3RhmhFtCCaEU2IuYhGRAOi HjEHUYeoRQiIGkQ1YjaiClGJmIWoiNoqoH/liDJEKaIEUYwoQhQiChD5IngatQWhlhBGBhF5 iFxEAJGDyEZkITIRfoQvaq2EyjIQ3qiVTfT0qHUWwIORboQLkYZwIlIRDkQKwo6wIawIC8KM dzDhHYwYmYwwIPQIHUKL0CDUCBVCiVBgnUkIOUbKEFKEBMEjOARFEBF0CjGJmECcQHyBOI74 HPE3xGfibelfxR7RTzHyE8THiI8QHyKOIT5A/AUxjngf8WfEnxBHEe8h/oj3+0PU4nXF6O8R R6IWmDn0XcTvopZyCL2DeDtqmQOh30Yt9YC3EG8i3ohaGiDy9ailEfAa4jeIV7HqVxAvY2W/ xsoOI36FeAkr+yWW+wXiRcQLiEOI5xHPYbmfY9XPIn6Gjf8p4hm830+iljpo2UEs8DTe6Cls 9Y+xsgOI/YgnEU8gHkfsQzyGVe/FqmNY9aNY9R7EI4jdeKNdiChiDG8bQexEPIxVP4R4ELED 8SPEA1EzeH16f9RcC7gP8cOouR1CP4ia5wHujZo7AN+PmrsB90TNAuB7mOVuzLIds9yFWe7E tO9izjswdDvmvA3xHSxwK+KWqLkT6tyGxW9G3IS4EZv0bcx5A+a8HnFd1NwF5bZizmsR1yBG o6Y+SLs6auoHXBU1LQRcGTUNAK6ImloAl0dNCwCXYdq3MOc3Mculwk7IekzX4PpA2+R6Wz3P 9RTIj0EOgOxXneGKgoyBREB2gjwM8hDIgyA7QH4E8gDI/SD3gfwQ5Acg94J8H+QekO+B3A2y HeQu5UrX7SC3gXwH5FaQW0C2gdwMchPIjSDfBrlBsdJ1Pch1IFtBrgWpVXAnuOPkDOLivgCu JC56SdQILpNeHE1mE3A9Yl3UwEbtWsR5iDWI1YhvIM5FnIM4G3EWogpRGdWzymYhKhDliDJE KaIEUYwoQhRGQcExWoDIRyQjDAg9QofQIjRRMEqMqhEqhBKhQCQh5FENM7VMWAD8C8g4yPsg fwb5E8hRMOdvQd4CeRPkDZDXQV4D+Q2Y5VWQV0CeBHkC5HGQfSCPgdwJpvguSIxuQU1vihrY 5NiIyrkAsQFxPmIEMQdRh3qoRQiIGkQ1YjZ22YwwIYwMe3me56KC694neY7sBjkIwvME23Ih oget3o0t60J0IjoQ8xDtiDZEK6IF0YxoQsxFNCIaEPWIdIQHG+9GuBBpCCciFeFApCDsCBt2 04qwCHdAdydAToB8AXIc5HMYA38D+QzkryCfgnwC8jFY9SOQD0H+CPIHkN+DHAF5F+R3IO+A dQ+BPA/yHMjPQZ4F+RnIT0GeAfkJyEGQp0FiII+CxfeAPAKyG2QXyB3M+twE6ngz4iLEqqgB lkJ0JWIFqmU5YhliKWIYsQQxhBhELEYsQgwgFiIWIOYj+hF9iDMRZyDCiF5ECBFEVechchEB RA4iG5GFyET4ET60TQbCi5AiJAgewSEozkgi3ANGmgKZBHkPFPsyyK9BDoP8CuQlkF+C/ALk RZAXQNF7QS7nfa7L+KDrWzTo+mbTlvClO7aEL2naHL54x+awanPl5tbNvGqzA3Dh5h2bX98s u6hpU/jCHZvCkk2mTZxyY9OG8AU7NoRVG6j6/KaRcO/IkZFPRnjTSO/I0pH1IzePHIYI+b0j u0cOjvCxqQNC8kh5ZeOWkRtGOBOkc2SE6li0Z0SlbVzftDa8bsfasGRt8Vqu8pO19O21lMtf SzvXDq7lINeutRlZjSx3yVpLSqN+bf5aYS1/XtPq8Jodq8Mdq1evvmT19tX7V0svWX39am4n XHHCaoWm8RtN54Z/ey4lj3NTRA9ygJuK8srV+7hJOPX4gJsUpujZoICzQBGrgivCK3esCC8P Lg0v27E0PBxcEh4KDoYXBwfCi3YMhBcG54cX7Jgf7g/2hc+E/GcEe8PhHb3hnmBXuHtHV7gj OC88D+Lbg63hth2t4ZZgU7h5R1O4s4nODTaGG/hSFzxBSBr8rUnbknYsTaIadK5xcmucbzuP Ofk1qcdSuUscVJdyScr1KbwOvjj8srvs19u323fapTrxglevSd6SzK0xbDFw+QbB8AvD2wYJ Mdxt4HTX67brdur4Dt1i3Qe6KZ1kp47u1O7XvqjlO7SLtau1vE7Lwrxe0AYLGnUal0aYG9Lw VSFNjaZDw1+voYImWNgoaDIyG2vUHerFan67mgpqf3bjB8opJScoIeEDxZSCm1JQwlM3hXMo PYBPYjaiZldjjJJdFiqlMXrDWG9PINAak091t0aSOhdE6FURXw/7FrrmR2RXRUh4/oK+MUqv 6x+j3JzeiKm1az6GL9+6ldQ5WyPOnr7I3c7+1sgWuBDYxRRcEOeYhdT1BxatG1m3bn1gXQC+ QBatg5j1I/AngsI3XI/AF7sikCXwNR+WAxIht5hp3cjiEagDMkM0q30ELliAZfmaKv5vo1nb /msf+l+78//3N7YtXsRObwmZvGnGge2l5FLyXbKDPEIeIz8mPye/Ih9TJZwVX072k3fJn8hH 5AuYpnJqpqk0e0a5/8fLyW9JzyUa/gCRESshU8enjk4+MHUUDqW1M2JugpBV4j8ZM5U8NX56 3ORNk7HJF2QqohfL6rnnoLZjdHzqOFcDJfVTpSzMXcmuxTsdk981uXNy+ykdWEPWkhFyAdlI NpELyWZyMbmEfItcQa4kV5GrQReXwPU15FqylVxHric3kG+TG8lN5GayjdxCbiXfIbeR28kd oMc7yV1kezyNhe+Cf7eIqSzlHvJD8gB5EPh9ci/5AbmP3A/hH4H2HyQPQxzGYPghiLmbfA9i fwj5WK4HyUNkJ/yLkDESJbvIbrAZhhOhGDlA9pBHSYzsBWvuI4/D6f+TYMcDYNmnxDgWkwh/ fU7M/zQ5SH5CniE/JT8jz8LIeI48Tw6RF8iL5N9J+cl0LayGX5BfkpdgrB0mvyYvk1fIb8jr 5C3yW/I2+R2Muve/lP4q5HgN8rwZz/UO5Po9OQo5x6EmrAfzvAF1vEPeE2s4DHW/TY7QJPIp 5cgXZAqumPVuES10m2hHZr3bwW73inpm9tgJYWYh1DqzzUOg84fAvswy7Pr2uDUehrxjoNeE ppmWv6ybF+K2Qn0/DnmYLpg+UZu/AA2jzVg9T05r/DlRT1HRok9N2+KkFZgOmf5eIQntvDFD h78nfxA1w7T7qqi7N2Zoj2n5CGiQWYHVcapufwdl0TqsLNM502miDEt7DcJHwTu8D5pm/LNo iT+TP05f/zGePk7+Qj4gn4rfx8iH4E8+Jp9A+K8QcwxCH8D3qbGnx3xGPiN/I5+T42DBE2Ri RmjmNUuZIJNgY0Ip5ShPJk9enYxlKVQCSwwZ+LQkqqBKqqYaqqU6WIrIT0tRTacYvpRystTJ NIVYTzI1UhP4Syu10RTqAL/ppGnURT00nZ5Ms0+nuCHFSzOoL17OIpa0T5d1wRLJGq+F5c2m +XQDfAdokIbguoAW0xJaRisgJg/ChRCeBWn5IutIJ1lCziHHpe9xz0O7TOBVxoTGxYsGFi6Y 398X7u3p7ursmNfe1trS3DS3saF+Tl2tUFM9u6pyVkV5WWlJKJiXm+X3ZXjTXTaTQa/TqJSK JLlMKuE5SnIbvI2D7oh/MCLxe5ua8ljYOwQRQzMiBiNuiGo8NU/EzcoNQdIpOQXIufy0nALm FKZzUr27ilTl5bobvO7IoXqvO0bnd/XB9dZ6b787Mi5et4vXEr8Y0EDA44ES7gbbynp3hA66 GyKN568cbRisz8ulYyrlHO+cZcq8XDKmVMGlCq4iWd41YzSrmooXXFbDrDGOJGnYbSO8r2Fo aaSzq6+h3uHx9ItxZI5YV0Q2JyIX63KvikCbyTXusdwDo9fG9GTJYEC91Lt0aGFfhB+CQqN8 w+jolRFDIJLtrY9kbzpiAwUui+R66xsiAS80rLV7+gY0IvXpve7RTwk03jv+PrR6RsxQPEbm 039KWCLr4rSaInQocU2gbdBC6J/Hw9pyTUwgSyAQ2dLVh2E3WeKIEiEU6I9wgyzlQCLFHGYp WxIp08UHvaDZBm/DYPzv/JW2yJYl7rxcsKz454tIfJDujvD+wSXDKxmHlo1666GHoEvSC6vz ergQhuLKbBjLD0H+oUHoxCqmhq6+SMi7JmLy1qG2IQIq8TWs6ukTi2BsQ8Q0J0IGh+OlIqEG KAtDpGGUGYY1kNXl7erbS4qm3h4rdjt2FZFi0s/aEbHMAaP4G0b7li6PuAYdS2F8Lnf3OTwR oR/U1+/tW9bPrOTVR7LfhtvBBwwoloK+nZY7kRm6HZH7ktx9nIPvZ9aCCHcjfHnrqiBBH5Fh kFm0rsrdRx0kkQ3uEs/Brk6pBwK8b04TFAZC0TlNDg8MbvHzd5rkwA5AMyJJ022SQCOkJ9uE 9/napmFu1qBsd8Oy+hkNPKVSCIgNjNf21e3kmC7iyoAmJDFzNrE+5OVycO2G5KQIB/0Uo5gV be4I6XT3eZd5+70whoTOPmYcpmvRvq09XrYDFK0dHyW9p4QwvRzTIsTT2tuXCMD+sS/SGBDt yswqhueK4elg02nJzYlk92iSt7VnlN3cG6+QuGEGgXFk/uaha8qTi2GyNoKj9DYOed16d+Po UGxqy5LRMUEYXdMwuHIWTINRb/PSUW9PXxXYUpz3mx2b2K2TSStt7a3LywXfUzfmpVd1jQn0 qp75fXthLeu+qrcvysHud7CufywD0vr2ugkRxFiOxbJIlsXNAqymbggkifkdewX4HYqYKhEj xPAwbMDFOMwEcZQMxziM0yfycRAnwThBjOuHD8ww20owAfjhBvdSZp6L+leODvazyUUsYEr4 oxHqrSYRzlsNe3aZOqL0LquLqLx1LL6GxddgvIzFy711EWqhoJwY+KTRQS/4KRhyfcRB+2F0 6Nno53zu2NRUb5/nkGO83wNTYiHI/L6IIgDPAamvBfLNZTII0XMjW4aHWDtIGKY6m5nNw/0w FxIVQpbmiAJqUMRrgByNYhk2HKHQMNgGDCiW3wKByJb+SH+A3bRvFWuR262PkCbvLDA71in1 sxuF+keTvYVsYEPWiNJ3JYMC2kbgNEKMcUAQbgYOl/VIroaWD3shaXjQDRaQkOEeGOroS5XM bhCzDFyixL9MFKUjnkhYt3ifSqOMKIJQIfyxa1UQKoQ/eT8ohXVeDF0ZzwD31kdU0CL/DFXG C4B2IKmZtQX+roTGs6w/ZtV0xUi39wJwjazR4q3kkBzR+JqHwPljeRXEeMsThaGuJB+LYnUc xFg567ka9M77emNT93k3Mg+Q+OTletnDgQ1M4tgLA5v0j54eEVkQyMtNOj1WI0aPjiZpvroA 6itJM02ohUjYz6ZehB2oimzlHyRbpXbSzKUDG0BWkU7JpRD/M1Ij2UcscoEE+I/JXEkraZXI SQv/HHHA9cX0M3I2/4rIi1lY0k6aGLlXycV8AdT3DOxnd8allWzkg6QByhD+EbIOegkLVviG n2nBXrUe6CFOIiUmYoefdFkhNoWYiZEYIFYDOZOIjtgIB79hS4YhkUos8Es2F/zaSwGllWyv K35gBwrr3O3cEu52vo3fL1kjzZXeIMuRW+TRpIsVlyk55ZnKV1R21d1qo/oRTbFWrr1L+yOd R3enPqTv0b8JdUjhxGAd/zrsrnmovYK0k3mk93GioXdCo2bR53bX1yflyZ+EIEfc9DloF6V3 CkYJp3E4arwlsmv5LkNzjfxarpfUTLz15jPwdSi5InSIht4cf3lcP/GMoSI0fni8IJ8aPAZR TFpOLpfJvOlBriTTX1pUVFjNlRT7velaTowrLi2r5osK0zgecmJMNcfClH/9RAffMJHBbfRU 9hRIacBndRmTknhXmsZX5Na1tntLs1KkkiQZL02SZ5bWecMbWtJfUNoyU52ZNiXQmQqceEqq Pf6RVPvFmZL6Lx7n3qvoq86QbdSoOKki6c6sNHNGQersVo1OI9U6rCmp8iSDVpnTNDRxW4rP qlRafSmpPlaXb6ISNLKVEMkB0F0y2OY8dlQZ7ttPjNwdoNgU7kYwlm3qvd0qHW2zxWhQUGi7 HDYWcsRob1SQ9hJbTUr7eKBmPEBRSTAT/tkSBfn9lCnIk+4vMRSXFnlAQ9LiIOf1GphGJQcG Hv78wcnnPHl5Htr20Ic/OGPyWGDxto2XX33OzcMF3O3RibtbM3MlK3Mzu7b/6fsL71pfe+KG 8vPuh5G3deo4Pwx9yiR7sUdjcmOMu1mwaJwkzSnP0tF2uU2toW1yvQouH6NnEuPUsT1wbTTa ZbGpt3dBDiB0XEvbZDG6YLeQ3mUPQ2fF3gZgeATG4cCOhkIHDRXjhQX5DsHwH6x3WjMGphOz qCRDYiwlVAVdVGkVk/10q0KrkorX69Suwkx/UZomz8MNsVjJPWnZNvXkvUpbVlpaVopqMk2l V8lk8CXZlpupsueAtpqn/iS5Q5pBasjrqK1dqak6W4y7MUoydfu422ANChZlKrGBSnZpRB7b pWakmbvT0ytC1ftoCOahMj5UlKAxQVHRYxKHiilGF0eF0BmJoTIRODxuAA2iAscPHxyHAGhQ HDj/O7dJ6BMmLJukZlMaTMfSMoMXRl4xTE1Ry6BgyYzJKgGlKDQKzazBy/sWfeecWZVnbZuf e4bv02STVKlV0Ef0dqPSXDu4YlXJHZ/+aP5g5PPbekdX1DvUkgZnjl2ZkZNRu+G+ZasfWDvL ZKK5eaWpfqtKZXGZJibS8lJSTcr+Bz6+ffvE2CKrx59ahGOWbpOawIPmoBXgicLd/Iig1HdL xYFHQzDRQE27EhHQKd/JMYEOxky3adJwCGhchf7MwjRNhlKvlMngS/JM4op5cpgjkpg0mcwm j+D99mTqlEGdzhTjiqNpwULAbpJW3p0dmzomJOv8XFt2VjBdrWdXapVMF6ObH81U2tm0CMJ1 VJDFfUFNTXJFxbihoiIARq4I1NDQ4fFC/XhhyFBkKIL2R/8DdSa6zsyVSf3+TK/FYj5lgjBv azWm8dYiP3Muce1IYnqHz7jGWxTIsk8+mTrLykkkKkcwwxtMUZZlbfUXZ2cYT1gCWf5kyvPq 1GBGetCuXGjNsKm0vppCbqB0c2XT9W0TC5Q4iZSSa0IhTVpJ5mRmoKenM6vxOw3cYqVeLZWq 9UrwrZ1TR6V2qQ+eiZknfauJewp8axp8K4k9PmHsMbpQUOh6vOKE8cboAPjW6Qkz07f+syVm jHhxhCdc6/Tor+ak9s67jt526zu3tAJvv+mdW9sn33e3bxkc+manx922ZYiRu+V7k2MDHfcc 33HnF5FF8+75bM/y+zbUNm/6/oKzHrigpumiH7AnCIykdvC2pbAmuBPH0m590JCt3AfLCULK uDui2TWGGAe/VA3qRacKzw99jPp2CYJ1diJidoxm7xE8XdYwDnfR0YpeogKeLIWH4QnMxhMM oLF/r5bEmGFDhg/y8JA5OXnYs8diTeOZp5XDoLFaLLTYn+n3Jx5F7UlpswpzCp1qyXpzVoGQ 0x2fZWp4NHUU1TnmbT4z6BEWVTmL8rKM5+qUkw/NqjMV5Z1/RXlveWq6SqeEcWZQU09BW1HK pDExDyW35mZKeFXpmRvaa8/urTZqsyqag1N+L79U6EuWyia/7SiAZRYlNVNH+WthHDWTfQnf UMvd+khGYUah2hHjvhsl6uA+mkfKiJLm7TGUwT9LVUKxVTGaJ6hrHdLsHos4vCwx2jdzeLHp GoD5Ggrpx/XjbLpCTCjEfM3jJPgfqvbkeJQkxiOumoKyeFgmPuZOemgZf23bNx8enrOurzJF JVHolNqiztXN+W0lqfntS1Yuac9vGNneH1zYWW2SSzlerlGp8hsXlgWEgDnUsXTl0nn59LLl t68otrjSUwqCrpwUlSfLY82p9ufWFATyZ4fXdw1sHQhqbWkmrdWb4sxKUad6HGZfsTOA6etA 7xYY2T8En5xBelDvUWJPiXHte4QMu1ttt7I1hUrQ2F3dNmly3E0nV9RQe8h2GJx1ckWK/s0U AGjy0dPysNGo5cF/SZj/Ki0V/RUtomzdaLHI5LxBqs+oLsyqyLIbFJLJS9RSe1VpsDhVJaWV lJZI1M7SULDIKFcHDWYVnBgnqQ0ayYUZOWapRGnSnUjh3zGY1RKZNccL/QhMHZeboB9V5BLs h6AIKdWkKj9fDX6+XVBWqa02jc/rVafHuG1CsmBTl3XndOd7VXyyszs5MSOTrRU1MzpnD1VU JFfY9Gy82EPJcM06Kui+tuh0n2ECenmx96L3jvfeWGTEVbM1fsX0IP2tzJxTV1TRkJUsfZE7 KE3OnFM2CwKyydcUnL2iKFSWquTfpe9LNK7SvPwKl1byCfcur0wtDuUWWHjFHJtTJ5XqnDa+ +MTzVqdevJasysi2SHmV2XjCw79qtGmkEo3NdCKLf0Nv1UilloAPvNpcmHPnw16piAg0O259 hbU4xi3YTTIzyawY1yDoDbyVfmyl1pi6mJ4opsXsNxwKtrAsLg7W5sSoTXC8nU75zelb0zkh vTN9MJ3XpbvSObUkPV3ihIWmoFWDM3Ta9LTdeTzYwryhoIDA7COCul1CbKHE6potOeFMfGBg 8YC4eAoMnDc+cB54xoMVMG0LUfP/5daIHpZti+CRWxLfHrEnb1EJW9RPb46qJWywm+W4ErOw hRh/vimQk5dtKNt6xtwNZ+bP3rh7w5mGzNr8muG2Ir3KoJIpUxsXra5ctW0w97PB2WeU2ufW lPQHXVq9XK7Xzq2s8zWf0zRvXWtGaU5Njik1PVWb4re6MpzeNGN2+IqFryVnFHnKhVL4r04c aQW7Pg/vdv2wU9wWt6vKUbGPg5fPJMStFZRGT6OqItMh0eYkXChYsllQ2FqKRf9ZDKHdgrZd 2pbYD8Duh80NcQeEplD8u3WIOoQ9EfjBU3QIj6fpVQwPz6UZz/Ey/nmlLTvNnWVXNdy6cPnW /qyiJTcubt1UpXLm+3z5qerjpcOlBXMD5uTs+uKUgqJSNz6QlDrVcEt3xxW7hjc8eUXT7Er6 bmJZM1Fc31TQvayk/KyeQl16GfwXMo60gN72wHwIkGIqRb3tMho9uTFuTjRQLIkxzXn4XGMu 58h9WsImghV2CkSil3BtnZJBCXe3JCKB5VZqCLTKVvmMghvyhI74W2x/JVq9ljPwWoUNNhYK G2RQfC6ktoubholA4DAM/nHQM5sHA+ctGgiMLxpg64I3wfmwzYOg+L+9N9iJmmRej7iTiK8u TVo8EkisNjNLRTvJ+T3ZGRPvOCoHauuWNufrFOoknpMkaWbNX1+3YdcFldXnP3DWmu3L8z/h FyzOnxuyc/R4MLdioDbdaDXKkz12i8ui09qshqpNj23esP/yxrqRuxe5z9qYMbsnBCcejsmb +Hv4X5FqOPVYTLm4f+/Q5cv5cm9LUcvTLbyrhba886yagmbVz/bQtB5q66E9Hx6CV4BmSsx6 M6czmwfL+c+rmnLcuXWP18FZLq07VN6iW0D1/ILnBXcH7t3ABjXjAwPwiBN9EHNHEBx4WQTM AGaH8Mw7q1roP775yXtX1T1fx0nqqO7v3h9um2jBKQ0YEFsgmoVtB8TVnT9TBusKizW+tkts 78rAQ8EhDftmtrNYYfkHC75pj1TNGWH5l6mFBSH4p2qOv8eiX2UxFg9d3RuYZ1Ybi4K/advQ FZi1fufI2u+tCBk8+a5AqDTgzSlbclV3TruHOgzmySc6m33lvuTOuf5yn7GyqWZXissoW7aw Yl6+iR/MD9pme+Zt7AmYtZoMi9PHJcE7iUVVdSNnFGYI/SWeqrJCq7UjVDmU6V3SPO/CcJ5S kTv5eVOnPVDhqu+w5ZRNnJGXz0mNXneavrDY6g+xdeLFcO7xknQNKSTn4jjYS1Tc4mhhDmzq Bnel5dhnLr/bBYWQ15LRaG9DR4ZHG8nx1TaYMvrP5Z/psQyio5fJZyyt43PDgA95M/+SOrUg w1eQqjZmVPjzl5SoRSflVCdYe2Xzgs3t6elKnVIqhS86UdtS4mycM7EzESP1JvzUpFGoqVp5 zTDzT2dPHadbpfNg/+whDdj7/cTC7YeDRzM3CHstF73wEcGub8bevgzrM9FfQ0f3fkXaqb2K d8IIM56dGMBqzUI3JVqcoLG6N1w5O9xbNd12fhP4WDhtgV7kt80qb26rrIhbaR9YqZgsSbSz AFqYTtTwbSFebs+uvDyLMsY9KmgFYklXSbOaUxsN02aCdRYs0sX1ZQiOJwuPsGmn+qpsMzqR Sb/CJuJqk50vyeSUWiz8PpWzMCu7yJMsn3wl0asEaVKSyVPg9xW51Drd5Bc0qFZ5lDqFVKLQ a+jLk1lfts6JD+mwOlm0okqXbpx8dTLP5MT+003QfzNhr1PgvFHQacxUpaIqJYVzY5WEwGhl Bx+NaKr4wYe4+hmA44949IzOndzgf9kq08Y4OWwSMwWeZoXkUmzDWI5xH6g/TZwwJA0myrFd cB4oThi2RIP9ajus9fNacuwZzdNTBvwQ2IGdAx6GrRPzf3vhB13/SslTe8GWSV81e8z/aPYo U7Jd7hyrsuW2nn8we/iLEpZa0dlZtWJ0COZO09RRiQS0cdo5xYh4TjFy6jlFCpxTtEyfU6TC RhKf0aedAc84p/i7JaD/4hkwW+/En5viEfCM9Y1EUrUpduGGyPry2ZsevfCCyLryyQlzYU9N eW+pw1LQW13RW5pCj659/KqWuotj56994sqW2otjl9at7g5md6yeC8zLnrcaennx5DYJgV7m wJnXLWj1qKcUTikGYSgGuMsFBTErS0s8Eml+YuGXH6Otgsbf4mjWd1SIi7+KGG2Z2ecaXPvh ABDXfnv+3TpmqCLzy5PVjHujhHLkBov4ZJIQWOwtyqydXeVOzFSlPduVlm1XZrbO6wktGT0z a/K4IXtOoR1Wfmklg8UFDblmOr5h/xVNOlfQNbkw4UwlbyUGxqqs2dmm9iuiGypWdRfo0kuz Jl+b01zYtRznDbcPdFhE4LcnbO6O+XUwWwV496NTupQhJa/hlWyBB3MHToF7BKUQaPHrzO5m s7haBt8lzhiYzDR0MD5j4Nj4H+WfoRv2kP6KBwzqR8btg5WVMslkT0s25+TBYyb+eElMEG91 eXmqJs1tg7Nxjm/NgIM/eZLckFGVO3E40f+TU2R1Ya1fx8sVSrUZT8qPch9B75vJUez9XlLL BafPYeoF8OGSIA0eKQNXpvyjoUxgLqTMXcbx4pmMrorCscwxwcHeoFQdYWcyLRY92y8SC9VL LB9NTybQT0A8Rw0MiCcziwcC+vEB+DvleEZw/y/f7aTa/+lTG+6jipXX9RQuaMq3qOFUQqEK COHS9JJMk292e1f7bF/hoit7czqEXGOShOfl6iSFv6I1P73QrfdXd3R1VPtpWtv6eZk6q82c l+v0muX2tBRtSlZKWsCdmp4rzK8Rzm7LUSebdTqzy+pIN8nNNrM2xWty5bhTPblCP4xR69T7 3HWSMTKL3IRWetRg0FRmE29eDBZDVk1eYnbnxahrl7fJqUlEaCAiam0qiNG5UUEe92swwQ+B 0FDRROHBQvbiQnTzefGj23+pEtAnHNnjW4bplw+wPY6vL8zixhgWGXA2Kc5uFuauUyV74Zij 9RtN6Wcb4eWDTnmWyolrqKfYkDUZnw5Wmtx2g1ymkkk35YaMsOjwd1zQTZ8NlTmzrMqfwhSH 90N6uLBmOctCkwPNzXKFXG7OmJpi2pLUS+dxfuIAdy+Hg+lHgaIWJfmgxVpSEw3V6kF1uwNp aQGY7Yv38CWB2iZ9gKmvsqQJ3u/M3eVrV7QRcIY1h8YLYSOM+zJ26g+vTQtnns17ZnQN1uhf rwv+9zmexFpxcvWMHiqTM75GHfyBjPQT9yemMffSyY6m5uaZv1Yr0NuN7FSAfwbWA2fH/Zoq E48EXNxiQWfMa85USe3N8CIAZm4GrAVOOwBgfk1cTop7IO0/kx3Hwqk7/ektviHxhioxNGCP D27dk22DR3z3ws3tHnEI5DvVyT5YRg+VJfb608sd9nRfefVybjpiMqlRXEhzXQkFQb8bYOn8 F/4A7OrvwX4LSp2P6nU6apCBzffucZngH/HHuCeiCp8hMVEMMeoUlPYmXaaokEwIwkOxNf6G rxCmSyFo4xCeKRfkE3BniwZgkTpd979UVUG+WB7fdrGXxWzClFF2xdQjvrwTT+4pu+T+wl52 Tex1OHmFTk3nTR40WqUwAziP1qSRS5LgcH43HVTAG5wVzmybIiM7mOx0pBo4SX6JM9OqlOlT zQUmV2qqfmIiyZIJ6wbCHxB3Fir4hYOJvZXbv1um4NVNpOYt+I0A+13AzG0B3ZrYBkyukzwf X/VP7oB61k19yC+RroR1fxNpfZyUcHvhlauUq92jq4F/2XCwfLWgJ9kZGS6FaZdUmq+on8X+ X7VjLL+RwMR68wX2OwTmf6afAey8nt3+5M8RMjP9oJH4yfqXztxOX2nxS0LhDU1JtKzYk5ei hh8bJ5ndFm1Je6HVUdZTXjSv3KcEDy2VmcrnDRaff//ZhZOvajxlWTmlHo3GU5qTVebR8G90 XzY4K+np5GQ+Sat6351lU6SXtwXyO2e5TDaTwpab7nWbHFZ97TeuO9GXXZ6u06WXZ+dUeHU6 bwX4GeZpkkHYRwbrT/g9TXdrX21gztA5q5asXZVXt/qcpZD0PxUULeEKZW5kc3RyZWFtCmVu ZG9iago2MiAwIG9iagoxMDI2NwplbmRvYmoKMTAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1 YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvSEJORUNKK0NhbGlicmkgL0ZvbnREZXNjcmlw dG9yCjYzIDAgUiAvVG9Vbmljb2RlIDY0IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAx MDYgL1dpZHRocyBbIDU0MyA0OTggNDIzCjUyNSAzMzUgMjI2IDI1MiA1MzMgNTc5IDY0NiA3 MTUgNTI3IDM0OSA0NTUgNjE1IDM5MSA0NzkgNTI1IDU1NyAyMjkgMjI5IDM5NQo0NzEgNDU5 IDQ1MiA1MjUgNTA3IDUwNyA4NTUgNTA3IDUwNyA4OTQgNDg4IDQ4NyA0NTkgNTA3IDUwNyA2 MzEgNTQ0IDMwNSA4OTAKNTI1IDUyNSA1NjcgNjgyIDQ1MyA3OTkgNDg3IDUyNSAyNTAgNDMz IDUwNyA1MDcgMzA2IDY0MiA2NjIgMzg2IDI1MiA1MTcgNTA3CjQyMCAyNjggMzAzIDMwMyAy NjggNDk4IDYzNCAyMzkgNjE2IDYyMyA0OTggNDk4IDQ5OCA2NzMgXSA+PgplbmRvYmoKNjQg MCBvYmoKPDwgL0xlbmd0aCA2NSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBXZTLjptAEEX3fEUvJ4uR20DbYwkhRRON5EUeipMPwNB4kGJAGC/89zm3cCbJLC7SdXVV 1+ku9+p5/2nfd7NbfZuG+hBn13Z9M8XLcJ3q6I7x1PXJOnVNV893Z7/V52pMViQfbpc5nvd9 O7iiSJxbfSflMk839/CxGY7xg377OjVx6vqTe/j5fLBfDtdx/BXPsZ+dT8rSNbGl3Odq/FKd o1tZ6uO+Id7Nt0ey/q74cRujoyMy1ktL9dDEy1jVcar6U0wK78vi5aVMYt+8C90Tjm39Wk1J kW5KFvud49PwST2fylvmfc27jGAZqRZXjUv9+r/FwS8NHdt7J+m6LCTvQ1qyX4pF3m+CbIZF 2Ew2xyJslA1Y5P02l91ikff5TvYJi7CWu8Mi7FrRCouwVuqIRZTaKlpjERu1sg0WEbUmIxYR PSraYhGl1EbG2Uos1r4ZcBKLtW8GnIS1xdBkC1GtKDQSUSFknKVEqUoWOImomsyAkzg62wi4 zAC3G0WBk1j8JAtcZkQ0g4VGoudGFhrJezrHQiNhVTmHRmKxopyfCas7yqGRaENEHLaJqNrg SEyUUhtkmLAWBY5lqiwiPiaszjkHTgLBFgPHzWojWwxcboBbawPAfLlBaxLW3HgZSErBKjHB ZmHl3rFbnXMOq8RGOo0Aq8RGigZ4JaLqijk1UUpXxtmbKCVAzqAIdoNcKxYiiVI0yd/tz+Cv w7s/QgBUgl0jx84mdjELaDBYBo8ooBJlBRsAlThVaxjQsFyudQhoWC5XUxQA3Rgd/46kYCpN 5GqYQTSxr1lwGFQqb5TLPZho0nIhYxQL/uWaEwatYG7Vho6RDBNNMnL/sOvV0ev49prV12ni IbMn1N44vV1dH99e2XEYVcD0G/+TZOYKZW5kc3RyZWFtCmVuZG9iago2NSAwIG9iago2NzAK ZW5kb2JqCjYzIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0hC TkVDSitDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBbLTUwMyAtMzA3IDEyNDAgOTY0XQov SXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQgNjMy IC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9NYXhXaWR0aCAxMzI4IC9G b250RmlsZTIgNjYgMCBSID4+CmVuZG9iago2NiAwIG9iago8PCAvTGVuZ3RoIDY3IDAgUiAv TGVuZ3RoMSAzNDU5MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHUvXd8XMXZ NjznnO29F620RSvtSlr13iyt1YtlW7JlS7ZlW+427h3bgMFUA4HQEhMSICE0E5BlG8uQBJPH CWkGklBSCTwpEBInpFIlvdfM7Mgy5Xm/3+/753ll3XtdM3PO0Zl72j33zKx3bt+1mhjJQaKQ 4pWbhrcS9lP+a8BjK3fvDPNw9jpC1Olrtq7dxMN5VxOiT1u78dI1PFyZQ8jcn69bPbyKh8lH wMp1iOBhqRyYtW7Tzr08XHYfIVL9xi0rU+kV1yP+vk3De1N/n9C/H948vGk1v/46CuGt21en 0qUBPM7G0vQbOyhKEv1s2rJl57pqygixIBIwRwoTG/kvoiUysIjgifZbpauICqk0Xf2VsZvf /ZF9mbX+38SvQwQhT//5wI8pPnfdwzd++MH4jfq/aJ9EUI8n8B/cp/3K+C8JMdz34Qcf3Kf/ C3tSKpHBnFG9Eh6Trz6h90ldIIcEuUqQKwU5KMgVglwuyGWCHBBkvyD7BLlUkL2C7BFktyC7 BNkpyA5BtgmyVZAtgmwWZJMgGwW5RJANgqwXZJ0gawVZI8hqQVYJslKQFYIMC7JckGWCLBVk SJAlgiwWZJEgg4IMCLJQkAWC9AsyX5B5gvQJ0ivIXEHmCDJbkB5BZgnSLUiXIJ2CdAjSLkib IK2CtAjSLEiTIDMFSQrSKEiDIDMEqRekTpBaQWoEqRakSpBKQSoEKRekTJBSQUoEKRakSJBC QQoEyRckIUieILmC5AgSFyQmSLYgWYJEBckUJCJIWJCQIEFBMgRJFyQgSJogfkF8gngF8Qji FsQliFMQhyB2QWyCWAWxCGIWxCSIURCDIHpBdIJoBdEIohZEJYgiiCyIJAhJEWlSkAlBxgX5 SJAPBflAkPcFeU+QdwX5jyD/FuRfgvxTkH8I8ndB3hHkb4L8VZDzgvxFkD8L8rYgfxLkLUHe FOSPgvxBkN8L8jtB/luQNwR5XZDfCvKaIL8R5NeC/EqQXwryC0F+LsirgrwiyMuCvCTIzwT5 qSA/EeRFQV4Q5HlBzgnyY0F+JMgPBfmBIN8X5DlBvifIdwU5K8h/CfIdQZ4V5IwgzwjybUG+ Jcg3BXlakKcEOS3ImCCnBHlSkJOCnBDkuCCjghwTZESQJwR5XJBvCPKYIEcFeVSQRwR5WJCH BHlQkK8L8oAgXxPkq4LcL8h9gtwryFcE+bIg9wjyJUHuFuSIIF8U5AuC3CXInYLcIcjtgtwm yOcFuVWQWwT5nCA3C3KTIDcKcliQGwS5XpDrBLlWkGsEuVqQQ4JcJciVghwU5ApBLhfkMkEO CLJfkH2CXCrIXkH2CLJbkF2C7BRkhyDbBdkmyFZBtgiyWZBNgmwU5BJBNgiyXpB1gqwVZI0g qwVZJchKQVYIMizIckGWCbJUkCFBlgiyWJBFggwKMiDIQkEWCNIvyHxB5gnSJ8hcQeYIMluQ WYJ0C9IlSKcgHYK0C9ImSKsgLYI0H6fWMqzm0WBDCDbzaNANuIqHrhwN1iJ0kIeu4HD5aNCE yMt46ACH/Rz2cbh0NGMmLtk7mtEM2MNhN4ddPG0nD+3gsJ1HbhvNaMINWzls4bCZX7KJw0YO l4ymt+LKDRzWc1jHYS2HNaPpLbhkNQ+t4rCSwwoOwxyWc1jGYSm/b4iHlnBYzGERh0EOAxwW cljAoZ/DfA7zOPRx6OUwl8McDrM59HCYxaGbQ9dooBN56OTQMRroQqidQ9tooBuh1tHALEAL h2YOTTxtJr8vyaGR39fAYQaHen5lHYdafnsNh2oOVRwqOVTwh5VzKONPKeVQwqGYP6yIQyG/ r4BDPocEhzwOuRxyOMT5o2McsvkzszhEOWTyR0c4hPl9IQ5BDhkc0jkEOKSNps2GsvwcfKNp cxDycvDwSDcHF490cnBwsPM0Gwcrj7RwMHMw8TQjBwMHPU/TcdBy0Iz65+Kvq0f9vQAVB4VH yjwkcSAMpEkOE+wSaZyHPuLwIYcPeNr7PPQeh3c5/IfDv0d980Nj0r9GffMA/+Shf3D4O4d3 eNrfeOivHM5z+AtP+zOHt3nknzi8xeFNDn/kl/yBh37PQ7/jof/m8AaH13nabzm8xiN/w+HX HH7F4Zf8kl/w0M85vDrqXYisvDLqXQB4mcNLPPJnHH7K4SccXuSXvMDheR55jsOPOfyIww/5 JT/g8H0e+RyH73H4LoezHP6LX/kdHnqWwxkOz/C0b3P4Fo/8JoenOTzF4TSHMX7lKR56ksNJ Dic4HB/1NCLTo6OexYBjHEY4PMHhcQ7f4PAYh6McHh31oNeXHuFPeZjDQzztQQ5f5/AAh69x +CqH+zncx+Fe/rCv8Kd8mcM9PO1LHO7mcITDF/kNX+ChuzjcyeEOnnY7f8ptHD7P027lcAuH z3G4mcNN/Mobeegwhxs4XM/hOg7XjrqHkfdrRt0rAFdzODTqXoPQVRyuHHX3I3Rw1I3BRrpi 1F0JuJzDZfz2A/y+/Rz2jbpX4ZJL+e17OezhsJvDLg47Oezgj97Ob9/GYeuoeyWesoU/bDO/ chOHjRwu4bCBw3p+3zoOa/mbreG3r+awil+5ksMKDsMclnNYxmEpz/QQf7MlHBbzTC/ijx7k f2iAw0L+ugv4H+rnT5nPYR6HPg69o64kMjZ31EXVOmfURRvs7FHXIUDPqKsAMItf0s2ha9QF Q0Lq5KEODu08sm3UdTnSWkdd1wFaRl1XAJpHXQcBTaOONsBMDkkOjRwaRh2wC6QZPFQ/ah9E qI5D7aidtqMaDtWj9naEqkbtA4DKUfsiQAVPK+dQNmrPR2Qpv7Jk1E4zVjxqpx1SEYdCfnsB /wv5HBL8YXkccvnDcjjEOcQ4ZI/aqZayOET5MzP5MyP8YWH+lBCHIL8vg0M6hwCHNA7+UdsQ nukbtS0FeEdtywAeDm4OLg5ODg5+g53fYOORVg4WDmYOJn6lkV9p4JF6DjoOWg4afqWaX6ni kQoHmYPEgSQnrStCVCasK0Pj1lWhj8A/hHwAeR9x7yHuXch/IP+G/Avx/4T8A2l/R/gdyN8g f4WcR/xfIH9G2tsI/wnyFuRNyB8ta0N/sKwL/R7yO8h/Q95A3OvA30Jeg/wG4V8DfwX5JeQX kJ+bLwm9ai4JvQJ82bwx9JI5FvoZ5KfgPzEnQi9CXoA8j/RziPuxeVPoR+A/BP8B+PfNG0LP mdeHvmdeF/queW3oLO79LzzvO5BnIcnJM/h8BvJtyLdM20LfNG0PPW3aEXrKtDN0GjIGOYX4 JyEnkXYCaccRNwo5BhmBPGG8NPS4cV/oG8YDoceMl4WOGi8PPQp5BPIw5CHIg5CvGwtCDwC/ Bvkq7rkfeJ/xktC94F8B/zLkHvAv4Vl341lH8KwvIu4LkLsgd0LugNwOuQ33fR7Pu9UwO3SL YU7oc4a1oZsNXw/dZHgodI2SHbpaqQ4dkqpDV/Uf7L/y6MH+K/ov67/86GX9xssk42WBy7ov 23/Z0ct+dVnSoTEc6N/Xv//ovv5L+/f07z26p/8p+VqyRr4mWd+/++iuftUu166du5R/7ZKO 7pJadknFuySZ7LLtCu9STDv7t/fvOLq9n2yfu/3g9pHtqrqR7a9vl8l2yTA2eeb49kCwDZg8 sN1sa9vWv6V/69Et/ZvXbOrfgBdcX722f93Rtf1rqlf1rz66qn9l9Yr+4erl/cuqh/qXHh3q X1K9qH/x0UX9g9UD/Qtx/YLq+f39R+f3z6vu7e872ts/p3p2/2zE91R398862t3fVd3R33m0 o7+9uq2/FZkn6bb0cLpioy8wOx1vQgJSU3EgGXg98E5ARQIjgTMBxWFNC6XJuVa/1DzHL23x X+G/xa9YfS/45KQvN7/N6n3B+1vv37wqZ9KbW9hGPDZP2KO4ad48PfNp3o57Gls4llSwvPZ4 orE2q1uyukNuuTXkloj9dfs7dsX9jO0Fm2y1SlbrpFVOWnG51RKyyPRj0qIkLSVVbVZzyCzT j0mz4kmaEUNfPm6aO7/NagwZ5f5G4xyjnDQ2NrcljQXFbUSRwlgrkmwARUffRnKH2sYkctwj qaUx6dZj8+clEt1jOtLXPaKbu3hEun4kex79TPYuGtFcP0L6Fy0eOCZJnxs8JsnN80dc3b2L ePiam28mTRndIxnzBkbuyxjsHjkIkqRkEoRkHPOQpsHE0h27diQSO5fiY+mOnQn2i5C0i4bw gwT87tiJMP0HQJjQlM/+4ZfhumU78MMew5/+2bf8P5Ai/T/wjv/LX/EYQRUdmDkpX01WyYcg V0GuhByEXAG5HHIZ5ABkP2Qf5FLIXsgeyG7ILshOyA7INshWyBbIZsgmyEbIJZANkPWQdZC1 kDWQ1ZBVkJWQFZBhyHLIMshSyBBkCWQxZBFkEDIAWQhZAOmHzIfMg/RBeiFzIXMgsyE9kFmQ bkgXpBPSAWmHtEFaIS2QZkgTZCYkCWmENEBmQOohdZBaSA2kGlIFqYRUQMohZZBSSAmkGFIE KYQUQPIhCUgeJBeSA4lDYpBsSBYkCsmERCBhSAgShGRA0iEBSBrED/FBvBAPxA1xQZwQB8QO sUGsEAvEDDFBjBADRA/RQbQQDUQNUc2cxKcCkSEShJBVEuKkCcg45CPIh5APIO9D3oO8C/kP 5N+Qf0H+CfkH5O+QdyB/g/wVch7yF8ifIW9D/gR5C/Im5I+QP0B+D/kd5L8hb0Beh/wW8hrk N5BfQ34F+SXkF5CfQ16FvAJ5GfIS5GeQn0J+AnkR8gLkecg5yI8hP4L8EPIDyPchz0G+B/ku 5CzkvyDfgTwLOQN5BvJtyLcg34Q8DXkKchoyBjkFeRJyEnICchwyCjkGGYE8AXkc8g3IY5Cj kEchj0AehjwEeRDydcgDkK9Bvgq5H3If5F7IVyBfhtwD+RLkbsgRyBchX4DcBbkTcgfkdsht kM9DboXcAvkc5GbITZAbIYchN0Cuh1wHuRZyDVk186B0NdghyFWQKyEHIVdALodcBjkA2Q/Z B7kUsheyB7IbsguyE7IDsh2yDbIVsgWyGbIJshFyCWQDZD1kHWQtZA1kNWQVZCVkBWQYshyy DLIUMgRZAlkMWQQZhAxAFkIWQPoh8yHzIH2QuZA5kNmQWZBuSBekE9IBaYe0QVohLZBmsup/ eTf9v/31Bv+3v+D/8vfzLVtKdwwRMnH79E1CZC7ZQHaQg/h3LbmZ3E6eIb8iK8ghsCPkPvIg eYSMkGfJD8irF931/zMwcal6EzEpp4iGOAmZ/GDy/MSDkDG1ZVrM7Qg5VeELMZO2yb9+LO6v E7dP2ibGNA5iYPea5Z/iaf+Uxic/wPiqIebJShqWrwO3sr/0d+1XJp6YeOiiDMwlvWQRWUyW kCGynAwj/6vIOrIemrmEbCSbyGYW2oy0teBrEFqGq9CXMH7hqi1kK9lCtpOdZBfZjX9bwXek QjRtGwvvInvwby+5lOwj+8kBclnqcw+LOYCUfSx2L1IuJ1egZK4kVzEmkMccIleTa1Bq15Hr yQ0osc8O3TB11WFyI7kJ5fw5cgv5LH7zRSm3klvJ58ltqA93kDvJXeSLqBdfIvd8LPYLLP5u 8hVyL+oMveNOxNzL2F3kC+Sb5HvkJHmcPEGeZLpcCd1yjQi9rGGa3godHECeD017Y67NPVPa uhzaoPk+nMr3Xujvqml37E7pkWrvEK6k2jmcKgf6lMtSMUITtyJnnF/IJ9URzcMtF+VT3PF/ i6U5pnq6B/oSmqE6uwtxd38idvoV0/ld5Mtogffjk2qVsq+Cc3Yv49PjvzJ17X0s7WvkAfJ1 lMVDhDKBPOZBxD1EHkbbfpQcJY/h3wU+nfHUx8k3WMmNkGNklBwnJ1CST5JTZIzF/09pT6Dv +Pg9x1PPGp16ymnyFHkaNeTb5Ax6mu/gn4j5FuKeScWeZVfx8Hewl/Isu4qmfgd16zn0UD8k PyI/Ji+Q7yL0PPv8PkIvkp+Sn5FXJTPYT8if8DlOXlT/HlszZ2Lj5VMojXvIUrI02b5q2dKh JYsXDQ70z5/X1zt3zuyeWd1dnR3tba0tzU0zk40NM+rramuqqyorigoL8nNi2VnRzJDPZbdZ zUaDXqfVqFUKLNv81mjb8vBIbPmIKhbt6Cig4egwIoanRSwfCSOq7eJrRsL0vmEkXXRlEleu +diVSX5lcupKyRauJ/UF+eHWaHjkXEs0PCYt6h0Av7klOhgeOc94D+OqGAuYEYhEcEe41beu JTwiLQ+3jrTtXne4dXlLQb50zGhojjavNhTkk2MGI6gRbCQnuvWYlNMgMSLntNYek4nOTP/s iJLdOrxqZG7vQGtLIBIZZHGkmT1rRNM8omXPCq8fwTuTG8PH8s8cvmnMRlYsT5hWRVcNLxkY UYZx02Gl9fDh60bsiZHcaMtI7r7f+6DA1SP50ZbWkUQUL9bdN/UHpBF1ti0aPvxvgpePnv8L 3npazHAqRpNt+zehiTSLU2oakYYFJ3g3vCHyF4nQd7lxLElWIDBysHeAh8NkRWCUJIsSgyPy cppyRqS4+2nKQZEydfvyKDTbGm1dnvrdvc43cnBFuCAfJct+s0dU2UgPjyix5StWrqM4vPpw tAU5hC7JfDhtWkCSwyllth4rLsL1w8uRifVUDb0DI0XRrSOuaBPXNiLwkOzW9fMG2C08tnXE 1TxClq9M3TVS1Ip7UUVaD9OCoS9InxXtHThNyiZfP1YeDhwvI+VkkL7HiKcZhRJrPTywas1I aHlgFernmvBAIDKSHIT6BqMDqwdpKUVtI7mv48/hBwXI7kLePna1uBjZHtFm68IDckAZpKWF iHAbPqJN9UiwjWh4kJZoU314QAoQcRn+SuoKyi56DgJKdnMHbgbi1uaOQASVm/38D68U4BnA a4zopt5JhZdQX3gn/nc+89X41fSFcsOtq1umveBFD0WAvWDqaZ/+njLVRUoZeAUdLc4OmoeC fBk8jGTdiIx8sihair7wCJkbHoiujg5GUYeScwdo4VBds/LtnheljkFW2qlaMv+iEE+v5mkj JNI9f0AEqM9mpC3BypUWKwu3s/BUsONjyZ0iOXxYF+2ed5j+8WjqgSSMFoTC0cQ6h2+sdpSj sbaho4y2DUfDtnDb4eGxyYMrDh9LJg9vbV2+rhbN4HC0c9Xh6LyBepQla/eXBfbRP+0g3VL3 /KaCfPQ9Tcei0vW9x5LS9fMWDZzGZvzw9fMHRmU4RZc3DR7LQtrA6TAhSRYr01gaSS8J0wB9 Uh8COnZ94HSSkIMsVcUiWHgl/LIsjl+EOImsHJN5nE1cJyNOxeOSLG4QP2hhvnUoAvTDreFV tHgODK47vHyQNi7iQVHiVxqRog1kRI42wJWrMY0YoqubRozRJhrfSOMbebyGxmujTSOSR4Jy xtAnHV4eRT+FKjcAF/kgaoeN1n45Ozw2OTl/IHIucH4wgiaxBLJoYESfwDigzu7Cde1UliO6 feTgymH6HqQfTZ22zM6Vg2gL4oG4pHNEjyfoU0/AFW3sHlodcdNKlA0KkN1/EIGRg4Mjgwn6 RwfW0zcKh20jpCNai2Lnz1TH6B8qGjzsiJbSio1LRwzZ11HQ490InNQsJoAg/hg6XJojrQlv vjKKpJXLwygBFVk5D1Wd96UGWm6IWY0uURVbzcQQSCUSmi0l22g2jOgL8UD8Um4sxAPxqx2E UmjmWei61AX427YRI94oNk2VqRugHSR10nfB73V4eXrps/QxvWOkL7oXXSN9afantEgeMWd3 DqPz5/cbEROtFjfjWbpsGkWfcZbHamnOTdC7kj1/bPKh6KW0BxA/BflROjjQikkCp1GxyeDh j0eMLE4U5Os+Hmtm0YcP68yffgPXl848hfQp4VaMNYSo6DGWF4D3k6hqEXlM1UKGVX8hjylv Qb5BHlObyGLVR+QxWYXwEHlM8yri8iCzyEpVJnAFcIBd2678kVjVmeRR1WGSqQ2SGQgHlZfJ ElU5OaKsIIuAy5UPyZC8jWSrzpNs5SypoGnww10jvT35svI1xo9oVpEjNF5Vze45Iv8Q90dI r/w4iah2cVE7geXkDuXLJFM9RiqUPSRXuZdkKrlkEM8j8D/myVmkA/I0vJRfULxEgoe5Vflo 8j/wKl8D2afehVlznOngEuihD9IBeRyyHbIWUgxZDRHpfcpHpA2yFLIaBcXP+BBiwhwU828S IV3ETtJJGomRBFINqL0yMZMSEie5JErUJI/4SIDkkyxcW05CxEGKSZi0kFY8o5m0odjpvFmL 53QSHU5NZRAPThXlEDdpJGUkm3iJn1SSUtJOOkgdccHWrSU1mP9245RVNZlBGkgVmUUKSSYJ 4kRRPekhs3Euif7cT+6XiqQ/yCvkF5Ru5YRqsepDdZv6Ds1Mza+187XndOv0Tv0fDLMMrxo7 jb80dZneN99mCVpOWhdYf2G7zr7T/p5jm+M9523Ol11PutvdL3s2ev7gPeqL+8p8j/gX+/+c 9tXAvnRD+pb059P/kRHNuDTj2YzfBY3BwuC84D3Bv4S+Eb4lMiNzZdQTPZe1KXs4Fov9Kva7 2J/jD8T/mVOYsxGaIRM7lJ9ipq8g9zXsvRd/k5jhkvOQWunkSXdLi65A+22422QShsNOhzNZ zUmrSjafSktrjJ6q0Nys2DvHpIITjdqb4YpuHH9t/Pmi8dfOO2qKzktFv3njtTdsf3/eXlNU 9sZLb5QUS/aInYnLImu1Lk00s1CuiMcqy8pKG+SK8lg00yKzuPLKqgalrDQoK7iSxzTINCwp P/1okTJnXCNfHm1cUKYOplldZo1aTvc5CuqzbfMWZ9cXZmgVrUZR67Q5VU2Z3RtbM3+ptWe4 PRkOnc6R4XFn2LXjv1JbPviH2vJhs2rjh3comroljVnKFw06WaXRjAV9/ry6SOcCq9OmMjpt do9O67CbclqWjF/rTqfPSHe7+bPGe6CW6OQHqsvVLpR9jHz5NMmafOuEySbNio6lSGxs8p0T RsQYBcGa8DvJNBqVbaOfZvZpYp/JHCmbJucbpZ6saCz7XyajyZeZETWYJY/KREw2k/xE9Jno C1ElaoqaHBl9jn51P2lsbHTU1BQVDQ3ZvTV2UHuZ7XypvQwaTwxxPxpWG7M9Hg1TeVyJKBYl mhmLVVZJXM9ebVRBO9dJtuxQKNupV20Z/+MGxeCMpmdkWyWdNKoy++PBcF6aRbVf+q30nRme gEWlaE16qW7iB3qzXqW2BDyqUaNFpyg6q/Hm8f0EdeoxtHMJtSuIdllNvp9MC/lsUk/IZqUf Znz4TPgII6/YoViYzElzJ5HuTiLd7Tbm04vz6cX59OJ8enE+vTj/KbkUvqczJ8FJrAyaPo4r ge8cx8UMcT3wP8dxC0vHlWVjsi1pvs94xigb0+L/KinRZo1J2DnSWz4mGY9p55PG842s3tZI RUNvMK2VvpTgBNU5kajhHEp1WVTRSGaswl5eWRZBrXTT+hxUpPJCORq108rsvEBVUqh6zspt nROPe3NzvVJs5x0rSz2JmXkVS1pzJsbTqhd1jZ5t7qv0z85uv6T3+Q/qBppj0o4Za/sa8tyh uOqqeCh//r6ewvnt1Q5DRd9mWSqaVZE+MRStmzP+m9qB+tBEdXpVH3q94cl3VCZ1EK14xfF0 UpdIaQXItAL8y3FoBfhXqhWWDq0kvi2XoT/zSUXoG2NS/qhznuppKY9UkGKp8Jh+AZr0S+ep SEU8+7ZXzpYUZ7ssvPGWs2apoQqgzZQ2YLcriKbKm6vKJKt1ruSy/Z2X/+iWnnl3/eSK6g2L 2gI6taLSGXWW0jnb5iy4eVVVxcpbF/fs6C23ag0a5ZTN57C4cuOB+Q/8/cv3f/TEEnc4L2Bx pjlc6U59vCjeeu2zB/Z/64qZsaKYxh5EC6S17BbUMgd69j3JjMaI5KQ1x0lrjtOFPDsdyLDT h9w6n6Y1h6TxGpOW0g1DXAdkNQb41nFcnfY01ub00I1p1NIbGJNix9S8lghdvCRqxBCqhHxR ldBOqwC3LPj6Ow9O/JUVf/bDb32592T5lkevfeLYgUe318h3P/zh1/t4QS/82ltH1p+8uusj e8PBZ+k4h5wpB5CzfLL7WFo8VaJAVqIM8dZA9tYsHW8dH5PtSb3eGXaG8fJpY5IuaT4Yk87E pBdjUiym8Y8hP+beOOCYZqrWD23bjiIuYt2IjWerlJXzxdliBR2xi0of5VQ5oDKYdeO30xzK a3RmnVqNjwmNNKpD16DSg8+WJZ3ZoGp3BBw6nludI+ByBOy6iQ16W7rTkWbTTpTo7AGW78kP lPnId5wsOaZ1pvINZPlmSEs1lW+WTssW+T5pziDBDC2ydtzp9GvGpJzjmb1+2kGmRqSis/ZU M0bueKFNz4wYbUTDVuYjY9oJaE+Ll2c8qXOF03yZLh2y2sZizzrTkYsOrS3gdgbs+vE/aM1a tRofqsfjIQw5NEeLJ/+q2qsOw574ajIjPd3qozXUR2uoj/ZtPgNqqM+GXPho6ZnJM3EpHE/G l8eVuDWVfyDLP5C1ZCBrySwdd1rH5NITReVSuW9MMpzIzKwpanhaMmCMN0i5ozXzXGNS/rEi tGfWmjFI0AE61c+9NDR0lpc5olN6uag1V1bZaX9HWzsrejvtAengzdu/SrVXpTNpTdVLDy26 5NHdja37Hlldv79i4iW7XaXHGPElo8dhcNQuWbGq5K6/fG3B0CPnb+26anVrmkG11Jnh1MUK Y7MPf3vLgTNXt2RkSJdmZkGNOp0t3THhTItlZPpMQ4+9c8fdH4wMp0Vz0zJpu8CYOxdjbhEZ O9FYIkVNKRUBmYoYQq1A1jRYOlRkospN92YZqfaNVPtGqn0j1b6R9g9GOkZ4SdKNgSXppB82 uzSLJJFOvHRjERIoPok0b14fBpD8pPWMSXrRJJkuHo2Lhradb5QwarxER5JUg7rQsIbQg3LD BibRFOXalN2IE1Q1V+eK+NLCLt34cTA/rXk6V6bPH3Hp5B5WF8HSoH1UOZNObhj/juCqXwo2 /oGsETzVvqQB6M9N5p5q9M7xPuFVSEqFQKZChtANkKmQpUND5Cn0iYbJM6egCYOtjxkfyOZU R3ghXyIH0oB4b7074qXvPfW2F95Q9HbdeKs00nGauHkXjT1m7HUY4nWA7HWArIt2o0RPEL21 zz0mJVLdmVR0TrwOexs+UvMBCaqlVmU3+iT9+FlvrlCl9CI1YrpdAacevdPjQlkf3q+3p6c0 pkmgR6onjyVtyxu2Nsjm4mJvUZGh0OdjwwUqFBtGUKcY4l2B7F1ZOlSXRmtfMKvEZDLQ+meg 9c9A65+B1j8DrX8Gql1YNkk/VXVWZa/R5zUX+UoKNaGc3lC/MPYaHTDzylC9hH0CW0/ULXuZ vWZGUVkZtf6m1bKoRC2+QjkuRafVN2p5B2WvVEbNQErdmoTOFfJ7I06dPFGmGN0ZLnfQZZQn 2iXUNb8v7NTmB9aFi7N8emmPWrrWmBaK+TdZA07ThUJd++EdWoNWUWEwh3l9ROhS9WBelikt J/DRQuXBYJ7fqHdmuFNt+XK1HbOoa47HrVZXqh4yhIIYQkfAd6jdwsJQjospM2goLCylyiz1 4dpSHy4steGqUqrMUnqJjQSr+wyF1rjKT0cCOuDBWPbWUOWlWuUF3RVBZ6zKcE3FYvGox+P+ FH0FFW9ZjNp/qVqlutzsTjNXpcWjUffEuvDMdFmWdc6Qzxdy6PLT+jLioQy7VJtRWVrikzAQ OkN+T9iha3dhPmHMKI3Lr9dcVtdxV9dH/5waOh7NyTR4c0Pj3y9fuXyoaM7ROfK3YW1jLDVp CWyelZPnVW+pI5i1xsmBZJqL6sBFK5SLGjwuavC4qA6gprKkPoz57kHY48GUcoGsVQHZUAJk QwlLx13Bp2EUGogfA4d1XpS2LDUbOKaMwJdSA8eFsSI1EsjM7plmBare6rr9tTtue/nGlq47 Xrvjlpdubj0ZX/zFrVu/uCw3tugL27fdvTRHvuvLHx1btvDB/9x35IMnli34+j8f2fytG2fP v+nptdvP3Ngz/5ZvUhsPFsFzaH/pmNHvPZalSWUEyDLCEBkHsibH0pERDa0CXnsGVU8GVU+G zWSWZmXQWUQGxstRYs/GaHlcozEhm8bj7l7TNGOBVxDRsFJ5vbj5oDdRTTP1lOeSe76x93a9 M+KnHV1emuTO61m/aVbuybqFQ/n3fmn22rYs5fbhezbXTxROtQsUtdbbuOTShXM2lFvG389p X8lLeKb6OpRwHB6HzyUzDBFHDs1FDs1FDi3kHFrIObSQc5CTpIGE04vTD6Yr6aUp5QCZcoCs lIGslFk6bkP7KDvhiBjMBWNS7gnvvGxVFS1qMy3ql85RiwkzId5GXrpgH9SUFKtTA1acTydF 0fNZkJrNgqbVAOTCYNK4Bnde3VBy10pRE2782S0dztyGvM7NHTku3cRjH68U270huybSuKg+ mL/gwXfvu/t9WjP+8eXeO67eWlDfnGl1RuXXN3/zxtnzbn5q3fZnbkI1+RbVGrUMjKgnlfDu fD4ZtBXaq3TIahXVWhUr+yqqxSqqtirk/1QunXHmNtqprsAY4lqGUDKQVSggG2/sqFCj6YU2 WNVPbk1KyaR3BurNyUivNzUPp3bm0PkpxU2bQUJxYnCMK4UKJooXxn06jfR4g0pqIul1ejxS eSwei6WmkyqjxpUVTIu4jKo97oKG+XU7RBXDjNJZMjOte8fseLRpSU24vCDHtdOimxhvmetv LPv8wy0rm0LomnXoOdAxlpQvbIyO/2Kq6sFAVSvm6gVbmmeunVPrsiTqZ5dM/C4rQ7lm1nqv VjMxK1I3F310++R5ZSXqYid58zSZCceGFW6LmVRlUBFDqI4hqiSQqWrmmJyfTJQmnS5pVmnS Dn9GaVapKeCj9wbosBew4a4A7a4DtDgCT2EnJsa+4wFmdZw57k+hi+OTVmqKmQqfluJwtxmk WNJoD1dJVUmjSZqF8jmTNFBWZa+ye+oxAzg5M6DOnedB3U71XqjP5+3UTZJIDNnO29CZTbPN 2MRHGGpT3ZpK1G3uoCrUpMIfn/BqlJXNe+4fmrllYZ3XCFNYZymbu62reqg5q7Rv/eZ1fWV1 6z8/P7Gwp96pUcmKxqg1FrUM1VbOLU8rnbdh84Z5ZdIliz8Ht0A405cdgqdKm5kTDVbNLaua XVdS1jB/25zeKxYUWP0hp9HuczowD06PZmQUN2VXzq4vLZsxbxvKyIoe8lXU/Eyy+pQvCfX6 7LDZzpwAI6w7hLJZN4nazRAJwIu7S2p+2OFYQZpd46DTp4xUj1gKI+/vzCny3YTtbCKloWm2 a0RMB5iB9Sqb9N0hLL+JO8SkULmaTQnZnOnDr0xVxBU6e7rTyd1q1N56FOPbpbAFE+RIMmN5 gRSmrTZMW3GYVp0wtZjCtNbge5hsSft0ix01jXhSXSCQdYEMcR+QZZil427PU9h5C2uW2vX0 qEZSD8PeEOuz9WG6L+oNM+NT/eCULQ/jik0faa6nzAB7yvVxIUZ1aevBsV2XjFzewqeNTl3+ vF2d3bt6YWbBmI849dJru08fbGq49Mk9SlSo46N/LLoWq10DVy1UvCKOaiUTvds6aCWLbE5m ZNGOLSdLSqMYS5Ny4FsyS/l+Kd8n+ZF/1kgZoUOeT8RQknTQKL/P74tlh/p8age34x01jXaH xFtIAkVMhoakoaEhuBCzmfGoisN/UFk5zWQshUtRK59SWfzxDE/EZzdplYlBneTIyUyPOPQq aYckrVd06LpCWWZFF6TuQUmlhutHNcociHAJfPiMqpHGUwcizeOMyQ80ryOP9WTt8Vi9hMHq vWQzbdjZqII6SnKKJDhOaUy2lOmjJDdT8oUpKSiRCoqlgiypICpV9eX1RYuNynQnKey+RpQc fqhjNPWPZ45axswrSm3kj2dzykZmGVYfUtnSc4OhRLpFNfF3+QPFkpYbjuSnW5WJRzWSPRYO ZTm1shSVJJeid2UH0yMuvSLlylKGonFGM4JRm6SOWezUmrNblJ98VCS46qgXDlZFZzF+eFZV a7Si14Yz9cPvqeoM4GpLmpdqKMhsIRdWNQaxZMXnSWy6htbBEBUdyCo6kHXGbNpmQkX3slnx mSQqQI8puy+gcfRpqMmDsqezVV7N0bovDE4XlIFRyVtWWVnlpD5jVvKdfP7k1k3cZlRb45Fg tseoPu4vTZO9Jf4TitGZmZaVa1MbpXcnpiq39Bv5lzSbKjhPJm6q2FlXs61K2m2waGkGPRjD l2C0aVR+iJWXJBlJhq1NoaaiJsWo95ab0OrLafsvp02/3EaHEnhv303CVRS3EslEaA9Bammr x6XAt+gIxRA3UGStonZM1iVddu93SbmtXK47Uy4R+E3KC2fmjUmBpPXFTCkzU5XxdmHXjF+b elSkKOUZHjpP3SZD25YOCUP4bGLpUE0RtxBLMcAvxYyLGkWYG1RMM47KKqg3cGpxo0HFplpa 7i31lJVWVimNtvRAWshS9/ne9h29BQ07H15/wFMyu2bGcGeJSQfDXxtoWrCmfPj6+bEHbm5Z 1RQanDtzywyfyQTL1bSosS27bc3MWVu7stvK51YEsBKks/mt/oy0aIYzv//y+We9BY25bfOa WqDdI9Duy+ptqD2YcZ1sbJQMkcpUZQGyER3IKg0NM31VjknvJQPuBLU4E2FoNEH1n6B9coJq PDEmG5J64jZUVkRU6uIxSf1krCvQZptVA3pM3UOdTtQF54VdlJp1XdDZVD8aF17kC92nna9O iEmF1u6Bthpk5eWylbcOJTrb2uLwIroxjdJonWGfH3OqnO6OjpwVNy7MedxdviAZbki2xlsO NDcMVPmlN3c9fXWbPVabuxl9KqqfSaeuZpYRPsb/kFsdtc0+NLKr9apVMxx5TaUTR+YtrF+5 H+1tETQWVn4Al/gNx9LRoM5QQxH4Oq1btIGdgDIIc78igblloRMgs7YvuGUn36Y3wD1rTJqL LJLF/2YoaTB3hOBFkk84u5Q/l9DxWm/uKMkfkzTH9FDb+EsJ6q5LXHDVncUIxB2zH3PAs2A0 E5ZJcMr9roRltdZf3z1QNHzX6oqZ244MJnpbKnx6jewwW+P1/bV7rogkh+prFjQmTHTK/lW7 3272Z2c4kvuP77rmmX11trRMn8Xpc8RDkZzIqccXHhpIZCWiOid8mjJZDr3cg33HMaw53JgM NdZJxkANbZ01dHSuodZdDa0dNbSy1DyNUyiEFHGtFdEahnQgG58Z4iYWj6uLaIUyOCNtxpp4 QGVBs1SP+rrQ1FXHLT1YBkdlYtUJfVZqYOZA2+AFp8f0JgjzemqYVmBXT5ugVCn3aO3pLrq4 135k8cqbFuaUrvj8sjmHklpXiNYp/YPNl7U0ogahRs2MzEi2xf2iAu3pWdBz6NiKnU9f3d7a LBvF7H28FXVnxYFky1WrUZeaYdbKZAjaOoJeLYEV6MeTeUWVjZVbKhUnbU3OMLTkdEbyqS2c T7XFF7xY/4a68P7JlsQDCZku5Zykra1clap8QFbHWBi3AXkHp6L6i0TynzuoulUln1FJL6ok lSq96NexLt/byy1bLbJF/3Y6q2BDfNWL+/+ZFkt/k+DTe3R21AxAA9VEI9OqFdrp9Monu+OV TKFa5UjcPz4abNvam1zVWWTSGjWKrGiNlQu2Jbc8tL22ftt9KzfcubzgQeXSPTOWNGTCSRKP dO9dUOhOc2stfofZaTUZ/T5nw76xfTtPX9nasuNLA86r7iictbqKjnvZ2IN+rXovLINVox4b bYCs4QVSvRZF1luBsLEPyLoxmHLvjxbnYV31xaSD+nOzDecr29Ni54s7wrNsHdQhdL60EU0s cbaMmbhnE2VY4xLmHasqbtZjQw/TZm3o5tl0AL07cwOp5Gth22i07mBuILs8bPmBzqhXO6w/ 0KFrguNMd4XNRqcGV0Q7NnVFm7JMsHmsTq9FrTfqfWW9tSu09jRnVvijP1PziC6PKe5wljPN rh1aet2CXLPV5GRrI9mTf1M9Bi2sJoPHkl20YzatjkZJ+erVpraBMoK8HvfYTLPRVJLuZT3J jrKO2lpPwfn09i5iOu/p0LDGU4r8onRpzuEtLXuj9KWzCJZBbG/QhZELo/8nMik6aa6WiJgg uadriHXSXGOpdQK7tOETamjfhPEqCJNR0eiwSki1VoaWcJfOQR2NDt0f6ZzBYX2zssOTne7W 4iLMYYO5RZ72VckMpfAzFGU1Q1HO6Xp9RTjOXuEanjAMLdMb9GqLz5GRabPoNdmYPePknUIq Jm5XblC+j/0cs3Ei4cWk21HQTnuwdh0aZnvY5pRmtZc1wiKl1gWQ9V3A15+kSY3aOaBJs9Uh zZoTUFmLlTKtlrZUdHSoi2eSZpCCMm0goC0rUNH6myxHoyUD9E8MhG24bSAvO2kEZluLtUp1 1y9N895yu5dXK3+q78gLN/2iumvxL8JzUgvVjcwaOf8KH1YTZecSibMJL6a3dIJrx1hrO5fA b0J80BqN+guHJvM7xOC9cbs83pTXQazmVMF0we4L+kkrtccLxwRcEVOmCl3ajsXjFrgq+FB8 g9N6ZTS9dOjg7KqVAYd3ZuWfm7f2FZZf8uC2TUdW5NsiJeGSotLsUFb5kitn5baHJJvdPjGx eqi4vci7enFJR5F33rLeP4Vzffqrd3evbggoO6OhrIVFs/fOy8/wOAqD0ULZIEdmDNY1bO0v yU4Olkcaqsv8/ln5M5bHsoeaevbNL9DrIhN/X7I2XN2ZM7gmVNUxvrS2Udb5C3Jz3DObM4ob aN9xBDbzfbB6SsmlJxrLpbwLi4apTmPaaiKzgZy0ZXmDfGmIDmp8fYh1yUaaZuCrQvBkwxmk OVXQldXmn8WGJmrpwNBJLYpwQ+eiccnOrEGN9kIrE35kO59duZX70AiYPeMr7CxuONDC24RT K8yc9ls7F+2fFfGLvkK29ixtyRroH79RxEy3bbo7Z6y5YZiOQtdMfiD1qouw8hMhN51qjM6J bokqHtpRIovAC7NjTIQRZpUXKGbRrEP1PI3dZOlYomGa+uSSTEqlWJJ570lDiO7mwNd/NJzw 2zqZfl45n0gN2ylbkI4xwjV2wfZz0v1BtDKiFkoNH1eAM7+uNkFlSgXK1bDo0HGatFJxbV5u DQQ5nnx54nZpFXKcBR/4tcfnlNL9NcwQA/6DtmMgHzRB3qHL/tn0G+ISJjRQdh1QTKX4+III PqdCX5s0+P2ktJDmsRB5PJ4T6sRCq+qYmrVS5NReVpbK7FmeW+Q15T9NOZdYM/qMbPcGk6va wwU+TKUVrV6riXojRUGL6EmpDvISdXV51lX75yd0BrPdYabr6GpXQUencvST6uDt4ADaQTm5 M2lqrJRyS6SSpEPqgen5Ihs8QZhdC3ybaoeFoZSSp3H+OZOYUmX72SusaBppnoICQlXCm4gn 06jO6Uxvs4vmwRzLMGQx2rDxtvR15liCZqaqQXzaEDTVOFJ7ldwujVaSPB7lgA7zy0DUZ9VM XP3x+iHN1zn8WCbNdOvN1omnpM1mI3ODKlqzXvrHhPmTzeSjn2IWatYrMFj0Jp9t4qmJbLs7 1XdIDdCZmyTZaukWtlrK6v60upGqEin9YBx+74TB1sYqfKoCfGot/2TNnqrQF1pw6i3UL8J+ nEveTgYcdKsA29ESY56QOHODbO2T2qb1Y+yNEGaObYYoEiCr1ax/CwY9aPbBYClfgaTdHF+G ZN2cAfX71FzquZ3bgFkMawTTZjPssQizroEhbo8/jYPmpcQmaUa7uzCx0STNM7sa2gqqOwtm TXWPKH9qvwvbvSa1ioltgin/A+0t2ddjTOsV6AT6oi7zExGptTh3ykPFp45u9Yu8K3XqXPkt hTU7Wmnrwfqm1pPfXFizc6pn1TjSvZ4Mm3bWLZ3Vgy3FtoLe7vashbs7Q1PlIUdrPtbHfjIG 7k0jqpDeqNvTPyetaGZOSUueE53vLDEGoQRLyR1JKy9BWoyp4ejjpZQahbjaUWqp0kTzCgSN dG7Fty5Q22H6/gXpvVOpgYkOS0lDQVeeP6tTqB5eHqhdqDm1spXS9v+k64tV+9nD05QSv9Dz fxmeLlIUFLScjk50pv0aNERXNR9OpjfmSjkOKddO/ZoxkxTTSTGtlMc8aWylEkoAsvoHZN0W 8OKVTDoRChYZJMO0JVI655q2RPqUbKDrDqespGcrign7o6RRaxfWA+WU6wIqG0rVTLFjhvZV qR8xTxCWsHBWiIm48lrtjm9s3/L1zZU1Ox7bAax6PNCwYU7n+pZIoHHDnI4NLWHpD5tPX9vd dPmJ7cAu4IHOq1bUlC+7qqfrquGa8qVXQTdHJu5QXoZuqN/mIPXbRCrpRlI6bgNZ46Rh1omD sOqCFgwjxs1dNsx5w1ZfuPfmU302nbY5n+mz+TSXzSdNGPdnu2xuW5rTMjOZJbpqVBaXO+DQ 5s7q6S1YcZi6bMqYy6Yt3rKvuWGwKk360+5vHmq3ZZZHJxqEp0b1JzQubDI16i/Na8h1z7r6 iV2tV66qd+Y2l0zcjdMtqw6kekv5IWirjKw8sbVCillTKgIyzQC5qiihOrRSVTlSm37oEgKt JCQNGsxO6hNdMas73OmmcyfWeUlF1A/DZsu09YgqQK3kT7HquEo08kOyRq/TeTOy3P7iitro ND2wnid7Zm1NhjmSlWFSKZKywhO06/V6natwVtX4iBiuLjSbQ5UtcauiMxj0FjYv7J08Lz+P HHeS55Omou7G7jndV3Q/0a2etkzHKgkLo9MAnjkOI4+F0ZIYojuaOSb9Ohnia3V0QAhQZ05q qQ7JAdrhBJ7C14jQbSoGBIgpiXgYBGeSMTyv0fSESTYV/qbK8Gf7XPty+1a7wpfkfkXX47o8 b3F3INTIF+NSS3HYpiw2syCpKOXW4d4HC90p9f95KU5+vmzpVbOLF7YWewwqutSWaFxQnddS Gogn5/b3JuO5ffv7sjpqc92YeCrYo6LPrOwsykvmunOSff3zknHJ0roR5e31u7JCTlhTgXDA Ea3MjpXnhDITDQvqK4Y7800Ot81k9djsfpvW4/c4o8Xp8YqccGZe/Xxa+yKTf5M3qb6BUwJL TuQSe7SAVjKoiiF0CmRlAWRuMIZQIhbiMZ33mgvORzsyzOe9HSXUltQy/+l5rMhL2EfPTKXS c2e5E5DvwrN/fJYuf/p0XN6ks4VzC71tmEBfbnXQTZqXiRnFm9TLjNl2Vbs3K92lU+vVqsXT p8fcF/HZc2kyOUnzrfxNXYRvycEpF5woqJDp+QymD+XX0MdMMmO0aCYGpvdOJILBBNrc+0mT UpGY2WFLnK+r6KCm8/HsHj138J2DV0YqKv3NG9wtQTcmlk7fjYPFx09xNHyKKpSHgx6M+l4/ nDATRdMy+NnaUE4F0j76wlSrc0/3GUTsUz6DjyuF51X1E9XP4Z9ZjrxakNfRxOwBmtOQucmc jn+kIjGfzO6Y2VFXF+4o7pA7BiyJ8xUdWG5VjWb3LJlW5PBLlZ7FAgN6+6Kz1D2DhkF3K5Xi F+rAiJ0q/4+pgnvnPq1WXNhYiG3qdOM682hNqVH1E52de1gagxMzp2kKbjxrMOfTa470jJiQ /JHVIcuble1THpvFGRGbxZBysUzTot1lN5vNwvfycT1Kklj2nJj8uNMGOr6Dep6Vb8KSug1+ 53LJGKc9VZz2VHG6Ghpn9mucWlfY5vz+k4QasSSU6uqBrPUB32PDJSV04kcvEBFsJohp6/tY Ei7ojBvV/k6Ys+oL7mc6DggLdqrrumiaL9zPU35nvjyMvbRiRgPHsyPD7c2wa3ruYgaT1sVd hd6ijuKG/a1wQFNPmH7KBN3TP7t+7Q0r5ExhZY7/a86y5uyBfnmXiKHtDevEyn7oJ5/87jQO qMAGoIujIbZ6mh2SgpwEJTaxR8bZ7kqg2FwnzE1HarS0QzHJKlxQBVvMLsVtUo5aysxBxIxM KStTilCKffdZESnMYsNSVliKW6XdESlC3a56u7sjEsbogNBbST2Gm0gY/SEN0Ukm8J2kCc+I 5HRGjGmdRj7QQr+styOJIWZvJeha9FCCrkmnTrXQFdwEHX21U9sbpzYly16nly9VYsPnfklW 5IlzKnNaTjCY48e67fMqNd2I582I4rTLhEr5UMZ6Q8AbtGuVe1V6g0n70SN0WVqlsxiUhSaH XkGNlPGhH08zmeQ/6uG+lXVGqu2KyQ/UV0PbreS109gqcyY5A1nDyhL2FVVLVRSzC6VYRIqF pVhIigWlWIYUT5dyVFKuItXWSXW1Ul2BVJ8v2cLYhoAvamROF4pYHkJEGE+wwU5h0RTZ4q2V RltndrLrqDIbbXNsW2xX2FS2pMPTYSvrzO6svTVfyqdp+XR0tjk9HWvz9+TLrYj1zmK97MtU k0NnGxvPQZNc30znbPGfL/9zM5crGhPv1DZSJa6dtloubN9pKp9G1Ver1BPvKmZvTjCU5zcp 35LlJxRzGlbQ4whNvK9W0d45PdOhU34hy8/JegeqPXZOyq/K0isydjql+XBoS7lX67JeKBT5 Zr1+fMeFIrK6tHojSgjz+/E0vR4lZMYADx/IuE+EZB0MfYnkonV0o7yKyLWnSQkUY0fNw9YC uHBoj1FXKGGPxDtPgpb7JOz2Zn0DbSosyiPpaW3NQzKh99QTqToqVRolY5hOymipGI0lxbmd UaM9o1P4PGhvQfdWsAUVtq8Caqe/tCJne9iiMTYeKBfOZU1bdp9ab5eUZp0zHgpG3UbVz19V Gd2ZOJ5ll/SSb+JdneSMhzOiLoPq3Isqgz0UyMh2yPqJ9/MtTpMaPg2ttHriSwBFbXJapFPS QxanWaVoDNqJY9IcgKIyuqwTS2nvgZnGAegni/SdJgHktQLZrApIuQHJRxenYj4pZqm0yHG9 lEZNv9o0yV8NrPNLoU6/wdlp6FbNwdlIrC7QbQVousgl30gylIgofF28yondtVKsfGo7iZO5 mz0urVy2V1NSmha2y5oDepsy8YzOlhUMZrr0aklS3tPYM8PpWXbNxEmbXW1yWaQalcOgLHH7 LGocPDOPF8qvOI1q6ttHTgYxqXwV34qUIHWniQ058dB9LzG2D7AI6eX6Fr2sz7Zjqnfc32HF WIEpH16cLgdht8nQOfQ7KB7qL6ebyGktr5IuOghBfelaiW55kl/V6Cy68VfcAdplSDdPXGFz 0l3mssqIbTE0bmKX9CA2P2nacLxBmx7JtHg8fpu8IZKNUzBajcVjD1t83jTb+F04SUJnw0Q5 xXy1RpxSdWGnh7zthEavmLBg9do5jDzcnz/lIZV6hUd04gnVuZQDdOIYcpk38Zq0g7yOE7CG UaM3ndheOse3Imq1vDFXOUX7lXZoLF77DWqz0++0ew2S6hqjLyvNn+U13hIqLyzwP681YO6F RiU5DwbCNo3GFqZv2jHxW+lm5U7M23GK7FiW62l8l2MMCftPGkKJYrWVFJ3DH8U7v/TG9+hr M4NeHB6R6RzyU17lZr0/JxTOQev15YRDOX69xuy1X682O/wO9mqHTN4svw+vpoTD+QGjMZAf ziygWDDew172xzqDFptpjHrJPvWyMnl68t3Uu8ZJ4BjBBun9pwzBKDwkVmj2XCNeE+thn/6W YpGEmk7SJ97v4+/7yffKifAXxUl9DCJpMJIl8gW8z2aUjpF4j9GNemeeRA+CcsYQiFdJPEuL apojfHNRQ30hlU3tRYWtEPoMaeJNxaD+NjyUumM2NSmCbehNFW3KZ6p9WGV2Zbj9EYdKIw+p zM6gGyvbKvXfzdhYpDU7zZr9ZqseJesy43mt0gm5UJ6BE86WE0RrPI8tMOexTshrHKv//Nyj XOiwTyx14Ef6Kmq2Wno/HgzFYkGNPQ2Hwf8jnVfJ+DZSK7GP4imnpXQczP70B6lkp/OjRqfD 4VSe1Vv1ahkLyjj9GtXz82DXTDwk/VN9I85yZybdCu2kFToNVVhDVtwh4zWksQjlhr4U76iB WevwTh12LVRYu+VuCelvy4aWLVZLlgy/I81pUir7qtNDNX1lEs6gebzpNlm94gcTg6+8OrHo Rya7UY1jM+o1P/n5b7Zt+/UvfroWp4PRYeJgt0T24Y3exBtFSNlp4sDsDu8Ea4nN8iiepB2N A+7hM3TQgB+Bv2GilL8irfG0gOgJ3EpHRbkcj3EXm9fjkN5Mr+6tVEw48ZiWYZbUS5YuXaqS beleN46ZyWt3yf5tv/n5T9ZgpVlWo2v5ofTQq69ID/1Ab8PZSY1GdW5iDtRM8M1uIXUXmY9v B6PfiFaUNHTuKA/u9S/SWjePScrJ2T25uVa4ejQnW3pW/cXallpUxFYnrByWFDtpV8c1l1rH pQdcvQ0K6wRZFOv6gtgJVsmWFJEbDGCs1qkkbBag16Z2PSmpvQN4IC6QNgaTaztzarJteUO3 rRu4sj8Rm39oKHPuwsX5sH5NWhsOR4RcGPVLggXNRSGDwWFETk3hNFdxsr8mb2j9jubGbctn VcCIsoYKQp0r6wPuwraSis4iz85oy5rm3NntyUD52uWD2aXNuY6JN6T+qpVDC/MrB2a1Rhu2 LSyLta2cUbdiyeLS3MFFC3MCrT1zc7Pg91fJWqvZX71x7dKcrOKgSdb5/P6g1aCzROsLM2tz vZ7chjkrFDlQPaMtkduaTGZlVOT6AgX14znlCxqj9oxcb8HwiuHCcGNjUrkGa8lk0qzZqy7E t9TRb5LbcHzbIR+OGmxKlhSafAXVZL+v39dP2lbufCOUEyq5/K/2RX+dO7dbazpUuC1LbQ/h 39IZf914dW/335aizTS+hCVFTP5QNqVwk2PzMj3xgzb57Fka/aztJ69gZ/MbENZxsVlhqixQ +dl2M28VH2q1ioZO9+BOoQ50y0X7hVCk6Gqy2OKvhhaymu2UUaXWeqskzV57rGHRnp7ctsps LbZatUYSTWVZPoMlXD1v+6xwXWVpml2VHnP4LWp50FbcnNtUmukxFG1/5tbdYzetas3zaMsu f+n+zt0LK+F3UcsSNmHVDF81++mJ8a91GEPVg1d847c3P/C3e2aNfzM2tww+m6hHX9HoK61u jH34kSK1fO7aPYvKnFk12Tk1WTZ7pBir4oktu7cNVlnDxZEBiwVHjrQT5Qvn5bYNrd1YuvDL e9rLB3ceuuGKrfEtY9d22Z12rdVrtzisJoPLZRl44I+fK7/uyL1fvG517ZxbXziTbMmd2beg N9Q11x6tiSt9GNcuwTzzWzi1WU46yJHTpAu2otcq9yzvkhK7GqU1jVJzo1TeKGU1So1jcnPS ZUpPN+2rkDZUSN0VUm2FlKiQKpDwJNzKYXQa1IRHt0XXD0/hMaQYpwbHJj+AF03uMdVOFher Y/hynFHnYMuY5D6mXibaJMo5MYS96kNDbzBjnPlDGMM4BdOKj6fUQUZL+qK96dqPeWNTLVH5 VvnGB7f1HlgyI9vmKJyz58HN2bOS+diCKUtY/TLGKnvKhq7tz1XSZvYsKFl/62DscW/loqbs rtbGtEjj0sbk0oYM6Wv9917amdO18fADS+c9+pUb19brrQ6j2eq0YAlSZ7FbZh18ZIk16LPW rL5hee2ypiyzN+S48vH1BcW9+BIPhfRBt0+x8y1VpF266jSppJNv7M6pRPd5gnafFZTQGEZo TLmIYYTGlCHmOCb3DKHbTtrj0iLqlIrFcxihW0Wnx7xOe+xi/FdNSb8rh40jOFmDa1KcHhDC sRpfMi1ojQaRC0yO2UfQFTRUs+ur6cTWnYGpHrsxFUlvrH5Kbkb7f+k4LeQLhX7meOokQ2r/ 4Bnqd6ZDBNvG1ITXTRponpqK8VAaZL4IRlg0fRKe3kSrmt1ALW9DxQx1wbh/sHV8qrJg40Fq qYIdbkg5qROs90hQ4F58/klrD1tno9Ps6WbZJ7t+he9ZoIsa3spK+vUG6F9Yv1CpPFW/7cFL Vn1lc21O9+bW+iXJSMnKI2tW3DKUTzcXtm/pjv88o3pexcYtgZqF9as35mW2rm1pXDYjdM3V Bw9Js+YfWlSY17e3Z8aaBd2ZodbeJZUtewbKino3N5Ytnd8Zjnb1L5OX5bUU+1f0x5vra0Ll l49/tbB75oxIqKGpM394wyXU/kRdeo6dhktgddT/sUWjbLFoBDfrmWQ2rR0F0rTlILoG6qK+ IxctPBf9mglYsNSDGebu2TCtZKgBQLZ2CmQOJOBb1FqDrwPHEAqSegM9aJckCl2ISepxR5Fh jkEmzAOCEE58sgpB/eYgBoJvA8TmNAMO2dFTaOKQ3YU9+Jg42d6gM0Rs4uGOX+oQRz/Af6aX GO2tsfKEnn/qGxhUynNFm0au3PfQmkTxxpGD+4EjlkCivqe4f8MMT3Dm6o7q/hmwr+XDd/7n 2PDCR9697453GT42fPfu/ir/3Ju+ufHzPzpYm9W8dPs16L4eR7O9V+3F99z8IZmVFZSyMqSs dCkakLLSpCy/RKeFXimXLdg56FwYzQ17nqi6iyVCVUtyqb8HKUCmUIbQPpApFMgm27n02J4l iD39OMZipJ9GuKBY5wlk7Qp4hj5qWvwZ6kpCGKrHHffhm2ac8Kk2Ho/25cLlrOWng0sbx2FW c50mzmHHFN/yl/gu0yzhziWu3tS8L+VQimCOpuHboqqyea/qZj5U5V4NviNgfInWZNRo8FUH kuUDuvsMp3z0Up7K5PA54MLTvK2z6NUtdD1Ba0vDtx3Y9crP7zSozEGv3WczaZ5RVNihiQ2T H96ih/EMbW+Htu9BnW7AarE5t1JKBKXcDOo9SlK1smEoKXnoFmxs90Ov4aFq8qAaPlmWjX+k JqXrmqfwnwIYoSwoxwglJo2oiUZ7dU04XIPKV/hkmUdTOM8GUzBHaAi9BNZm6HdBUAfcG4lz 1MZgFZB1GOxQyEXKoW42Yeyl5kjMfGAmopYdCLpHDbt+vMLitmoVg9X04cL1NY70irnlbIM7 3BIqfFGIr27wkrqlNw8Vetqv3XJOLsPZB3UXPe2ktQU9rqDXa5YMS27buyKR6KnNzMzJ1DmC bizCWNxZUV/Fkn2tDftveWL7K3oHWw9biz7hNuhvQFKfxsLymWQ6rYmLpBIdVFZCpw8lTG8l VG8lY3JF0jB7Xmz2bB+8lFDxW8kYLolR51kSsbGkYgnQO/n6F7szQO/Exj5WZQPQ/EnmEEJz x34itG9LqsoCWW0Hnkk6UQyWuiQeW0fdeLOK6iRWlRFBkY8AdfY6uweb7o2w2ufl/zMcVnfS g2zGqYNsRedrbFNn2dB1U58d+nveR8BIZHsAsQkw1dtPsxI0bENVkG0RZ0U2NadNHXGbfk7h QiG6g4pyW8PORy+ZuW2g1qrTKBazvmLelpamVS2ZiXmX9uxHWWk1Rot+W9P6znhaeW9F7fCs UgP1N2EO5azt35JcdP3ignDDorrmLXMLpO2Dt6ypcmeELBbMSrPSw9nhzIb+0qqBZCaah9vp t2ozk4NVOZ2VoWhOVG0NeKjh5kQ5F87f1T5jfW+NUdZWzKV9fzG8eT/DeaE89EsfJmupq7VA iudLWXEpKyZlp0uxgBRlHVS2T8rGGSmPFHNLMZcUs2FZWMpSS1kqKRGg5sKZpIP3VgUeH4iH dmLw+7F+h+IplJ0nvRCnPyc/SmbgChttfjZal2x0AcJGBxEbnZ7a6DfHxImK91XYlv0ibX50 m3bSgGSVqrgoHsCGMRSwKhGx2QyRPgM/hYNWV4ZVn5SvMJFa70vA3KdbOenWfwzZrAWKUWBq MGBLOSnXCr6ug/db4gueaF/lwZGkiPIzl+M2cZZ//G2TzYxZrkEr/VTtDOYHMemy3WZ3T9wv TyyWHpK2RmIT74hVMMmmsQV9zqDfa1YcWI7HV2yZ9R99Lyr/abyW9lir0eLuwgnEBvJs0hyv kuKVbMuGwnosZpQlpapUrwTEt2Kh/lfRI4c5UH0OVJlD20WOZU7pltIrSpXSTz+2/RTOptNT T7SJoczojngs24Odovab0+lDw8lPmvJr/xXOxDkedX4vvhBlWtMZwuyJbjWSbK+kWszZoZd4 4+HKpdpNDa1oLXxefqFxMF+M+H4Yun4WSW3aVO5qO3hsY/3G+ZVWfCEZ/E5aQ177+o7mrb2F 8d4DC2YMxNJ9oQx5hs5qULscExnRzuItD26pke5b99UttXa/z2Kypzns+OYTnNsJt6ztaljW GDKlZcvWSFiPTjArZ+JOtVwxfBjrrKl5Cf43kJlQxaSwpRFugtUis/CD6PuKEf5W0plbKOWp pVy23pCH7wAySC20sodpZW9Bh4iqy/vCjH0lUk1JZ8n6EiWBjYH0AK+eWCxhTGKpFYOGwHT+ +gmq8zra8+FW4Dv8QOGuOqmyrq1uTZ2ShVWNMTmRtBRlY//EP8JhbeW/8uahHHTHtPybBDCH wbSGTWjovuUEO0aFqgwHyYVSYOVAJ7MXLf5XTTtZJY7fT1k9lcqDruLe/Y9sTfTOzMexO41R Z8yZ0Vc2fONAvlxxx/KNtw/GSzc8sL33siXJuP2JzKbljTOX1KX7qxc1dd8kPzX/sXtvXFdn tDkcoTRPmkVtdVi7L39wSai4bs1N8xZ8aXdbbs+mw/e3HXxiY3HRnFUVdStaspkXr41s/D9d nDFPwkAUx3t37VF7LXJwBROtxIqB4MDQSFw0RmIiDq5uJrqRMKm7k9/AlS+hhnTwK3Tla7gw 2ob/qwkhdmiuHdt31+vvvfcTc5usgeaj39knxZIPif4gyfKMNGz0i4Yk7f/ZmWzkY8vP5Fx6 aN5O0Q0bmghWoXQr8CT2Fy4buxouDiAgjAKQqYsGTEroq1UkW1Ium6ITqkF2JYyA4hySLr3j HsXDPTsVMzG2AjDg6MuqVkL1zUiTqHHeAV9Y4F0kWUk9EdB/TBmF35rCe30lZq3tHFUPRvNl 3WyOhei1271OHBd3lF47iuNyPYCxMbUPYOXyP+t7NQkKTOSZnkWFrfdSjBFmGg6bLSrpTG3p yd8fVSMeU1X8LX8FoeQo/FfCeAE/17tGieKFCB4yRqHvsDN2IlXzMAIs47J4drqYAliNiP/T IS3YNq8vb69GN8ejh+nk8WmyAr/riQsKZW5kc3RyZWFtCmVuZG9iago2NyAwIG9iagoyMDIy OAplbmRvYmoKMzIgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9C YXNlRm9udCAvR01ZV0JLK1RyZWJ1Y2hldE1TIC9Gb250RGVzY3JpcHRvcgo2OCAwIFIgL0Vu Y29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDExOSAv V2lkdGhzIFsgMzAxCjAgMCAwIDAgMCA3MDYgMCAwIDAgMCAwIDAgMCAwIDUyNCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzNjcgMCAwIDAKMCA2MTMgMCAwIDAgMCAyNzggMCAw IDAgMCA2MzggMCAwIDAgNTgyIDQ4MSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUyNQo1 NTcgNDk1IDU1NyA1NDUgMzcwIDUwMiA1NDYgMjg1IDAgMCAyOTUgODMwIDU0NiA1MzcgNTU3 IDAgMzg5IDQwNSAzOTYgNTQ2CjQ5MCA3NDQgXSA+PgplbmRvYmoKNjggMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvR01ZV0JLK1RyZWJ1Y2hldE1TIC9GbGFn cyAzMiAvRm9udEJCb3gKWy04NiAtMjYyIDEwODIgOTQzXSAvSXRhbGljQW5nbGUgMCAvQXNj ZW50IDkzOSAvRGVzY2VudCAtMjIyIC9DYXBIZWlnaHQgNzI4Ci9TdGVtViAwIC9YSGVpZ2h0 IDUzMyAvQXZnV2lkdGggNDU0IC9NYXhXaWR0aCAxMTE0IC9Gb250RmlsZTIgNjkgMCBSID4+ CmVuZG9iago2OSAwIG9iago8PCAvTGVuZ3RoIDcwIDAgUiAvTGVuZ3RoMSAxNDM0MCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVe3t8VNW971r7nZnJvJOZvGcY8oAJBAgh ARG2kCGBmBAGNBMgJjxigvURkAhVrNRaoVHBc2pBq63aqlB7WocpB4KtSK0CR01bKz5bz+F4 qXCs8VIvVYtkcr+/tRMebc+9n9t7zx93T9Zev/XYa6/1+/3W77V21q/r7WQOtpnJzFx1w4oe Ji7nJmRHV92yPmSVNYMxqefanq4brLKxkTG1r+v6L19rlV13MVZ6trtzxWqrzM4hn9aNCqvM pyIf233DejxHl1PBbeP1N60aaXfVojzrhhUbR97Pfody6MYVN3Qix1V9HLexPTfdvJ5KKG/G raNnXedIf55gTPkRY3Nuuml9dw31wDsY48gKWSPTWQNTmcTcrIJdhZWc5sNYLxftKgYOvJvX 7pr5J5aHZeL60Yr9OZS/8IsfvjLcPHTS2K3fg6JN9KcGjKt/LT2dMeM/hpuHNxq7z7dQK12F pm3J809y80lP1rwn+rkjNaXo8X6eZaaKim46Mjl8I9INSNcjfQnpOqQ1SN1IXUjXInUirUZa hbQSaQVSB1I70jVIbUjLkZYhLUVqRUogtSBdjXQV0hKkxUhxpEVIzUgLkZqQGpGuRGpAWoA0 H6keqQ5pHlIMqRapn1enbjKQTUvdSFlV6gbKpqaup6wy9SXKpqSuo2xyag1lk1LdlFWkuiib mLqWsgmpTsrKU6spi6ZWUTY+tZKycakVlJWlOigrTbVTVpK6hrLiVBtlY1PLKYukllE2JrWU snCqlbJQKkFZUaqFssLU1ZQVpK6iLD+1hLK81GLKclNxynJSiygLppopC6QWUpadaqIsK9VI mT91JWW+VANl3tQCyjyp+ZS5U/WUuVJ1lDlT8yjLTMUoc5jDtUZ4TcvkogTS1UiL4pOL5tVO LoohLWyaXNSIFNo5aae5s3mnMmkrd93Lt9/16F3P3PX8Xb+6S93e/Wj3M91yx5qeNdL2ZXz7 Ut7Twrc3P9r8TPPzzb9qVrcvenTRM4vk7fFH48/E5dmbFm6Smm/ruK3nNrmnifds55O2d2zv 2S6zbRx/5raebRLbNmmbua15WwcKmrvH7JE61vOOm3lPLWdlZWBWr8cwq12zf5nNXd8r+p4U BNH9SE6kTCQHkh3JhpSBZCDpSBqSiqQgyUgSEkcyNzHcjweN8O/8RvhNpxF+I9MIH3MY4dft Rvg3NiP8WoYR/rVhhH+lG+FfakZ4QDXCrypG+BXZCL8sGeF/4Ub4KDPCEWdsjCMWtsVCRqxI ixUqsQIpls9iuUbQyDb8htdwG07DYdgMw9AMxZAMZjT068PxhqTRvCyxh/NtrUlvA2tYMucA 43z46/dF/87r5jm8oCGZtziR3FHQ2pCcAoAV7Mlmc1obQihFkjsWLU0kJxW0RnlszeI5vKE5 scdA69zlVp7t7pm1p7o6tiaUZEsSSbOjtXbPJNbzkylsEsvpCfbcLK716638ovvfOd//k8fW R8ED6gdIB1gOkl+pYH7Ghk8ifUQpvRxtv2AsvYQxGdJVfR0ydDHyo5CJ/6+vo2wAvx1sL37W dZAdxe9e9hh7GPV0WTWMPY0fXavZ7exO9NiBPqPww+w352HUS5P4NB7kT/A32TwpyMv5CxDj b7I/sD/w1/gdfAn38Rjv5uXsPqmKt8qzVRXwXnYjnrqGv8pfVd5mN6L0JkZt52fQtlH6Nb9f voNtljajheb6ZPp7bAo7gHn8X1/G/5Yeo68getBF9Pgvuf6L6GFOW9IQXjC/vm5erHbunCvM 2bMun3nZjOk11dOqKiZOKC8rKR4bGVMU9Hvcrky7LcPQNVWRJc7KY5F5HaFkSUdSKYnU10+g cmQFKlZcVNGRDKFq3qV9kiF6bgWaLulpoue1f9HTtHqa53tyd2gmmzmhPBSLhJIDtZFQP1+6 KAH4vtpIayg5KOBGASslopCJQjiMJ0KxYHdtKMk7QrHkvFu6+2IdtRPK+R67bW5kbqdtQjnb Y7MDtANKlkV69vCyWVwAUllsxh6JGZn02qRcHFuxOtm8KBGrzQuHW0UdmyvGSmpzk7oYK7Qm iTmze0J7yg/13dvvZis7oo7VkdUrlieS8go81CfH+vq2JD3R5LhIbXLcrSeCQGBnsjxSG0tG I5hYQ/z8C3hSLXZHQn1/Yph8ZPAjzPqimhUjNVqx+0+MGmmJ59GU5CtGYYa5YYZYXzhMc7mn 32QrUUhuXpSwyiG2Mi/FzIpoa1LqoJZDoy1ZV1HL5tGW8493RIDZWCTWMfJ3S3cwuXllaEI5 KCv+ipNKMdpDSbmkY+WqbspXdPZFarFC4FJI4FoA5ooRZMb2TKpA/xUdWMQaQsOiRLIi0pP0 R+ZY2EYFBimGbE+IR6zaWNI/N8k6Vo08layI4VmwSKyPCEMTpLEiixIHWOXw8T1TQ3k/qWRT WSvNI5k9F0QpifUlVl+bLOrIWw3+vDaUyAsnzVagrzWS6GwlKkXcyXHH8TpcIKB4Cmv7i96j nbHspF5shBJSntxK1EJFaB5ukTkz0eBOalaRKDpnZijB89hoN7xlpAdBl4yDglw8tx4PI8ej c+vzwmBucf0vppRnLQDTSBrn56RgEuqFOVnv+U+nZvWmCY0LxTprL5rgJYOiICY4MtrfnqdE uBhBBqZgEDnraQ0TyiXAITQbSQnrFFVExSCUdXMoEemMtEbAQ2ZzgohDuBb0bVgcaYDWF9Qe 2ZN9RqRhcR/VRmqsKhbqm59kYCcTW6nGO9WqnQch1tc3LxKa19fRt6J/ePPKSMgd6dvT0NDX E4PwYc0J8ED/8LP35CXn3duadHd08xng3b7I/NV9kcWJmSAAOKv5/GZNSnOXJEYmJN4sOAZ9 IEHm7InwrYv2mHzr4qWJA27GQluXJFISl+Z2zGltnQDPiUGLrYE+f4ptU6aw56TTrEw5xXZI M9gBNY/tUHazx+R3WLMyFamXbZE/ZVcgb1Da2BXSnwArqG9nW6R61iwtZzu0J9gWKisNot8W OZ/tkC9nV8jlbCHqb5f/wBzqGeaCvrJ8MAYPVGPPohxiiUt8KQl1l17ypcW/KpFnaV3w7EYu bRSAJ2hdBss4X/fXgI3ZMaNMuJAu+Iwe5hVdfLCKslg2C6AUZDksl+WxfFYg2spYGfsF++98 jTROekC+U5mqLtFu0cv1943vZLxhm29faP/McZfjC6fu3O3qccfc+z3LPSe8d/ocviE8L7HN /Bp5s3INvFKdlZjZ6iPyd5RHdLyqGlVMf4SjyFjF0NAgr2hvQzZ5ks8T9hSHPeHNMhvaLLE0 wxBsCJSk8bYNf6TGYKeVssns+2ZHrPyq8s7y3nJFHp9t2CJjC9wuf36gMXdcY0G5v8lW3qRO 2TCRS4FIaaQ6UhdpiXRFNkR0FomPLZk0kUmGERgHPZwTyFuUH1g0bpx3YjheMjEueeOZJXbJ nsnY7Nmz3YP083inVwzOHHQPuN8bAJxTEQR42P3eYHtbext3vzl4bNB9DB0G3MfE33sDA+1t kycVa5ExJVVTp1XTrXJKQC+JhLL8gXBVtacyK+LxZ1dOqQ6gj+wJa1nu8JTqEvnxfxh47URs +X0nX/hlz+J1S9OfrufrD/75zwuWTZuft2ZLWzJ9QzufvLXWXln32fvrn152786H3ln27fbT dy7dPz899Fh6X9/q4j2FvIk/cOvd6aOTJxIvPgf79ib1eaD8crN4o8SJAHVM1uU6WZJAhyYu +TmX5IUSW8gVbkgSFk6Lem9wy8To7e4XeXtbG1YTjvBKfs3jku9RDAZqlA1/JKVAjRxWzL5u dtzq4J1BLm8NPhjcHewPKqzeSGCs0oLqgrqCloKugg0FOwt2FewvOFLwVsHJAgcLeEu9G7yy VPC1SGZQNtZ0oSRt9T7o3e3t9yre0jLOWe7XQtzW7QrZsa2IGBVuoBxza2sbOjZw+JjAP9GA sM3aeASIniVVTY2M0UuB8Owsv6brWpZfF6BFDH7jXWOqfmq+ce2V8zuP7jhSWfWPifxZicQs JP6j9vH1O17rqUrO37746W31X6955Pq7s95FW2sr2rFmWOrKg/AaDOblVWa533Q4pIZgJiI1 G9FquLa6JFesW9+oSy06l7bovEznut/nkxr0/uEP97rdAjht2u12QDZ6Gg2nzUBmJiCHw6E1 6JLTibsF9w+fMV2ZmSjbanUe4KVc5v3DpzCQ1gDgo700NIAzYmgAZ027y4UqhV6AcnovjQzg 4700LIBz1AMQ3iDKX5hT6AXcF3R3uze65ZbMDZkSu8rR6eh1yEs9XC5VuZTl4DZHPZcyPPXg EIU4xD04pRJJIB83osoF/wzkOV9oo9ZBQaI2Hg2HPWMrQ8zj5h6wv9fjDo/hz6Xf4bkLwV3X njs8d9VvTqcn5KsHbOl70i+fO6WqXxyw8ct4EG4whx/C+Ffhzcns4AGmDh8yKwRuVV6mcrk2 CHlVw+ohbbuZ1g2SbGUPMkVn/aANKyOcsf7hYwJnAE4InAH40MIZEzhD+cxeoguAj007YY+F CHWi7CHUMU6oY/mENtQe3+vxCOCXpj0jA1CdwgxubaJPz2OBgPa2tesGaSvxaKWn0nPgqHrg bB1WtWP4I+XrWFUG//E+NUiUo1mYEYJsXNWwSyVN0msNTZJqZSOXVmI4aOVG//C/imUA+GQv 9QcA9qJpGmAhUf7EWobhp2Wg/Zzpt9kAuWm2hl2XA3KpLMuj7ATAYicAI+wkC9SgbLETgE8E O4mu9C7RRFihGtNOw8sGDY/yaTOLJizbaBFc0TIyZEOXBA/Nnj3gHoCO/4nGZQWCdXorCma8 X+PsWxrv1SC8+X7sIw4nljMH58v59XwTl+Uu9JA1HtEqtbnaYm2VdrOmyUFexmt4PU/wjVwr 1aq1Oq1F26Dt1zQGDgTySU7gRmlt+9pW7j58EXnaLi65BzGRpDq91QKYmNhetVdmvVAHrRA2 EEPRqMo9EU8lBy2V+UP2g83Svx9EnOGL36sHztnlP52tBN89BomxGzEFF8vlmhnocm5wStyp 2Nk8lys/WyMeyo7ZaU8T9QB8aHqJ6ex1+e5apVZXS1WJqcStRG8An+wlhAM4LQgP4AxqRNM5 wbioOSt2PYA0akTnM6gRAAkh63FzHPGDmlcf4FIsi8stTi5d5eNLc67LuTVHdudoGU6P7JvP uZqD6ZmZ9JKc+RnMUI0M4m5IgKgHerFyCjFzJWGYfpfIgfa2wUE3NsFg1D1TqNHppEj4mFLg bQrkgAcCmgtJMK1qagk04S/SX577D0ftPDxHcj/dy39w7lB97d4nkgcLpV7bEHa+K7287728 oWtUNT3Wtv5bt11PGq55+KS8Vf0NK+Gv7pHIZjRz9DG5TrGTnF7aBc4xujNXKfYF/P0QGqLK 72EKLw7M98jK/OIMNntwNvS7d7p7IOqd7g1M5xXR6EDFwORJeXs0MeTdxliuuzkrDsVCnaHe kDLezuX6st1lUreP+/SYPqZ6TNcYeUwuy43VOPkWJ2fO0g0Kl6oKOwt7C+WqolhRZ1FvkWJz zHAscFznuNWhVo7hMvra7EWFSnG9P+Hv9m/0K35PNa/jLbyLb+C7wP86E/OkaXpkIJ5MEtgX 7oE2zBMYxyXQTmL2Rfcx3EjGWDzflmf+fzrx1tbq6myoCGKM0tKS8yYUuAQaPTs7EMiGflci Y5bMr9k1p3fbwkdv2bHh1L7/0X5Z2RPzru0d37B+444vpz/711/M7R9XvXnVgjsaqucd2vLE 2wt/XDBt/bKa5bNqpte99OCTH2CPNg9/JJ9Q5sLyLeav7ys1SU0Xkzi0g3UAfGzOp92j+wI+ iXeFNoQkqcxV75LYftcR11uuky4FbJHlUquDdcGWYFdwQ3BLcGdQDxY32hq3ZvEsIaqzHDRs Vv/w52K7Ajhteog3swppv2c5aDeK2lra4FkOemVWabipRuVMdYgtnk0yQnXTU6qQEqp4ShXG giqeUEtmyFwuhgI5tDcTLyQAGh4jWnpxIxwjKZiTH7cZzrjhCrrKXDVYS8L1oGu3q9911PW2 65TLwVz0vC8gNRBgjqUZurwLCpcWSnJhfLfRb0gJg7PrjFsNSa4zWgwYP/SE3y80Dh61lBNZ KqLmlFg09TF9Ph/UjuGIxCVH3JsDU9urW+IEEmI6tp3QlCRK2mDfud8jvTnofkNY323YlBeL GGo5b3asHRw83OZ+EXrEkkRiD0SjPDpih4+FCe4WpqGwDT3+QNaYEtniJ1ji0ol1f/jKAV7w 3swrT6U6mqc93/Ifry9Zf3N06dj79710/023bd+/9fv/nsuVjkfLZx87md58X0X7HP5v/gc6 d30DPLQFOnw84s1uVsBtZqDFzqVgU539LbtUZ9+JNdoII0LOEyVJzgthDeBtIawBnBE6VfQh qU0AGYaAvEqjt1GXAlKptEX6TMKpH/WmEQF8atoJyZJCREL5rAkrBZCNmEWCFSBqPxeDozlt hoi/JIneIUk0vlQI+T8+b0begjw5K+7MG9VGBJguGiAvbnC7027o8Bcg+Un0R90wZf5a2I/a fW1rQTy4QDoUpGcaEM6y3AwWuCzcHkvaa3zc3PaDed+q/x33pD/+8Mpv2rYVv7D7xacitzeu UM8OnS2elf71qfSZ9MB0efzQDvf8Z3+779WZkPdXYL/+M/ZrgOeYhTGVP865XJZTkwMqZO7M 3JUpS0zPJFDOJDwRdgB8KFhQALSvAZwyVxDOMvWmGm+9V9ri3eXd7z3iPelVmddNT3mDhElv iPp7g9TXq9E29Ypt54UeAewmFHqDxbYqW8wmj1dmKAsUWXbE9cxApoS3HDLFts108bgBFxum qEmUYQqhmZBLgJlDoyvxLFuQqmziZba4y55Fe0NgOxp9T+yE96K0Ly5GPUqWvd020+J8MjH1 khFJOeJksio3C0/Jlp+5puCbdQ/ve/bJzXc2PPT+b9Pv83FcWvyC/PbdBVPfee5nL616bBUv +QIhjGnzyMtrGB6UPwJfO1kOLzSz86y5N2bmOBrrMnlmiJhQ4HQEy+BGwlmmQWtEw6diiQBO mMKYzoQk06jhfWGaAPjEvJYwmOkXUszftEXjNVq9JjHNoJG0XBpJyyW0aELoaQL7GsSg1qAJ oaflFmdXZcey5fGeGZ4FHllOyN2ylB0kumW7aZTsuOwhNDupyhPPqM/gktNG1uk+apbtGRDz +4kGGbrw/KOzo7MhfWC4APkkiy6wOqE7OsrnaByCaUM2fXGVFhkD75NBzoDpLckCt35atTxx 1XP/cpaHjjx19cGD9bc/9BzvmPAVN1+4iodO/5Ff1cT/eDZPnnb9iWT69ukhwjo4XMkHh+ew MXzY3DJWYD0R4HK/zvv0b+tP68/qL+vv6prUovJuY6Ox1XjQ2G2oZUaNQX73hap+46jxtuFg LdBKkjGGqGQIrjYEoxnltGZD4NIQnGwUNdUVwvAOkjbrEppsV3B/8EgwI0i+DrE/AMvrAPA7 sasAED3hC5ODRUMCOCEoTID5JaJwkBc28aYtbl7jrncn4G0qbjcNh62GWbkFndz5RCB3Ng2B SYHCbkFhd2SLvlPfBflTqlardWqLqkh6fLwxw1hgyHKL0WVsMGTdCOC0lPQQDQKApiJcnkNm lVino7DZsqzIrlIZN4n43KQ2guEGczWRy3PjfjEbWIunxGoIMIUb6Bf86+/yc2mBf6lfGtHG cYfdb+1U8IqbVNhgm6XMhPJCmbwO7Nv2tRcYCQpukPSbuPDc4IvnwbXEciRAeZSH/QHYQYgU 6eCv0pIqdzXEaQDGDx+ja3p4ammJknnuXNey7d+/obl82bp7X77vO4/f/9Lv7/xKeuwdV8ft 0qL6hZL6s85E+zfKQ+O/sXOYZzy2/aubBmbzNfGm9Tc3LiGJCqYbxi7PYk8cYAEg0AWKBEh2 TSBU9nq5nFWDTZPIkDPsToduVxv1RntjvQNemUTUc3gJkw6KM9B2BXDKsm4cIUKuI5sIjdo/ mtjIgPxEGEdGHEaIS4r7HDaX5jsfcJuJeOAIVkjiAUkzEW073HZ41O/ilmgLUBQNv6pKEV6T Xp4xpWWt+u67Bx955OWnFrerM/13deYVPHZurbz9sYEPC7GvmtPL5aPKepxPz+QdZnl9TiKn O2djjsJKo9VRSerkvQiEhdz5Xq2pLFoTrY8mot3RjdGtUT1KCoQWAeC0FZOJ5sxoynfS6vOh Zsy7if/zhYTKn8UiTZlTm0a1BeHG6yVMekW79/IA51tzHszZndOfo5wPmZU5ahwSI7Nfkq6b fOtkqbO6t1qS3aHqstxAUTCrWmzc6niRmQEHu2inscvYb8g77bvs++0yK1tsFC+2I8JzaK8H ZpgA6JUjNSLYc8jMIPRzOT5xMpFIOHWT41kTnXZNaBrS7O4h4Re7B48NgQmPkfN2GL45+eeC KXE7Lw4R+TwsLLDBw5CIbRQpPW99+arBttD0MNgjY0QY1CPoVB3QRyJzMOTRQwTqYMiXcGHZ WyZ/R9dT9371Wz8L7a448aWF73/4T99tbd+0bv7LT3wn/5qV0X3l392T/uyV7g9446rbv9zV ue629G8fvKl1zp2hf6q62ncd13Yfv2Jd79XtD33vd263XFw4rmjn3Q/sW6Aq967u+eb29atx mM3ZFsRF3wHP+3immZklJKzuDrhxHAsbfR+hiTX6yAsghxnA58LgAvCpGSCi+2xEVp9QTz5h ZqHtTcEjopNQdz4nSRV62vQRy/sMe6PRqGcEMkozZAal84kYHoBlzxFg2XMZwp4TZWHPZQh7 LkO8SHQnZgRw1hQSKcN/nXKrIglbwkUTU+Iuny3D5tLxNcOIyXaRDhNGNYLWo9uMXPSR3RX2 kCeu6RTaEJZbdpZHzrvlS7F7ig8eLPnB0qd/Lj2+sW/RtHMn1A+GXr9s4fEXhtpJZzUDqT9X X2R2nC28s88nRCsWfmgfCYCM2ygyJJADwHKBAJwVSgPAn80QYVz2OB2NGzyceRQyLDxCtniA Q8CjsgXAR+IxAB9YRgX10KjH56adhvFgl4nym6bQMB6DQnQeX+Yit/CHhLBimzQxRxgSNrcG HIGPSd1fkM+EHJxLHLbQJHR8lF8USpYhesIe3jA5Fps8KVZb/U2+SH0xNomKk2vPzoTU+eI1 4jTE9yQdnGawIweYDfuT1majjUp8RIA5noSHbgvYSm3Vtjpbi63LtsGG7wMCCGTJmtRoBX/f 4grDdj4f9v1YDICaTyybfyTsq9BgqH3VDBCTcIgN3H1i50OzCknwkZlntwPK2K8eUSVuM3IN 0qaKFtft+BIQNifUzyWoIExYwcto1AfWwPFFVmjHwVXN6e28Qtn/xZqrV+HDFbGvtALYLkW8 36wJm6RJwiJOrudzfALVHZZKw9XhlvDO8JGwyhqri3iRmxBSZBA2ivKJ2EVYpBkgTVIkzJQi sRmKBJnRNmiRuQiGA+Qg+TQFtNAio7Ea8XYxmi5YR8+l0RBiHxlNF6PpYjQd5iWceowm7BQA aRNmN6o0GlZ3N+qegKfUc9KjMGItsVEBICZKL/MgfCq4EvtV8KoYFO2Ww0GARRSP2LgesXFF 7WLBrMLk8oQC+aX51fkyDwojJIjYAwwlGGVaw2gsQWFBk16IO/ATzHb5s+V4niOeXWQzbB5b np6te4l9rU2O2NB7CKoS4wruvYSExM0Xbfm2wUsKI1EjxDUhAkYkwAVRECCjgxw5iAO1/bex jdkHN6yc/tW8g5tm3/jkB8tDP17+1D7pqaGrpp07Jf154bJE1bkPlYpN92+/PP5SamjqiLx9 G3yBIwUz6LPkrSvgkvgGH2eNHkFL4OeYEBIALHlr4ZE4wyPk7UV49JBg8eQTl1wQAIKW4ukR EXDGdBOjey6RuiM0Oy9jPxUbyRK+xDEjwnaU6lYDEeG8/BVeNspeJe70QM7aNKeIYkCBXozy SxFOVuHfkLJAbcjjkXO7vnzFtpKDd8685g3eId30w280TT93Qqno+256yRAOsi2vwAYM2lkW n2kWB0SgKoC9IDXsVzmvCXBPU0DEvbs0RYN1DY+JTHVaEYBzwjQDQIa5qLFMddRYpg2A4wJ/ 1Me8hRCoOZq2sJ1sF9vPjrCTTBs9XsGBtLDamZDNLEREYBDhuAvbnQkfjQkmZ8KCZ9nXybwz g8tdTo6IqRRzXuXsdMoLfEt91/lkp7C3nfEMaIzTZjbN2BeXM4TBQ3dg2g41YYWRCPhnqpOB 8ig8NXLS8EcWM/1dRACULnD8yCkUxBf5aDh7QkCC+chDq8IxlHYFt7/7QTp97vjvh9lRXvD1 nekTdz4s5X7OJ6d/mz6XHkq/wSdylr7h7Z/ybceIHlvSy5Vy0MPF8nijmV0gePpkAc9uqrN9 ZpPqbDttEqT7CUEAAFbIB4CFdwCWRgTwgcA79TERDtQabB4PVxp5YwDntSNxn5OI/Gh/R+TH eoeI/FQS0i6J/OQnMrszcVjZpUtSzM8X5HC/0Jgj/k88E7H/02JHEkCmBg4B4jp3yhpcd6uF ANNPLZl2XTytC2rqo9QZjRfBQPwL8pCYQtgO9v2IJEIJOyRaTMZHFoSN1+O3okYIBYcsw4TH Dh68/qET6WH2Se3D2d711Xzl7gNl6y9Lh9XXE9enT6Q/PpN+ZZJcPnR/3mR+/ys/qyENDFuP /Gkne8YstMFoIJ836C5zH3UrR5xvOSWnltGoNXZDe4yqVwCWegUwol51cQymC/UqmgmdAOjc RQCWMUc1ZjFJC911sULXmGoTktwmxR2GhuNfITHcgwPRKZfqWvILha5lUcvVGUVHQBqYNbtz 58GD3QOVHfLG6LNfG/q2UvHD571YI2IG0jmsMcxOmtGI4EWjKFgk6c6AUyqL1Ee2RmQ2w8Gr Crh81MM9ahOdyUsFtE6aLIDj5lKSqQUBFmiCb7fTscux33HSoTCHQj0cY07l8NI8TqfapS5e FuJSZ25vriTrObmyX673Jrzd3o3eo17V67pwhLGfH6EjDGza46bfg9ivHA/5gwT443SyT0iw 9u9LcJ1favPgVAN+sjjVEFsZIJwMMAidbKBgHfbj/A0HBJVTqqaWTpTPf19BHoR1MgCf44q5 j65IPv21ZXPDhx7uTU1bu662rXfr7ete/skPzL3dD1x35cxZC1sr73pgQXKpObmratb0f7zx /u+TBbOQMKkm4A2/LLxhc7aDGMYX9EllAY4AhnunwY0MzjS4w+IwOKPRiq5/Tp8diXA/s5H4 ZZalSWa+kJC0ZYSQJOergHDNhGfMsGHgb5QQH7EyEgCwU8+ZeYR1Vu6b6ZNcmZKqZ8a9CCLG da9dFwYr2ASMAue47YLDLLT+YHQm9hQ+V2mz2AjI8sFNxocn4azwhQ9PSqpe2bTpIC9Jv7us c35T/i333fGM/NCO4/PTb+0Y+mjLuuJdhc/dD3zcjnjrf8P30172hVnqF5y1wc9tCAHoBg8Y dYi97DKULXBGTxqygXMOEXM5K7gKURjLXCXA8mwMEQ9F+WMRWwHw6mhXwo54+IyZRVgwWOMp 7+deSffS1yIy846aBQDOCp0N4FMzQsLH6yAUIyYLJeQ1CLde7FSEZmGY4U6Gm4fw6fXJcWeG DdFsbcRu+kuVfZHKQNhm3SCJJMRhPOSs4tMdWP0auKukysMve+uaR3IOHgz9fHnyp0rF0FWf X18nnf7itQdmr3n5WQlfySA8Atz9G74/09jgyNmkU5G4HYf6Gj7+lWQ4bGf208QVxdDhPVdE Yb69N0D2nHf6hdNHz6UPjfS9tKvZXQ22pL8yBAEpJkjBPx0f9qgLLxyHq2VSjVQvJaSNkqrd zqTbOb50663h/Vwq5dUcJ/STsgJagxKyA3f9Cg8opUq10qVsUFSmrOV2DTOn2SGWtRaHKxWQ 2NMvxwdRg+4h7FMcCqwFtlpbVfpaiFdKGVPSVb/meTx8xK/MG/JKHwMnLnzH9XvgxMGfJH/I +pwFUvPUT4h1LDRRg6Um0XDM2iu6TZJVhdshhjVDUzWH3aZCjOrQbZ8LHEqSM1PgcIBwOILG 2bNJokCpREeOcveRESe47HPL6/xPxx0Z7m+NBis5z8THbPgahksJHLnVObnhTDg3Onc733aq TFuo2heOZ3yiysMOLju+wtSvKLouKzYb72VyLz5LCeAbNCWIDyHuyFDuwKdSGb0BoxS76Yjx Gc7Y90u838YNG0fI19A5PtzSpGxJshRKC7xDNaCX6tV6i75Bx4HQWsO2lutrBXYcAjuWSwC6 4EfSFN89tK1dC4INig/YiFSIb7upRDgTFKR+VnchgYmQDJ85RDgHOX2gqK9S6ZySPpw+MiX9 1Vd+zwum8JJP f+qX3hkqBXWvkJ6nJL79ww3/W/EFu0MAf3krRAXCH5AoY1gpK8f3fFVsGqtl MTYP36bVs/lsAf677Uq2EFGFRSzOFuM/3K5mLfiyp5UtFYNxPAs/FZdGXzLWNba2zGmILlnX ubJ3VXfn+sbF/xMFBwOBCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKOTMzMAplbmRvYmoK MTkgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAv TFFQWUlUK0FyaWFsTVQgL0ZvbnREZXNjcmlwdG9yCjcxIDAgUiAvRW5jb2RpbmcgL01hY1Jv bWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAxNjUgL0xhc3RDaGFyIDIwOCAvV2lkdGhzIFsKMzUw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDU1NiBdID4+CmVuZG9iago3MSAwIG9i ago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9MUVBZSVQrQXJpYWxNVCAv RmxhZ3MgMzIgL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAwMCAxMDA2XQovSXRhbGljQW5nbGUg MCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWlnaHQgNzE2IC9TdGVtViA5NSAv TGVhZGluZwozMyAvWEhlaWdodCA1MTkgL1N0ZW1IIDg0IC9BdmdXaWR0aCA0NDEgL01heFdp ZHRoIDIwMDAgL0ZvbnRGaWxlMiA3MiAwIFIgPj4KZW5kb2JqCjcyIDAgb2JqCjw8IC9MZW5n dGggNzMgMCBSIC9MZW5ndGgxIDY4NzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBrVl5eFRFtj9VdXvJRjoBsnbSt2nSSDoxEMAAYZLO0gEnIgkE7cYgHSCSIJhIgrvQjCLQ rPKUUVxwGRX1KTcdZDqgQxR1RpTlKeOuIDqjzjcI+n3quOW+X91uEBy/ef+8rvzOOXXOqe3U uXWr091LlrZSMoVIkHfe4pZOMj7ZbWCd867pVmP1lCwic9MVnQsWx+qDFxGZvliw6PorYvXs Y+BPt7W2zI/V6UfwC9qgiNXZWPDhbYu7r4vVs5vBkxd1zIvbs99G3bq45br4+PQ+6upVLYtb Y/45UVnv7Ojqjtc3gZ/XuaQ17s/8REl/Iqru6OhuGx/zGUTEIAn6iibRfWQhTjYqoUuIlDYl j0yoS7uJb9z81bpv5qRO+tqaazWaPvTxiEIp7FM6N32/46cFNrImo5pg+EsD2lkqBi6mGht9 v+P7G2yxkaTl9Ef0UZM4r9ed5Tj8rBhJxwAuRkY8eY4+MULkRcod3qhw9aYPLU2tKhYqeiwx qAraAewA9gIKzRH5sNpAlwMhYAewFzgMmLHAfMOqgncA24BjgFnkCXtEddiqRohstM3GelNF Jp0EdECQA7QEmAbMATYC2wCz4Sc1HcByYC9wCjCTV2RGNo/B3DMjaw3Wu3BRqVFtiVWbZxvV 3ksDMT61McZrL4y5TYy5jR4bU59fHeMjimI8vaA0hM57E1NK+6syRAYWmYGJd4Iy/iKlMkYO ekAMJQ3gAlM1NF6R3jvcXbptr1CICS4YzSeH3i9YJCWttCqR6/wkpZODf8FPxCz8RO+gtNJt Vb/lx2kHsBcQ/DjKR/wjWs6PyZiDVgLbgL3AIeAkYObHUI6ifMg/pFT+AZUAlcAcYBuwFzgJ WPgHoDb+vswYg0q5EuD8fVAbfw/Leg80lb8L6V3+rt7P34iUTSjtMwRPSVxwFMSFzNy4kJ5R GuWvR74biYxyY6eRUXvEMKqgMWJYpGC0IyqyIpPaHVH+ca/qcTxQNYofIQ3gmMkRjHyEVKAB CAKdgBnSm5DepBCwCXgA0ABkGagNUPl+4DXgTRoFeIEGwMoPRzBMlB+KuKsdVRn8IP8zZSLi B/hfDP4af9ngr/KXDP4KeD7s+/nLkXwHVSXBTmhjA7eBl8Bu4s/3Dk936FVpfC8i6AAtASqB acAcYCNg5nv5sMh8Rzo62UP78Qw7eIQ+N/ij9JCVvAsdXncNElCVxD3xN5BAtqnb3Nzr3nI3 qpK4N2yGJIn71nWQJHHfsAKSJO5F10CSxD1/ISRJ3LPmQJLEPa0JEkiU3//H4SMcZdOuZGpV Kr8WUboWUboWUbqWFH6tLPSdIud4T6SwEBHb6vWMLHSEdrPQsyw0nYUeYqFWFlrGQitYaBIL Xc5CHhays1A+C3lZaA8bj1CEmHfnOdUJ3iwW2s9CT7FQFwu5WaiAhYazkMrKvFHujFyIpw7M Z7DeKvnQcWfvbypw+qRyJyLqRM47cSbsBT0E6EbNCyd1WMw5O1/yYb2FlbH6+RNLO6qm8H1o uA/bsI+OAgo2aB/SaB862YfuUkErgTlAP3AS0AEzvIdhHRsNmgpaAlQCc4DlwEnAbEznJKbC qQNUTnGHMbES0EpgmqzxfSjDUJzc6c2z2W0e2xSx0c5S89m0fD2fl1FGBs7l9DRrWpSl7Po2 5V/fplBCVQLfwDdSHjZiU5xvjHyX54iyuyLuPY6qoez3lK8g69gEcrMC8PHUZdTHkd0q9WPJ zp8EL43YL0Gz1Ii7yLGbDZKtdjm+s3/i+Nwe5RA/s+9xvKVGFRZx/BWaJ3c5jtjXOF4piVqh edYdZWC7VcO1zz7e8dR+w3UFDFsjjmWS7XLcbJ/suNJuGFpjhsu7UPOmOqa7ZzmmoL9a+1yH twt97nJU2i93TIp5jZNtdjlGYQqemFiIyY60G4O68o0OZ5ZFWZu3yLLF4rdMs1xgKbUUWZwW hyXPkmsZYk232qyDrMnWRKvVarYqVm4l65CofszrkW+9IWbj5WdGQjNSDNmGE4bJYwaUOLNy +i1pg0U9r59Rzeq1/nlUP1fVvpnhirLExlmayVXNtPR6qm+q1sZ76qMWfbpW5qnXLA2X+XsY 2xCAVuOro4ya/FGmS9XKXC29xt9HjKWtXJ8r+Xkr1wcClJVxTWVWZXpF2oS62l8hQUMZrPX8 /Mn6WfRkefK0LfUz/NoTeQGtVAp6XqBe+68ZarO/j33FTvlq+9iXkgX8faKCfeWbLvWiojYQ qI+ySww/UtmX8EPGgMHPmk+q9CPVmh/z2xrzK0B7+A2XDH4JCVRg+BUkJBh+CpN+PV3DfbU9 w0Hgk6lSl+HTlame7bO/AD4FIPDJCNF+w2d/Rkj6aBVGN3Y7XPJB4MJyyG642FmO4WLMvMdw KYm7rDnjssYYScRmY/hIgm5Sjp32STkGn7MC+Z/F1mqPh/WWB+Y1+1pdvqDL1woEtbXXtGVp obmq2jMvIA2qJtzBufPaJG9p1QKu1lptnqtW7Sk32v3C3CzN5a7aHmr2Nfl7mr2ttZFyb7nP 1VIb6J3cMLbsnLHWnBlrbMOvjNUgOxsrx5pstPvFWGXSPFmOVSbHKpNjTfZONsYiI8cb/D1W qg7UYP8k7+VJicjXYK4zUJ1h66wwkrfcmbUsdzduK9spyRPQkl3VWgog87q4qrhKmvBMSdMg qFPjpqxl5c7c3Wx73GSDOs1VTZ7upV1LKcvXXhv768IHqu6lciti1CN1v/qBi0/zttTKu3W9 VjijXqtsnOXvsVigDdYGoJt4WpeU5Ivq/THl+VBOlI5CnHGUuklSl5AQd/z3XDDmBDWi04eL xp5e5s1n3dQVEFp+fRPHUdA0C2FonuXfjbuUfEl0BbDALuZhXad7k+swZIppCMvuOo3upXEp HovuODdcuzzk6TodktPdeWSwDGLEqtuDo820m7KBHNNjlK24KYtI/xT4TPKBdv0zaZec/wMH nfx2IkG0nZ5i7fQU7aUX2Cm02kF9tJPkFaiW7qWb6A5ahdfaLGjW0HQUE/R3sGx9J76ZPIgX 5oN0AL6X0jLaTRksS/+cltNK8QZaraQUGkZV1EAdtJ5dpC+lZjqq3EJldBFdRZ0spPv1Dfpm /Q/0CPWJv+g/URLl0DyUA/oXprf196kYLe6ku+ko25zwDHkxSgie99ES2ipmK0xfoH+PGTjp WsxBoal0gPVzD3pvpU9ZFrtJ1KCXh3VNfxFedppNbbSVdrNxbDJ3mpr1qfoBysAY16HXuylC u1Ci9By9y5JNp/Q/6Kcom4roQqxnJx1k/WLgpxUDlYiYCVEaSRNg6aA/0Z/pMHOx53mHKdlU avKabtCP0BAaTTMx28fQ8u/sW74MZbl4WanTq2kQ4nK7jDa9RB+xHFbCprFL+Ejewe8XS8iK EUejzKd2xPsu9P4h0mgXT+aHxMPKk8oP5ryBY/og7Iib7qH76HmWgpWqrIv9jr3JPuY1fA6/ hx8XdyiPK69bWrDqy2kxracn6VuWzsazRnYZa2M3sVXsdnY3O8AOs894FW/iV/KTok1cLZ5T qlFmKF3KLabbTGvNnw34B14c+J+Bb/VS/TZqRD6swOzvpPuxsj46RO+gHKXjzMSS2CAUlTnZ THYjyjK2nj3EtrPH2U6McpgdZ5/jlfQ1+4HjTcvNPBeXH3kFcvEluGHewe/lh1AO83/y70Sm GCY8YpyYJAKiA7NaJTahPCM+UnKUQ4qOOJeatpi2mbabnjS9YDplTrb8Du/41358+KfCnz4c oIHVA1sGIgM79Y9oKPYQbw98BZuE2begLMR+b0HG7aA3WDJil8MKWQW7CJGZwxayq9l1iOSt bCt7xJj70+xZROktdhJzTuF2Y87n83G8mk9DuZy38qtxGdvMd/I3+ffCIpJEqhgqCsVkMVu0 im5xvdgiNPGa+EAcF9+IH1F0JVFxKMMUt+JRJitzlKXK/cqnyqemZtOrpr+ZE82LzbeZo+Yv caupsDRYGi2zLRstuyxHrEFk5z56hv5oPLVxwo6JFcInnqENfIySja8wB5HPc2i+mMqRqXw7 W81vZjv5cNN15nJezi6mU4obsX6Zb+Pf8HIxldWzGbSQj451Zx6iPAFpkrKPTijPYm0H0fN1 5mS2jJ80J1MEd6QJuCO9JEYpHvEqvSuOMovyIL2nJLJMdoI/JhqQBc8pFSY/OcW99LS4mt1M z3AfUeIP1nXI44vZEzgXmlgp+5fQcQ2+GFlUJj6mW+hK/jadwHO8mn7P5isLaAONYTfRp/Qo noqRpqvMheah7BXeroT5YLaTuPI4VjeBDWfCNIRuZbPFVvNJ/g4tpUNKIn0o/huzP8SfFlOV U6bprA1PwM10G12tr6DrTX7ldbaABLuECpRjON1uEqWKE3w5TpVmnGm78HTvxjlQJaZCk4XM uQh5MRMnxFaUu3BOKMigdjzjl+IUO0g7zU08SgtMgxhOHfyn5tWB6TRLf5Tu1hfQVfpmKsZ5 sEq/CT1up7/RRtrOVg7cSJ34KvkOnu2LTHX8kKlOL+Zh/g6fwbecu7+IdgHLon+gPI2dqTDt obDyFs2gSn2d/ldk93k4Ye+mubiwfoJVfoERpoh+GjNwMe/R60Qn1nuUGvXHdAdLpDZ9EU2j Z+kRi4laLB7sscZex3pvpFY+Xe8WrQPtiMNGRMGLaC3F+bPGWzOzqcpbWfGbSeUTJ4wvGzd2 TOnoUSXnFxd5CkeeN8JdMNw1zKk68vPsuTnZWZkZQ4cMTk+zpQ5KSU5KTLBazCZFcEZFPldd UNXcQU1xu6ZMKZZ1VwsULWcpgpoKVd25Ppoq27XAdI6nF55X/MLTG/P0nvFkNnUSTSouUn0u VTtQ61KjbFajH/L6WldA1U4Y8lRD3mTIKZCdTjRQfVlttarGgqpPq7umLewL1hYXsZ6kxBpX TWticRH1JCZBTIKkZbo6e1hmBTMEnumb2MPJmoIlajmuWp+W7UJTdCMKfC3ztYZGv6821+kM FBdprGaea65G8qbkMVyoxhhGM9doFmMYtR13HI3Wqj1F/eF1URvNDXqS57vmtzT7NdGCPnxa mgfj1mqZN3yS9XMVneNOtupsa64I+7LaVekcDq9StQca/We1zXXKHgIB9IG2vKAuGK7D0Ouw U/XyLq7xlQG/xlZiSFwsC4xVxdYXu/UWBBeqWoKr2tUWXhjE1uSENZp+vTOSk+Pt049Rjk8N N/ldTq0y1xVoqbX3DKHw9Ot7s71q9rmW4qIeW1ossD2DUuNCcsrZQiuCHrMZkuEupfrpZyLL 5BxdF+ImqKnzVMzE78KaxkvSOp7C88ZjA/AJMLTS5mNH2rWEmmDYNlHqsUSmmQpsLjX8NSED XCf+ea6mJa4xF9i+JmmUeXIm1TTWclrWPB6tsFCmiKUGe4o5Vhj1ccVF10S5y9Vpw/dn+aWB GhDblsDEEoTf6ZQbvDbqpbmoaKFGf6yu0tzcCHlLcLfmQWnpP20ZOlNaQqctZ5oHXcjknfL7 LA3VrO4zf6m2jMG+tokay/gP5taYvX6Gqx5XY9UXDsaztr7pnFrMLgOKuMEWl7TBNX6Ry6GT Es8VhjV2Qz7tguuyP1lTCvBnNpJ6ftRiRVYaGqbWabbglBgNJDqd8Wfm/2oU1U/JVgb7uVl8 GdpET3yisWlr5efUz5lecljUN+HI4bjZh8OJ59iQarFZXhhnyHh80XeqNRrNxJNZgD985Rgv EcjVvAgZLE14igx1IDdePccxN94ogI/MzuKiOpyZ4XCdS60LB8MtUT0016XaXOE+/gJ/Idzp w2kXS5yovnttrla3LoCItbGJeDw4Vfe42OrGHi9bPWOWvw//4lBXN/kjnPGaYHVAbguvafLH w2JsiEx97CF+MUHG8AO0WOnS5e8hzEgg/O4Bw1zUH8HtVKbU//+HG10OpXK8VfHKkJdsk/wl xELkTHOmFYDgvzX0oyr6f/Sa6AdSlX45v8XsMG/DXSSJHH14qc/wDkowv6bSKNwxlyZf+liW x/bN7BNUcmL0qMFjLxhTijeU2TXMvfjOtvY772xvu5MfbL/jjnbI6Ev/ke1XOvhlGDXfm8rG Ec8xqRgiW+m9Ictzse2T2ba/U8lUdCXGOYcqShfbf/vtctqxuZM+AvfKX/sIKFfh3iDnmx6P nxnfA+iixobAhU2eqiXtLYumNv0v5yH8cAplbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjQ2 MTQKZW5kb2JqCjIxIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv QmFzZUZvbnQgL01DVlNDQytIZWx2ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjc0IDAgUiAvVG9V bmljb2RlIDc1IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvV2lkdGhzIFsgMTM5 IF0gPj4KZW5kb2JqCjc1IDAgb2JqCjw8IC9MZW5ndGggNzYgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AV2QwW7DIBBE73zFHpNDhO0zQqpSRfKhbVQnH4BhsZBqQGt8 8N8XiJNKPeyBmXkwLD/37713CfiVgh4wgXXeEC5hJY0w4uQ8azswTqf9VDU9q8h4hodtSTj3 3gYQggHw74wsiTY4vJkw4rFoX2SQnJ/gcD8PVRnWGH9wRp+gYVKCQZuv+1DxU80IvKKn3mTf pe2Uqb/EbYsIuVEm2kclHQwuUWkk5SdkommkuFwkQ2/+WTsw2j3ZtVLUaTpb80+noOWLr0p6 Jcpt6h5q0VLAeXytKoZYHqzzC37acEoKZW5kc3RyZWFtCmVuZG9iago3NiAwIG9iagoyMjIK ZW5kb2JqCjc0IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL01D VlNDQytIZWx2ZXRpY2EgL0ZsYWdzIDQgL0ZvbnRCQm94IFstOTUxIC00ODEgMTQ0NSAxMTIy XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDc3MCAvRGVzY2VudCAtMjMwIC9DYXBIZWlnaHQg NzE3IC9TdGVtViA5OCAvWEhlaWdodAo1MjMgL1N0ZW1IIDg1IC9BdmdXaWR0aCAtNDQxIC9N YXhXaWR0aCAxNTAwIC9Gb250RmlsZTIgNzcgMCBSID4+CmVuZG9iago3NyAwIG9iago8PCAv TGVuZ3RoIDc4IDAgUiAvTGVuZ3RoMSA1MDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ab1Ye3AURR7+9Tx2NyScSQDZJCwze8PmHUOicoFwZEl2Q0IAAwFuF0F2k2xMIpEU hhxgwW0pqCzIqQgqWCr38AQOGTYUN4GTi5SWWr5QS089q5TzdXUl5T3kSkUz9/VsshJKqfxB OV09v2d3f/11b8/M9qxZG6GxFCWRGpeFu9vIusY9DFHc0hXuTtiZf4bMbuntURO2nE8krmrr vrErYTvuJxrjunHV+qH2mR/A394eCbcm4vQN5DTuSNjsGsgp7V096xJ25lFIx6rVLUPxzLdh 27rC64bGp/dgqzeHuyKJ/HG83ZTu1bf0DNl1kFO710SG8lkA+F4lBq9A91EK3UR2aOkoK4js /xjjIglRHse17vbSl1ZeMfMcZTgse+X8X1vyxQe+ePTLyDd5qfc6voIjZTifS1vBYAFRGkP8 bOq9yYjVDjfBoKYig+pRq1CvRS0qmu2kKHuc7kF9DFWkDraN1qNuRX0IVUpq+2H1s21xyeE9 ztZTNpvrTZWUxeOzFOeYVOV1g9mOPqK84/zwBMvC6p1hWfGxlDJ7DHuMPUqtpLDfk4dtoDrK Z3v6ClYpIYT2UzdqFFW07oztj08uV06yYvJIDG1yabLEjimflpUoH5cZAosrp/IMCeLpybC8 VygDrkeUv7huVE6iHkyEDhQg45iy37VK2TnZYHviyn0ug6HNvQmx1oWmx5Sugt1Ka5kVn7fb EA7GlemIL/WmKtMq3Mq1ro+U0jzDwWCXuOYphWUvK1PQEGkqOvV4M5RJrp3KDIQmu/x5M1BP sANsLxWyvXHPXOU4VEy3r76gYrfBbu2ryy/zGGyDd1pd/u6CujxPwTzFU1Cblwd96fP2zfbr 7bPt5fYie7491+6259jHOzId6Y6fONIcYxwOh91gf4xXKbYT7CBVgZaDfQ6bQzbYk3BKJ9gh y3noTw7JITjIMd4wP8DmZTTeYAePpnMNyjGbpdkMdqgv4TrkVSSuSVYgXeA6briTwBwCzSWd 3W3YaMuVvVXOqsxZGdNrfT90C1mR4XvRD19O5tJ3NzQF9AOuoF7OFdMVHE53Dis/KHvWIhSp LipqWLS+r7e7s80f0fwhzR9BDenbetuderRZVY90dvOAqou5oeaWdi7DEb1bi/j0Ts2nHum1 2l0UbuPhXs13hNr8iwNH2rwRX7zX2+vXwr5gX3P1mhUjxtqaHGtN9feMVc07W8PHarbaXTTW Ch5u5mOt4GOt4GM1e5utsfjk/R1N1bf0YHeq/o4GVc9v0usXLgvoajjoM9jjcPrWkjxA6fJT lC9HKVsqJYXIfAf1XS4Hl5ifyM9R+mCX+W+xEovaz6swWDWTBuhu2kuHyUZPQM+nG+hBeoF1 4re9nI7SW2wyXYWzVyKD5tFLzDRfozb6HfJ76BTtoiOUhjZdNAHRHcxjboDthd5Mm83f0BSq oDvoKZqOXnfQWXO/2YfoIlpCB+gg2r/INOGINM580vyIHLQQfW5G5DVznnmYMqmYqqkR3s10 knnEd812clIl0D1Mj9I+epo+Y7exo2a72WueNs9gqzppEjWhbGRH2RnxsHSH+bD5T3MQTORT IUYN0U76Lfo/jDKAo9XPbmI9bCfbJXiF24Sj0hZ54uC34KGA5qDU0Wq6Cwz00zP0H/qKfS44 xXSxR3zWvNb8L6VSA2bJZxKhXpQ7UXZgTieYjU1lNayRbWT3s13sDaFQWCIEhF8K64RPxAXi cnG9+IZ0ixSXt8sP2lIHz5knzOfMN2kiueh6WkObMLtTdJq+oK+ZiL4mMQ+rZNXsBpQo2yv0 s32sX2hkA+y0cIC9zz5kn7PzgiykCROEIqFH2CkcFE4Jr4gd4i7xIfF98Zw0SxbkffLHNo/9 b4PNg1sHXzErzTPmlzhiHeTGylTTAlpJYcy2m66hX2EWh1AOY9WeoWfpBat8yCbRWfoSLBDL ZNmsnM1HWcCuY22sgz3CjqOctLD8T8BCCClChjBRmCQ0Cc1ClxAV3hSiYo5YKM4Vl4mHUZ4X 3xLPi+clWRonTZDmSPW0XeqS9qA8Lj0hxaVX5enyLHmBvFSOylvl7WKL/Jr8lm2TbYctbvvc 9i8ci/Psq+3bsTovYM8+jb383SWxKUBfTjdTC/OxZtqN1djHwhTD7mpld4Gvbso3V4ibxDnC VOyGk3Qrduse2khbxeW0z3xbPEB/xU5ZhS6j9AepmlzyA1id22gqdtFQ8RYUFuTn5XqmaD91 qzjyJ+VkZzknXjlh/LjMjPSxaaljUhx2myyJAqNiv1YbUvXckC7lanV1JdzWwnCEL3CE8FNW 9dqRObrK24URGpHpRWbbRZneRKY3mcnS1Zk0s6RY9Wuq/rJPUw22bGEA+t0+LajqZy19vqXf Y+ljobvdaKD6ne0+VWch1a/X9rbH/CFfSTHr94KOMSXF/ODwUirvWKea8EYcsFTDM/x6tubz 61kadMREjz/cqjcuDPh9OW53ED64FgUwRklxhw6ctC2tVWvdZnipOcS18PKALoaDuhDifWUU 6RM1nz5xw8fO78xhzb/9gqAueGrDkVit7g1tA7ncDHErvB1WQ5OKboUtwYDOtgyB4Bg7gZTD TTwTPKFOVU/RqrX2WGcI5NKiQDzbm20dvjo1BuJZ3izLKCnud26qdGP2/SWzS2ZzWel2bkrI T29P+F8f4NK56ZkPIBsWJQlgnAGtHjh1tcUaRAPYCn6LVFCspQI84QoyTLMDeGp0AXtG9Oiy pz6sR5uGYbT7EuBCnb54Sla29RCqDiI/FEufgZVCfrqmxs7haR3Szn420hMe8tg86eeIB/lC J/eKzsLDei9/WHow63an1s7Xt9daU9ia03+BAzanhmPWx+MB3hhw62oQDrxNFjcYlNIYOMLY jqDBzC0G+Vz9eEcVV96AcDHfah0+jA+jpBiOQje0q4rVWoxcy/eKGlNj9a0xtVZtx2aSPJZE IBILloLBpgB4osUY0RvMSaqRYHAG+inl/aAJ0mNB9NA51AOk5Sr9FklTi/EwFXMbAwsDetSX o3t9QawCtu9AY0AfwM4NBpFVlkQKxBs7nEOYy4G5rBDxqxO94N0lii6CsRjvsymgufWBWCwn xn9vCdtgdLHDO+QwiKdwyg0WbURbCM2dY62BW3MDVpBzeg229PCOwjv7pRmelsSNlj8D2mkW wxWXieHpo2F4xqgYrkwiHcHwTGCu5Az//MdjeNYIhqsuzbA3iRsgZwOt12K4+jIxXDMahn2j YtifRDqC4Vpg9nOG5/x4DNeNYLj+0gzPTeIGyAagnWsxPO8yMTx/NAwvGBXD1yWRjmC4EZiv 4wwv/PEYXjSC4aZLM7w4iRsglwDtYovhpZeJ4V+MhuHAqBgOJpGOYHgZMAc5w9cnGfbm6HTh ORy96Nily34wL7+AcrwpyZlUzVxQ+OczPqBxpeHLIg3SnfQQ3rf5v0wC3sFJOo1vNxH/AVUl /pdxlOLhiepIN4hOo3IbuvieQRIqQbe/R8fRgmhp0XH0IkNOLbs6w52Rh1ot7TC++bv81Nc1 hjT/PL7xkWFdZgTfLN93Ic4E+9qbO8qnltdaCQxfYQn0NvwvRfNrljbV1BTVRVb1Rno6WsLI SUR5MuI0yRy6uCOpM7WU2/8H3Vdk+wplbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjI3MTcK ZW5kb2JqCjc5IDAgb2JqCihJQ0FOTi1JUkQucHB0eCkKZW5kb2JqCjgwIDAgb2JqCihNYWMg T1MgWCAxMC44LjIgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9iago4MSAwIG9iagooU3RldmUg U2hlbmcpCmVuZG9iago4MiAwIG9iagooKQplbmRvYmoKODMgMCBvYmoKKFBvd2VyUG9pbnQp CmVuZG9iago4NCAwIG9iagooRDoyMDEzMDMxMTIwMDEyMlowMCcwMCcpCmVuZG9iago4NSAw IG9iagooKQplbmRvYmoKODYgMCBvYmoKWyAoKSBdCmVuZG9iagoxIDAgb2JqCjw8IC9UaXRs ZSA3OSAwIFIgL0F1dGhvciA4MSAwIFIgL1N1YmplY3QgODIgMCBSIC9Qcm9kdWNlciA4MCAw IFIgL0NyZWF0b3IKODMgMCBSIC9DcmVhdGlvbkRhdGUgODQgMCBSIC9Nb2REYXRlIDg0IDAg UiAvS2V5d29yZHMgODUgMCBSIC9BQVBMOktleXdvcmRzCjg2IDAgUiA+PgplbmRvYmoKeHJl ZgowIDg3CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA2ODAyNCAwMDAwMCBuIAowMDAwMDAw NTcxIDAwMDAwIG4gCjAwMDAwMTUzMjIgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBuIAow MDAwMDAwNTUyIDAwMDAwIG4gCjAwMDAwMDA2NzUgMDAwMDAgbiAKMDAwMDAwNDcyOSAwMDAw MCBuIAowMDAwMDAzNTIyIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAyNzA4 MSAwMDAwMCBuIAowMDAwMDAwNzg2IDAwMDAwIG4gCjAwMDAwMDM1MDEgMDAwMDAgbiAKMDAw MDAwMzU1OCAwMDAwMCBuIAowMDAwMDA0NzA4IDAwMDAwIG4gCjAwMDAwMDU2NTIgMDAwMDAg biAKMDAwMDAwNDc2NSAwMDAwMCBuIAowMDAwMDA1NjMyIDAwMDAwIG4gCjAwMDAwMDU3NTkg MDAwMDAgbiAKMDAwMDA1ODk2OCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAw NjQyMTYgMDAwMDAgbiAKMDAwMDAwNjMwNyAwMDAwMCBuIAowMDAwMDA1ODk5IDAwMDAwIG4g CjAwMDAwMDYyODcgMDAwMDAgbiAKMDAwMDAwNjQxNCAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAwMTU2NjMgMDAwMDAgbiAKMDAwMDAwNzYzMCAwMDAwMCBuIAowMDAwMDA2 NTI2IDAwMDAwIG4gCjAwMDAwMDc2MDkgMDAwMDAgbiAKMDAwMDAwNzczNyAwMDAwMCBuIAow MDAwMDQ4ODc5IDAwMDAwIG4gCjAwMDAwMTAwODAgMDAwMDAgbiAKMDAwMDAwNzg5MSAwMDAw MCBuIAowMDAwMDEwMDU5IDAwMDAwIG4gCjAwMDAwMTAxODcgMDAwMDAgbiAKMDAwMDAxMDM2 OCAwMDAwMCBuIAowMDAwMDEwNDIxIDAwMDAwIG4gCjAwMDAwMTE2OTcgMDAwMDAgbiAKMDAw MDAxMDQ3NSAwMDAwMCBuIAowMDAwMDExNjc2IDAwMDAwIG4gCjAwMDAwMTE4MDQgMDAwMDAg biAKMDAwMDAxMzE2MiAwMDAwMCBuIAowMDAwMDExOTU4IDAwMDAwIG4gCjAwMDAwMTMxNDEg MDAwMDAgbiAKMDAwMDAxMzI2OSAwMDAwMCBuIAowMDAwMDEzNzE4IDAwMDAwIG4gCjAwMDAw MTM0MjMgMDAwMDAgbiAKMDAwMDAxMzY5OCAwMDAwMCBuIAowMDAwMDEzODI1IDAwMDAwIG4g CjAwMDAwMTUwNzQgMDAwMDAgbiAKMDAwMDAxNTQ0NSAwMDAwMCBuIAowMDAwMDEzOTM3IDAw MDAwIG4gCjAwMDAwMTUwNTMgMDAwMDAgbiAKMDAwMDAxNTE4MiAwMDAwMCBuIAowMDAwMDE1 NTIxIDAwMDAwIG4gCjAwMDAwMTU2MTIgMDAwMDAgbiAKMDAwMDAxNjQ2MSAwMDAwMCBuIAow MDAwMDE1OTQzIDAwMDAwIG4gCjAwMDAwMTY0NDEgMDAwMDAgbiAKMDAwMDAxNjcwMSAwMDAw MCBuIAowMDAwMDI3MDU5IDAwMDAwIG4gCjAwMDAwMjgzMDMgMDAwMDAgbiAKMDAwMDAyNzUz NyAwMDAwMCBuIAowMDAwMDI4MjgzIDAwMDAwIG4gCjAwMDAwMjg1MzggMDAwMDAgbiAKMDAw MDA0ODg1NyAwMDAwMCBuIAowMDAwMDQ5Mjg3IDAwMDAwIG4gCjAwMDAwNDk1MjYgMDAwMDAg biAKMDAwMDA1ODk0NyAwMDAwMCBuIAowMDAwMDU5MjMxIDAwMDAwIG4gCjAwMDAwNTk0OTEg MDAwMDAgbiAKMDAwMDA2NDE5NSAwMDAwMCBuIAowMDAwMDY0Njk5IDAwMDAwIG4gCjAwMDAw NjQzODEgMDAwMDAgbiAKMDAwMDA2NDY3OSAwMDAwMCBuIAowMDAwMDY0OTQ5IDAwMDAwIG4g CjAwMDAwNjc3NTYgMDAwMDAgbiAKMDAwMDA2Nzc3NyAwMDAwMCBuIAowMDAwMDY3ODEwIDAw MDAwIG4gCjAwMDAwNjc4NjIgMDAwMDAgbiAKMDAwMDA2Nzg5MiAwMDAwMCBuIAowMDAwMDY3 OTExIDAwMDAwIG4gCjAwMDAwNjc5NDAgMDAwMDAgbiAKMDAwMDA2Nzk4MiAwMDAwMCBuIAow MDAwMDY4MDAxIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgODcgL1Jvb3QgNTcgMCBSIC9J bmZvIDEgMCBSIC9JRCBbIDxhYTJiZGM2NzNiYmM0YjU3ODBlNDFkYTBkMTcyZjkxNT4KPGFh MmJkYzY3M2JiYzRiNTc4MGU0MWRhMGQxNzJmOTE1PiBdID4+CnN0YXJ0eHJlZgo2ODE5OQol JUVPRgo= --B_3445862652_3991529-- --B_3445862652_4002163 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFKf3Qi8f4vtbIjDVDt0zukutB0i3MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMTIwMDQxMlowDQYJ KoZIhvcNAQEBBQAEggEABUUM0CHj0HKMEP9TKiqfZHzf5rQ4vDcrf5DNj/cRW9FoeSPC8T7J Po+LnGlxw+LSedI9Oflw2fhxOJK6ZaBZTaNYA9t5EuqhcSg5JoWgN+7M03t0DuqDAV1sr45X NXZore9Pqa2VFSuXZ5rL4mejRKGnAb21HTJDaf1+qON5JYkwGL4EbB6qu284XhSbtDo584tg aPWGXpsMMAHMjUHPvlqx8JojFut4SpVZ+rEOddY4WOBPgErmgCaV970hRjy1U5x7GAslyYw+ cxTXsBWxj9mNb4m6BDnnAgUKIJdEnq9jfQ5mLXvuy2TDq8G7BTZwxuIR6QBJh5LPet1Z2Ewi Lg== --B_3445862652_4002163-- From nkong@cnnic.cn Mon Mar 11 16:05:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A581711E80CC for ; Mon, 11 Mar 2013 16:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkNeB27TDmd for ; Mon, 11 Mar 2013 16:05:10 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id C4BB921F8C69 for ; Mon, 11 Mar 2013 16:05:08 -0700 (PDT) Received: from unknown127.0.0.1 (HELO dhcp-1218.meeting.ietf.org) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Mar 2013 07:05:01 +0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B202B9A-BB16-46E5-9147-482C7F71BBE8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: Date: Mon, 11 Mar 2013 19:04:57 -0400 Message-Id: <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> References: <5130F3B1.4080909@gmail.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1499) Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:05:12 -0000 --Apple-Mail=_5B202B9A-BB16-46E5-9147-482C7F71BBE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks, We just set up an online demo at http://rdap.restfulwhois.org. Our server support: 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) 2) 3 types of response (JSON, XML and our self-defined = presentation format) 3=EF=BC=89 Client authentication by RFC 2617 (only one = authenticated user: admin/admin) Our server don't support: 1) Authorization (no different between admin with anonymous = user) 2) Logout The following examples can be used as inputs for test. 1) IP: 1.0.0.0 =20 1.0.0.0/8 39.1.2.3=20 39.1.2.3/8 2) Domain: baidu.cn qq.cn faha.cn=20 3) Entity APNIC bu1048055833141 s1265874462073 4) AS 1223 2569 3661 3662=20 5) Nameserver ns2.ee28.cn ns1.google.com Any comments are appreciated! See you tomorrow morning. Cheers, Ning > Do we have a lot of people planning to do demos? Are the demos going = to be complicated? >=20 > I don't understand how an hour would not be enough, unless there's a = large number of implementations I haven't heard of yet. >=20 > Who's got something to show (or will by then), and how long do you = need? >=20 > -MSK >=20 >=20 > On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez = wrote: > Unless we write a detailed plan of what we are going to do, I don't > think it will be enough. >=20 > In any case, I think we can continue in the term room. Or in the = hallways :D >=20 > regards >=20 > Carlos >=20 > On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in = room > > Boca 1 for implementation demos. We only have that one hour before > > other sessions begin, so please come prepared! > > > > -MSK > > > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_5B202B9A-BB16-46E5-9147-482C7F71BBE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = folks,

We just set up an online demo at http://rdap.restfulwhois.org.

Our server support:
1)   = 5 types of query (IP, Domain, Entity, AS and = Nameserver)
        2)   3 types of = response (JSON, XML and our self-defined presentation = format)
3=EF=BC=89 Client authentication = by RFC 2617 (only one authenticated user: = admin/admin)

Our server don't = support:
1)   Authorization (no = different between admin with anonymous user)
2)   = Logout

The following examples can be used as = inputs for test.
1)   IP:
1.0.0.0 =  
= 1.0.0.0/8
39.1.2.3 
= 39.1.2.3/8
2)   Domain:
3)   = Entity
= APNIC
bu1048055833141
= s1265874462073
4)   AS
= 1223
2569
= 3661
3662 
5)   = Nameserver

Any comments are appreciated! See you tomorrow = morning.

Cheers,
Ning

Do we have a lot of people planning to do demos?  = Are the demos going to be complicated?

I don't = understand how an hour would not be enough, unless there's a large = number of implementations I haven't heard of yet.

Who's got something to show (or will by then), and how = long do you need?

-MSK


On Fri, Mar 1, = 2013 at 10:30 AM, Carlos M. Martinez <carlosm3011@gmail.com> wrote:
Unless we write a = detailed plan of what we are going to do, I don't
think it will be enough.

In any case, I think we can continue in the term room. Or in the = hallways :D

regards

Carlos

On 3/1/13 4:21 PM, Murray S. Kucherawy wrote:
> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in = room
> Boca 1 for implementation demos.  We only have that one hour = before
> other sessions begin, so please come prepared!
>
> -MSK
>
>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>

_______________________________________________
weirds mailing = list
weirds@ietf.org
https://www.ietf.or= g/mailman/listinfo/weirds
= --Apple-Mail=_5B202B9A-BB16-46E5-9147-482C7F71BBE8-- From fobispo@isc.org Mon Mar 11 16:09:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FBC11E80FC for ; Mon, 11 Mar 2013 16:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD7XU3nElnSQ for ; Mon, 11 Mar 2013 16:09:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F0FBF11E80F7 for ; Mon, 11 Mar 2013 16:09:24 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6E6B8C958E; Mon, 11 Mar 2013 23:09:14 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363043364; bh=yIiCmgVYARqhiU4mgZQRY9/gcYihf8+y2bsCImkUHeA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GaKRBN6fLHnv7w4J1xrjuf6SS0jJ0jrhWJEQEzgjcRPiN8p88ViQrdJpEX9V2kuCv FjhDdbtO1O3SmVLAruhKy8LmXdD+QSYEfgzptxPAiN1q6sT0iaY9k5p2uSPoODjJV3 6KTUpJ8F0NGt6u6evzCCTe0oqnJrQeqrp1y/OcqA= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 11 Mar 2013 23:09:14 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:8c53:fb22:8fe2:f64b] (unknown [IPv6:2001:4f8:3:64:8c53:fb22:8fe2:f64b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5D8A3216C3B; Mon, 11 Mar 2013 23:09:14 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> Date: Mon, 11 Mar 2013 16:09:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> To: Ning Kong X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:09:26 -0000 Hi Ning, The XML output for qq.cn doesn't seem to be a valid XML doc: 20030321s10001s00193214-cn qq.cn clientTransferProhibited, whois.cnnic.cn 2003-03-21 22:42:05 ABC cnniccn115 2013-03-21 22:42:05 qq1048056475479 =E4=B8=AD=E5=9B=BD=E8=81=94=E5=90=88=E7=BD=91=E7=BB=9C=E9=80=9A= =E4=BF=A1=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=E9=BB=91=E9=BE=99=E6=B1=9F=E7= =9C=81=E5=88=86=E5=85=AC=E5=8F=B8, liaomh@vip.hl.cn, registrant, liaomh@vip.hl.cn, , http://restfulwhois.org/entity/qq1048056475479 self http://restfulwhois.org/entity/qq1048056475479 The JSON seems to be just fine. =20 On Mar 11, 2013, at 4:04 PM, Ning Kong wrote: > Hi folks, >=20 > We just set up an online demo at http://rdap.restfulwhois.org. >=20 > Our server support: > 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) > 2) 3 types of response (JSON, XML and our self-defined = presentation format) > 3=EF=BC=89 Client authentication by RFC 2617 (only one = authenticated user: admin/admin) >=20 > Our server don't support: > 1) Authorization (no different between admin with anonymous = user) > 2) Logout >=20 > The following examples can be used as inputs for test. > 1) IP: > 1.0.0.0 =20 > 1.0.0.0/8 > 39.1.2.3=20 > 39.1.2.3/8 > 2) Domain: > baidu.cn > qq.cn > faha.cn=20 > 3) Entity > APNIC > bu1048055833141 > s1265874462073 > 4) AS > 1223 > 2569 > 3661 > 3662=20 > 5) Nameserver > ns2.ee28.cn > ns1.google.com >=20 > Any comments are appreciated! See you tomorrow morning. >=20 > Cheers, > Ning >=20 >> Do we have a lot of people planning to do demos? Are the demos going = to be complicated? >>=20 >> I don't understand how an hour would not be enough, unless there's a = large number of implementations I haven't heard of yet. >>=20 >> Who's got something to show (or will by then), and how long do you = need? >>=20 >> -MSK >>=20 >>=20 >> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez = wrote: >> Unless we write a detailed plan of what we are going to do, I don't >> think it will be enough. >>=20 >> In any case, I think we can continue in the term room. Or in the = hallways :D >>=20 >> regards >>=20 >> Carlos >>=20 >> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: >> > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in = room >> > Boca 1 for implementation demos. We only have that one hour before >> > other sessions begin, so please come prepared! >> > >> > -MSK >> > >> > >> > _______________________________________________ >> > weirds mailing list >> > weirds@ietf.org >> > https://www.ietf.org/mailman/listinfo/weirds >> > >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From bje@apnic.net Mon Mar 11 16:13:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290C711E8126 for ; Mon, 11 Mar 2013 16:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzAiqCRU4bt9 for ; Mon, 11 Mar 2013 16:13:46 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 4A96711E810D for ; Mon, 11 Mar 2013 16:13:45 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Tue, 12 Mar 2013 09:12:24 +1000 (EST) Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67%18]) with mapi id 14.01.0218.012; Tue, 12 Mar 2013 09:13:28 +1000 From: Byron Ellacott To: "weirds@ietf.org" Thread-Topic: [weirds] WEIRDS implementation demo Thread-Index: AQHOFqmgIFUbuPReoECjeC7clURQO5iQgKSAgAAWxYCAD+1TgIAAqgOA Date: Mon, 11 Mar 2013 23:13:29 +0000 Message-ID: In-Reply-To: <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.168] Content-Type: multipart/alternative; boundary="_000_CD64A1591D50Ebjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:13:47 -0000 --_000_CD64A1591D50Ebjeapnicnet_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable APNIC's pilot is online at http://rdap.apnic.net/ - the output does not con= form to current spec; I believe it conformed to the last revision pre-WG ad= option. You can see the general gist of the mechanisms, however. We are l= inked from rdap.org, too. Byron From: Ning Kong > Date: Tuesday, 12 March 2013 9:04 AM To: "Murray S.Kucherawy" > Cc: Carlos Martinez >, "weirds@= ietf.org" > Subject: Re: [weirds] WEIRDS implementation demo Hi folks, We just set up an online demo at http://rdap.restfulwhois.org. Our server support: 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) 2) 3 types of response (JSON, XML and our self-defined presentati= on format) 3=1B$B!K=1B(B Client authentication by RFC 2617 (only one authenticated use= r: admin/admin) Our server don't support: 1) Authorization (no different between admin with anonymous user) 2) Logout The following examples can be used as inputs for test. 1) IP: 1.0.0.0 1.0.0.0/8 39.1.2.3 39.1.2.3/8 2) Domain: baidu.cn qq.cn faha.cn 3) Entity APNIC bu1048055833141 s1265874462073 4) AS 1223 2569 3661 3662 5) Nameserver ns2.ee28.cn ns1.google.com Any comments are appreciated! See you tomorrow morning. Cheers, Ning Do we have a lot of people planning to do demos? Are the demos going to be= complicated? I don't understand how an hour would not be enough, unless there's a large = number of implementations I haven't heard of yet. Who's got something to show (or will by then), and how long do you need? -MSK On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > wrote: Unless we write a detailed plan of what we are going to do, I don't think it will be enough. In any case, I think we can continue in the term room. Or in the hallways := D regards Carlos On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room > Boca 1 for implementation demos. We only have that one hour before > other sessions begin, so please come prepared! > > -MSK > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds --_000_CD64A1591D50Ebjeapnicnet_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <833600245D65CA45A8F2635763DC6C70@apnic.net> Content-Transfer-Encoding: quoted-printable
APNIC's pilot is online at http://rd= ap.apnic.net/ - the output does not conform to current spec; I believe = it conformed to the last revision pre-WG adoption.  You can see the ge= neral gist of the mechanisms, however.  We are linked from rdap.org, too.

  Byron

From: Ning Kong <nkong@cnnic.cn>
Date: Tuesday, 12 March 2013 9:04 A= M
To: "Murray S.Kucherawy" = <superuser@gmail.com>
Cc: Carlos Martinez <carlos@lacnic.net>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] WEIRDS implem= entation demo

Hi folks,

We just set up an online demo at http://rdap.restfulwhois.org.

Our server support:
1) &nb= sp; 5 types of query (IP, Domain, Entity, AS and Nameserver)
        2)   3 types of response (JSON, XML a= nd our self-defined presentation format)
3=1B$B= !K=1B(B Client authentication by RFC 2617 (only one authenticated user: adm= in/admin)

Our server don't support:
1) &nb= sp; Authorization (no different between admin with anonymous user)
2) &nb= sp; Logout

The following examples can be used as inputs for test.
1)   IP:
1.0.0.= 0  
1.0.0.= 0/8
39.1.2= .3 
39.1.2= .3/8
2)   Domain:
3)   Entity
APNIC<= /div>
bu1048= 055833141
s12658= 74462073
4)   AS
1223
2569
3661
3662&n= bsp;
5)   Nameserver

Any comments are appreciated! See you tomorrow morning.

Cheers,
Ning

Do we have a lot of people planning to do demos?  Are the demos g= oing to be complicated?

I don't understand how an hour would not be enough, unless there's a l= arge number of implementations I haven't heard of yet.

Who's got something to show (or will by then), and how long do you nee= d?

-MSK


On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Marti= nez <carlosm3011@= gmail.com> wrote:
Unless we write a detailed plan of what we are going to do, I don't
think it will be enough.

In any case, I think we can continue in the term room. Or in the hallways := D

regards

Carlos

On 3/1/13 4:21 PM, Murray S. Kucherawy wrote:
> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in room<= br> > Boca 1 for implementation demos.  We only have that one hour befo= re
> other sessions begin, so please come prepared!
>
> -MSK
>
>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>

_______________________________________________
weirds mailing list
weirds@ietf.org
https://www.ietf.o= rg/mailman/listinfo/weirds
--_000_CD64A1591D50Ebjeapnicnet_-- From jean-philippe.dionne@viagenie.ca Mon Mar 11 16:46:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191711E813F for ; Mon, 11 Mar 2013 16:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkMw-ljtkP7c for ; Mon, 11 Mar 2013 16:46:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46F11E8159 for ; Mon, 11 Mar 2013 16:46:11 -0700 (PDT) Received: from dhcp-11cc.meeting.ietf.org (dhcp-11cc.meeting.ietf.org [130.129.17.204]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 93B7A40167; Mon, 11 Mar 2013 19:45:33 -0400 (EDT) Message-ID: <513E6C9C.1030607@viagenie.ca> Date: Mon, 11 Mar 2013 19:45:32 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ning Kong References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> In-Reply-To: <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:46:15 -0000 Hi, I can see the json embedded inside the html response, but I cannot get only json. Do I need to specify an "Accept:" header to get it? Thank you Jean-Philippe On 2013-03-11 19:04, Ning Kong wrote: > Hi folks, > > We just set up an online demo at http://rdap.restfulwhois.org. > > Our server support: > 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) > 2) 3 types of response (JSON, XML and our self-defined > presentation format) > 3） Client authentication by RFC 2617 (only one authenticated user: > admin/admin) > > Our server don't support: > 1) Authorization (no different between admin with anonymous user) > 2) Logout > > The following examples can be used as inputs for test. > 1) IP: > 1.0.0.0 > 1.0.0.0/8 > 39.1.2.3 > 39.1.2.3/8 > 2) Domain: > baidu.cn > qq.cn > faha.cn > 3) Entity > APNIC > bu1048055833141 > s1265874462073 > 4) AS > 1223 > 2569 > 3661 > 3662 > 5) Nameserver > ns2.ee28.cn > ns1.google.com > > Any comments are appreciated! See you tomorrow morning. > > Cheers, > Ning > >> Do we have a lot of people planning to do demos? Are the demos going >> to be complicated? >> >> I don't understand how an hour would not be enough, unless there's a >> large number of implementations I haven't heard of yet. >> >> Who's got something to show (or will by then), and how long do you need? >> >> -MSK >> >> >> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez >> > wrote: >> >> Unless we write a detailed plan of what we are going to do, I don't >> think it will be enough. >> >> In any case, I think we can continue in the term room. Or in the >> hallways :D >> >> regards >> >> Carlos >> >> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: >> > The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >> room >> > Boca 1 for implementation demos. We only have that one hour before >> > other sessions begin, so please come prepared! >> > >> > -MSK >> > >> > >> > _______________________________________________ >> > weirds mailing list >> > weirds@ietf.org >> > https://www.ietf.org/mailman/listinfo/weirds >> > >> >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nkong@cnnic.cn Mon Mar 11 20:35:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6E821F8790 for ; Mon, 11 Mar 2013 20:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcMihnYhNG0K for ; Mon, 11 Mar 2013 20:35:26 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 8238B21F85BF for ; Mon, 11 Mar 2013 20:35:25 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.255.4]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Mar 2013 11:35:14 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: Date: Mon, 11 Mar 2013 23:35:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <92760D3A-C647-4F43-86D6-D64E59617F7C@cnnic.cn> References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> To: Francisco Obispo X-Mailer: Apple Mail (2.1499) Cc: Carlos Martinez , weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:35:30 -0000 Hi Francisco, You're right. Thanks for your feedback. We'll fix it later. Cheers, Ning > Hi Ning, >=20 > The XML output for qq.cn doesn't seem to be a valid XML doc: >=20 > 20030321s10001s00193214-cn > qq.cn > clientTransferProhibited, > whois.cnnic.cn > 2003-03-21 22:42:05 > ABC > > > cnniccn115 > 2013-03-21 22:42:05 > > qq1048056475479 > = =E4=B8=AD=E5=9B=BD=E8=81=94=E5=90=88=E7=BD=91=E7=BB=9C=E9=80=9A= =E4=BF=A1=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=E9=BB=91=E9=BE=99=E6=B1=9F=E7= =9C=81=E5=88=86=E5=85=AC=E5=8F=B8, liaomh@vip.hl.cn, > registrant, > liaomh@vip.hl.cn, > , > http://restfulwhois.org/entity/qq1048056475479 > self > http://restfulwhois.org/entity/qq1048056475479 > > > > > >=20 > The JSON seems to be just fine. >=20 >=20 >=20 >=20 > On Mar 11, 2013, at 4:04 PM, Ning Kong wrote: >=20 >> Hi folks, >>=20 >> We just set up an online demo at http://rdap.restfulwhois.org. >>=20 >> Our server support: >> 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) >> 2) 3 types of response (JSON, XML and our self-defined = presentation format) >> 3=EF=BC=89 Client authentication by RFC 2617 (only one = authenticated user: admin/admin) >>=20 >> Our server don't support: >> 1) Authorization (no different between admin with anonymous = user) >> 2) Logout >>=20 >> The following examples can be used as inputs for test. >> 1) IP: >> 1.0.0.0 =20 >> 1.0.0.0/8 >> 39.1.2.3=20 >> 39.1.2.3/8 >> 2) Domain: >> baidu.cn >> qq.cn >> faha.cn=20 >> 3) Entity >> APNIC >> bu1048055833141 >> s1265874462073 >> 4) AS >> 1223 >> 2569 >> 3661 >> 3662=20 >> 5) Nameserver >> ns2.ee28.cn >> ns1.google.com >>=20 >> Any comments are appreciated! See you tomorrow morning. >>=20 >> Cheers, >> Ning >>=20 >>> Do we have a lot of people planning to do demos? Are the demos = going to be complicated? >>>=20 >>> I don't understand how an hour would not be enough, unless there's a = large number of implementations I haven't heard of yet. >>>=20 >>> Who's got something to show (or will by then), and how long do you = need? >>>=20 >>> -MSK >>>=20 >>>=20 >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez = wrote: >>> Unless we write a detailed plan of what we are going to do, I don't >>> think it will be enough. >>>=20 >>> In any case, I think we can continue in the term room. Or in the = hallways :D >>>=20 >>> regards >>>=20 >>> Carlos >>>=20 >>> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in = room >>>> Boca 1 for implementation demos. We only have that one hour before >>>> other sessions begin, so please come prepared! >>>>=20 >>>> -MSK >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >>>>=20 >>>=20 >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > Francisco Obispo=20 > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 From nkong@cnnic.cn Mon Mar 11 21:11:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670EF21F8319 for ; Mon, 11 Mar 2013 21:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCtnfmYBLruB for ; Mon, 11 Mar 2013 21:11:26 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 6059B21F8314 for ; Mon, 11 Mar 2013 21:11:25 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.255.4]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Mar 2013 12:11:16 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: <513E6C9C.1030607@viagenie.ca> Date: Tue, 12 Mar 2013 00:11:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> <513E6C9C.1030607@viagenie.ca> To: Jean-Philippe Dionne X-Mailer: Apple Mail (2.1499) Cc: Carlos Martinez , weirds@ietf.org Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:11:27 -0000 Hi Jean-Philippe, Thanks for your feedback. The current response is only JSON objects embedded in the HTML response. = The representation and xml presentation formats are just converted from = JSON objects.=20 Setting http header is not available now. We will modify this function = soon. Cheers, Ning > Hi, >=20 > I can see the json embedded inside the html response, but I cannot get > only json. Do I need to specify an "Accept:" header to get it? >=20 > Thank you > Jean-Philippe >=20 > On 2013-03-11 19:04, Ning Kong wrote: >> Hi folks, >>=20 >> We just set up an online demo at http://rdap.restfulwhois.org. >>=20 >> Our server support: >> 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) >> 2) 3 types of response (JSON, XML and our self-defined >> presentation format) >> 3=EF=BC=89 Client authentication by RFC 2617 (only one authenticated = user: >> admin/admin) >>=20 >> Our server don't support: >> 1) Authorization (no different between admin with anonymous user) >> 2) Logout >>=20 >> The following examples can be used as inputs for test. >> 1) IP: >> 1.0.0.0 =20 >> 1.0.0.0/8 >> 39.1.2.3=20 >> 39.1.2.3/8 >> 2) Domain: >> baidu.cn >> qq.cn >> faha.cn =20 >> 3) Entity >> APNIC >> bu1048055833141 >> s1265874462073 >> 4) AS >> 1223 >> 2569 >> 3661 >> 3662=20 >> 5) Nameserver >> ns2.ee28.cn >> ns1.google.com >>=20 >> Any comments are appreciated! See you tomorrow morning. >>=20 >> Cheers, >> Ning >>=20 >>> Do we have a lot of people planning to do demos? Are the demos = going >>> to be complicated? >>>=20 >>> I don't understand how an hour would not be enough, unless there's a >>> large number of implementations I haven't heard of yet. >>>=20 >>> Who's got something to show (or will by then), and how long do you = need? >>>=20 >>> -MSK >>>=20 >>>=20 >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez >>> > wrote: >>>=20 >>> Unless we write a detailed plan of what we are going to do, I = don't >>> think it will be enough. >>>=20 >>> In any case, I think we can continue in the term room. Or in the >>> hallways :D >>>=20 >>> regards >>>=20 >>> Carlos >>>=20 >>> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in >>> room >>>> Boca 1 for implementation demos. We only have that one hour before >>>> other sessions begin, so please come prepared! >>>>=20 >>>> -MSK >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> weirds mailing list >>> weirds@ietf.org >>> https://www.ietf.org/mailman/listinfo/weirds >>=20 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 >=20 From superuser@gmail.com Mon Mar 11 21:50:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85DA21F85D4 for ; Mon, 11 Mar 2013 21:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTKfO4wgrrLo for ; Mon, 11 Mar 2013 21:50:03 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6421F85DF for ; Mon, 11 Mar 2013 21:50:01 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id 12so5801621wgh.7 for ; Mon, 11 Mar 2013 21:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KWEV4WMPXPXudVFww1LxUS1aQDxd1/IgOnLaDOw+qlc=; b=mCpPvOA/HP0V4Oe+OPMAiqy18YusR6+72xwufEkCs+rs9U4ZdL3PCHCdRBT1l1xhax sD0/C0nn9tYRPLhF2opKsHC3gBvpn3BKzGVlMa39srP6JO8o98DVMYbolaG1OLkkWCz6 7yN/VxyE91o2DJ2yOjVQvLVqFfEy9vES+G0RQxA3iizYJaSOu+nKksxTQXQgxI8nEyXy 286rCxV7cUdnvvDUV6rBzzuHaqdkZR0bhKNVs/aTcUiBdAhILNVdBE9B7bW0zdiodS3c PFVKaxbIg4g/yJxq9cWAIFGS62OUWMYwl2Ry/1qRuFoAVTHZ2C/x4xPBlAZLPA+HM3g5 YF3g== MIME-Version: 1.0 X-Received: by 10.180.183.4 with SMTP id ei4mr16621300wic.21.1363063800662; Mon, 11 Mar 2013 21:50:00 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Mon, 11 Mar 2013 21:50:00 -0700 (PDT) In-Reply-To: References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> <513E6C9C.1030607@viagenie.ca> Date: Tue, 12 Mar 2013 00:50:00 -0400 Message-ID: From: "Murray S. Kucherawy" To: Ning Kong Content-Type: multipart/alternative; boundary=001a11c22a2ea50f5304d7b3052a Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:50:07 -0000 --001a11c22a2ea50f5304d7b3052a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I didn't follow up on appointing someone to provide a brief report about the demo session when the WG meets at 10:30am tomorrow. Does someone want to volunteer? -MSK On Tue, Mar 12, 2013 at 12:11 AM, Ning Kong wrote: > Hi Jean-Philippe, > > Thanks for your feedback. > > The current response is only JSON objects embedded in the HTML response. > The representation and xml presentation formats are just converted from > JSON objects. > > Setting http header is not available now. We will modify this function > soon. > > Cheers, > Ning > > > Hi, > > > > I can see the json embedded inside the html response, but I cannot get > > only json. Do I need to specify an "Accept:" header to get it? > > > > Thank you > > Jean-Philippe > > > > On 2013-03-11 19:04, Ning Kong wrote: > >> Hi folks, > >> > >> We just set up an online demo at http://rdap.restfulwhois.org. > >> > >> Our server support: > >> 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) > >> 2) 3 types of response (JSON, XML and our self-defined > >> presentation format) > >> 3=A3=A9 Client authentication by RFC 2617 (only one authenticated user= : > >> admin/admin) > >> > >> Our server don't support: > >> 1) Authorization (no different between admin with anonymous user) > >> 2) Logout > >> > >> The following examples can be used as inputs for test. > >> 1) IP: > >> 1.0.0.0 > >> 1.0.0.0/8 > >> 39.1.2.3 > >> 39.1.2.3/8 > >> 2) Domain: > >> baidu.cn > >> qq.cn > >> faha.cn > >> 3) Entity > >> APNIC > >> bu1048055833141 > >> s1265874462073 > >> 4) AS > >> 1223 > >> 2569 > >> 3661 > >> 3662 > >> 5) Nameserver > >> ns2.ee28.cn > >> ns1.google.com > >> > >> Any comments are appreciated! See you tomorrow morning. > >> > >> Cheers, > >> Ning > >> > >>> Do we have a lot of people planning to do demos? Are the demos going > >>> to be complicated? > >>> > >>> I don't understand how an hour would not be enough, unless there's a > >>> large number of implementations I haven't heard of yet. > >>> > >>> Who's got something to show (or will by then), and how long do you > need? > >>> > >>> -MSK > >>> > >>> > >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > >>> > wrote: > >>> > >>> Unless we write a detailed plan of what we are going to do, I don'= t > >>> think it will be enough. > >>> > >>> In any case, I think we can continue in the term room. Or in the > >>> hallways :D > >>> > >>> regards > >>> > >>> Carlos > >>> > >>> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in > >>> room > >>>> Boca 1 for implementation demos. We only have that one hour before > >>>> other sessions begin, so please come prepared! > >>>> > >>>> -MSK > >>>> > >>>> > >>>> _______________________________________________ > >>>> weirds mailing list > >>>> weirds@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/weirds > >>>> > >>> > >>> > >>> _______________________________________________ > >>> weirds mailing list > >>> weirds@ietf.org > >>> https://www.ietf.org/mailman/listinfo/weirds > >> > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >> > > > > --001a11c22a2ea50f5304d7b3052a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I didn't follow up on appointing someone to provi= de a brief report about the demo session when the WG meets at 10:30am tomor= row.  Does someone want to volunteer?

-MSK


On Tue, Mar 12, 2013 at 12:11 AM, Ning K= ong <nkong@cnnic.cn> wrote:
Hi Jean-Philippe,

Thanks for your feedback.

The current response is only JSON objects embedded in the HTML response. Th= e representation and xml presentation formats are just converted from JSON = objects.

Setting http header is not available now. We will modify this function soon= .

Cheers,
Ning

> Hi,
>
> I can see the json embedded inside the html response, but I cannot get=
> only json.  Do I need to specify an "Accept:" header to= get it?
>
> Thank you
> Jean-Philippe
>
> On 2013-03-11 19:04, Ning Kong wrote:
>> Hi folks,
>>
>> We just set up an online demo at http://rdap.restfulwhois.org.
>>
>> Our server support:
>> 1)   5 types of query (IP, Domain, Entity, AS and Nameserver)=
>>        2)   3 types of response (JSON, XM= L and our self-defined
>> presentation format)
>> 3=A3=A9 Client authentication by RFC 2617 (only one authenticated = user:
>> admin/admin)
>>
>> Our server don't support:
>> 1)   Authorization (no different between admin with anonymous= user)
>> 2)   Logout
>>
>> The following examples can be used as inputs for test.
>> 1)   IP:
>> 1.0.0.0
>> 1.0.0.0/8
>> 39.1.2.3
>> 39.1.2.3/8
>> 2)   Domain:
>> baidu.cn <http://baidu.cn>
>> qq.cn <http://qq.cn>
>> faha.cn <http://faha.cn>
>> 3)   Entity
>> APNIC
>> bu1048055833141
>> s1265874462073
>> 4)   AS
>> 1223
>> 2569
>> 3661
>> 3662
>> 5)   Nameserver
>> ns2.ee28.cn &= lt;http://ns2.ee28.cn&= gt;
>> ns1.google.com= <http://ns1.goo= gle.com>
>>
>> Any comments are appreciated! See you tomorrow morning.
>>
>> Cheers,
>> Ning
>>
>>> Do we have a lot of people planning to do demos?  Are the= demos going
>>> to be complicated?
>>>
>>> I don't understand how an hour would not be enough, unless= there's a
>>> large number of implementations I haven't heard of yet. >>>
>>> Who's got something to show (or will by then), and how lon= g do you need?
>>>
>>> -MSK
>>>
>>>
>>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez
>>> <carlosm3011@gmail= .com <mailto:carlosm3011@gm= ail.com>> wrote:
>>>
>>>    Unless we write a detailed plan of what we are go= ing to do, I don't
>>>    think it will be enough.
>>>
>>>    In any case, I think we can continue in the term = room. Or in the
>>>    hallways :D
>>>
>>>    regards
>>>
>>>    Carlos
>>>
>>>    On 3/1/13 4:21 PM, Murray S. Kucherawy wrote:
>>>> The Secretariat has assigned us 8am-9am on Tuesday, March = 12, in
>>>    room
>>>> Boca 1 for implementation demos.  We only have that o= ne hour before
>>>> other sessions begin, so please come prepared!
>>>>
>>>> -MSK
>>>>
>>>>
>>>> _______________________________________________
>>>> weirds mailing list
>>>> weirds@ietf.org <= ;mailto:weirds@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/weirds
>>>>
>>>
>>>
>>> _______________________________________________
>>> weirds mailing list
>>> weirds@ietf.org <mai= lto:weirds@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/weirds
>>
>>
>> _______________________________________________
>> weirds mailing list
>> weirds@ietf.org
>> https://www.ietf.org/mailman/listinfo/weirds
>>
>


--001a11c22a2ea50f5304d7b3052a-- From jean-philippe.dionne@viagenie.ca Mon Mar 11 22:33:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4621F86C2 for ; Mon, 11 Mar 2013 22:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x130N8AwEoF for ; Mon, 11 Mar 2013 22:33:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5921F8654 for ; Mon, 11 Mar 2013 22:33:00 -0700 (PDT) Received: from map-experiment-128c2.meeting.ietf.org (unknown [130.129.128.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EC88040436; Tue, 12 Mar 2013 01:32:25 -0400 (EDT) Message-ID: <513EBDE7.6070201@viagenie.ca> Date: Tue, 12 Mar 2013 01:32:23 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> <513E6C9C.1030607@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 05:33:07 -0000 Hi, I volunteer to present a report. Jean-Philippe On 2013-03-12 00:50, Murray S. Kucherawy wrote: > I didn't follow up on appointing someone to provide a brief report about > the demo session when the WG meets at 10:30am tomorrow. Does someone > want to volunteer? > > -MSK > > > On Tue, Mar 12, 2013 at 12:11 AM, Ning Kong > wrote: > > Hi Jean-Philippe, > > Thanks for your feedback. > > The current response is only JSON objects embedded in the HTML > response. The representation and xml presentation formats are just > converted from JSON objects. > > Setting http header is not available now. We will modify this > function soon. > > Cheers, > Ning > > > Hi, > > > > I can see the json embedded inside the html response, but I cannot get > > only json. Do I need to specify an "Accept:" header to get it? > > > > Thank you > > Jean-Philippe > > > > On 2013-03-11 19:04, Ning Kong wrote: > >> Hi folks, > >> > >> We just set up an online demo at http://rdap.restfulwhois.org. > >> > >> Our server support: > >> 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) > >> 2) 3 types of response (JSON, XML and our self-defined > >> presentation format) > >> 3£© Client authentication by RFC 2617 (only one authenticated user: > >> admin/admin) > >> > >> Our server don't support: > >> 1) Authorization (no different between admin with anonymous user) > >> 2) Logout > >> > >> The following examples can be used as inputs for test. > >> 1) IP: > >> 1.0.0.0 > >> 1.0.0.0/8 > >> 39.1.2.3 > >> 39.1.2.3/8 > >> 2) Domain: > >> baidu.cn > >> qq.cn > >> faha.cn > >> 3) Entity > >> APNIC > >> bu1048055833141 > >> s1265874462073 > >> 4) AS > >> 1223 > >> 2569 > >> 3661 > >> 3662 > >> 5) Nameserver > >> ns2.ee28.cn > >> ns1.google.com > >> > >> Any comments are appreciated! See you tomorrow morning. > >> > >> Cheers, > >> Ning > >> > >>> Do we have a lot of people planning to do demos? Are the demos > going > >>> to be complicated? > >>> > >>> I don't understand how an hour would not be enough, unless there's a > >>> large number of implementations I haven't heard of yet. > >>> > >>> Who's got something to show (or will by then), and how long do > you need? > >>> > >>> -MSK > >>> > >>> > >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > >>> > >> wrote: > >>> > >>> Unless we write a detailed plan of what we are going to do, I > don't > >>> think it will be enough. > >>> > >>> In any case, I think we can continue in the term room. Or in the > >>> hallways :D > >>> > >>> regards > >>> > >>> Carlos > >>> > >>> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, in > >>> room > >>>> Boca 1 for implementation demos. We only have that one hour before > >>>> other sessions begin, so please come prepared! > >>>> > >>>> -MSK > >>>> > >>>> > >>>> _______________________________________________ > >>>> weirds mailing list > >>>> weirds@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/weirds > >>>> > >>> > >>> > >>> _______________________________________________ > >>> weirds mailing list > >>> weirds@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/weirds > >> > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >> > > > > From fobispo@isc.org Tue Mar 12 01:33:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1EA21F8763 for ; Tue, 12 Mar 2013 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G02P4McLJwdE for ; Tue, 12 Mar 2013 01:33:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC1921F875C for ; Tue, 12 Mar 2013 01:33:55 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B92F45F9863 for ; Tue, 12 Mar 2013 08:33:44 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363077234; bh=yLWDoSfRCFGIkOCvYRp27rhT1dWiMHrlZN4NyfzVwdQ=; h=From:Date:Subject:To; b=ROxipr0Q3OaNzmwsIE+PFA3LjRx4zrvHQgGVTve7+JRNDNAOzZie/gWPbSIpNz2oS pSTD2MCtF/BTKwaNHuNWnXYWcETfbF3CYhMWis8wIFrks5WPXJdEdw+bN9zmjddYVE infZNScxP2VdEKNLOd4o7/9LB1Ikl0mB9WzaboTQ= Received: from [IPv6:2001:470:1f05:1326:5806:f2e:885:904f] (unknown [IPv6:2001:470:1f05:1326:5806:f2e:885:904f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2AF48216C40; Tue, 12 Mar 2013 08:33:43 +0000 (UTC) (envelope-from fobispo@isc.org) From: Francisco Obispo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Mar 2013 01:33:44 -0700 To: "weirds@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 08:33:56 -0000 I'm currently working on our implementation of RDAP. So far I've found three things that I think should be improved: 1) When describing a DNR Domain Object Class, the "phones", structure as shown here: "phones" : { "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ "1-958-555-4323" ], "mobile" : [ "1-958-555-4324" ] }, assume that we have information whether the phone is of an 'office' or 'mobile', which does not match the EPP schema where we only collect: voice, and fax (with ext). perhaps the easiest way to solve this issue is by adding a 'voice' key. 2) the field entityNames is an array reference with strings signifying the names of the entity. In a domain registry, via EPP we collect name and org, we can probably fit the two in there, but it leaves no pointers on which is which. I wold like to maintain the definition of what is a name and what is an org, this is specially useful when formatting for humans, even though some don't care about that. 3) It is confusing how each object type lays out the information within the format. I personally don't like object attributes at the same level as the protocol spec, makes the resulting output more difficult to read. In addition, the concept of: 'roles' in an 'entity' is redundant, and generates additional processing, because entities associated with an object are not longer just 'rendered' they need to be checked to see where in the 'parent' object is referenced in order to set the field. Fortunately it is not present in the example of DNR Domain Object, and even though I added it to mine, it seems unnecessary. As soon as I have a beta, I'll share the link with the list. Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE From zhoulinlin@cnnic.cn Tue Mar 12 02:27:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9494E21F8826 for ; Tue, 12 Mar 2013 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnUoaA1L3SWR for ; Tue, 12 Mar 2013 02:27:57 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 806EE21F87B6 for ; Tue, 12 Mar 2013 02:27:56 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Mar 2013 17:27:48 +0800 From: "Linlin Zhou" To: "'Francisco Obispo'" , References: In-Reply-To: Date: Tue, 12 Mar 2013 17:32:15 +0800 Message-ID: <00ad01ce1f04$7c1d7a80$74586f80$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4e/FxVJi3D6JklR8C8iHrSMCmCUgABcsRQ Content-Language: zh-cn Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 09:27:57 -0000 > > 3) It is confusing how each object type lays out the information within > the format. I personally don't like object attributes at the same level > as the protocol spec, makes the resulting output more difficult to read. > > In addition, the concept of: 'roles' in an 'entity' is redundant, and > generates additional processing, because entities associated with an > object are not longer just 'rendered' they need to be checked to see > where in the 'parent' object is referenced in order to set the field. > > Fortunately it is not present in the example of DNR Domain Object, > and even though I added it to mine, it seems unnecessary. > That's what I'm going to point out. The RIR entity has the object of 'roles' while the DNR entity doesn't. > As soon as I have a beta, I'll share the link with the list. > > > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = > B38DB1BE > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Tue Mar 12 03:26:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D2021F880B for ; Tue, 12 Mar 2013 03:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD7kcZ3Hd2Wp for ; Tue, 12 Mar 2013 03:26:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68321F8640 for ; Tue, 12 Mar 2013 03:26:07 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:64:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DC8DE40367 for ; Tue, 12 Mar 2013 06:26:04 -0400 (EDT) Message-ID: <513F02BC.7020707@viagenie.ca> Date: Tue, 12 Mar 2013 06:26:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 10:26:08 -0000 Le 2013-03-12 04:33, Francisco Obispo a écrit : > 1) When describing a DNR Domain Object Class, the "phones", structure > as shown here: > > "phones" : > { > "office" : [ "1-958-555-4321", "1-958-555-4322" ], > "fax" : [ "1-958-555-4323" ], > "mobile" : [ "1-958-555-4324" ] > }, > > assume that we have information whether the phone is of an 'office' or > 'mobile', which does not match the EPP schema where we only collect: > voice, and fax (with ext). > > perhaps the easiest way to solve this issue is by adding a 'voice' > key. This will hopefully be solved by vCard. :) See here: http://tools.ietf.org/html/rfc6350#section-6.4.1 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From superuser@gmail.com Tue Mar 12 05:23:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12C721F8A11 for ; Tue, 12 Mar 2013 05:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79za96KXyXyr for ; Tue, 12 Mar 2013 05:23:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id B577A21F8A08 for ; Tue, 12 Mar 2013 05:23:35 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hq4so1766876wib.11 for ; Tue, 12 Mar 2013 05:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iZWqoUNlta15GaKR9QuLxvne0atCb0HsaPR5xsN+Cn0=; b=r1tiXr9ck8qlmCk54/uvnb04dhKg9Tg/MnX0nVTyCSwXJYBo05ELoVGlKOW4PANHqs IoHiXTaoAZbDtr1R1hkZ6zpnUmQuBwtwOGj3oBHRDIzlpEY3TNcd8rcYzU5Nua+Tktgs eS8sRrkZoQPSSttEN+kvSk5I8zBFKm7hh5s1tPptqQw0I0M9dCjitV3fZWiwN/RXH8rV VeJKpuMbbudP5c3td+y6cEM9bJshGsiYpG/Hd/nPhE30pg1ptmELkDM4EWmf5QA+m36A v28Hg733Kc+9RDHdvMSf2FI8GlVk2YaSQxsuzFqTws5u04eqpF5ivCzjAYpd5TRimEFM XQIA== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr5481059wic.5.1363091013618; Tue, 12 Mar 2013 05:23:33 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 05:23:33 -0700 (PDT) In-Reply-To: <513EBDE7.6070201@viagenie.ca> References: <5130F3B1.4080909@gmail.com> <853958F2-EB4C-4DBA-BC5D-CAE06BEAF99C@cnnic.cn> <513E6C9C.1030607@viagenie.ca> <513EBDE7.6070201@viagenie.ca> Date: Tue, 12 Mar 2013 08:23:33 -0400 Message-ID: From: "Murray S. Kucherawy" To: Jean-Philippe Dionne Content-Type: multipart/alternative; boundary=001a11c34a62a9d07304d7b95b4d Cc: Carlos Martinez , "weirds@ietf.org" Subject: Re: [weirds] WEIRDS implementation demo X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:23:41 -0000 --001a11c34a62a9d07304d7b95b4d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Apologies, Jean-Philppe. I didn't see this until just now and took Andrew volunteering in the meeting to give a short report. Thank you for offering= ! -MSK On Tue, Mar 12, 2013 at 1:32 AM, Jean-Philippe Dionne < jean-philippe.dionne@viagenie.ca> wrote: > Hi, > > I volunteer to present a report. > > Jean-Philippe > > On 2013-03-12 00:50, Murray S. Kucherawy wrote: > > I didn't follow up on appointing someone to provide a brief report abou= t > > the demo session when the WG meets at 10:30am tomorrow. Does someone > > want to volunteer? > > > > -MSK > > > > > > On Tue, Mar 12, 2013 at 12:11 AM, Ning Kong > > wrote: > > > > Hi Jean-Philippe, > > > > Thanks for your feedback. > > > > The current response is only JSON objects embedded in the HTML > > response. The representation and xml presentation formats are just > > converted from JSON objects. > > > > Setting http header is not available now. We will modify this > > function soon. > > > > Cheers, > > Ning > > > > > Hi, > > > > > > I can see the json embedded inside the html response, but I canno= t > get > > > only json. Do I need to specify an "Accept:" header to get it? > > > > > > Thank you > > > Jean-Philippe > > > > > > On 2013-03-11 19:04, Ning Kong wrote: > > >> Hi folks, > > >> > > >> We just set up an online demo at http://rdap.restfulwhois.org. > > >> > > >> Our server support: > > >> 1) 5 types of query (IP, Domain, Entity, AS and Nameserver) > > >> 2) 3 types of response (JSON, XML and our self-defined > > >> presentation format) > > >> 3=A3=A9 Client authentication by RFC 2617 (only one authenticate= d user: > > >> admin/admin) > > >> > > >> Our server don't support: > > >> 1) Authorization (no different between admin with anonymous > user) > > >> 2) Logout > > >> > > >> The following examples can be used as inputs for test. > > >> 1) IP: > > >> 1.0.0.0 > > >> 1.0.0.0/8 > > >> 39.1.2.3 > > >> 39.1.2.3/8 > > >> 2) Domain: > > >> baidu.cn > > >> qq.cn > > >> faha.cn > > >> 3) Entity > > >> APNIC > > >> bu1048055833141 > > >> s1265874462073 > > >> 4) AS > > >> 1223 > > >> 2569 > > >> 3661 > > >> 3662 > > >> 5) Nameserver > > >> ns2.ee28.cn > > >> ns1.google.com > > >> > > >> Any comments are appreciated! See you tomorrow morning. > > >> > > >> Cheers, > > >> Ning > > >> > > >>> Do we have a lot of people planning to do demos? Are the demos > > going > > >>> to be complicated? > > >>> > > >>> I don't understand how an hour would not be enough, unless > there's a > > >>> large number of implementations I haven't heard of yet. > > >>> > > >>> Who's got something to show (or will by then), and how long do > > you need? > > >>> > > >>> -MSK > > >>> > > >>> > > >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. Martinez > > >>> > > >> > wrote: > > >>> > > >>> Unless we write a detailed plan of what we are going to do, = I > > don't > > >>> think it will be enough. > > >>> > > >>> In any case, I think we can continue in the term room. Or in > the > > >>> hallways :D > > >>> > > >>> regards > > >>> > > >>> Carlos > > >>> > > >>> On 3/1/13 4:21 PM, Murray S. Kucherawy wrote: > > >>>> The Secretariat has assigned us 8am-9am on Tuesday, March 12, = in > > >>> room > > >>>> Boca 1 for implementation demos. We only have that one hour > before > > >>>> other sessions begin, so please come prepared! > > >>>> > > >>>> -MSK > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> weirds mailing list > > >>>> weirds@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/weirds > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> weirds mailing list > > >>> weirds@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/weirds > > >> > > >> > > >> _______________________________________________ > > >> weirds mailing list > > >> weirds@ietf.org > > >> https://www.ietf.org/mailman/listinfo/weirds > > >> > > > > > > > > > --001a11c34a62a9d07304d7b95b4d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Apologies, Jean-Philppe.  I didn't see this = until just now and took Andrew volunteering in the meeting to give a short = report.  Thank you for offering!

-MSK


On Tue, Mar 12, 2013 at 1:32 AM, Jean-Ph= ilippe Dionne <jean-philippe.dionne@viagenie.ca> wrote:
Hi,

I volunteer to present a report.

Jean-Philippe

On 2013-03-12 00:50, Murray S. Kucherawy wrote:
> I didn't follow up on appointing someone to provide a brief report= about
> the demo session when the WG meets at 10:30am tomorrow.  Does som= eone
> want to volunteer?
>
> -MSK
>
>
> On Tue, Mar 12, 2013 at 12:11 AM, Ning Kong <nkong@cnnic.cn
> <mailto:nkong@cnnic.cn>> wrote:
>
>     Hi Jean-Philippe,
>
>     Thanks for your feedback.
>
>     The current response is only JSON objects embedded in th= e HTML
>     response. The representation and xml presentation format= s are just
>     converted from JSON objects.
>
>     Setting http header is not available now. We will modify= this
>     function soon.
>
>     Cheers,
>     Ning
>
>     > Hi,
>     >
>     > I can see the json embedded inside the html respons= e, but I cannot get
>     > only json.  Do I need to specify an "Acce= pt:" header to get it?
>     >
>     > Thank you
>     > Jean-Philippe
>     >
>     > On 2013-03-11 19:04, Ning Kong wrote:
>     >> Hi folks,
>     >>
>     >> We just set up an online demo at http://rdap.restfulwhois.org.
>     >>
>     >> Our server support:
>     >> 1)   5 types of query (IP, Domain, Entity,= AS and Nameserver)
>     >>        2)   3 types of= response (JSON, XML and our self-defined
>     >> presentation format)
>     >> 3=A3=A9 Client authentication by RFC 2617 (only= one authenticated user:
>     >> admin/admin)
>     >>
>     >> Our server don't support:
>     >> 1)   Authorization (no different between a= dmin with anonymous user)
>     >> 2)   Logout
>     >>
>     >> The following examples can be used as inputs fo= r test.
>     >> 1)   IP:
>     >> 1.0.0.0
>     >> 1.0.0.0/8 <http://1.0.0.0/8>
>     >> 39.1.2.3
>     >> 39.1.2.3/8 <http://= 39.1.2.3/8>
>     >> 2)   Domain:
>     >> b= aidu.cn <http://baidu.= cn> <http://baidu.c= n>
>     >> qq.c= n <http://qq.cn> &= lt;http://qq.cn>
>     >> fa= ha.cn <http://faha.cn> <http://faha.cn&= gt;
>     >> 3)   Entity
>     >> APNIC
>     >> bu1048055833141
>     >> s1265874462073
>     >> 4)   AS
>     >> 1223
>     >> 2569
>     >> 3661
>     >> 3662
>     >> 5)   Nameserver
>     >> ns2.ee28.cn <http://ns2.ee28.cn> <http://ns2.ee28.cn>
>     >> ns1.google.com <http://ns1.google.com> <http://ns1.google.com>
>     >>
>     >> Any comments are appreciated! See you tomorrow = morning.
>     >>
>     >> Cheers,
>     >> Ning
>     >>
>     >>> Do we have a lot of people planning to do d= emos?  Are the demos
>     going
>     >>> to be complicated?
>     >>>
>     >>> I don't understand how an hour would no= t be enough, unless there's a
>     >>> large number of implementations I haven'= ;t heard of yet.
>     >>>
>     >>> Who's got something to show (or will by= then), and how long do
>     you need?
>     >>>
>     >>> -MSK
>     >>>
>     >>>
>     >>> On Fri, Mar 1, 2013 at 10:30 AM, Carlos M. = Martinez
>     >>> <carlosm3011@gmail.com <mailto:carlosm3011@gmail.com>
>     <mailto:carlosm3011@gmail.com <mailto:carlosm3011@gmail.com>>> wrote:
>     >>>
>     >>>    Unless we write a detailed pla= n of what we are going to do, I
>     don't
>     >>>    think it will be enough.
>     >>>
>     >>>    In any case, I think we can co= ntinue in the term room. Or in the
>     >>>    hallways :D
>     >>>
>     >>>    regards
>     >>>
>     >>>    Carlos
>     >>>
>     >>>    On 3/1/13 4:21 PM, Murray S. K= ucherawy wrote:
>     >>>> The Secretariat has assigned us 8am-9am= on Tuesday, March 12, in
>     >>>    room
>     >>>> Boca 1 for implementation demos.  = We only have that one hour before
>     >>>> other sessions begin, so please come pr= epared!
>     >>>>
>     >>>> -MSK
>     >>>>
>     >>>>
>     >>>> _______________________________________= ________
>     >>>> weirds mailing list
>     >>>> weir= ds@ietf.org <mailto:weirds@ietf.o= rg>
>     <mailto:weir= ds@ietf.org <mailto:weirds@ietf.o= rg>>
>     >>>> https://www.ietf.org/= mailman/listinfo/weirds
>     >>>>
>     >>>
>     >>>
>     >>> ___________________________________________= ____
>     >>> weirds mailing list
>     >>> we= irds@ietf.org <mailto:weirds@ietf= .org> <mailto:weirds@ietf.org<= /a>
>     <mailto:weirds@ietf.org>>
>     >>> https://www.ietf.org/mailman/listinfo/weird= s
>     >>
>     >>
>     >> _______________________________________________=
>     >> weirds mailing list
>     >> weirds@ietf.= org <mailto:weirds@ietf.org&g= t;
>     >> https://www.ietf.org/mailman/listinfo/weirds
>     >>
>     >
>
>


--001a11c34a62a9d07304d7b95b4d-- From superuser@gmail.com Tue Mar 12 06:11:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243DF21F8826 for ; Tue, 12 Mar 2013 06:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF6G+WNNe4ut for ; Tue, 12 Mar 2013 06:11:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E76221F880F for ; Tue, 12 Mar 2013 06:11:34 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr12so5930928wgb.11 for ; Tue, 12 Mar 2013 06:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=apCXBqgPPAVGXRXV9dimNbJYsBRmIVG7gxO/fetsGRU=; b=OQuaEnUtF91BDBcyLrN5QLMZfdRRWWG1D+Gl7PLb0EbYdD2YIMjh402O9/g7pBfAag vNEbIMLY7ezMpR1zIodC1J0w7nOWLVybiJjP5VLntNkNVk96XnaOuPLGIIrwdLUgwjbf XNHWnP6TbksS8R/qYz2vAtVxphi0zbXTgLsJlsW1MHSecWGtU+MXSHWQjuJfzWy71BgL lzuMRRNKHJ2PCDIf8ikvLWCAX8ahBYnEPWhxYrt2egWl0wD1Qgij8Vb6J4h+Hz5ViN3U R4wY2F4ooaelLzcnpScu3kJaLRGA7gwx6LGAorzCqURTSdBUz1P2AaUZEOgv36OV5b/t 6Vqg== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr19414090wib.33.1363093894243; Tue, 12 Mar 2013 06:11:34 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 06:11:34 -0700 (PDT) Date: Tue, 12 Mar 2013 09:11:34 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba6e35cb38d04d7ba0791 Subject: [weirds] Second meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:11:48 -0000 --e89a8f3ba6e35cb38d04d7ba0791 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, It's fairly obvious now that one hour won't be enough to cover everything we need to discuss at this meeting. Thanks to Pete, we're taking over the slot of the canceled AVTCORE session on Thursday at 5:30pm in Caribbean 5 to allow us to get more work done. Apologies for the short notice and to those of you that already have travel plans prior to then. The jabber room and audio streams will be available for remote participation as usual. If you will be departing after today (I know Andy will, for example) or have a major conflict with the Thursday session, please let us know ASAP and we'll try to juggle it so your favourite things happen today. I'll try to post a revised agenda shortly. -MSK --e89a8f3ba6e35cb38d04d7ba0791 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

It's fairly ob= vious now that one hour won't be enough to cover everything we need to = discuss at this meeting.=A0 Thanks to Pete, we're taking over the slot = of the canceled AVTCORE session on Thursday at 5:30pm in Caribbean 5 to all= ow us to get more work done.

Apologies for the short notice and to those of you that already have tr= avel plans prior to then.=A0 The jabber room and audio streams will be avai= lable for remote participation as usual.=A0 If you will be departing after = today (I know Andy will, for example) or have a major conflict with the Thu= rsday session, please let us know ASAP and we'll try to juggle it so yo= ur favourite things happen today.

I'll try to post a revised agenda shortly.

-MSK<= br>
--e89a8f3ba6e35cb38d04d7ba0791-- From superuser@gmail.com Tue Mar 12 06:27:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4076A21F8ABD for ; Tue, 12 Mar 2013 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg7ewo+DGd+M for ; Tue, 12 Mar 2013 06:27:26 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66E21F8AA1 for ; Tue, 12 Mar 2013 06:27:26 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so6297600wgb.9 for ; Tue, 12 Mar 2013 06:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=aKlrClytKB85K3hWwmInax414455d3pPzyx9GK+xsB8=; b=HfY/XrspqxU9ixqx3Q+xrOfgR/a9RzDSaZrSr0YyIp618yv0H0mY0sJwi+nC5x9yqG /ODBHXoaJbZp8RcS9mO9FN8h2d4eW/GiFpYCgOqY2LwxbqS0HWQ94TBNXm7MDxJXGMFH 1+wL00/PHT/kf6Z6FU1vm4Z6jjm6ytrcaizgVUOZ30i9t/5TwPHGxXAQzlD6Xpa6S+EW LYTmI8B5Wb26sWp5TSTLChtF6n0d4Bn6pBmNbOlb7EBb1bu2YiBH++I+ilb8C5iaWyRo UFZzdy68znrrrJhRuKmwxuGydxHZyrYdRo0motMJUGsxsmPds3XeN/cA2qHik8Hg9tQH nc5g== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr26749177wjc.39.1363094845542; Tue, 12 Mar 2013 06:27:25 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 06:27:25 -0700 (PDT) Date: Tue, 12 Mar 2013 09:27:25 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1f28105c6f04d7ba40e6 Subject: [weirds] Tracking document issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:27:27 -0000 --089e013d1f28105c6f04d7ba40e6 Content-Type: text/plain; charset=ISO-8859-1 Olaf and I invite you all to start adding issues to the working group's tracker as you discover them. This is especially useful and important to implementers who discover ambiguities or unclear parts of the specs as you create your implementations. We need to make sure new implementers don't hit such issues. The tracker should not be used as an alternative to the mailing list, however. I prefer to use it like a checklist of things that need to be adjusted or "fixed" before we could consider the document ready to ship. For example, a section marked "TBD" or "text needed" doesn't need to be in the tracker, but "There's an ABNF error in Section 1.2.3.4" is ideal fodder for the tracker. I haven't checked yet if the tracker's permissions are set appropriately. If you have trouble opening tickets, let us know. http://trac.tools.ietf.org/wg/weirds/trac/ I'm aware of the warning at the top; I'll look into it. -MSK --089e013d1f28105c6f04d7ba40e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Olaf and I invite you all to start adding i= ssues to the working group's tracker as you discover them.=A0 This is e= specially useful and important to implementers who discover ambiguities or = unclear parts of the specs as you create your implementations.=A0 We need t= o make sure new implementers don't hit such issues.

The tracker should not be used as an alternative to the mailing l= ist, however.=A0 I prefer to use it like a checklist of things that need to= be adjusted or "fixed" before we could consider the document rea= dy to ship.=A0 For example, a section marked "TBD" or "text = needed" doesn't need to be in the tracker, but=A0 "There'= s an ABNF error in Section 1.2.3.4" is ideal fodder for the tracker.
I haven't checked yet if the tracker's permissions are se= t appropriately.=A0 If you have trouble opening tickets, let us know.
http://trac.tools.= ietf.org/wg/weirds/trac/

I'm aware of the warning at the top; I'll look into it.
-MSK
--089e013d1f28105c6f04d7ba40e6-- From andy@arin.net Tue Mar 12 06:29:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65421F880B for ; Tue, 12 Mar 2013 06:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PubH6t2FehYR for ; Tue, 12 Mar 2013 06:29:45 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id C6B7F21F8702 for ; Tue, 12 Mar 2013 06:29:44 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 76601164FC8; Tue, 12 Mar 2013 09:29:44 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 275F316512A; Tue, 12 Mar 2013 09:29:43 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 09:28:51 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 09:29:24 -0400 From: Andy Newton To: Linlin Zhou , 'Francisco Obispo' , "weirds@ietf.org" Thread-Topic: [weirds] observations so far.... Thread-Index: AQHOHvxjQzusUs1c3EKxuyxQ03FSIZiiDgyAgAAP8YA= Date: Tue, 12 Mar 2013 13:29:23 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2A68@CHAXCH01.corp.arin.net> In-Reply-To: <00ad01ce1f04$7c1d7a80$74586f80$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B02532AB936B84992A13EA3FA3CC13B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:29:45 -0000 On 3/12/13 5:32 AM, "Linlin Zhou" wrote: >That's what I'm going to point out. >The RIR entity has the object of 'roles' while the DNR entity doesn't. The both have it. The draft splits out RIR and DNR for the understanding of what might be expected from those types of services, but the attributes are allowed in both objects. >From Section 1 Paragraph 2 of json-response: The data model for the responses consists of two major categories: responses returned by Regional Internet Registries (RIRs) for registrations data related to IP addresses, reverse DNS names, and Autonomous System numbers; and responses returned by Domain Name Registries (DNRs) for registration data related to forward DNS names. The RIR object classes are a proper subset of the DNR object classes. The current division between RIR and DNR object classes is given to illustrate an expectation of what data may be expected from an RIR vs a DNR. However, implementers should be aware that RIRs are not limited to the data in the RIR object classes (as an example, some RIRs have a notion of "status" for entities as defined in the DNR entity object class and may at some point start publishing that data). That text may need be clarified, but we've wrangled it before. -andy From olaf@NLnetLabs.nl Tue Mar 12 06:49:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392A021F856D for ; Tue, 12 Mar 2013 06:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njfdpKbn218d for ; Tue, 12 Mar 2013 06:49:34 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AD21F8168 for ; Tue, 12 Mar 2013 06:49:34 -0700 (PDT) Received: from dhcp-603e.meeting.ietf.org (dhcp-603e.meeting.ietf.org [130.129.96.62]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2CDnTMn015928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Mar 2013 14:49:32 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.4 open.nlnetlabs.nl r2CDnTMn015928 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1363096173; bh=xq+Q9bVXdNM2kRRPKNRhJvdawnrbOLVBT7MZ2E3sWRk=; h=From:Subject:Date:To; b=QcvDK7pFkDW+ck5CtoVt53gpwk8T+EmQQDHbn5OwIa0lLQtpiganUBfreFH3VXvek bO91FScHbcW9EHJtRu/yxLbqOGVySMhl5VoUO6jNR48Inju4ukU88sGoRqxqKjGTK2 J7lBuQVf2wpFuOYnN3EMTUtnjeYcq0FAWmqFN6X8= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_CD7111E5-9D67-4A6D-8D33-FFE1CA8CB7E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <95A35BF2-C480-4727-8502-9D38AFA56416@NLnetLabs.nl> Date: Tue, 12 Mar 2013 09:49:27 -0400 To: "weirds@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 12 Mar 2013 14:49:32 +0100 (CET) Subject: [weirds] Extra Agenda Point for 2nd hour X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:49:35 -0000 --Apple-Mail=_CD7111E5-9D67-4A6D-8D33-FFE1CA8CB7E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folk, Since we have another hour of face time I would like to use a bit of = face time to discuss the the issues that came up in Client handling of unknown attributes/names. and Client handling of known attributes/names. I would like to ask for a volunteer to give a summary of the issue.=20 The goal of the discussion would be to get shared understanding of what = the two issues are, why they are blocking for some that want to = implement RSEP, whether there are credible mechanisms to remove those = blocks. We hope that even though James Mitchel might not be in the room, his = view will be represented, possibly by a 'advocatus diaboli' We are looking for two volunteers to summarize an issue each.=20 --Olaf & Murray, chairs.. --Apple-Mail=_CD7111E5-9D67-4A6D-8D33-FFE1CA8CB7E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRPzJoAAoJEFRqER47aqpk6KEP/26P1br2J8QNiS5PfZiOQSAo Ivy+2SPSCI0/PLxoR9nQSYXMiXEZ0GpP69nWWxzWadIvg89NnjVckLqdnz/auqp0 FKd135KaRGQuNSBPv2pPkjCOdm5A5a3GLSW2pvYo8NAs6LqiEyE+1+jATVMc5eL7 nTeK7xk+mBhbimLJTJkJmr7BLJnx/lT/8pvlKzOhncfKa8ByOjYbmQ2Eub7wl+xu +eRnehrgEBSRBTEd540KV53AXk7pojE9kLPRpr0dLTQ8jcUyC4x+OBL+9DcSTCdm b2owmXEdT/rF2t38BIN+AWtYuW2PED2x6/dPa1jrt70ar24f22aPcRDNMSgYnNbs rYOyC7wDmNuVNo2WUwmaBJcmPscJw0tEn75p12te4LKRej+FSQSE08oqvg0wwZ2n 9ZmBflXjOpJT7qsDxttNs13EegXzlyubLmuA24BgbvX/Em2xbgtd+e28FZjyu0uf cgvxsvyed/NrSlz6LTSWTqJO3Bqe7viBCPB2tzgLatlPgSUmVYq1n9fFT5NcNrzF zeZoN8c6HY1TwGD+P1pJuvFdcO8IZUBi9B1AMfDNn8J5HXazuIM22d4HzTnixyVt RPJSrrkybheYpj3fOh32MN/jgY0GBKkZS5uij/XUyTuqh4XpZBYh6njtIlG2mB2p oQeteZAMDG+y5eJnSqX4 =kqNT -----END PGP SIGNATURE----- --Apple-Mail=_CD7111E5-9D67-4A6D-8D33-FFE1CA8CB7E3-- From james.mitchell@ausregistry.com.au Tue Mar 12 06:51:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A12821F8A74 for ; Tue, 12 Mar 2013 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWCTn2uPclwe for ; Tue, 12 Mar 2013 06:51:39 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id EC3EF21F8AB2 for ; Tue, 12 Mar 2013 06:51:38 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 13 Mar 2013 00:51:37 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 13 Mar 2013 00:51:28 +1100 From: James Mitchell To: Linlin Zhou , 'Francisco Obispo' , "weirds@ietf.org" Date: Wed, 13 Mar 2013 00:51:34 +1100 Thread-Topic: [weirds] observations so far.... Thread-Index: Ac4fKLE+p0QNpS0wSjqARLlVwpXo2w== Message-ID: In-Reply-To: <00ad01ce1f04$7c1d7a80$74586f80$@cn> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:51:40 -0000 The roles model does suit the DNR object, its just a different way of looking at the data presented over EPP. It supports roles outside the core EPP spec, for example reseller or the operations and notifications (OPN) contact used in the .asia sunrise, however one could argue for such information to be expressed as their own attributes/names. I do however have issues with the example presented in the draft, comments below. 1. the entity in the DNR Domain Object example response should include its role(s). I cannot tell whether the entity is a registrant, admin, billing, tech, or registrar, or all of the above. If we remain with the 'roles model' I would expect that the role attribute would be "mandatory" in response to a domain query, otherwise it is potentially meaningless? 2. The use of the sponsoredBy attribute is inconsistent with the use of domain contacts; apparently both registrar and domain contacts are entities however both are treated completely differently in the response. I would expect registrars and domain contacts are either attributes of domain objects (with full information either available inline or through links) or the sponsoring registrar included in the entities section (both illustrated below). I'm sitting on the fence for this one, perhaps leaning towards an entities section. Regardless any method that allows me to return only names and links would suffice. Example with attributes: { name:"abc.example", =8A sponsoredBy:{handle:"SponsorXYZ", link:"http://example.net/registrar/SponsorXYZ", ... }, registrant:{handle:"XXXX", link:"http://example.net/contact/XXXX" }, -- or -- registrant:{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], =8A}, =8A } Example with entities: { name:"abc.example", =8A entities: [ {handle:"SponsorXYZ", name:"Registrar 123", role:"registrar", =8A}, {handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], role:"registrant", =8A} ] =8A } Regards, James On 12/03/13 8:32 PM, "Linlin Zhou" wrote: >>=20 >> 3) It is confusing how each object type lays out the information within >> the format. I personally don't like object attributes at the same >>level >> as the protocol spec, makes the resulting output more difficult to >read. >>=20 >> In addition, the concept of: 'roles' in an 'entity' is redundant, and >> generates additional processing, because entities associated with an >> object are not longer just 'rendered' they need to be checked to see >> where in the 'parent' object is referenced in order to set the field. >>=20 >> Fortunately it is not present in the example of DNR Domain Object, >> and even though I added it to mine, it seems unnecessary. >>=20 >That's what I'm going to point out. >The RIR entity has the object of 'roles' while the DNR entity doesn't. > >> As soon as I have a beta, I'll share the link with the list. >>=20 >>=20 >>=20 >> Francisco Obispo >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D >> B38DB1BE >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From zhoulinlin@cnnic.cn Tue Mar 12 07:00:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB44621F858C for ; Tue, 12 Mar 2013 07:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmTp35Rn3ZJt for ; Tue, 12 Mar 2013 07:00:21 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 03DD011E80BA for ; Tue, 12 Mar 2013 07:00:17 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Mar 2013 21:59:57 +0800 From: "Linlin Zhou" To: "'Andy Newton'" , "'Francisco Obispo'" , References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2A68@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2A68@CHAXCH01.corp.arin.net> Date: Tue, 12 Mar 2013 22:04:25 +0800 Message-ID: <00e701ce1f2a$811dbba0$835932e0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOHvxjQzusUs1c3EKxuyxQ03FSIZiiDgyAgAAP8YD///Yg0A== Content-Language: zh-cn Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:00:23 -0000 It's a little confused presented by the two JSON response examples. Clear now. Thanks. > -----Original Message----- > From: Andy Newton [mailto:andy@arin.net] > Sent: Tuesday, March 12, 2013 9:29 PM > To: Linlin Zhou; 'Francisco Obispo'; weirds@ietf.org > Subject: Re: [weirds] observations so far.... > > On 3/12/13 5:32 AM, "Linlin Zhou" wrote: > > >That's what I'm going to point out. > >The RIR entity has the object of 'roles' while the DNR entity doesn't. > > The both have it. The draft splits out RIR and DNR for the understanding of > what might be expected from those types of services, but the attributes are > allowed in both objects. > > From Section 1 Paragraph 2 of json-response: > > The data model for the responses consists of two major categories: > responses returned by Regional Internet Registries (RIRs) for > registrations data related to IP addresses, reverse DNS names, and > Autonomous System numbers; and responses returned by Domain Name > Registries (DNRs) for registration data related to forward DNS names. > The RIR object classes are a proper subset of the DNR object classes. > The current division between RIR and DNR object classes is given to > illustrate an expectation of what data may be expected from an RIR vs > a DNR. However, implementers should be aware that RIRs are not > limited to the data in the RIR object classes (as an example, some > RIRs have a notion of "status" for entities as defined in the DNR > entity object class and may at some point start publishing that > data). > > > That text may need be clarified, but we've wrangled it before. > > -andy From andy@arin.net Tue Mar 12 07:31:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771D021F8917 for ; Tue, 12 Mar 2013 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvd2w8vWA3KN for ; Tue, 12 Mar 2013 07:31:05 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EED7921F8713 for ; Tue, 12 Mar 2013 07:31:04 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9F604165138; Tue, 12 Mar 2013 10:31:04 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 3D328164F79; Tue, 12 Mar 2013 10:31:04 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 10:30:24 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 10:30:56 -0400 From: Andy Newton To: Linlin Zhou , 'Francisco Obispo' , "weirds@ietf.org" Thread-Topic: [weirds] observations so far.... Thread-Index: AQHOHvxjQzusUs1c3EKxuyxQ03FSIZiiDgyAgAAP8YD///Yg0IAAGxSA Date: Tue, 12 Mar 2013 14:30:55 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2B25@CHAXCH01.corp.arin.net> In-Reply-To: <00e701ce1f2a$811dbba0$835932e0$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <28A99E8FA8F82742B1206136FD9D9DB5@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:31:05 -0000 On 3/12/13 10:04 AM, "Linlin Zhou" wrote: >It's a little confused presented by the two JSON response examples. >Clear now. Thanks. Linlin, I'm sympathetic to this issue and will think about how we can make it clearer. -andy From ajs@anvilwalrusden.com Tue Mar 12 08:06:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95D21F89E9 for ; Tue, 12 Mar 2013 08:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqBeYY2P3vjF for ; Tue, 12 Mar 2013 08:06:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AF04621F89FB for ; Tue, 12 Mar 2013 08:06:14 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0297D8A031 for ; Tue, 12 Mar 2013 15:06:13 +0000 (UTC) Date: Tue, 12 Mar 2013 11:06:03 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130312150603.GC39238@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:06:15 -0000 In the interests of time, I'll send this to the list. It is absurd to insist that queries be A-labels. First, A-labels and U-labels are perfectly convertible to one another, and therefore there is no reason to prefer one over the other. Second, nobody can use A-labels, so we're just creating a user interface problem but pretending we aren't. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ray.Bellis@nominet.org.uk Tue Mar 12 08:08:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD06821F8A84 for ; Tue, 12 Mar 2013 08:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj64VY1CVLMx for ; Tue, 12 Mar 2013 08:08:58 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id A9DFA21F8A42 for ; Tue, 12 Mar 2013 08:08:56 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=p0ybNWEH/1+nzdmXXtmb7jMMe2K9mG76OC0Wy39AAmIP/Fk7hFOuF0Is DAOchnSKbSqpeDx27Kcr0pSEgOAoJ+1ct1Zd8u5gCmHyJJc3XPOWZpfJG ndFpsAME5gGj+I5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1363100937; x=1394636937; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20CORS=20and/or=20JSONP=20>|Date:=20Tue,=2012 =20Mar=202013=2015:08:54=20+0000|Message-ID:=20<53F00E5CD 8B2E34C81C0C89EB0B4FE73105A9BC0@wds-exc1.okna.nominet.org .uk>|To:=20"weirds@ietf.org=20Group"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20; bh=/lMnK6o/rh4RFD/St8gkWKGBCXNovgg24fif5ez6w/o=; b=szWXhSBP4wx0zWhysQtm5l184IW9btI/VQfO+vLY7Q4qTbeA/HzVkAKQ OgHdzEKXCVuLc3VEOlm06XT0FS9haK8dNmKRUXMEd1g5T/WkMv9I6o17n ezLtI3a+kfeR+7a; X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208";a="47106978" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 12 Mar 2013 15:08:55 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 15:08:55 +0000 From: Ray Bellis To: "weirds@ietf.org Group" Thread-Topic: CORS and/or JSONP > Thread-Index: AQHOHzOCwoneGUbUSEiX91SCbOdOBA== Date: Tue, 12 Mar 2013 15:08:54 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73105A9BC0@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] CORS and/or JSONP > X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:08:58 -0000 To allow for an RDAP client to run in a browser, the "cross origin" securit= y features in the browser would require either: 1. all requests go to the same server as the page was loaded from, or 2. the server wraps the output with a JSONP callback, or 3. the server sets a response header of "Access-Control-Allow-Origin: *" where IMHO the latter is preferred. Is this something that should be mentioned in the JSON response document? Ray From stpeter@stpeter.im Tue Mar 12 08:17:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5570D21F8AA1 for ; Tue, 12 Mar 2013 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXzdzsrSA7Y5 for ; Tue, 12 Mar 2013 08:17:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7021F8B7C for ; Tue, 12 Mar 2013 08:17:05 -0700 (PDT) Received: from [130.129.84.195] (unknown [130.129.84.195]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7EEF140725; Tue, 12 Mar 2013 09:25:38 -0600 (MDT) Message-ID: <513F46F2.7030504@stpeter.im> Date: Tue, 12 Mar 2013 11:17:06 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andrew Sullivan References: <20130312150603.GC39238@mx1.yitter.info> In-Reply-To: <20130312150603.GC39238@mx1.yitter.info> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:17:13 -0000 On 3/12/13 11:06 AM, Andrew Sullivan wrote: > In the interests of time, I'll send this to the list. > > It is absurd to insist that queries be A-labels. First, A-labels and > U-labels are perfectly convertible to one another, and therefore there > is no reason to prefer one over the other. Second, nobody can use > A-labels, so we're just creating a user interface problem but > pretending we aren't. Hi Andrew, As we discussed in the meeting, the question is where the pain of conversion happens. It's not obvious to me (coming from the outside) what exactly the user agents are in this architecture, and how smart they could be about doing conversion (vs. leaving it up servers). But I think I'll try to chat with you in person this week so I can understand it better. Peter -- Peter Saint-Andre https://stpeter.im/ From marc.blanchet@viagenie.ca Tue Mar 12 08:22:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34D21F8C5B for ; Tue, 12 Mar 2013 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNpqrn-k65JL for ; Tue, 12 Mar 2013 08:22:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7823421F8C04 for ; Tue, 12 Mar 2013 08:22:38 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A3FAC40367; Tue, 12 Mar 2013 11:22:37 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <513F46F2.7030504@stpeter.im> Date: Tue, 12 Mar 2013 11:22:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:22:39 -0000 Le 2013-03-12 =E0 11:17, Peter Saint-Andre a =E9crit = : > On 3/12/13 11:06 AM, Andrew Sullivan wrote: >> In the interests of time, I'll send this to the list. >>=20 >> It is absurd to insist that queries be A-labels. First, A-labels and >> U-labels are perfectly convertible to one another, and therefore = there >> is no reason to prefer one over the other. Second, nobody can use >> A-labels, so we're just creating a user interface problem but >> pretending we aren't. >=20 > Hi Andrew, >=20 > As we discussed in the meeting, the question is where the pain of > conversion happens. It's not obvious to me (coming from the outside) > what exactly the user agents are in this architecture, and how smart > they could be about doing conversion (vs. leaving it up servers). But = I > think I'll try to chat with you in person this week so I can = understand > it better. one of the advantage of client-based processing is that the client will = be able to reject non-valid strings right away and give proper error to = the user. Marc. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From ajs@anvilwalrusden.com Tue Mar 12 08:29:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1F721F859B for ; Tue, 12 Mar 2013 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD3WV21GTFlM for ; Tue, 12 Mar 2013 08:29:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A6E5621F84B7 for ; Tue, 12 Mar 2013 08:29:21 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2FF948A031 for ; Tue, 12 Mar 2013 15:29:21 +0000 (UTC) Date: Tue, 12 Mar 2013 11:29:10 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130312152910.GF39238@mx1.yitter.info> References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <513F46F2.7030504@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:29:22 -0000 On Tue, Mar 12, 2013 at 11:17:06AM -0400, Peter Saint-Andre wrote: > As we discussed in the meeting, the question is where the pain of > conversion happens. It's not obvious to me (coming from the outside) > what exactly the user agents are in this architecture, and how smart > they could be about doing conversion (vs. leaving it up servers). But I > think I'll try to chat with you in person this week so I can understand > it better. You're quite right about this. Perhaps I could put it another way: if we insist that input is A-labels, then we need to specify something like what IDNA2008 did in handling input. I note the success of the IDNA mappings document in blunting the publication of UTS-46. A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Mar 12 08:37:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6021F8BF4 for ; Tue, 12 Mar 2013 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.732 X-Spam-Level: X-Spam-Status: No, score=-110.732 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sInfe10UlmZ0 for ; Tue, 12 Mar 2013 08:37:45 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55421F8C1A for ; Tue, 12 Mar 2013 08:37:45 -0700 (PDT) Received: (qmail 94200 invoked from network); 12 Mar 2013 15:37:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Mar 2013 15:37:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513f4bc8.xn--hew.k1303; i=johnl@user.iecc.com; bh=HV+SBy2n3/4KXzl9Q+1dpIyIbtgGj9A3+JJVlwbtc0Q=; b=anKDglmoYIooqewSCFrsq05ufEZdx3JHBoA9hj01XLz3YSEzOf+RgSWsovJ4+qFD2CnPXMRffYVGj2EQOWxKN9++o9foQfhbVD0LQNdTvMX8rSc/9irjQmYbDGcB7QKZA4sVWiBm2FGhCCLOuAzvECJ424BPEwLijEwt9tu3ji4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513f4bc8.xn--hew.k1303; olt=johnl@user.iecc.com; bh=HV+SBy2n3/4KXzl9Q+1dpIyIbtgGj9A3+JJVlwbtc0Q=; b=eMWyYrWq/NeK/0NS9G5fGAXnWwVIxCkZRQgi5T9GqDKnY48QOYMgAKAlp1Msj2sp6xn0t2pUj03YrEbLmGF/qBHLEpKEeGGDdLoVpMkBjOleq+oqoxjc+AwHVm+Vz0qUCk9d9MJorv+CGIPAM3fJ//HtrmEJuOPaZPvHCg6LCFw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Mar 2013 15:37:21 -0000 Message-ID: <20130312153721.31417.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:37:46 -0000 >one of the advantage of client-based processing is that the client will be able to reject >non-valid strings right away and give proper error to the user. That's not much of an advantage. If you want to sanity check your input and verify that a string is a U-label, you can do so whether or not you translate it to an A-label. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From zwnj.org@gmail.com Tue Mar 12 08:41:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2202621F8CA0 for ; Tue, 12 Mar 2013 08:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS0gShIVv1FA for ; Tue, 12 Mar 2013 08:41:28 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA21F21F8BD5 for ; Tue, 12 Mar 2013 08:41:27 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr12so6306518wgb.35 for ; Tue, 12 Mar 2013 08:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=yy9Tk0a32DvaXdyXPE7dfdnJjoS1F1a+waN6Fllrq0A=; b=vKXx70x0R5NemmukWWhUwsS6Vq6SD/ssQYN3tCDVvRxFqPH8ATbBQOIr6i3bAW7R8R zCNz7/4M7h79hAifOIx84SQP7eH/2sr+x7qeIpamOU2ux7Lr4yisGyVZVx4w/zDnjZCp Qq8uSBKV0XTsFRR5v3NRa7DIdLXa0wvMuB27yGRJ4kKwTulcvkKIQYe2jH/mQUn3tIDq 1mYyDfTzeKAhaYCopLpY+iA9qOloRmkG6LIMFL7eDD70pN3b+NOCw1v6+g3w3wasFgg6 r2R+JlAJS1L3jnuk5IvV/TAmZUHJ6L1ZLn/p8TzlVTVPCuxA2GdaHrXPcJbMo91j1OAz cESg== X-Received: by 10.194.62.170 with SMTP id z10mr27711386wjr.34.1363102887096; Tue, 12 Mar 2013 08:41:27 -0700 (PDT) MIME-Version: 1.0 Sender: zwnj.org@gmail.com Received: by 10.194.26.4 with HTTP; Tue, 12 Mar 2013 08:41:07 -0700 (PDT) In-Reply-To: <20130312150603.GC39238@mx1.yitter.info> References: <20130312150603.GC39238@mx1.yitter.info> From: Behnam Esfahbod Date: Tue, 12 Mar 2013 11:41:07 -0400 X-Google-Sender-Auth: Y4si2VRkXTi1zauC_6FeL2FmDeA Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7ba9830260bd1c04d7bc1f16 Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:51:17 -0000 --047d7ba9830260bd1c04d7bc1f16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 12, 2013 at 11:06 AM, Andrew Sullivan w= rote: > It is absurd to insist that queries be A-labels. First, A-labels and > U-labels are perfectly convertible to one another, and therefore there > is no reason to prefer one over the other. Second, nobody can use > A-labels, so we're just creating a user interface problem but > pretending we aren't. > +1 And also note that using U-labels would make the protocol transparent to IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 on the client side, using A-labels could be very destructive for IDNA2008 adaptation, IMHO. -Behnam --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --047d7ba9830260bd1c04d7bc1f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 12, 2013 at 11:06 AM, Andrew Sullivan &l= t;ajs@anvilwalr= usden.com> wrote:
It is absurd to insist that queries be A-labels. =C2=A0Fir= st, A-labels and
U-labels are perfectly convertible to one another, and therefore there
is no reason to prefer one over the other. =C2=A0Second, nobody can use
A-labels, so we're just creating a user interface problem but
pretending we aren't.

+1
=
And also note that using U-labels would make the protocol tr= ansparent to IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDN= A2008 on the client side, using A-labels could be very=C2=A0destructive for= IDNA2008=C2=A0adaptation, IMHO.

-Behnam

=C2=A0
-- =
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB= 9 7520 5701 CA40 259E 0F8B

--047d7ba9830260bd1c04d7bc1f16-- From marc.blanchet@viagenie.ca Tue Mar 12 08:54:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8932D21F8BCC for ; Tue, 12 Mar 2013 08:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVxlWVpOdSV1 for ; Tue, 12 Mar 2013 08:54:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD521F8BA1 for ; Tue, 12 Mar 2013 08:54:26 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8D7644034D; Tue, 12 Mar 2013 11:53:55 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <20130312152910.GF39238@mx1.yitter.info> Date: Tue, 12 Mar 2013 11:53:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> <20130312152910.GF39238@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:54:32 -0000 Le 2013-03-12 =E0 11:29, Andrew Sullivan a = =E9crit : > On Tue, Mar 12, 2013 at 11:17:06AM -0400, Peter Saint-Andre wrote: >> As we discussed in the meeting, the question is where the pain of >> conversion happens. It's not obvious to me (coming from the outside) >> what exactly the user agents are in this architecture, and how smart >> they could be about doing conversion (vs. leaving it up servers). But = I >> think I'll try to chat with you in person this week so I can = understand >> it better. >=20 > You're quite right about this. Perhaps I could put it another way: if > we insist that input is A-labels, then we need to specify something > like what IDNA2008 did in handling input. that is what I wrote (or at least intended to or try to) in my review = sent sometime ago. so I agree. Marc. > I note the success of the > IDNA mappings document in blunting the publication of UTS-46. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From marc.blanchet@viagenie.ca Tue Mar 12 09:05:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF611E80FB for ; Tue, 12 Mar 2013 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR4HlC-VhNoa for ; Tue, 12 Mar 2013 09:05:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48E1811E80E8 for ; Tue, 12 Mar 2013 09:05:02 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9A08C425ED; Tue, 12 Mar 2013 12:05:01 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <20130312153721.31417.qmail@joyce.lan> Date: Tue, 12 Mar 2013 12:05:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D22F77E-EBD4-474F-B1AD-413ACFF07166@viagenie.ca> References: <20130312153721.31417.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:05:07 -0000 Le 2013-03-12 =E0 11:37, "John Levine" a =E9crit : >> one of the advantage of client-based processing is that the client = will be able to reject >> non-valid strings right away and give proper error to the user. >=20 > That's not much of an advantage. If you want to sanity check your > input and verify that a string is a U-label, you can do so whether or > not you translate it to an A-label. let me try to be more precise on what I was trying to say (which was in = fact imprecise): a) we have various fields that are internationalized, not only domain = names b) because of a), we need to make some pre-processing steps. question is = where should we do them c) the end-users have various input methods, etc... d) so the client is doomed to "process" some of the = internationalization, including handling errors. e) because of b) and d), it seems to me that the client side should do = the work, as browsers are "doing" today for idn. client side pre-processing means roughly: - doing idna processing for domain names - doing precis-based processing for other i18n identifiers (and maybe something similar for search, depending on what we want to do = and the level of agility we want to put on the search) Marc. >=20 > --=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = http://jl.ly From johnl@taugh.com Tue Mar 12 09:14:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A21F21F8BE0 for ; Tue, 12 Mar 2013 09:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trKdvB0bS86y for ; Tue, 12 Mar 2013 09:14:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8A21F8BD7 for ; Tue, 12 Mar 2013 09:14:54 -0700 (PDT) Received: (qmail 4176 invoked from network); 12 Mar 2013 16:14:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=104f.513f547c.k1303; bh=vksHXK5fu5KuC69IVDJ3UHa7iFE8/4h88GMslEacIlk=; b=Rvq84iwbLYQWjsdifPROba25cAMEIidKygr/lTqc3SplTawyAJeBgPs4dGqjJG3kqwYxEfP5snnr9pOwNcnP4eLjtcDPOPiS5ksJOYeYVpR6M01Dufh9Amg5lYgMQjSaWxorf0qPpQ1eMwsfOjgHnIRFVVKSnbE3iBdzZlJLFHM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=104f.513f547c.k1303; bh=vksHXK5fu5KuC69IVDJ3UHa7iFE8/4h88GMslEacIlk=; b=dCkWZRke/83esyIZ7z6hvTy+iqfMIMigp82UT2WFsuGbs1VSG2jDWJDHv4Z0Og+v0CFpJCwzaDFCY3Msc1qjOb1FTg9E6+z5gtH+CAgt85Vb7nFd5FeGveSCDRuyeQLHvxnlgdMIw+wBppO+Y1megv7dwFj3RTLUHB72uM8MrVQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 12 Mar 2013 16:14:30 -0000 Date: 12 Mar 2013 12:14:51 -0400 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <6D22F77E-EBD4-474F-B1AD-413ACFF07166@viagenie.ca> References: <20130312153721.31417.qmail@joyce.lan> <6D22F77E-EBD4-474F-B1AD-413ACFF07166@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:14:55 -0000 > d) so the client is doomed to "process" some of the > internationalization, including handling errors. > e) because of b) and d), it seems to me that the client side should do > the work, as browsers are "doing" today for idn. Whether or not the client validates its input, servers also have to validate their input, because clients have bugs. It's not comparable to browser IDNA, because the whole point there is to allow existing DNS servers and caches with no knowledge of IDN to continue to work. WEIRDS servers know all about IDNs, so we might as well take advantage of that. Also, as came up at the session today, if you want to permit any sort of search or approximate matching, A-labels are hopeless. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From superuser@gmail.com Tue Mar 12 09:21:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEB721F8A6F for ; Tue, 12 Mar 2013 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os8SlN8+pXS6 for ; Tue, 12 Mar 2013 09:21:14 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id CC4EF21F8A5F for ; Tue, 12 Mar 2013 09:21:13 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id dr13so15225wgb.26 for ; Tue, 12 Mar 2013 09:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XnA6W/xAV3Es4pjBWJHgVcIQimN8ptR0M+z3Jbu6sG0=; b=hBEBCwrtpp8ylPryT2z7C5Ad8HJDHx9Pv1YAbnxluzZbI0n+U8E9xos4DHV9Ps7kQn jbjhFOLkIn2fTRmia6o4NF43s9myOh9eoxKeAf7/Pf3O35dVo5UwynPN/BRR1I3Kz5aq GHcnBtes8FFNqjNfxgPq/73WgRvGwmauNTWRqUvgezM8h0JNSXtgo/oQNjbLuETOlgLj 6wIIpqqY8FFNZGhzdNpvPnGkaDXhgGg7pA58XH/yxcvfJ/2Ulwmx9OILHpDgCfCS+FlB t2TU0dlDgHgUSD5QDfVS6RICa4pues8CHBnPNMzbDK8uDScfarISIGfh0uYqO3/848GJ 8geA== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr27996768wjc.35.1363105272982; Tue, 12 Mar 2013 09:21:12 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 09:21:12 -0700 (PDT) Date: Tue, 12 Mar 2013 12:21:12 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1da8967cfc04d7bcaddf Subject: [weirds] Slides updated X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:21:17 -0000 --089e013d1da8967cfc04d7bcaddf Content-Type: text/plain; charset=ISO-8859-1 I have uploaded the slide sets that were not available prior to today's session to the meeting materials tool: https://pub.ietf.org/proceedings/86/weirds/ -MSK --089e013d1da8967cfc04d7bcaddf Content-Type: text/html; charset=ISO-8859-1
I have uploaded the slide sets that were not available prior to today's session to the meeting materials tool:

https://pub.ietf.org/proceedings/86/weirds/

-MSK
--089e013d1da8967cfc04d7bcaddf-- From andy@arin.net Tue Mar 12 09:34:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C07E21F8CCA for ; Tue, 12 Mar 2013 09:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWJjsyVMNDLy for ; Tue, 12 Mar 2013 09:34:25 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4E21F8C93 for ; Tue, 12 Mar 2013 09:34:24 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 72485213688; Tue, 12 Mar 2013 12:34:24 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 2BEB32135C9; Tue, 12 Mar 2013 12:34:21 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 12:33:47 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 12:34:20 -0400 From: Andy Newton To: James Mitchell , "weirds@ietf.org" Thread-Topic: [weirds] observations so far.... Thread-Index: AQHOHvxjQzusUs1c3EKxuyxQ03FSIZiiDgyAgABIcwD///ssgA== Date: Tue, 12 Mar 2013 16:34:19 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2C05@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <064D1F599719854CA500961EF72450DA@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:34:25 -0000 James, On 3/12/13 9:51 AM, "James Mitchell" wrote: >2. The use of the sponsoredBy attribute is inconsistent with the use of >domain contacts; apparently both registrar and domain contacts are >entities however both are treated completely differently in the response. >I would expect registrars and domain contacts are either attributes of >domain objects (with full information either available inline or through >links) or the sponsoring registrar included in the entities section (both >illustrated below). I'm sitting on the fence for this one, perhaps leaning >towards an entities section. Regardless any method that allows me to >return only names and links would suffice. ..[snipped].. > >Example with entities: >{ >name:"abc.example", >=A9 >entities: >[ >{handle:"SponsorXYZ", name:"Registrar 123", role:"registrar", =A9}, >{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], >role:"registrant", =A9} >] >=A9 >} Yes, this is an inconsistency. And it doesn't just exist with sponsoredBy but also with lastChangedBy, registrationBy, and resoldBy. This convention comes out of the RIR way of doing things where the only information regarding these is either a NIC handle or email address. I think converting this into roles and modeling them as entities is more consistent with the rest of the model as long as we are willing to accept that the entities may be very sparse. As in: { "handle" : "ALN-ARIN", "roles" : "lastChangedBy" } Or=20 { "emails" : [ "andy@arin.net" ], "roles" : [ "lastChangedBy" ] } That last example will get more exciting when we transition to jCard. Either that or we accept the fact that in some registries the handle might be an email address (which I'm fine with as well). -andy From andy@arin.net Tue Mar 12 09:36:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BAE21F8C93 for ; Tue, 12 Mar 2013 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVD0EA0tqn84 for ; Tue, 12 Mar 2013 09:36:52 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0850911E80CC for ; Tue, 12 Mar 2013 09:36:52 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id AEBD0213688; Tue, 12 Mar 2013 12:36:21 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 4C3B32135C9; Tue, 12 Mar 2013 12:36:21 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 12:36:05 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 12:36:14 -0400 From: Andy Newton To: Ray Bellis , "weirds@ietf.org Group" Thread-Topic: [weirds] CORS and/or JSONP > Thread-Index: AQHOHzOCwoneGUbUSEiX91SCbOdOBJiiUcWA Date: Tue, 12 Mar 2013 16:36:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2C19@CHAXCH01.corp.arin.net> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE73105A9BC0@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <40A059CE00CB1440B87E26C0762DDA57@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] CORS and/or JSONP > X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:36:52 -0000 On 3/12/13 11:08 AM, "Ray Bellis" wrote: >To allow for an RDAP client to run in a browser, the "cross origin" >security features in the browser would require either: > >1. all requests go to the same server as the page was loaded from, or > >2. the server wraps the output with a JSONP callback, or > >3. the server sets a response header of "Access-Control-Allow-Origin: *" > >where IMHO the latter is preferred. > >Is this something that should be mentioned in the JSON response document? Are you suggesting some appendix material for browser-based client implementers? -andy From Ray.Bellis@nominet.org.uk Tue Mar 12 09:41:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143FF11E80D3 for ; Tue, 12 Mar 2013 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVPQGiJdNk9H for ; Tue, 12 Mar 2013 09:41:47 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEBB21F8C8C for ; Tue, 12 Mar 2013 09:41:46 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=JPxqVmSoh4oloU7hC87amNEx31hZYKQ+uuKUO8DoW40f6QLevO/zBom6 8h2JCwKggXqGLrXlqoqfmdkqBc77sKkxJ6oMroy6I9lALru/lVUZijrFo 0MJU1ZWu8CgjX0I; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1363106507; x=1394642507; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20CORS=20and/or=20JSONP=20> |Date:=20Tue,=2012=20Mar=202013=2016:41:44=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE73105AA608@ wds-exc1.okna.nominet.org.uk>|To:=20Andy=20Newton=20|CC:=20"weirds@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20qu oted-printable|Content-ID:=20|In-Reply-To:=20<62D9228640AC7F 49B2DD9ED0C9CE60E58BBF2C19@CHAXCH01.corp.arin.net> |References:=20<62D9228640AC7F49B2DD9ED0C9CE60E58BBF2C19@ CHAXCH01.corp.arin.net>; bh=2mqKBiWlD3VvB8rwWBWLe3GRQiZ7vwEGwugWqZX8KwQ=; b=T3X4xrZhz4XUJpCz0UT1fbEN4qnH+5yA6WBwNKz3PGffLi0rCo8ep5Cp 0EMG9fULOXzLw+HUyO7p8dqx++bMLi/7IY5GJ21/JaGGMKl47cM6PXeOX QazBuixT1O0o9q5; X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208";a="38933186" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 12 Mar 2013 16:41:45 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 16:41:45 +0000 From: Ray Bellis To: Andy Newton Thread-Topic: [weirds] CORS and/or JSONP > Thread-Index: AQHOHzOCwoneGUbUSEiX91SCbOdOBJiiUcWA///wyQA= Date: Tue, 12 Mar 2013 16:41:44 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73105AA608@wds-exc1.okna.nominet.org.uk> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2C19@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF2C19@CHAXCH01.corp.arin.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] CORS and/or JSONP > X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:41:48 -0000 On 12 Mar 2013, at 12:36, Andy Newton wrote: > Are you suggesting some appendix material for browser-based client > implementers? Actually the advice would need targeting at _server_ implementers, not clie= nts. I just tried APNIC's test RDAP server. Since it doesn't send the appropria= te header a browser-based client would refuse to accept the answers from it= . The alternative would be relaying everything through an RDAP broker, such t= hat the client only ever talks to the broker (which sets the relevant heade= r), and the broker does the real RDAP query. Ray From shollenbeck@verisign.com Tue Mar 12 10:39:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35DA11E809C for ; Tue, 12 Mar 2013 10:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwoOoAxBsGiP for ; Tue, 12 Mar 2013 10:38:58 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id CF16B21F85DB for ; Tue, 12 Mar 2013 10:38:53 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUT9oLdXF0xDgBKSsGVATuwWft7KgznuE@postini.com; Tue, 12 Mar 2013 10:38:57 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2CHcoBP002935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 13:38:50 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 13:38:49 -0400 From: "Hollenbeck, Scott" To: Marc Blanchet , Peter Saint-Andre Thread-Topic: [weirds] A-labels vs U-labels Thread-Index: AQHOHzMnRX8N9zndrUSnVDotpi2t5ZiibfgAgAABiQD//+G3kA== Date: Tue, 12 Mar 2013 17:38:49 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2432E2C7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> In-Reply-To: <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:39:07 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Tuesday, March 12, 2013 11:23 AM > To: Peter Saint-Andre > Cc: weirds@ietf.org > Subject: Re: [weirds] A-labels vs U-labels >=20 > Le 2013-03-12 =E0 11:17, Peter Saint-Andre a =E9crit= : >=20 > > On 3/12/13 11:06 AM, Andrew Sullivan wrote: > >> In the interests of time, I'll send this to the list. > >> > >> It is absurd to insist that queries be A-labels. First, A-labels > and > >> U-labels are perfectly convertible to one another, and therefore > >> there is no reason to prefer one over the other. Second, nobody can > >> use A-labels, so we're just creating a user interface problem but > >> pretending we aren't. > > > > Hi Andrew, > > > > As we discussed in the meeting, the question is where the pain of > > conversion happens. It's not obvious to me (coming from the outside) > > what exactly the user agents are in this architecture, and how smart > > they could be about doing conversion (vs. leaving it up servers). But > > I think I'll try to chat with you in person this week so I can > > understand it better. >=20 > one of the advantage of client-based processing is that the client will > be able to reject non-valid strings right away and give proper error to > the user. I concur with both of these points. The client implementation sits much clo= ser to the actual user. I'm not a fan of having to do a lot of input valida= tion on the server when it comes to doing lookups or searches because that = processing will place a load on the server that takes away from doing the a= ctual lookup/search work. Scott From ajs@anvilwalrusden.com Tue Mar 12 11:36:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDECB11E80F3 for ; Tue, 12 Mar 2013 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXDDaAhvDhZl for ; Tue, 12 Mar 2013 11:36:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1639721F8596 for ; Tue, 12 Mar 2013 11:36:13 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5FBD48A031 for ; Tue, 12 Mar 2013 18:36:08 +0000 (UTC) Date: Tue, 12 Mar 2013 14:35:38 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130312183537.GD39324@mx1.yitter.info> References: <20130312150603.GC39238@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:36:14 -0000 On Tue, Mar 12, 2013 at 11:41:07AM -0400, Behnam Esfahbod wrote: > And also note that using U-labels would make the protocol transparent to > IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 on the > client side, using A-labels could be very destructive for > IDNA2008 adaptation, IMHO. This is both true and false. For instance, a client might send a query for faß.de. Depending on what version of IDNA (and preprocessing) the server is operating, that either matches the domain "fass.de" or "faß.de" or, worst, {"fass.de","faß.de"}. I don't think U-labels get us out of that pain. A -- Andrew Sullivan ajs@anvilwalrusden.com From zwnj.org@gmail.com Tue Mar 12 12:03:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CF11E819F for ; Tue, 12 Mar 2013 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0-84XY7Yuc2 for ; Tue, 12 Mar 2013 12:03:07 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id B142B11E81C1 for ; Tue, 12 Mar 2013 12:03:03 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id es5so183803wgb.17 for ; Tue, 12 Mar 2013 12:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=SqqV8h3jfPZmQ6Rv5tfuwAuKKDVkEFtSNyhAfiPUS3o=; b=D71Crobo4IPG3dsH/nTl5AvDR3PzHdjKRLfMxUlfFMrhK0oHDqBXPEnphTHh4oGtv4 3fYUgT4Cm1scMtYfC0VjObM4oEH43sqLAfqMx+ykmB+qfsdADXMF63rmI/YpnQsi337e yW8IJpcXuEp6dnJca+KBk+8H0oApeUd0J0SfP8OrpZ2Y9W7BYgFlP8k0xjYdBhT9AXge cfL7MYX7VOecuBo8XexON/UhPcIwuWEJEWnwLq5cYMGlrTMlKnp+OWwkTzp6TlMZYYor cuUI6l0I/IdgD5ZhWMpzVaZNf9A7tyltNqv/0RjSKTubzQmzVVfwRtk9Y+7/se9zTLC5 lBVA== X-Received: by 10.194.5.4 with SMTP id o4mr29107476wjo.40.1363114982519; Tue, 12 Mar 2013 12:03:02 -0700 (PDT) MIME-Version: 1.0 Sender: zwnj.org@gmail.com Received: by 10.194.26.4 with HTTP; Tue, 12 Mar 2013 12:02:41 -0700 (PDT) In-Reply-To: <20130312183537.GD39324@mx1.yitter.info> References: <20130312150603.GC39238@mx1.yitter.info> <20130312183537.GD39324@mx1.yitter.info> From: Behnam Esfahbod Date: Tue, 12 Mar 2013 15:02:41 -0400 X-Google-Sender-Auth: pzQSjrkJ1Or_SQ3mTi1wLrBXHXQ Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b5d88ed52474804d7bef0c7 Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:03:08 -0000 --047d7b5d88ed52474804d7bef0c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right Andrew. That's exactly my point. Using U-label here doesn't get us out of the pain, but using A-label would add to the pain! ;) -Behnam On Tue, Mar 12, 2013 at 2:35 PM, Andrew Sullivan wr= ote: > On Tue, Mar 12, 2013 at 11:41:07AM -0400, Behnam Esfahbod wrote: > > And also note that using U-labels would make the protocol transparent t= o > > IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 on > the > > client side, using A-labels could be very destructive for > > IDNA2008 adaptation, IMHO. > > This is both true and false. > > For instance, a client might send a query for fa=C3=9F.de . > Depending on > what version of IDNA (and preprocessing) the server is operating, > that either matches the domain "fass.de" or "fa=C3=9F.de = " or, > worst, > {"fass.de","fa=C3=9F.de "}. I don't think U-labels get u= s out > of that pain. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --047d7b5d88ed52474804d7bef0c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right Andrew. That's exactly my point. Using U-label h= ere doesn't get us out of the pain, but using A-label would add to the = pain! ;)

-Behnam



On Tue, Mar 1= 2, 2013 at 2:35 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 12, 2013 at 11:41:07AM -040= 0, Behnam Esfahbod wrote:
> And also note that using U-labels would make the protocol transparent = to
> IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 on= the
> client side, using A-labels could be very destructive for
> IDNA2008 adaptation, IMHO.

This is both true and false.

For instance, a client might send a query for fa=C3=9F.de. =C2=A0Depending on
what version of IDNA (and preprocessing) the server is operating,
that either matches the domain "fass.de" or "fa=C3=9F.de" or, worst,
{"fass.de","= ;fa=C3=9F.de"}. =C2= =A0I don't think U-labels get us out of that pain.

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com
_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds



--
=
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8= =A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9= 7520 5701 CA40 259E 0F8B

--047d7b5d88ed52474804d7bef0c7-- From zwnj.org@gmail.com Tue Mar 12 12:11:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36FD11E817E for ; Tue, 12 Mar 2013 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isTKonbbbTZe for ; Tue, 12 Mar 2013 12:11:43 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id B59DE11E8178 for ; Tue, 12 Mar 2013 12:11:41 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hq4so163264wib.17 for ; Tue, 12 Mar 2013 12:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=drwFwsVKQzWR+GGlSTvHUdE3l8JNachIXz8djf7KFhE=; b=ximWNq7RrKmu62hjeofzwzHoYvILfQgR8hO+JamEPeJQzJnVvjCxcN/xW5nBO7pDQl //EXfw+oXhD8IoFcogs45/40EJcwBb0LVkyMqWFMB0TYYOTixxbZ/JEx+CoJi2CvgDiq rjYd8U1MuJgbTXP7cpRt8qCLRkz+qtDT+eynyyizQPDRZ4+IFOcUHhv0Z/TXw+0mtc58 AJYU0+jvW3NrYZ8Q3V8/rzHRxwLkHkheoE9G6MUrfKszCXjNLO7sVLMPAtsO0aMg3lff tXtW4IldfNW6B7G9/hHVaPDfAGGbmqIzL7EFiSo0csYyEhXfMkV8f2/DaYBZDucMmoeu aIsQ== X-Received: by 10.180.91.106 with SMTP id cd10mr22317801wib.6.1363115500713; Tue, 12 Mar 2013 12:11:40 -0700 (PDT) MIME-Version: 1.0 Sender: zwnj.org@gmail.com Received: by 10.194.26.4 with HTTP; Tue, 12 Mar 2013 12:11:20 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432E2C7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F2432E2C7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Behnam Esfahbod Date: Tue, 12 Mar 2013 15:11:20 -0400 X-Google-Sender-Auth: oLGSGIxQJo2CT7zl7PHTzdSqU5k Message-ID: To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=f46d043be11a3542d404d7bf0f7b Cc: "weirds@ietf.org" Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:11:44 -0000 --f46d043be11a3542d404d7bf0f7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Scott, > I concur with both of these points. The client implementation sits much > closer to the actual user. Why is that a concern? IDNA is an *encoding* and not a *policy*. > I'm not a fan of having to do a lot of input validation on the server whe= n > it comes to doing lookups or searches because that processing will place = a > load on the server that takes away from doing the actual lookup/search wo= rk. > Are you assuming A-labels are in some way more trustful than U-labels? If yes, why is that? -Behnam --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --f46d043be11a3542d404d7bf0f7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scott,

=C2=A0
I concur with both of these points. The client implementation s= its much closer to the actual user.

W= hy is that a concern? IDNA is an *encoding* and not a *policy*.

=C2=A0
I'm not a fa= n of having to do a lot of input validation on the server when it comes to = doing lookups or searches because that processing will place a load on the = server that takes away from doing the actual lookup/search work.

Are you assuming A-labels are in som= e way more trustful=C2=A0than U-labels? If yes, why is that?

=

-Behnam=C2=A0

=
--
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8= =A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4= C A8AB 9BB9 7520 5701 CA40 259E 0F8B

--f46d043be11a3542d404d7bf0f7b-- From shollenbeck@verisign.com Tue Mar 12 12:21:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAB711E8146 for ; Tue, 12 Mar 2013 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlh8+-s-JFK0 for ; Tue, 12 Mar 2013 12:21:36 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 0594A11E8123 for ; Tue, 12 Mar 2013 12:21:31 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUT+AOitCr68BRbJ4UZgYHS4wlOP3aR+P@postini.com; Tue, 12 Mar 2013 12:21:32 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2CJLRnb006381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 15:21:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 15:21:26 -0400 From: "Hollenbeck, Scott" To: Behnam Esfahbod Thread-Topic: [weirds] A-labels vs U-labels Thread-Index: AQHOH1VgP6ybWQrtZU+6YZXLSMXzS5iibJWA Date: Tue, 12 Mar 2013 19:21:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2432E474@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130312150603.GC39238@mx1.yitter.info> <513F46F2.7030504@stpeter.im> <51E943A1-EB02-445D-BFB4-1102084CF55C@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F2432E2C7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F2432E474BRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:21:38 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2432E474BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogenduai5vcmdAZ21haWwuY29tIFttYWlsdG86enduai5vcmdAZ21haWwuY29tXSBPbiBC ZWhhbGYgT2YgQmVobmFtIEVzZmFoYm9kDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyAz OjExIFBNDQpUbzogSG9sbGVuYmVjaywgU2NvdHQNCkNjOiBNYXJjIEJsYW5jaGV0OyBQZXRlciBT YWludC1BbmRyZTsgd2VpcmRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dlaXJkc10gQS1sYWJl bHMgdnMgVS1sYWJlbHMNCg0KU2NvdHQsDQoNCg0KSSBjb25jdXIgd2l0aCBib3RoIG9mIHRoZXNl IHBvaW50cy4gVGhlIGNsaWVudCBpbXBsZW1lbnRhdGlvbiBzaXRzIG11Y2ggY2xvc2VyIHRvIHRo ZSBhY3R1YWwgdXNlci4NCg0KV2h5IGlzIHRoYXQgYSBjb25jZXJuPyBJRE5BIGlzIGFuICplbmNv ZGluZyogYW5kIG5vdCBhICpwb2xpY3kqLg0KDQpbU0FIXSBUaGUgc29mdHdhcmUgY2xpZW50IGhh cyBhY2Nlc3MgdG8gdXNlciBlbnZpcm9ubWVudCBpbmZvcm1hdGlvbiB0aGF0IG1ha2VzIGl0IG11 Y2ggZWFzaWVyIGZvciBpdCAodGhlIGNsaWVudCkgdG8gZGVhbCB3aXRoIGVuY29kaW5nIGFuZCBk aXNwbGF5IGlzc3Vlcy4gSSB3YW50IHRoZSBwcm90b2NvbCBhbmQgY2VudHJhbGl6ZWQgc2VydmVy IGltcGxlbWVudGF0aW9uIHRvIGJlIGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4NCg0KSSdtIG5vdCBh IGZhbiBvZiBoYXZpbmcgdG8gZG8gYSBsb3Qgb2YgaW5wdXQgdmFsaWRhdGlvbiBvbiB0aGUgc2Vy dmVyIHdoZW4gaXQgY29tZXMgdG8gZG9pbmcgbG9va3VwcyBvciBzZWFyY2hlcyBiZWNhdXNlIHRo YXQgcHJvY2Vzc2luZyB3aWxsIHBsYWNlIGEgbG9hZCBvbiB0aGUgc2VydmVyIHRoYXQgdGFrZXMg YXdheSBmcm9tIGRvaW5nIHRoZSBhY3R1YWwgbG9va3VwL3NlYXJjaCB3b3JrLg0KDQpBcmUgeW91 IGFzc3VtaW5nIEEtbGFiZWxzIGFyZSBpbiBzb21lIHdheSBtb3JlIHRydXN0ZnVsIHRoYW4gVS1s YWJlbHM/IElmIHllcywgd2h5IGlzIHRoYXQ/DQoNCltTQUhdIFRoaXMgaXNu4oCZdCBhYm91dCB0 cnVzdCwgYnV0IHdpdGggYW4gQS1sYWJlbCBJIGRvbuKAmXQgaGF2ZSB0byBkbyBhZGRpdGlvbmFs IGRlY29kaW5nIHByb2Nlc3Npbmcgb24gdGhlIHNlcnZlci4gT24gYSBoaWdoIHZvbHVtZSBzZXJ2 ZXIgYWxsIG9mIHRoZSBleHRyYSBjeWNsZXMgYWRkIHVwLg0KDQpTY290dA0K --_000_831693C2CDA2E849A7D7A712B24E257F2432E474BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHp3bmoub3JnQGdtYWlsLmNvbSBbbWFpbHRvOnp3bmoub3JnQGdtYWlsLmNvbV0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+QmVobmFtIEVzZmFoYm9kPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1h cmNoIDEyLCAyMDEzIDM6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEhvbGxlbmJlY2ssIFNjb3R0PGJy Pg0KPGI+Q2M6PC9iPiBNYXJjIEJsYW5jaGV0OyBQZXRlciBTYWludC1BbmRyZTsgd2VpcmRzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbd2VpcmRzXSBBLWxhYmVscyB2cyBVLWxh YmVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TY290dCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNvbmN1ciB3aXRoIGJvdGggb2Yg dGhlc2UgcG9pbnRzLiBUaGUgY2xpZW50IGltcGxlbWVudGF0aW9uIHNpdHMgbXVjaCBjbG9zZXIg dG8gdGhlIGFjdHVhbCB1c2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGlzIHRoYXQgYSBjb25jZXJuPyBJRE5BIGlzIGFu ICplbmNvZGluZyogYW5kIG5vdCBhICpwb2xpY3kqLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBUaGUgc29mdHdhcmUgY2xp ZW50IGhhcyBhY2Nlc3MgdG8gdXNlciBlbnZpcm9ubWVudCBpbmZvcm1hdGlvbiB0aGF0IG1ha2Vz IGl0IG11Y2ggZWFzaWVyIGZvciBpdCAodGhlIGNsaWVudCkgdG8gZGVhbCB3aXRoIGVuY29kaW5n IGFuZCBkaXNwbGF5IGlzc3Vlcy4NCiBJIHdhbnQgdGhlIHByb3RvY29sIGFuZCBjZW50cmFsaXpl ZCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gdG8gYmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIG5vdCBhIGZhbiBvZiBoYXZpbmcgdG8gZG8gYSBsb3Qgb2YgaW5wdXQgdmFsaWRh dGlvbiBvbiB0aGUgc2VydmVyIHdoZW4gaXQgY29tZXMgdG8gZG9pbmcgbG9va3VwcyBvciBzZWFy Y2hlcyBiZWNhdXNlIHRoYXQgcHJvY2Vzc2luZyB3aWxsIHBsYWNlIGEgbG9hZCBvbiB0aGUgc2Vy dmVyIHRoYXQgdGFrZXMgYXdheSBmcm9tIGRvaW5nIHRoZSBhY3R1YWwgbG9va3VwL3NlYXJjaCB3 b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXJlIHlvdSBhc3N1bWluZyBBLWxhYmVscyBhcmUgaW4gc29tZSB3YXkgbW9yZSB0 cnVzdGZ1bCZuYnNwO3RoYW4gVS1sYWJlbHM/IElmIHllcywgd2h5IGlzIHRoYXQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTQUhd IFRoaXMgaXNu4oCZdCBhYm91dCB0cnVzdCwgYnV0IHdpdGggYW4gQS1sYWJlbCBJIGRvbuKAmXQg aGF2ZSB0byBkbyBhZGRpdGlvbmFsIGRlY29kaW5nIHByb2Nlc3Npbmcgb24gdGhlIHNlcnZlci4g T24gYSBoaWdoIHZvbHVtZSBzZXJ2ZXIgYWxsIG9mIHRoZSBleHRyYQ0KIGN5Y2xlcyBhZGQgdXAu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F2432E474BRN1WNEXMBX01vc_-- From superuser@gmail.com Tue Mar 12 14:51:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DCF21F89EE for ; Tue, 12 Mar 2013 14:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSRFX2ckotfg for ; Tue, 12 Mar 2013 14:51:08 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id B17D921F81FE for ; Tue, 12 Mar 2013 14:51:07 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi8so275664wib.13 for ; Tue, 12 Mar 2013 14:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=97wuM0UY6jvLy2YEPUM4GuyVm8YzhJTzvsSwtXK/298=; b=sAkLxO5a1+Np24NjxgHilaXBm1mxJeWoT+iUeMC98xzUL/9DE085OQbHnUGtpoHa4m CKPCZK1U6rg86LkRZn3aN9vQr9oc6KyT6eorbvPhwMsxPD89WRrwt7K7L0uL8PtVuIzM KS5LmSJ8xsXv9ICxbvdmY1c9lJChkI3sYdnw5LXoEo1+tfafMNm0apkZFRJ0UhbMJdrh T8Mggj16784/TQkcn17vPssHLm+GCflPd62ffM/Uq7+IckD0EXcfNVYMeG1KDOilaoLa 40YRuplA5QfKt53LTmWr+FlGEHlC9sOZnAIiBFBQuqhBOyNtqMM0te7zG0aliERY17UZ 0zqw== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr30046626wjc.39.1363125066931; Tue, 12 Mar 2013 14:51:06 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 14:51:06 -0700 (PDT) Date: Tue, 12 Mar 2013 17:51:06 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1f2866264b04d7c14975 Subject: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:51:08 -0000 --089e013d1f2866264b04d7c14975 Content-Type: text/plain; charset=ISO-8859-1 I didn't actually do a hum request in the session today, but there seemed to be warm fuzzies in the direction of combining the search drafts into a "basic" set of capabilities and an "extended" set. Does anyone disagree with that being a reasonable path forward? We can select editors and such after we figure out a path here. -MSK --089e013d1f2866264b04d7c14975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I didn't actually do a hum request in the session= today, but there seemed to be warm fuzzies in the direction of combining t= he search drafts into a "basic" set of capabilities and an "= extended" set.

Does anyone disagree with that being a reasonable path forward?=A0 We c= an select editors and such after we figure out a path here.

-MSK
--089e013d1f2866264b04d7c14975-- From bje@apnic.net Tue Mar 12 19:14:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12211E8114 for ; Tue, 12 Mar 2013 19:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsuQ4VowYhQH for ; Tue, 12 Mar 2013 19:14:41 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 3357211E8113 for ; Tue, 12 Mar 2013 19:14:40 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 13 Mar 2013 12:13:26 +1000 (EST) Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67%18]) with mapi id 14.01.0218.012; Wed, 13 Mar 2013 12:14:36 +1000 From: Byron Ellacott To: Ray Bellis , Andy Newton Thread-Topic: [weirds] CORS and/or JSONP > Thread-Index: AQHOHzOCwoneGUbUSEiX91SCbOdOBJiiUcWA///wyQCAAKAKAA== Date: Wed, 13 Mar 2013 02:14:35 +0000 Message-ID: In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE73105AA608@wds-exc1.okna.nominet.org.uk> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] CORS and/or JSONP > X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 02:14:42 -0000 Hi Ray, On 13/03/13 2:41 AM, "Ray Bellis" wrote: >I just tried APNIC's test RDAP server. Since it doesn't send the >appropriate header a browser-based client would refuse to accept the >answers from it. We're now sending "Access-Control-Allow-Origin: *" on 200, 404, and (catchable!) 500s. Does it look right to you? I prefer ACAO to JSONP for this, but I'm actually not sure on how widespread support for ACAO is. Byron From marc.blanchet@viagenie.ca Tue Mar 12 20:03:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD89D1F0D0E for ; Tue, 12 Mar 2013 20:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n+9SIncxvLc for ; Tue, 12 Mar 2013 20:03:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3381F0C36 for ; Tue, 12 Mar 2013 20:03:25 -0700 (PDT) Received: from dhcp-46f6.meeting.ietf.org (dhcp-46f6.meeting.ietf.org [130.129.70.246]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 63ED040391; Tue, 12 Mar 2013 23:02:54 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: Date: Tue, 12 Mar 2013 23:02:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65FBD2C6-A7E9-4EAB-88E0-6F7611732B48@viagenie.ca> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 03:03:33 -0000 Le 2013-03-12 =E0 17:51, "Murray S. Kucherawy" a = =E9crit : > I didn't actually do a hum request in the session today, but there = seemed to be warm fuzzies in the direction of combining the search = drafts into a "basic" set of capabilities and an "extended" set. >=20 > Does anyone disagree with that being a reasonable path forward?=20 My take is that we already have the "weirds" specification into many = drafts, so one draft about search is more than enough. It is within that = draft that I would see MUST, SHOULD, MAY for any search feature that is = agreeable right now: i.e. the basic which would be either MUST or SHOULD = and some common optional that would be MAY. Anything optional that does = not reach concensus would be put aside for an "extension" draft, where = the base draft will sketch how extensions should be done. > We can select editors and such after we figure out a path here. happy to help in editing/reviewing/... Marc. >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Tue Mar 12 20:59:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF9621F8C9A for ; Tue, 12 Mar 2013 20:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.826 X-Spam-Level: X-Spam-Status: No, score=-110.826 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mIc8jEhElHy for ; Tue, 12 Mar 2013 20:59:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0870E21F8C77 for ; Tue, 12 Mar 2013 20:59:43 -0700 (PDT) Received: (qmail 89645 invoked from network); 13 Mar 2013 03:59:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 03:59:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513ff9ad.xn--hew.k1303; i=johnl@user.iecc.com; bh=2AjE19mUapgx8e4vMqkXwCtlVvb4WmV90HEtnw0Bkl4=; b=pCAmi5H+V3NCgwU0CHUA1foc7fRd6GpyezlJ4iOaSr9J/Ivt8/1y4nl6/dAk1z+X2epbFprXlLtiCYXUW5HL004zzHPf5dhduWqueS/5+YpphAq+tgT34Iek04fd5mOqJsnt0GW7lU3XlDXgSe/9LzZ1OHIdxtJzp4ToI8rD1cM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513ff9ad.xn--hew.k1303; olt=johnl@user.iecc.com; bh=2AjE19mUapgx8e4vMqkXwCtlVvb4WmV90HEtnw0Bkl4=; b=otelqTWIqNOSpX9H0nxUJX9AYv32LKgHnLp14aLmKdjVcmYUdC1emsmUJFw8/vF/IJuym3HJT9h6x1jg+ebrnsyV7dMlFX1Vkg2UEK5jCa9IPy5Kw6clbUFVTr/6euBa+2vCFFX3/4VIh4tHMY2zwGJAULgoCGMdxwxmeWQRbZs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 03:59:18 -0000 Message-ID: <20130313035918.44991.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 03:59:44 -0000 >I didn't actually do a hum request in the session today, but there seemed >to be warm fuzzies in the direction of combining the search drafts into a >"basic" set of capabilities and an "extended" set. With the understanding that each set is standardized, and we do not expect each registry to go inventing its own mutant search, I agree. A quick look suggests that the range of search supported by current registries is semantically quite small, although there are a lot of different ways that people spell a wildcard. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From shollenbeck@verisign.com Wed Mar 13 04:01:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4829A21F8DDC for ; Wed, 13 Mar 2013 04:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gliHzoJmxKaJ for ; Wed, 13 Mar 2013 04:01:57 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 631E221F8DDB for ; Wed, 13 Mar 2013 04:01:55 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUUBcooSQwDbdRj6klucWSQYnx4L9VEmF@postini.com; Wed, 13 Mar 2013 04:01:56 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2DB1pJJ026874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 07:01:51 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 07:01:51 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Search documents Thread-Index: AQHOH2u3wg4EGP5QYEKUv0Bgfp2UsJijdS1Q Date: Wed, 13 Mar 2013 11:01:51 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2432E698@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F2432E698BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 11:01:58 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2432E698BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since I presented that proposal I'm going to confirm support for it. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, March 12, 2013 5:51 PM To: weirds@ietf.org Subject: [weirds] Search documents I didn't actually do a hum request in the session today, but there seemed t= o be warm fuzzies in the direction of combining the search drafts into a "b= asic" set of capabilities and an "extended" set. Does anyone disagree with that being a reasonable path forward? We can sel= ect editors and such after we figure out a path here. -MSK --_000_831693C2CDA2E849A7D7A712B24E257F2432E698BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since I presented that pr= oposal I’m going to confirm support for it.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, March 12, 2013 5:51 PM
To: weirds@ietf.org
Subject: [weirds] Search documents

 

I didn't actually do = a hum request in the session today, but there seemed to be warm fuzzies in = the direction of combining the search drafts into a "basic" set o= f capabilities and an "extended" set.

Does anyone disagree with that being a reasonable path forward?  We ca= n select editors and such after we figure out a path here.

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F2432E698BRN1WNEXMBX01vc_-- From Ray.Bellis@nominet.org.uk Wed Mar 13 05:06:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3D21F8D64 for ; Wed, 13 Mar 2013 05:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo3lQWiZYEbn for ; Wed, 13 Mar 2013 05:06:38 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5A21F8D62 for ; Wed, 13 Mar 2013 05:06:36 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=sdGLKfABnc8id9tU9ogyc9/wA+sEQBkCRKZumH0+QWTa9hO43Ij5hI/F NAlaGZB+6Fu2b9brJcA666WLjSwvcjElwHcc4Oy7PnVLYOMJ60Kkqy1pG ZtEwb+pSyE1Ng4d; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1363176398; x=1394712398; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20CORS=20and/or=20JSONP=20> |Date:=20Wed,=2013=20Mar=202013=2012:06:34=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE73105ABF5C@ wds-exc1.okna.nominet.org.uk>|To:=20Byron=20Ellacott=20|CC:=20Andy=20Newton=20,=20"w eirds@ietf.org=20Group"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<435BD47E1CC90A4583C5C6AFFBEB00BC@okna.nom inet.org.uk>|In-Reply-To:=20|References:=20; bh=wOXz7zpmYd5BlGLKmV/O5H6cvGEAr6jmCEoK1qmIT6o=; b=gcxJJsjSztUt1ewkLyqJLHXy0XucTRyXMcpNTqQ2rxhXznJ7QxGEz2hB BGx8WrIV0sZPUWd/nRUpdpDvBTav2QCBgJdoyhTfM3y5mvyzWyoRRxKzX DKBzN8oLvhfU19B; X-IronPort-AV: E=Sophos;i="4.84,836,1355097600"; d="scan'208";a="47125744" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 13 Mar 2013 12:06:35 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 12:06:35 +0000 From: Ray Bellis To: Byron Ellacott Thread-Topic: [weirds] CORS and/or JSONP > Thread-Index: AQHOHzOCwoneGUbUSEiX91SCbOdOBJiiUcWA///wyQCAAKAKAIAApWuA Date: Wed, 13 Mar 2013 12:06:34 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73105ABF5C@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <435BD47E1CC90A4583C5C6AFFBEB00BC@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] CORS and/or JSONP > X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 12:06:40 -0000 On 12 Mar 2013, at 22:14, Byron Ellacott wrote: > Hi Ray, >=20 > We're now sending "Access-Control-Allow-Origin: *" on 200, 404, and > (catchable!) 500s. Does it look right to you? Yes, thanks, it does! > I prefer ACAO to JSONP for this, but I'm actually not sure on how > widespread support for ACAO is. Me neither - ACAO is definitely superior though. Ray From nkong@cnnic.cn Wed Mar 13 05:32:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B66A21F85D9 for ; Wed, 13 Mar 2013 05:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWHpN+iTd5Qn for ; Wed, 13 Mar 2013 05:32:37 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 138BB21F8D1B for ; Wed, 13 Mar 2013 05:32:35 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.254.44]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 13 Mar 2013 20:32:23 +0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_033578B8-84CD-4BFB-9F65-D0DEE5D26D22" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432E698@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 13 Mar 2013 08:32:19 -0400 Message-Id: <3273F9CE-369C-46CA-89EF-1669C8BF0BB8@cnnic.cn> References: <831693C2CDA2E849A7D7A712B24E257F2432E698@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 12:32:38 -0000 --Apple-Mail=_033578B8-84CD-4BFB-9F65-D0DEE5D26D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shuo Shen and I would also like to contribute to this work. Cheers, Ning =E5=9C=A8 2013-3-13=EF=BC=8C=E4=B8=8A=E5=8D=887:01=EF=BC=8C"Hollenbeck, = Scott" =E5=86=99=E9=81=93=EF=BC=9A > Since I presented that proposal I=E2=80=99m going to confirm support = for it. > =20 > Scott > =20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf Of Murray S. Kucherawy > Sent: Tuesday, March 12, 2013 5:51 PM > To: weirds@ietf.org > Subject: [weirds] Search documents > =20 > I didn't actually do a hum request in the session today, but there = seemed to be warm fuzzies in the direction of combining the search = drafts into a "basic" set of capabilities and an "extended" set. >=20 > Does anyone disagree with that being a reasonable path forward? We = can select editors and such after we figure out a path here. >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_033578B8-84CD-4BFB-9F65-D0DEE5D26D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Shuo Shen = and I would also like to contribute to this = work.

Cheers,
Ning

=E5= =9C=A8 2013-3-13=EF=BC=8C=E4=B8=8A=E5=8D=887:01=EF=BC=8C"Hollenbeck, = Scott" <shollenbeck@verisign.com> = =E5=86=99=E9=81=93=EF=BC=9A

Since I presented that = proposal I=E2=80=99m going to confirm support for = it.
 
Scott
 
From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Tuesday, March 12, 2013 = 5:51 PM
To:  [weirds] Search = documents

Does anyone disagree with that being a reasonable path = forward?  We can select editors and such after we figure out a path = here.

weirds@ietf.org

= --Apple-Mail=_033578B8-84CD-4BFB-9F65-D0DEE5D26D22-- From shollenbeck@verisign.com Wed Mar 13 09:29:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F42921F8C85 for ; Wed, 13 Mar 2013 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsIB37rnYx4j for ; Wed, 13 Mar 2013 09:29:52 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 97ADE21F8AE3 for ; Wed, 13 Mar 2013 09:29:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUUCpf26EM0UnbPA11v6c4WcV1tKQi/Ip@postini.com; Wed, 13 Mar 2013 09:29:51 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2DGTmRM013509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Mar 2013 12:29:50 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 12:29:47 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: A-label and U-label Lookups Thread-Index: Ac4gA2aiGphfya3nQ7SfHT4gSamQnw== Date: Wed, 13 Mar 2013 16:29:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:29:53 -0000 While on the way home last night I had an interesting conversation with one= of my colleagues while we were waiting for our flights at the airport. He = asked me a question about IDNs that made me think. Imagine a web browser being used as an RDAP client. A human user types a UR= L that looks like this in the address bar: http://example.com/domain/ex=E4mple.com If we require the client to convert the domain name into a-label form, the = browser is going to have to parse and process the path portion of the URL t= o convert /domain/ex=E4mple.com to /domain/xn--exmple-cua.com). That means = "browser mods needed", which may be an impediment to adoption. As I slept on this last night I kept hearing "be liberal in what you accept= ". That's making me think twice about a-labels only. Supporting U-labels fo= r lookups would mean more work for DNR server operators, but it may be work= that's worth the price if it truly helps the adoption process. So should the query/lookup draft include support for both a-labels and u-la= bels? I'm seriously thinking it should. Scott From fobispo@isc.org Wed Mar 13 09:36:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672D21F8DDE for ; Wed, 13 Mar 2013 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSkWJEwLdPDU for ; Wed, 13 Mar 2013 09:36:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABBD21F8DDB for ; Wed, 13 Mar 2013 09:36:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1CC48C9476; Wed, 13 Mar 2013 16:36:46 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363192614; bh=/Jl/7+zGkKr+zlFJ6ePihEkZAhvsYX7yXGmtHNBXWS0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WGHm2U8F8y/hHlQKyGoTr7faPxDOmbJ3w31/Wzsi0axDh36JFagMmILc9O23Mo1sH p45/WwjaaOnxtKyECjbkVfjzTsJlx8M0JyzfJZA8IROVhPixQZpMj3qgvKH98OlKbw nwvz414vmueBTGsNkJLPtmBgPrd9mRvraaeMpZpM= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 16:36:46 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D6B12216C40; Wed, 13 Mar 2013 16:36:45 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 13 Mar 2013 09:36:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: "weirds@ietf.org" Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:36:56 -0000 Yes, My opinion is that we should be able to take both a-labels and u-labels. (in fact that's how I'm implementing ours). On Mar 13, 2013, at 9:29 AM, "Hollenbeck, Scott" = wrote: > If we require the client to convert the domain name into a-label form, = the browser is going to have to parse and process the path portion of = the URL to convert /domain/ex=E4mple.com to /domain/xn--exmple-cua.com). = That means "browser mods needed", which may be an impediment to = adoption. >=20 > As I slept on this last night I kept hearing "be liberal in what you = accept". That's making me think twice about a-labels only. Supporting = U-labels for lookups would mean more work for DNR server operators, but = it may be work that's worth the price if it truly helps the adoption = process. >=20 > So should the query/lookup draft include support for both a-labels and = u-labels? I'm seriously thinking it should. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From steve.sheng@icann.org Wed Mar 13 09:49:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDE521F8D6E for ; Wed, 13 Mar 2013 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA58Z9uPg2Lf for ; Wed, 13 Mar 2013 09:49:10 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id AA8A421F8D11 for ; Wed, 13 Mar 2013 09:49:10 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 13 Mar 2013 09:49:09 -0700 From: Steve Sheng To: "Hollenbeck, Scott" , "weirds@ietf.org" Date: Wed, 13 Mar 2013 09:49:07 -0700 Thread-Topic: [weirds] A-label and U-label Lookups Thread-Index: Ac4gCq6LOkWcy+NwTl+Rpo7Swa4sBg== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3446023747_559896" MIME-Version: 1.0 Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:49:11 -0000 --B_3446023747_559896 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 to this on accepting both U-label and A-label. As an end user, I think this a perfectly valid use case. Kind regards,=20 Steve -----Original Message----- From: , Scott Date: Wednesday, March 13, 2013 12:29 PM To: "weirds@ietf.org" Subject: [weirds] A-label and U-label Lookups >While on the way home last night I had an interesting conversation with >one of my colleagues while we were waiting for our flights at the >airport. He asked me a question about IDNs that made me think. > >Imagine a web browser being used as an RDAP client. A human user types a >URL that looks like this in the address bar: > >http://example.com/domain/ex=E4mple.com > >If we require the client to convert the domain name into a-label form, >the browser is going to have to parse and process the path portion of the >URL to convert /domain/ex=E4mple.com to /domain/xn--exmple-cua.com). That >means "browser mods needed", which may be an impediment to adoption. > >As I slept on this last night I kept hearing "be liberal in what you >accept". That's making me think twice about a-labels only. Supporting >U-labels for lookups would mean more work for DNR server operators, but >it may be work that's worth the price if it truly helps the adoption >process. > >So should the query/lookup draft include support for both a-labels and >u-labels? I'm seriously thinking it should. > >Scott >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds --B_3446023747_559896 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEXMnkmDfwMbQBs4/KjggpGK0cOBMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMzE2NDkwN1owDQYJ KoZIhvcNAQEBBQAEggEAS4S3TpWBMoJqLxGC31I8wOlhoLp1UBxHi1VkB2KC89f0qQ8Qs40N uMqDprutxrc2yOHf6tdtjSOPCV3KgSBA1exQ+OHd8cd3YNoXsn/8ZUPNpUWjUUntz9XdFQCz qAXkaguUaTNQQoUoi3kNeViDhwGnDko7ulYdLQRXC6CZKCNpx2WhQ05RXL+/0QVILm+3cQh8 rJowUXVNMkR1BFwm0hLggUzhmUsLNwu01dXH1lY6TGl7vOG1MObdYboPU4IXJIP2tCssY9If K1PrAdTkJ/WJVtPc7D5czIYhoIdVDMwiP4oaOt5wHMKzrwVdTuEUmHDnrwkhYv6spqKdq1xd zQ== --B_3446023747_559896-- From andy@arin.net Wed Mar 13 09:54:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21321F87CC for ; Wed, 13 Mar 2013 09:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwxT8biXFvhZ for ; Wed, 13 Mar 2013 09:54:51 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5421F8735 for ; Wed, 13 Mar 2013 09:54:49 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 385DB16520A; Wed, 13 Mar 2013 12:54:49 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id C3209165207 for ; Wed, 13 Mar 2013 12:54:48 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 12:54:34 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 12:54:47 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+Fbuuzrqg== Date: Wed, 13 Mar 2013 16:54:46 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <1432B5F03E43B4479C25B761DA12B1BC@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:54:55 -0000 I was asked during the session on Tuesday to send to the list a revamped remarks structure. After looking at the draft, I think it should follow the same pattern as the notices structure. It should also be noted that the remarks section can be used to solve the problem mentioned by Chris Wright and James Mitchell. Here's an example: { "remarks": [ { "title": "Unverified Contact", "description": [ "Lunar NIC has attempted to verify the data for this contact, but has received no response from the POC since 2010-07-28.", "See Lunar NIC policy 2010-XXX." ] }, { "title": "Rights of Use Claim", "description" : [ "The following information provides the rights of use information for this internet resource.", "Eligibility Type: Company", "Eligibility Name: Acme Widgets", "Eligibility ID: BN955912" ] } ] } A text based client MIGHT render this as Unverified ---------- Lunar NIC has attempted to verify the data for this contact, but has received no response from the POC since 2010-07-28. See Lunar NIC policy 2010-XXX. Rights of Use Claim ------------------- The following information provides the rights of use information for this internet resource. Eligibility Type: Company Eligibility Name: Acme Widgets Eligibility ID: BN955912 I don't think we should encourage formatting characters such as newlines in the text as that is a rendering issue and the client knows best how to render the data. -andy From shollenbeck@verisign.com Wed Mar 13 09:57:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC6C21F87D0 for ; Wed, 13 Mar 2013 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ObCB+u9QyHe for ; Wed, 13 Mar 2013 09:57:52 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5821F8623 for ; Wed, 13 Mar 2013 09:57:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUUCwDYS1cAtyv61K0D5eyZsn7rAQ2/yk@postini.com; Wed, 13 Mar 2013 09:57:51 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2DGvn6T014374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 12:57:49 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 12:57:48 -0400 From: "Hollenbeck, Scott" To: Andy Newton , "weirds@ietf.org" Thread-Topic: remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+Fbuuzrqpij13Lg Date: Wed, 13 Mar 2013 16:57:48 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2432F16A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:57:53 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Andy Newton > Sent: Wednesday, March 13, 2013 12:55 PM > To: weirds@ietf.org > Subject: [weirds] remarks and client handling of free form data >=20 > I was asked during the session on Tuesday to send to the list a > revamped remarks structure. After looking at the draft, I think it > should follow the same pattern as the notices structure. It should also > be noted that the remarks section can be used to solve the problem > mentioned by Chris Wright and James Mitchell. Here's an example: I like this approach, and consistency is a good thing. Scott From andy@arin.net Wed Mar 13 10:00:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9A321F8CB1 for ; Wed, 13 Mar 2013 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjlBTfgn9snM for ; Wed, 13 Mar 2013 10:00:44 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5321F8CAE for ; Wed, 13 Mar 2013 10:00:44 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 298A4165210; Wed, 13 Mar 2013 13:00:44 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id DD1231651E4 for ; Wed, 13 Mar 2013 13:00:43 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 13:00:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 13:00:40 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: a-labels and u-labels in json response Thread-Index: AQHOIAxKYblC5qdk5UWFQVsDtxfqiw== Date: Wed, 13 Mar 2013 17:00:39 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:00:45 -0000 Accepting u-labels is only half of the equation. What do people want to do with the json-response? Is it it acceptable to say that domain names in the response are always a-labels? Or is a better approach to say that if the name of the domain object is a U-label, then the server SHOULD provide a variants section and those MUST be a-labels? Opinions? -andy From fobispo@isc.org Wed Mar 13 10:02:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5821F8E13 for ; Wed, 13 Mar 2013 10:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghaUZVcateQv for ; Wed, 13 Mar 2013 10:02:16 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DA59421F8E12 for ; Wed, 13 Mar 2013 10:02:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id ADC9B5F9904; Wed, 13 Mar 2013 17:02:05 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363194135; bh=gcCGKrFrqufyFdR0FsCRZ7lXNlwA9CztV5p9s95qxhM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZFnHxnQm7lOGC1VevYYzmBRstDHJBs40eI0eoBOjDy2cInLiQyFN8lSfJMzXdpvSY YOhuxncGVzJbP5IHQGEJBfzg/z5g5/ng66TaNM8RE2JALPXfTSNcfVKIg7/Qy5Vr3w 5m8KoyFK0ToTAqgbEY8WDBt6h8p65MZR2DuQ0K7w= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 39183216C40; Wed, 13 Mar 2013 17:02:04 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> Date: Wed, 13 Mar 2013 10:02:05 -0700 Content-Transfer-Encoding: 7bit Message-Id: <93990F32-437F-4F93-9C21-E6900473C9B1@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:02:16 -0000 We should include both, in different fields. On Mar 13, 2013, at 10:00 AM, Andy Newton wrote: > Accepting u-labels is only half of the equation. What do people want to do > with the json-response? > > Is it it acceptable to say that domain names in the response are always > a-labels? Or is a better approach to say that if the name of the domain > object is a U-label, then the server SHOULD provide a variants section and > those MUST be a-labels? > > Opinions? > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE From behnam@gmail.com Wed Mar 13 10:44:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC43121F8712 for ; Wed, 13 Mar 2013 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3VkErmFI0C7 for ; Wed, 13 Mar 2013 10:44:01 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5221F8D8E for ; Wed, 13 Mar 2013 10:44:01 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id un15so1258797pbc.38 for ; Wed, 13 Mar 2013 10:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/d3HymDq+FGI3BwXSUhc6pl2mCHlOu1LO4ZNvpCAJ00=; b=E0nXqHIMg0C6pdE9gm7Sno8OU6Fzgbb8q952eFm41TBX1lGEZoaofdB0H4vTAjyPlI yahxIPwcD8X5mlUfmpXJuSczOmpwVnZmTIN1P31HqAnokubCvlm1Xu9bpg3H0I4lTgUN T9Yke0tcN5WS8Y0p371waoeCpKkhvyMBbPG8M2EQ5Kdh1LujTz/9Od41mzHi9acpq0Qq FQZG6/CquihnY/s2o6zqRIaau+Cz1Ee+BXZUMGWsk8/I4PwHSi872BoFi401qABVOMH6 /6RVzK6ibTkH4asRFduRrV/JiOE3DGPzDWETMZlDx4pIVZasfL5z+raamF/g2HChEx1l bjCw== X-Received: by 10.68.87.129 with SMTP id ay1mr16921449pbb.105.1363196641456; Wed, 13 Mar 2013 10:44:01 -0700 (PDT) MIME-Version: 1.0 Sender: behnam@gmail.com Received: by 10.68.223.129 with HTTP; Wed, 13 Mar 2013 10:43:21 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> From: Behnam Esfahbod Date: Wed, 13 Mar 2013 13:43:21 -0400 X-Google-Sender-Auth: sL6E5fzoN3hP8WVyUgi71YZKvMQ Message-ID: To: Andy Newton Content-Type: multipart/alternative; boundary=047d7b676b6293716404d7d1f3e3 Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:44:03 -0000 --047d7b676b6293716404d7d1f3e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy, Please don't ever do that! At IRNIC, we did a similar thing -- showing U-label of the requested domain and A-labels of the variants -- in our EPP extension and soon we realized it's very confusing for our clients (resellers/registrars). IMHO we need both of them everywhere, as the output is supposed to be understandable by end-users, whether they understand the script of the domain name or not. -Behnam On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton wrote: > Accepting u-labels is only half of the equation. What do people want to d= o > with the json-response? > > Is it it acceptable to say that domain names in the response are always > a-labels? Or is a better approach to say that if the name of the domain > object is a U-label, then the server SHOULD provide a variants section an= d > those MUST be a-labels? > > Opinions? > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8= =AF ' Behnam Esfahbod ' * .. http://behnam.esfahbod.info * ` * http://zwnj.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --047d7b676b6293716404d7d1f3e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,
Please d= on't ever do that! At IRNIC, we did a similar thing -- showing U-label = of the requested domain and A-labels of the variants -- in our EPP extensio= n and soon we realized it's very confusing for our clients (resellers/r= egistrars).

IMHO we need both of t= hem everywhere, as the output is supposed to be understandable by end-users= , whether they understand the script of the domain name or not.

-Behnam


On Wed, Mar 13, = 2013 at 1:00 PM, Andy Newton <andy@arin.net> wrote:
Accepting u-labels is only half of the equat= ion. What do people want to do
with the json-response?

Is it it acceptable to say that domain names in the response are always
a-labels? Or is a better approach to say that if the name of the domain
object is a U-label, then the server SHOULD provide a variants section and<= br> those MUST be a-labels?

Opinions?

-andy

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds



--
=C2=A0=C2=A0= =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3= =D9=81=D9=87=D8=A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0 =C2=A0=C2=A0 Behnam E= sfahbod
=C2=A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0
=C2=A0 *=C2=A0 ..=C2= =A0=C2=A0 http://= behnam.esfahbod.info
=C2=A0*=C2=A0 `=C2=A0 *=C2=A0 http://zwnj.org
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7= 520 5701 CA40 259E 0F8B
--047d7b676b6293716404d7d1f3e3-- From superuser@gmail.com Wed Mar 13 11:11:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC39521F8E76 for ; Wed, 13 Mar 2013 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO-1DMBMXqSV for ; Wed, 13 Mar 2013 11:11:37 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D339B21F8E0B for ; Wed, 13 Mar 2013 11:11:36 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so1057270wib.10 for ; Wed, 13 Mar 2013 11:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dbXf92Cn6PfBsak5H07LQfCvzFlBlxnXRO1ZCqx6pdE=; b=DsMP0cj2HyfUVhOZ+xo4fuGZJ+s/kYJPUoLCjuKgT2ybvMHMvW8HJDbye+TMLr3naF 3k2aJJHxd73uiFS7NQNnCIuoiG/fD27JnFHvSa/+kQAyGvYF18T55hGKVgw9aKtocZfY 28yY1U9XvhtzXLoXnogNic+6oeGyEgxGZvF8VyotLRCfGw4RPeeD+qvv4hzhB11vtLhf LlqfyLAzdxki9bDoNBzR5rsYhRmukAisRUe51xDxyjXaKBK5tJZsj+RUnZB+3uhYbdht /0Nnrrj9I7Wx2+uf4ql3/FPhYufVry/Je7RrggpoHimC7EguVJG/4SGiVU1f9qJ30Epz 4BGA== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr28940001wiy.5.1363198296019; Wed, 13 Mar 2013 11:11:36 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Wed, 13 Mar 2013 11:11:35 -0700 (PDT) In-Reply-To: <65FBD2C6-A7E9-4EAB-88E0-6F7611732B48@viagenie.ca> References: <65FBD2C6-A7E9-4EAB-88E0-6F7611732B48@viagenie.ca> Date: Wed, 13 Mar 2013 14:11:35 -0400 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=f46d04428eb6315c6104d7d2561b Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:11:38 -0000 --f46d04428eb6315c6104d7d2561b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any other opinions on this? I think the answer here depends on how big a unified (core plus extensions) search document would be. On Tue, Mar 12, 2013 at 11:02 PM, Marc Blanchet wrote: > > Le 2013-03-12 =E0 17:51, "Murray S. Kucherawy" a > =E9crit : > > > I didn't actually do a hum request in the session today, but there > seemed to be warm fuzzies in the direction of combining the search drafts > into a "basic" set of capabilities and an "extended" set. > > > > Does anyone disagree with that being a reasonable path forward? > > My take is that we already have the "weirds" specification into many > drafts, so one draft about search is more than enough. It is within that > draft that I would see MUST, SHOULD, MAY for any search feature that is > agreeable right now: i.e. the basic which would be either MUST or SHOULD > and some common optional that would be MAY. Anything optional that does n= ot > reach concensus would be put aside for an "extension" draft, where the ba= se > draft will sketch how extensions should be done. > > > We can select editors and such after we figure out a path here. > > happy to help in editing/reviewing/... > > Marc. > > > > > -MSK > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > --f46d04428eb6315c6104d7d2561b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Any other opinions on this?=A0 I think the answer here dep= ends on how big a unified (core plus extensions) search document would be.<= br>


On T= ue, Mar 12, 2013 at 11:02 PM, Marc Blanchet <marc.blanchet@viage= nie.ca> wrote:

Le 2013-03-12 =E0 17:51, "Murray S. Kucherawy" <superuser@gmail.com> a =E9crit :

> I didn't actually do a hum request in the session today, but there= seemed to be warm fuzzies in the direction of combining the search drafts = into a "basic" set of capabilities and an "extended" se= t.
>
> Does anyone disagree with that being a reasonable path forward?

My take is that we already have the "weirds" specification = into many drafts, so one draft about search is more than enough. It is with= in that draft that I would see MUST, SHOULD, MAY for any search feature tha= t is agreeable right now: i.e. the basic which would be either MUST or SHOU= LD and some common optional that would be MAY. Anything optional that does = not reach concensus would be put aside for an "extension" draft, = where the base draft will sketch how extensions should be done.

> We can select editors and such after we figure out a path here.

happy to help in editing/reviewing/...

Marc.

>
> -MSK
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds


--f46d04428eb6315c6104d7d2561b-- From jyee@afilias.info Wed Mar 13 11:19:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D621F8AD8 for ; Wed, 13 Mar 2013 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpugHcxKB0IL for ; Wed, 13 Mar 2013 11:19:42 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0621F8AA6 for ; Wed, 13 Mar 2013 11:19:41 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UFqH7-00064c-48 for weirds@ietf.org; Wed, 13 Mar 2013 18:19:41 +0000 Received: from mail-yh0-f70.google.com ([209.85.213.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UFqH7-0002ft-3b for weirds@ietf.org; Wed, 13 Mar 2013 18:19:41 +0000 Received: by mail-yh0-f70.google.com with SMTP id z20so1762356yhz.5 for ; Wed, 13 Mar 2013 11:19:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=RoIP4L3vTMQVouFciZyaV7aB+N8NXIP8IzPI/ksYKPo=; b=dOHr1zr/nrzuO0K2bJ1AR9roy7jh866JEFIpvuUG0HP/U/mI0yg7AShDRsCddteqj7 FSWqlIbRz9XbGT2eA/vvxRl74sO2RT37xDTkWSNEt+jeOJF2Iopglw6ay/c/u3UrX1Ra CIoKhxuTJe1+3B4DJDKYo0Zhu33k3m4tjQQOY1E00kFZz9vRd4j7axa1dR2uuA5auv/1 mFMF5TZ+jqX03LNRdUr520GgWD87CVBX1NWuFQNXxcdF7R57Z5opPAqzejZ31KrEKbcA iXHhRrbr/Rdlf4HEP8LRFIipp5NDr+iWy/CVHq22+T5ThY8RI4D4kNfHFQSgBjjoyzzW GRjQ== X-Received: by 10.52.29.209 with SMTP id m17mr7515024vdh.111.1363198775347; Wed, 13 Mar 2013 11:19:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.29.209 with SMTP id m17mr7515018vdh.111.1363198775242; Wed, 13 Mar 2013 11:19:35 -0700 (PDT) Received: by 10.58.134.5 with HTTP; Wed, 13 Mar 2013 11:19:35 -0700 (PDT) In-Reply-To: References: <65FBD2C6-A7E9-4EAB-88E0-6F7611732B48@viagenie.ca> Date: Wed, 13 Mar 2013 14:19:35 -0400 Message-ID: From: Joseph Yee To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6+8IOqL2eoFdYapaKZnQG2foV/eNDPDnbC79AS4kRjEcbhzEwnOAaUfGHzNYunl3YLsXxRTA7Xp7zQFjMX/TS1TG9d2/hzwW9q2lFWk3qXz2di9NYF2G1t+tPCMyYIM/Cxw2p Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:19:43 -0000 I support for two drafts instead of one. If the intention is to standardize how extended search be done, there would be several MUST, SHOULD under the 'you MAY extend your search function this way' section. And I recalled from previous session that most agreed that we don't stop at 'You MAY do paging' that clients need to recognize dozen of paging styles. Joseph On Wed, Mar 13, 2013 at 2:11 PM, Murray S. Kucherawy wrote: > Any other opinions on this? I think the answer here depends on how big a > unified (core plus extensions) search document would be. > > > On Tue, Mar 12, 2013 at 11:02 PM, Marc Blanchet > wrote: >> >> >> Le 2013-03-12 =C3=A0 17:51, "Murray S. Kucherawy" = a =C3=A9crit >> : >> >> > I didn't actually do a hum request in the session today, but there >> > seemed to be warm fuzzies in the direction of combining the search dra= fts >> > into a "basic" set of capabilities and an "extended" set. >> > >> > Does anyone disagree with that being a reasonable path forward? >> >> My take is that we already have the "weirds" specification into many >> drafts, so one draft about search is more than enough. It is within that >> draft that I would see MUST, SHOULD, MAY for any search feature that is >> agreeable right now: i.e. the basic which would be either MUST or SHOULD= and >> some common optional that would be MAY. Anything optional that does not >> reach concensus would be put aside for an "extension" draft, where the b= ase >> draft will sketch how extensions should be done. >> >> > We can select editors and such after we figure out a path here. >> >> happy to help in editing/reviewing/... >> >> Marc. >> >> > >> > -MSK >> > _______________________________________________ >> > weirds mailing list >> > weirds@ietf.org >> > https://www.ietf.org/mailman/listinfo/weirds >> > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From edainow@afilias.info Wed Mar 13 12:06:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B329E11E8185 for ; Wed, 13 Mar 2013 12:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBVLz-6w-MSh for ; Wed, 13 Mar 2013 12:06:14 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D8F3021F8E99 for ; Wed, 13 Mar 2013 12:06:13 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UFr09-000096-4L for weirds@ietf.org; Wed, 13 Mar 2013 19:06:13 +0000 Received: from mail-wi0-f198.google.com ([209.85.212.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UFr09-0004S7-3X for weirds@ietf.org; Wed, 13 Mar 2013 19:06:13 +0000 Received: by mail-wi0-f198.google.com with SMTP id hm6so1238146wib.1 for ; Wed, 13 Mar 2013 12:06:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7jrJH+Ogt+fKyaibneJK+6LaKojY+/FCkx6uQeFXOWk=; b=K3W5QlrKrTJLDi9eX6hLHTV3ZzAu6uhfIHSJaFBJsPU4yz3kAwprzmeU+QeQw0xkTM i10/I20JKAzL3tlbORmIplAkDZ8W8vwUskQs/vE907y6Sq0PFsTMiCRGMIvZomCXxRGM 7cIgbbSL6fBG6TRRPWOrGAmgdrR2gV4qt1FAvCXNtFuPQhB6fWMxl3U5P6nkAN9do+tO y5KJa5h/tlreRDIE7scpcah0qSgK2qlFRiPF3Q1ge3lua5pcSRIC1l8PlNMGeEpKrLQd aHTlWHW8gEt297ge/IjDZK4KSyvi4CtaRBmi69RXMrxcLOcePEhzBR8stLXBQffamBXJ 6FSQ== X-Received: by 10.112.44.66 with SMTP id c2mr1318lbm.69.1363201566874; Wed, 13 Mar 2013 12:06:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.44.66 with SMTP id c2mr1312lbm.69.1363201566654; Wed, 13 Mar 2013 12:06:06 -0700 (PDT) Received: by 10.112.155.164 with HTTP; Wed, 13 Mar 2013 12:06:06 -0700 (PDT) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> Date: Wed, 13 Mar 2013 15:06:06 -0400 Message-ID: From: Ernie Dainow To: Andy Newton Content-Type: multipart/alternative; boundary=bcaec554de8623643904d7d31904 X-Gm-Message-State: ALoCoQma5IgiIVgze8lf3SFeppRfeiUB2QbSy67USncOC6PwI8U0uble7pag0qIN63DL4ULtAUNLX9vkI5hh+msgbju7CYvba5w57dqS4fFV/I0UQLFPVfmAvEUBLSfT+/4OdgKTKfhW Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:06:14 -0000 --bcaec554de8623643904d7d31904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As there is a one-to-one mapping between A-label and U-label, they always occur in pairs. As pointed out, it becomes confusing if the U-label is used in some contexts and the A-label in others. So domain/nameserver names should always appear in json as a pair of names. The example on p.24 of draft-ietf-weirds-json-response-02 should be something like "name" : { a-label : "aaaaa", u-label : "uuu", } "variants" : [ { "relation" : [ "registered", "conjoined" ], "variantNames" : [ { a-label : "aaaa1", u-label : "uuu1", }, { a-label : "aaaa2", u-label : "uuu2", } ] }, ... ] Where u-label should be left out if the a-label is an ASCII name. -Ernie On Wed, Mar 13, 2013 at 1:43 PM, Behnam Esfahbod wrote: > Andy, > > Please don't ever do that! At IRNIC, we did a similar thing -- showing > U-label of the requested domain and A-labels of the variants -- in our EP= P > extension and soon we realized it's very confusing for our clients > (resellers/registrars). > > IMHO we need both of them everywhere, as the output is supposed to be > understandable by end-users, whether they understand the script of the > domain name or not. > > -Behnam > > > On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton wrote: > >> Accepting u-labels is only half of the equation. What do people want to = do >> with the json-response? >> >> Is it it acceptable to say that domain names in the response are always >> a-labels? Or is a better approach to say that if the name of the domain >> object is a U-label, then the server SHOULD provide a variants section a= nd >> those MUST be a-labels? >> >> Opinions? >> >> -andy >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> > > > > -- > ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8= =D8=AF > ' Behnam Esfahbod > ' > * .. http://behnam.esfahbod.info > * ` * http://zwnj.org > * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --bcaec554de8623643904d7d31904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As there is a one-to-one mapping between A-label and U-label, they alw= ays occur in pairs. As pointed out, it becomes confusing if the U-label is = used in some contexts and the A-label in others. So domain/nameserver names= should always appear in json as a pair of names. The example on p.24 of dr= aft-ietf-weirds-json-response-02 should be something like

"name" :=C2=A0
{
a-label : "aaaa= a",
u-la= bel : "uuu",
}
"variants" :
[
{
= "relation" : [ "registered", "conjoined" ],
&qu= ot;variantNames" :=C2=A0
[
{
a= -label : "aaaa1",
u-label : "uuu1",
},
{<= /div>
a-label : "aaaa2",
u-label : "uuu2",
}<= /div>
]
},
...<= /div>
= ]

Where u-label should be left out if the a-= label is an ASCII name. =C2=A0=C2=A0
=C2= =A0=C2=A0
-Ernie


On Wed, Mar 13, 2013 at 1:43 PM, Behnam Esfahbod <<= a href=3D"mailto:behnam@zwnj.org" target=3D"_blank">behnam@zwnj.org>= wrote:
Andy,

Please= don't ever do that! At IRNIC, we did a similar thing -- showing U-labe= l of the requested domain and A-labels of the variants -- in our EPP extens= ion and soon we realized it's very confusing for our clients (resellers= /registrars).

IMHO we need both of t= hem everywhere, as the output is supposed to be understandable by end-users= , whether they understand the script of the domain name or not.

-Behnam


On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton <andy@arin.net> wr= ote:
Accepting u-labels is only half of the equat= ion. What do people want to do
with the json-response?

Is it it acceptable to say that domain names in the response are always
a-labels? Or is a better approach to say that if the name of the domain
object is a U-label, then the server SHOULD provide a variants section and<= br> those MUST be a-labels?

Opinions?

-andy

_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds



--
=C2=A0=C2=A0 =C2=A0'=C2= =A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8= =A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0 =C2=A0=C2=A0 Behnam Esfahbod
=C2= =A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0
=C2=A0 *=C2=A0 ..=C2=A0=C2=A0 http://behnam.esfahbod.= info
=C2=A0*=C2=A0 `=C2=A0 *=C2=A0 http://zwnj.org
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7= 520 5701 CA40 259E 0F8B

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds


--bcaec554de8623643904d7d31904-- From johnl@iecc.com Wed Mar 13 12:33:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F054A21F8C5C for ; Wed, 13 Mar 2013 12:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.87 X-Spam-Level: X-Spam-Status: No, score=-110.87 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hKyl9CgMQsw for ; Wed, 13 Mar 2013 12:33:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8DE21F8C23 for ; Wed, 13 Mar 2013 12:33:11 -0700 (PDT) Received: (qmail 49790 invoked from network); 13 Mar 2013 19:33:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 19:33:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140d476.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=Li+wVyB+fmUNY75AlyDshduyvOUuvj7bJYxtx1Dfm9k=; b=LhOBMUIi3TbG1woGQMDt1N0MA/wugdm+24B4MLJX2QTSnLlAGFt7mf0N+iOuZWTMgWhB/JMI0/EFqHq0Em9/cAloOKCUEWJopMIsGgqewzMgy1DFCeo/BqFA4KDU6erT1Kejf4x32mRj7vzQLe7ZpMGwnCbUfyQlzOlX3LfnBIc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140d476.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=Li+wVyB+fmUNY75AlyDshduyvOUuvj7bJYxtx1Dfm9k=; b=nLRP2EGFvw/BtmVT5RtOnBkiDGSzOeXcapL8sno8lq5WgbStg7MEhyDR5vWJQtygr/Tl0d0BjBDqjUkmtrjHHMtJxZRtimLyQ5Vl6VDhBunnRmWpNGY6fX7g/AdGnWld54gD/d0EJEQ1X+68WuDdgpErkDyrg56Uh0ApeIiv5Mo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 19:32:47 -0000 Message-ID: <20130313193247.52987.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:33:13 -0000 >As there is a one-to-one mapping between A-label and U-label, they always >occur in pairs. As pointed out, it becomes confusing if the U-label is used >in some contexts and the A-label in others. So domain/nameserver names >should always appear in json as a pair of names. That seems reasonable, but please keep in mind the error scenarios when due to bugs or malice, the A- and U- labels don't match. My preference would be that clients can send either A- or U-labels, and don't have to say which they're sending, since the server can easily tell by inspection while it's sanity checking its input. Servers should send back both. From jean-philippe.dionne@viagenie.ca Wed Mar 13 12:37:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7189121F8CC7 for ; Wed, 13 Mar 2013 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nqRGk2j7HYU for ; Wed, 13 Mar 2013 12:37:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1A21F8CB1 for ; Wed, 13 Mar 2013 12:37:44 -0700 (PDT) Received: from dhcp-11cc.meeting.ietf.org (dhcp-11cc.meeting.ietf.org [130.129.17.204]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5474C403B3 for ; Wed, 13 Mar 2013 15:37:13 -0400 (EDT) Message-ID: <5140D569.4010102@viagenie.ca> Date: Wed, 13 Mar 2013 15:37:13 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:37:44 -0000 On 2013-03-13 12:29, Hollenbeck, Scott wrote: > > So should the query/lookup draft include support for both a-labels and u-labels? I'm seriously thinking it should. I think we should accept u-labels in queries. If we do this, we must have a canonical url with an a-label to represent the ressource. This canonical url could be reported to the client by a link in the json response or maybe an http redirect. However, the problem of matching/searching the u-label on the server's a-label in it's database still reside. Jean-Philippe From johnl@iecc.com Wed Mar 13 12:39:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FE121F8CE8 for ; Wed, 13 Mar 2013 12:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.888 X-Spam-Level: X-Spam-Status: No, score=-110.888 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dvt+qq4y14ZT for ; Wed, 13 Mar 2013 12:39:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C426D11E80A5 for ; Wed, 13 Mar 2013 12:39:11 -0700 (PDT) Received: (qmail 51519 invoked from network); 13 Mar 2013 19:39:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 19:39:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140d5df.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=Md1bN9VYUV1RLgJUWpF5zB7wvgHRq1nM2Qu2snq/xBc=; b=B339S17yfASi8Rof9fgBAJT6oXle8sbkoM5dnpDmkvB8rzwlQpa4qobCUU8YlR1KXblmYq3Wyre/adUDzA4boFUvi6e7pvA2DbT7nlh7WGf7mxS7ErZyUsOElG439QGjF/ll+4iC49wHxHImHDvzIQC0+8DeFMHhlC8WHTRtRcg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140d5df.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=Md1bN9VYUV1RLgJUWpF5zB7wvgHRq1nM2Qu2snq/xBc=; b=j3JuN0KVPhM+klhelQWgASDnh5cJdkyUoQuUOTdZEA5Tyfr6CkB9kGx5rnZ1Urf2sKxa8336y0K3uZgWK/jxqlLJXMnbjtQKsulROqPwhbubVpA0QRfEqFOABk++F5tWco4tMWrcTQSO+r13+XTakqoBVSWUgHKA9GUl+iSo6Vs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 19:38:48 -0000 Message-ID: <20130313193848.55056.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:39:13 -0000 In article you write: >I support for two drafts instead of one. If the intention is to >standardize how extended search be done, there would be several MUST, >SHOULD under the 'you MAY extend your search function this way' >section. And I recalled from previous session that most agreed that >we don't stop at 'You MAY do paging' that clients need to recognize >dozen of paging styles. I would disagree. Keeping in mind that we're defining a new machine-to-machine protocol, which is not the same as any existing machine-to-user imeplementation, if people want an option to return results a page at a time, we should define exactly one such option. Then servers and clients can implement it, we can test them, and there is a reasonable chance that they will interoperate. That would not be the case if the clients need to add different code for dozens or hundreds of slightly different paging setups.* I believe that there are a lot of current paging styles, but I would be surprised if there were a lot of semantic variation. R's, John * - says the guy with a WHOIS scraper script that is 3056 lines and growing every week. From fobispo@isc.org Wed Mar 13 12:46:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2121F8E0A for ; Wed, 13 Mar 2013 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7EWbIK25LNO for ; Wed, 13 Mar 2013 12:46:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A973F21F8E09 for ; Wed, 13 Mar 2013 12:46:20 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2103FC9512; Wed, 13 Mar 2013 19:46:11 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363203980; bh=JhFFdXTTYTUSQA2rTWgJ9k9e4ICwjnlCr9S2HcKwFeM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rOIjy8M0Giw0ZBWRq96bMG7yocN4HVEUuvUMpcv9DIjcS5k5JS9JYIZVn3HchGgo5 CBCEmmtBhQ7+GDQm6Fq0YfdidbHt5q8ofA8fzy6+BXJl5XMDy//P/mSzPmZqUYMlLX kMDG6g7QpsAJtombSrNtKXIuB/j/Irrvs6gnJNko= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 19:46:11 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:f1af:264f:4258:cb17] (unknown [IPv6:2001:4f8:3:64:f1af:264f:4258:cb17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0F48F216C40; Wed, 13 Mar 2013 19:46:11 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Wed, 13 Mar 2013 12:46:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB52C39-1527-4312-B1DB-1CBB12EFC13C@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> To: Ernie Dainow X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:46:21 -0000 I would prefer a full representation of the name not just the *-label, = perhaps something like "u-name" and "a-name"? =20 On Mar 13, 2013, at 12:06 PM, Ernie Dainow wrote: > As there is a one-to-one mapping between A-label and U-label, they = always occur in pairs. As pointed out, it becomes confusing if the = U-label is used in some contexts and the A-label in others. So = domain/nameserver names should always appear in json as a pair of names. = The example on p.24 of draft-ietf-weirds-json-response-02 should be = something like >=20 > "name" :=20 > { > a-label : "aaaaa", > u-label : "uuu", > } > "variants" : > [ > { > "relation" : [ "registered", "conjoined" ], > "variantNames" :=20 > [ > { > a-label : "aaaa1", > u-label : "uuu1", > }, > { > a-label : "aaaa2", > u-label : "uuu2", > } > ] > }, > ... > ] >=20 > Where u-label should be left out if the a-label is an ASCII name. =20 > =20 > -Ernie >=20 >=20 > On Wed, Mar 13, 2013 at 1:43 PM, Behnam Esfahbod = wrote: > Andy, >=20 > Please don't ever do that! At IRNIC, we did a similar thing -- showing = U-label of the requested domain and A-labels of the variants -- in our = EPP extension and soon we realized it's very confusing for our clients = (resellers/registrars). >=20 > IMHO we need both of them everywhere, as the output is supposed to be = understandable by end-users, whether they understand the script of the = domain name or not. >=20 > -Behnam >=20 >=20 > On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton wrote: > Accepting u-labels is only half of the equation. What do people want = to do > with the json-response? >=20 > Is it it acceptable to say that domain names in the response are = always > a-labels? Or is a better approach to say that if the name of the = domain > object is a U-label, then the server SHOULD provide a variants section = and > those MUST be a-labels? >=20 > Opinions? >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds >=20 >=20 >=20 > --=20 > ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8= =AF > ' Behnam Esfahbod > ' =20 > * .. http://behnam.esfahbod.info > * ` * http://zwnj.org > * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From jean-philippe.dionne@viagenie.ca Wed Mar 13 12:53:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7F21F8E15 for ; Wed, 13 Mar 2013 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1IVUzKOwkfp for ; Wed, 13 Mar 2013 12:53:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 636B121F8E13 for ; Wed, 13 Mar 2013 12:53:19 -0700 (PDT) Received: from dhcp-11cc.meeting.ietf.org (dhcp-11cc.meeting.ietf.org [130.129.17.204]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D6BF8403B3 for ; Wed, 13 Mar 2013 15:52:48 -0400 (EDT) Message-ID: <5140D910.7030305@viagenie.ca> Date: Wed, 13 Mar 2013 15:52:48 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:53:21 -0000 On 2013-03-13 15:06, Ernie Dainow wrote: > "name" : > { > a-label : "aaaaa", > u-label : "uuu", > } This is redundant information. I am against this. Only the a-label form should be found in the response. The conversion from a-label to u-label can be done by the client. Jean-Philippe From fobispo@isc.org Wed Mar 13 12:56:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7642721F8DC9 for ; Wed, 13 Mar 2013 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyEiveRaf2rJ for ; Wed, 13 Mar 2013 12:56:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id DC9D421F87D0 for ; Wed, 13 Mar 2013 12:56:52 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 73E47C9512; Wed, 13 Mar 2013 19:56:45 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363204612; bh=2FguQgd3SCVbmgGQfvvYwkLJorx1dHeZMp0x4sxssR4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KTEuHJ72eAB/OME75Q4uSLBYXUCZeMverMFUJt4TWGcp75mkt2xO/SLvdX8RqbiC1 578GisgOau2tm0dSIPe/+A+Yfz8GiJpMV3FUDWQXtmr+rxZx432pOOI7rHqDUWt/Vv P3iBw7UhDKB58KhFomCnjW8LOiA+AddczoeZTD7o= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 19:56:45 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from dhcp-114.sql1.isc.org (dhcp-114.sql1.isc.org [149.20.50.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4EE34216C47; Wed, 13 Mar 2013 19:56:45 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <5140D910.7030305@viagenie.ca> Date: Wed, 13 Mar 2013 12:56:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4697F9EB-9064-47F0-8DA6-387597F1A580@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> <5140D910.7030305@viagenie.ca> To: Jean-Philippe Dionne X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: weirds@ietf.org Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:56:57 -0000 adding more complexity on the client, doesn't help the cause. besides, we need to send a clear message that this is the 'official' = interpretation of the [u,a]-labels, if the client messes with the = encoding, they'll end up with a different string, and that's not = acceptable. On Mar 13, 2013, at 12:52 PM, Jean-Philippe Dionne = wrote: > On 2013-03-13 15:06, Ernie Dainow wrote: >> "name" :=20 >> { >> a-label : "aaaaa", >> u-label : "uuu", >> } >=20 > This is redundant information. I am against this. > Only the a-label form should be found in the response. The conversion > from a-label to u-label can be done by the client. >=20 > Jean-Philippe > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From marc.blanchet@viagenie.ca Wed Mar 13 13:10:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1772011E80FB for ; Wed, 13 Mar 2013 13:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVofxRy1rTbf for ; Wed, 13 Mar 2013 13:10:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0D11E80D2 for ; Wed, 13 Mar 2013 13:10:39 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C78D2403B3; Wed, 13 Mar 2013 16:10:08 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <4697F9EB-9064-47F0-8DA6-387597F1A580@isc.org> Date: Wed, 13 Mar 2013 16:10:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> <5140D910.7030305@viagenie.ca> <4697F9EB-9064-47F0-8DA6-387597F1A580@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:10:40 -0000 Le 2013-03-13 =E0 15:56, Francisco Obispo a =E9crit : > adding more complexity on the client, doesn't help the cause. in a previous email I sent, I claimed that the client has no choice to = have already enough i18n processing. So I think this consideration above = is moot. Let me restate another way: - weirds is about domain names (and else). - domain names now include idn - IDNA processing is needed for any software that is handling/processing = idn. - therefore weirds clients shall have IDNA processing already. Therefore, that "complexity" can not be avoided. > besides, we need to send a clear message that this is the 'official' = interpretation of the [u,a]-labels, if the client messes with the = encoding, they'll end up with a different string, and that's not = acceptable. I'm not sure I follow you. official interpretation of u/a labels is = defined in IDNA documents. What we need to define here, for idn, is where the IDNA processing will = be done, and what is sent on the wire. (those are obviously closely = related) Marc. >=20 > On Mar 13, 2013, at 12:52 PM, Jean-Philippe Dionne = wrote: >=20 >> On 2013-03-13 15:06, Ernie Dainow wrote: >>> "name" :=20 >>> { >>> a-label : "aaaaa", >>> u-label : "uuu", >>> } >>=20 >> This is redundant information. I am against this. >> Only the a-label form should be found in the response. The conversion >> from a-label to u-label can be done by the client. >>=20 >> Jean-Philippe >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > Francisco Obispo=20 > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Wed Mar 13 13:11:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D9F11E8152 for ; Wed, 13 Mar 2013 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQSEkHYUgVWD for ; Wed, 13 Mar 2013 13:11:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9230D11E80D2 for ; Wed, 13 Mar 2013 13:11:36 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B8A18403B3 for ; Wed, 13 Mar 2013 16:11:35 -0400 (EDT) Message-ID: <5140DD76.9010501@viagenie.ca> Date: Wed, 13 Mar 2013 16:11:34 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:11:37 -0000 Le 2013-03-13 12:54, Andy Newton a écrit : > I was asked during the session on Tuesday to send to the list a revamped > remarks structure. After looking at the draft, I think it should follow > the same pattern as the notices structure. It should also be noted that > the remarks section can be used to solve the problem mentioned by Chris > Wright and James Mitchell. Here's an example: I'm not sure what your proposal is exactly. Are you proposing to change the current text in any way? > > { > "remarks": > [ > { > "title": "Unverified Contact", > "description": > [ > "Lunar NIC has attempted to verify the data for this contact, but > has received no response from the POC since 2010-07-28.", > "See Lunar NIC policy 2010-XXX." > ] > }, > { > "title": "Rights of Use Claim", > "description" : > [ > "The following information provides the rights of use information > for this internet resource.", > "Eligibility Type: Company", > "Eligibility Name: Acme Widgets", > "Eligibility ID: BN955912" > ] > } > ] > } > > > A text based client MIGHT render this as > > Unverified > ---------- > Lunar NIC has attempted to verify the data for this contact, > but has received no response from the POC since 2010-07-28. > > See Lunar NIC policy 2010-XXX. > > > Rights of Use Claim > > ------------------- > The following information provides the rights of use information > for this internet resource. > > Eligibility Type: Company > > Eligibility Name: Acme Widgets > > Eligibility ID: BN955912 I absolutely agree with this part. This is a good example. > I don't think we should encourage formatting characters such as newlines > in the text as that is a rendering issue and the client knows best how to > render the data. But this is not the actual problem. The problem is that current implementations do things like this: "description" : [ "Lunar NIC has attempted", "to verify the data for this", "contact, but has received no", "response from the POC since 2010-07-28." ] Can we at least agree that this is wrong? I agree that embedding newlines may not be appropriate because that would be entering the realm of presentation. But splitting sentences like above is just silly. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 13 13:20:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1811E811D for ; Wed, 13 Mar 2013 13:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j66yvDPcQLzh for ; Wed, 13 Mar 2013 13:20:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id B06F311E811A for ; Wed, 13 Mar 2013 13:20:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 26D82425ED for ; Wed, 13 Mar 2013 16:20:26 -0400 (EDT) Message-ID: <5140DF89.70300@viagenie.ca> Date: Wed, 13 Mar 2013 16:20:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> <5140DD76.9010501@viagenie.ca> In-Reply-To: <5140DD76.9010501@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:20:57 -0000 Le 2013-03-13 16:11, Simon Perreault a écrit : > Le 2013-03-13 12:54, Andy Newton a écrit : >> I was asked during the session on Tuesday to send to the list a revamped >> remarks structure. After looking at the draft, I think it should follow >> the same pattern as the notices structure. It should also be noted that >> the remarks section can be used to solve the problem mentioned by Chris >> Wright and James Mitchell. Here's an example: > > > I'm not sure what your proposal is exactly. Are you proposing to change > the current text in any way? Sorry, I figured it out. No need to answer that. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From johnl@iecc.com Wed Mar 13 13:27:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325E921F8DB9 for ; Wed, 13 Mar 2013 13:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.904 X-Spam-Level: X-Spam-Status: No, score=-110.904 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNwy2JrSPpp3 for ; Wed, 13 Mar 2013 13:26:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E3C7421F874D for ; Wed, 13 Mar 2013 13:26:54 -0700 (PDT) Received: (qmail 67097 invoked from network); 13 Mar 2013 20:26:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 20:26:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140e10c.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=mAU36dvpKLZdo3I3rEkPD51nLfPwapnKeak7e7OlgfA=; b=RW9mA2hv1PfjICCir1Cm/1e57j4ISeUeFgbHjmmEKia1ZIi/V64tQOxAH3tRDmYZBnf6oUF5NgrKnb9RP9IMFrlsjXvMEsk+2G5STMXLtbmZmBy8kjCGJvDEq6c3S8idGKjfH+nwESuDSA1Kiwa58/hkJ5GZrbd+bCnQO1G4cYc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140e10c.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=mAU36dvpKLZdo3I3rEkPD51nLfPwapnKeak7e7OlgfA=; b=fxkwOYQhhvWXMiH/XDGn7tPI6DXr6wDKZ+sbaEQooPxv1gx3E94D9PrtXiI/tmyVijrKViueB7bBXITRvgYz7XQrySPSLfF4haRHk49xmST+w2lcBqxNe2GRpqJEoTyr1HQ1wSjzEqIzGvMt14VB3wVM4E+JiL9RjNusUzWLhgY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 20:26:30 -0000 Message-ID: <20130313202630.71366.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:27:00 -0000 >- IDNA processing is needed for any software that is handling/processing idn. Sorry, but that's just not true. A dumb client can just send along the UTF-8 for a name in its queries. If it turns out not to be a valid U-label (or sequence of U-labels), it'll get an error from the server, but so be it. Unless you want your server to crash any time someone uses a buggy client, it is mandatory that it check the validity of its input. It doesn't matter at the server end whether the client has already validated it, the server can't depend on that so it has to do it again. It would often be nice if a client with a human user did all sorts of elegant validation and provided brightly colored error messages, but there will also be plenty of clients that do not have human users, and it makes no difference to the calling software where a bogus name is rejected. R's, John From andy@arin.net Wed Mar 13 13:40:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D221F8DA2 for ; Wed, 13 Mar 2013 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=3.750, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNrmcoTK-5RT for ; Wed, 13 Mar 2013 13:40:55 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id B569221F8DA0 for ; Wed, 13 Mar 2013 13:40:55 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 58AE4165267; Wed, 13 Mar 2013 16:40:25 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 0D5D5165258; Wed, 13 Mar 2013 16:40:20 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 16:40:03 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 16:40:17 -0400 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+IA= Date: Wed, 13 Mar 2013 20:40:16 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF336D@CHAXCH01.corp.arin.net> In-Reply-To: <5140DD76.9010501@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B510CDC3E5E514D9871E0FF735CCC52@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:40:56 -0000 On 3/13/13 4:11 PM, "Simon Perreault" wrote: >But this is not the actual problem. The problem is that current >implementations do things like this: > >"description" : [ >"Lunar NIC has attempted", >"to verify the data for this", >"contact, but has received no", >"response from the POC since 2010-07-28." ] > >Can we at least agree that this is wrong? Yes. Servers should let the clients determine line breaks. -andy From andy@arin.net Wed Mar 13 13:45:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3DB21F8C4F for ; Wed, 13 Mar 2013 13:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+AzKobaMrCj for ; Wed, 13 Mar 2013 13:45:07 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 424AE21F8C23 for ; Wed, 13 Mar 2013 13:45:07 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E7C6F21368A; Wed, 13 Mar 2013 16:45:06 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 88BF12135F6; Wed, 13 Mar 2013 16:45:06 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 16:44:23 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 16:44:59 -0400 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] A-label and U-label Lookups Thread-Index: Ac4gA2aiGphfya3nQ7SfHT4gSamQnwAQEl+A///P4gA= Date: Wed, 13 Mar 2013 20:44:59 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3381@CHAXCH01.corp.arin.net> In-Reply-To: <5140D569.4010102@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <03E38D2E5902634E81101FD0CEA5654F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:45:07 -0000 On 3/13/13 3:37 PM, "Jean-Philippe Dionne" wrote: >I think we should accept u-labels in queries. If we do this, we must >have a canonical url with an a-label to represent the ressource. This >canonical url could be reported to the client by a link in the json >response or maybe an http redirect. I'm not sure about a redirect, but putting a canonical link relation seems like a good idea. -andy From andy@arin.net Wed Mar 13 13:47:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353221F8DBC for ; Wed, 13 Mar 2013 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.043 X-Spam-Level: X-Spam-Status: No, score=-7.043 tagged_above=-999 required=5 tests=[AWL=3.556, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMjipOxnp-9M for ; Wed, 13 Mar 2013 13:47:15 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABB21F8DB9 for ; Wed, 13 Mar 2013 13:47:15 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 6D3B4165267; Wed, 13 Mar 2013 16:46:45 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 68203165203; Wed, 13 Mar 2013 16:46:40 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 16:46:02 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 16:46:39 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] a-labels and u-labels in json response Thread-Index: AQHOIAxKYblC5qdk5UWFQVsDtxfqi5ikJ3eAgAAXHwCAAA0MAIAAARkAgAADvACAAASVAP//wpOA Date: Wed, 13 Mar 2013 20:46:38 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> In-Reply-To: <20130313202630.71366.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:47:16 -0000 On 3/13/13 4:26 PM, "John Levine" wrote: >A dumb client can just send along the UTF-8 for a name in its queries. >If it turns out not to be a valid U-label (or sequence of U-labels), >it'll get an error from the server, but so be it. I think John has a good point. People are gonna write dumb clients. There's just no way around it. As I said sometime back, RDAP clients should be easily constructed with bash and curl. -andy From andy@arin.net Wed Mar 13 13:52:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ECD11E80F1 for ; Wed, 13 Mar 2013 13:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxHdDlAcY4WB for ; Wed, 13 Mar 2013 13:52:59 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 084F311E809C for ; Wed, 13 Mar 2013 13:52:59 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 9AE4A16500B; Wed, 13 Mar 2013 16:52:55 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 1DBFD16500B; Wed, 13 Mar 2013 16:52:55 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 16:52:40 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 16:52:53 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Search documents Thread-Index: AQHOH2u180puIuFfgkW+GQvwhoZ+vZijMriAgAD944CAAAI9gIAAFiIA///Rp4A= Date: Wed, 13 Mar 2013 20:52:53 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF33B4@CHAXCH01.corp.arin.net> In-Reply-To: <20130313193848.55056.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E2B7DB8BEEB204EA9BDDC133F799357@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:53:00 -0000 On 3/13/13 3:38 PM, "John Levine" wrote: >I believe that there are a lot of current paging styles, but I would >be surprised if there were a lot of semantic variation. I think there should be two documents, and here is why: 1. If the documents are combined, the basic search features will have to wait on the advanced search features to be defined. Wasn't one of the worries being able to show ICANN we could get this done? 2. It's not hard to imagine advanced search features that crop up in the future, such as server-side filtering or geo-location searches. So we could end up with multiple documents anyway. 3. When people talk about which features they support, a lot of times they refer to RFC numbers. Being able to say clearly that an implementation supports RFC XXXX usually helpful. -andy From fobispo@isc.org Wed Mar 13 13:56:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECE911E80F3 for ; Wed, 13 Mar 2013 13:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJUpjRqqT5aI for ; Wed, 13 Mar 2013 13:55:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1166B11E8103 for ; Wed, 13 Mar 2013 13:55:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3BE51C951D; Wed, 13 Mar 2013 20:55:50 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363208158; bh=6sq9YVdF7sgtVgreMjNsw8nq5tVrhUETCbzkGUcAR+c=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=F6PzR1T8KHhCJe7wY899RmG8t/FZ78RGkEL/iK03xxQeLRmf8+z2WIHa+oOHe594C 0QsNYbb/JNcEWwaOdN/NBF6jM2u9NG6U1booXKJj3VwO8e7u9GLZFghJYsVHXTFG6Q m+HJyQ5eyVmFTO4GNSnSgpQsCWElIZtQNiQcOE48= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 13 Mar 2013 20:55:50 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:f1af:264f:4258:cb17] (unknown [IPv6:2001:4f8:3:64:f1af:264f:4258:cb17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 166BC216C3B; Wed, 13 Mar 2013 20:55:50 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> Date: Wed, 13 Mar 2013 13:55:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1499) X-DCC--Metrics: post.isc.org; whitelist Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:56:03 -0000 +1 On Mar 13, 2013, at 1:46 PM, Andy Newton wrote: > I think John has a good point. People are gonna write dumb clients. > There's just no way around it. As I said sometime back, RDAP clients > should be easily constructed with bash and curl. > > -andy Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE From jyee@afilias.info Wed Mar 13 14:07:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19D221F8DDB for ; Wed, 13 Mar 2013 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R84n0pATMmH7 for ; Wed, 13 Mar 2013 14:07:47 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E521F8DBB for ; Wed, 13 Mar 2013 14:07:46 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UFstm-0006Mf-4Y for weirds@ietf.org; Wed, 13 Mar 2013 21:07:46 +0000 Received: from mail-ve0-f197.google.com ([209.85.128.197]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UFstm-0008Ot-48 for weirds@ietf.org; Wed, 13 Mar 2013 21:07:46 +0000 Received: by mail-ve0-f197.google.com with SMTP id 15so2410249vea.4 for ; Wed, 13 Mar 2013 14:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xGWiJmml60k6IEmkR7Zu3Fkf2QdfCzvyd00MgGuJrYs=; b=XJtdVKCcDmhr6TxgXnEz1nMfOSo9br1DxpgS106gGy0Yt2Li0XPsZJxIqaxDty5BNG hiS/Q5DUKS6BarhUvg9wjLpP7/CcfWLQ36v31tDU7Kuk8CYrvdoZ4g9KZ6F8up7yScyX qG14+TegkqwUckvFvwEl6EZRglX1J0lNVeOzS2CJASs25En15bOFgB8lIA0UXiM3CAic xpCPzPSnwRoo2R7SCAQ+ADJYMA35G6V0naBLiAoC1wc7LhcSRm/B308efwJQOn2ebxir fgQJBLYGZVDDJIMXi6ChToQm/FMmgekSmV5xVJPaETqU+MfP3p3T9hTXxgYhdQfKXuyU zJrQ== X-Received: by 10.52.29.209 with SMTP id m17mr7726868vdh.111.1363208860787; Wed, 13 Mar 2013 14:07:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.29.209 with SMTP id m17mr7726858vdh.111.1363208860556; Wed, 13 Mar 2013 14:07:40 -0700 (PDT) Received: by 10.58.134.5 with HTTP; Wed, 13 Mar 2013 14:07:40 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> References: <20130313202630.71366.qmail@joyce.lan> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> Date: Wed, 13 Mar 2013 17:07:40 -0400 Message-ID: From: Joseph Yee To: Andy Newton Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnRjDx2XQ0afCGtrGsX+E+ONxN/YtgTNMD+MeAUcintW3WZ16ZWMu2Jis87WLDb+7uBogckpNDLEAQr49dzkQoX+OlFZ4+A6a6MdNxoSwFKreKA/fyCOgIsHSdVu6oSMLkGC8bn Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:07:47 -0000 On Wed, Mar 13, 2013 at 4:46 PM, Andy Newton wrote: > On 3/13/13 4:26 PM, "John Levine" wrote: > >>A dumb client can just send along the UTF-8 for a name in its queries. >>If it turns out not to be a valid U-label (or sequence of U-labels), >>it'll get an error from the server, but so be it. > > I think John has a good point. People are gonna write dumb clients. > There's just no way around it. As I said sometime back, RDAP clients > should be easily constructed with bash and curl. > This takes care of dump client request. That's only first half. And do servers expect do more on response when dump request comes in? If the client sends dump request, what should server assume for the client? It's dump that the response need to include U-label? OR It's dump that don't send Unicode in response because they may crash? I'm not entirely in favor of A-label only response, but I see the rationale behind it (there are other reasons beyond this). And we kept reiterate it's machine-to-machine. Sure, there are always some human will just do command line :) Joseph > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From jyee@afilias.info Wed Mar 13 14:13:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5443311E812F for ; Wed, 13 Mar 2013 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obh3io5NMRAr for ; Wed, 13 Mar 2013 14:13:26 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3846211E812D for ; Wed, 13 Mar 2013 14:13:20 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UFsz9-0006YJ-5f for weirds@ietf.org; Wed, 13 Mar 2013 21:13:19 +0000 Received: from mail-gg0-f198.google.com ([209.85.161.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UFsz9-00007g-5D for weirds@ietf.org; Wed, 13 Mar 2013 21:13:19 +0000 Received: by mail-gg0-f198.google.com with SMTP id a5so1933157ggn.1 for ; Wed, 13 Mar 2013 14:13:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=3wd5hOSFCKU+mPHbSoD6aDg9FhrSzm8CpZdQs2bkMSk=; b=lhC633+9UD4nZ/jlulc0KvLMdaxammLrDZMZl3xEgVgOLrAoH+h+NynldicCHaLgk/ DMdhx7lbXLoA5BeFSlkjlKdxvB6NzPjjRT6t+R8wYvLAGwB8MlIVQTz25LkwBn+SRqcc bfvkzYf7fVPklXz7AwTmPRhaK03j6CQPC1WjW9PAzIEkZ2Yo0CzgP95dgAyTKyBJvRnK 6OawQ12OEojvzyS5xVjdPiZxtqsSNCzSBvrt2o8A86ekGojEwmMn9xJlqnzJB4L6YoNK SbBKIpDv5rrdHqpC0vV1gOVawbZsSWBpyqPThzTerGe5IMRksijJKNyd5AeIHAmhHJ+l vSAQ== X-Received: by 10.52.175.130 with SMTP id ca2mr7788911vdc.109.1363209193754; Wed, 13 Mar 2013 14:13:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.175.130 with SMTP id ca2mr7788910vdc.109.1363209193654; Wed, 13 Mar 2013 14:13:13 -0700 (PDT) Received: by 10.58.134.5 with HTTP; Wed, 13 Mar 2013 14:13:13 -0700 (PDT) In-Reply-To: <20130313193848.55056.qmail@joyce.lan> References: <20130313193848.55056.qmail@joyce.lan> Date: Wed, 13 Mar 2013 17:13:13 -0400 Message-ID: From: Joseph Yee To: John Levine Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlILzHbUr6qhfNfiQ0sFQwtKaR0YroXpkPldOAsvLLYanAUqiFbqKMDMHEpfuFC/fH0xTQb3/AhonC1mKbmSexVNYud4Pntz3Ggb/tk5FfmFeZMJLKxjAvsESxxGR2qAhx5xY6j Cc: weirds@ietf.org Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:13:27 -0000 On Wed, Mar 13, 2013 at 3:38 PM, John Levine wrote: > In article you write: >>I support for two drafts instead of one. If the intention is to >>standardize how extended search be done, there would be several MUST, >>SHOULD under the 'you MAY extend your search function this way' >>section. And I recalled from previous session that most agreed that >>we don't stop at 'You MAY do paging' that clients need to recognize >>dozen of paging styles. > > I would disagree. Keeping in mind that we're defining a new > machine-to-machine protocol, which is not the same as any existing > machine-to-user imeplementation, if people want an option to return > results a page at a time, we should define exactly one such option. > Then servers and clients can implement it, we can test them, and there > is a reasonable chance that they will interoperate. That would not be > the case if the clients need to add different code for dozens or > hundreds of slightly different paging setups.* > > I believe that there are a lot of current paging styles, but I would > be surprised if there were a lot of semantic variation. > Wouldn't locking it to few agreed variations from the beginning a better approach? Paging is just one issue we discussed from previous session, there are likely some other issues better get it spec out now. Joseph > R's, > John > > * - says the guy with a WHOIS scraper script that is 3056 lines and > growing every week. From zwnj.org@gmail.com Wed Mar 13 14:22:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5844211E8142 for ; Wed, 13 Mar 2013 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlI09Pv7trkD for ; Wed, 13 Mar 2013 14:22:05 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D630D11E8150 for ; Wed, 13 Mar 2013 14:22:03 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so1513580wea.10 for ; Wed, 13 Mar 2013 14:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=QUp2M7Z0T84ItKZlZoyY4J+ldG0wS2uK9C288rV5zVA=; b=NuQU0JJrASUYCINqxqNOKI/pdrSFp2ZDXyQNlPoykr2kX0VQTk/xQ1k8HQ+ftqQ6DP wteL+7fn8fUnRLDlp04NzpYgjaDeQVqDpl4X6BsqvfdQduSX9kkaIYn83J6y22dXCJCE 1nSD8vvxk4aIX5lHKqK6PPTn+FdXRccXWxEktrXPvlpJsVok97H4aTET40UoBbS5EkUS cSel7C0IdWFZ/0ROoe9flpuxhYVpN6nZcF/s/LuvBZOpO/vVLlurBjKL6FkuHoDfjwKP vLR5GgJcJWaucetgiGV7CDwd1n07wbyzm6W1gguvF0R1a4IIYtZVUIcgWmaGvB8cf+ir JDkg== MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr29917238wiz.6.1363209722928; Wed, 13 Mar 2013 14:22:02 -0700 (PDT) Sender: behnam@gmail.com X-Google-Sender-Delegation: behnam@gmail.com Received: by 10.194.26.4 with HTTP; Wed, 13 Mar 2013 14:22:02 -0700 (PDT) In-Reply-To: <7EB52C39-1527-4312-B1DB-1CBB12EFC13C@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> <7EB52C39-1527-4312-B1DB-1CBB12EFC13C@isc.org> Date: Wed, 13 Mar 2013 17:22:02 -0400 X-Google-Sender-Auth: xhr_XazGA6PaIzoprb68VEbeSGs Message-ID: From: Behnam Esfahbod To: Francisco Obispo Content-Type: multipart/alternative; boundary=f46d0418270e4a249304d7d4ffab Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:22:07 -0000 --f46d0418270e4a249304d7d4ffab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Field names should not be named "u-label"/"a-label" as these terms are already well-defined and are not applicable here. Anything like "name"/"ascii-name", "unicode-name"/"ascii-name", or "u-name"/"a-name" would do the job. -Behnam On Wed, Mar 13, 2013 at 3:46 PM, Francisco Obispo wrote: > I would prefer a full representation of the name not just the *-label, > perhaps something like "u-name" and "a-name"? > > > > > On Mar 13, 2013, at 12:06 PM, Ernie Dainow wrote: > > > As there is a one-to-one mapping between A-label and U-label, they > always occur in pairs. As pointed out, it becomes confusing if the U-labe= l > is used in some contexts and the A-label in others. So domain/nameserver > names should always appear in json as a pair of names. The example on p.2= 4 > of draft-ietf-weirds-json-response-02 should be something like > > > > "name" : > > { > > a-label : "aaaaa", > > u-label : "uuu", > > } > > "variants" : > > [ > > { > > "relation" : [ "registered", "conjoined" ], > > "variantNames" : > > [ > > { > > a-label : "aaaa1", > > u-label : "uuu1", > > }, > > { > > a-label : "aaaa2", > > u-label : "uuu2", > > } > > ] > > }, > > ... > > ] > > > > Where u-label should be left out if the a-label is an ASCII name. > > > > -Ernie > > > > > > On Wed, Mar 13, 2013 at 1:43 PM, Behnam Esfahbod > wrote: > > Andy, > > > > Please don't ever do that! At IRNIC, we did a similar thing -- showing > U-label of the requested domain and A-labels of the variants -- in our EP= P > extension and soon we realized it's very confusing for our clients > (resellers/registrars). > > > > IMHO we need both of them everywhere, as the output is supposed to be > understandable by end-users, whether they understand the script of the > domain name or not. > > > > -Behnam > > > > > > On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton wrote: > > Accepting u-labels is only half of the equation. What do people want to > do > > with the json-response? > > > > Is it it acceptable to say that domain names in the response are always > > a-labels? Or is a better approach to say that if the name of the domain > > object is a U-label, then the server SHOULD provide a variants section > and > > those MUST be a-labels? > > > > Opinions? > > > > -andy > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > > > > > > -- > > ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8= =D8=AF > > ' Behnam Esfahbod > > ' > > * .. http://behnam.esfahbod.info > > * ` * http://zwnj.org > > * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --f46d0418270e4a249304d7d4ffab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Field names should not be named &quo= t;u-label"/"a-label" as these terms are already well-defined= and are not applicable here. Anything like "name"/"ascii-na= me", "unicode-name"/"ascii-name", or "u-name&= quot;/"a-name" would do the job.

-Behnam



On Wed, Mar 13, 2013 a= t 3:46 PM, Francisco Obispo <fobispo@isc.org> wrote:
I would prefer a full representation of the = name not just the *-label, perhaps something like "u-name" and &q= uot;a-name"?




On Mar 13, 2013, at 12:06 PM, Ernie Dainow <edainow@afilias.info> wrote:

> As there is a one-to-one mapping between A-label and U-label, they alw= ays occur in pairs. As pointed out, it becomes confusing if the U-label is = used in some contexts and the A-label in others. So domain/nameserver names= should always appear in json as a pair of names. The example on p.24 of dr= aft-ietf-weirds-json-response-02 should be something like
>
> "name" :
> =C2=A0 =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a-label : "aaaaa= ",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u-label : "uuu&q= uot;,
> =C2=A0 =C2=A0 =C2=A0 }
> "variants" :
> =C2=A0 =C2=A0 =C2=A0 [
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"relation&= quot; : [ "registered", "conjoined" ],
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"variantNa= mes" :
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a-label : &q= uot;aaaa1",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u-label : &q= uot;uuu1",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a-label : &q= uot;aaaa2",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u-label : &q= uot;uuu2",
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ]
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> =C2=A0 =C2=A0 =C2=A0 ]
>
> Where u-label should be left out if the a-label is an ASCII name.
>
> -Ernie
>
>
> On Wed, Mar 13, 2013 at 1:43 PM, Behnam Esfahbod <behnam@zwnj.org> wrote:
> Andy,
>
> Please don't ever do that! At IRNIC, we did a similar thing -- sho= wing U-label of the requested domain and A-labels of the variants -- in our= EPP extension and soon we realized it's very confusing for our clients= (resellers/registrars).
>
> IMHO we need both of them everywhere, as the output is supposed to be = understandable by end-users, whether they understand the script of the doma= in name or not.
>
> -Behnam
>
>
> On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton <andy@arin.net> wrote:
> Accepting u-labels is only half of the equation. What do people want t= o do
> with the json-response?
>
> Is it it acceptable to say that domain names in the response are alway= s
> a-labels? Or is a better approach to say that if the name of the domai= n
> object is a U-label, then the server SHOULD provide a variants section= and
> those MUST be a-labels?
>
> Opinions?
>
> -andy
>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>
>
>
> --
> =C2=A0 =C2=A0 ' =C2=A0 =C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8= =A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
> =C2=A0 =C2=A0 ' =C2=A0 =C2=A0 Behnam Esfahbod
> =C2=A0 =C2=A0'
> =C2=A0 * =C2=A0.. =C2=A0 http://behnam.esfahbod.info
> =C2=A0* =C2=A0` =C2=A0* =C2=A0http://zwnj.org
> =C2=A0 * o * =C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B<= br> >
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>
>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds

Francisco Obispo=
Director of Applications and Services - ISC
email: fobispo@isc.org
Phone: +1 65= 0 423 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D B38DB1BE

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds



--
=
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8= =A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9= 7520 5701 CA40 259E 0F8B

--f46d0418270e4a249304d7d4ffab-- From johnl@taugh.com Wed Mar 13 14:44:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FAA21F8C4F for ; Wed, 13 Mar 2013 14:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53SKF3gYN+X6 for ; Wed, 13 Mar 2013 14:44:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B7F4621F8B9F for ; Wed, 13 Mar 2013 14:44:02 -0700 (PDT) Received: (qmail 87313 invoked from network); 13 Mar 2013 21:44:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15510.5140f322.k1303; bh=E52mE6vbglQc8iJ8AhuoF4jP2v9h8RoCgz5ycDqiRnM=; b=vamMdp6Sgs+1lBAql0fzSTOLClIfyD/aRpt3tCEIZqkGzS8BH5BJjym6jN1Bs1w6lqx1WOePOUP6t+yIha+3+SAY3s9LpVuejswed4X3kYsrwYSwx4ZesrcpKgGwBwFsrCSuw0mIGbqfOu/qFCwY0jhe4xkG9i7ePzl6XynxRiE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15510.5140f322.k1303; bh=E52mE6vbglQc8iJ8AhuoF4jP2v9h8RoCgz5ycDqiRnM=; b=YD6yQ+KnsrVZ3yYJK7gQhxjf13h361D2Au22aluqV90kJi5HMXL2D701RaookbLlCiltOGoqZoDy+y9oTSOLyecTV3hLVlHo0CrZiviXxx++ybRFgJQCmINqp2Rtk1YHBFIT8EGUhFQF17zGKDAfIhCv+c7ynZaYYQ6dPlkvlqE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 13 Mar 2013 21:43:40 -0000 Date: 13 Mar 2013 17:44:01 -0400 Message-ID: From: "John R Levine" To: "Joseph Yee" In-Reply-To: References: <20130313202630.71366.qmail@joyce.lan> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3395@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:44:03 -0000 > This takes care of dump client request. That's only first half. > > And do servers expect do more on response when dump request comes in? No, they give the same response as always, since they can't tell what the client is. Having written my share of dumb programs, I expect there will be two general kinds. One is for debugging, and they'll just display whatever the result is. The other is likely to be looking for some particular part of the response, perhaps a contact telephone number or the country of the registrant. For that latter group, it would be nice to return both the U-label and the A-label, so dumb clients that want one or the other can just pick it out of the result, without having to drag in an IDNA library to do translations. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From simon.perreault@viagenie.ca Wed Mar 13 14:59:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BC621F87D0 for ; Wed, 13 Mar 2013 14:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8-wZSIJZpTy for ; Wed, 13 Mar 2013 14:59:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id A9A8F21F841D for ; Wed, 13 Mar 2013 14:59:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C021240431; Wed, 13 Mar 2013 17:59:25 -0400 (EDT) Message-ID: <5140F6BC.2030804@viagenie.ca> Date: Wed, 13 Mar 2013 17:59:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF336D@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF336D@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:59:57 -0000 Le 2013-03-13 16:40, Andy Newton a écrit : > On 3/13/13 4:11 PM, "Simon Perreault" wrote: > >> But this is not the actual problem. The problem is that current >> implementations do things like this: >> >> "description" : [ >> "Lunar NIC has attempted", >> "to verify the data for this", >> "contact, but has received no", >> "response from the POC since 2010-07-28." ] >> >> Can we at least agree that this is wrong? > > Yes. Servers should let the clients determine line breaks. Ok, good. Any idea how we could translate that into text? "The "description" element's value is an array of strings. Each string corresponds to a ....?" Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From johnl@iecc.com Wed Mar 13 15:38:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6811E80FA for ; Wed, 13 Mar 2013 15:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.919 X-Spam-Level: X-Spam-Status: No, score=-110.919 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RusSiKlMBUSx for ; Wed, 13 Mar 2013 15:38:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 35F6F21F8B47 for ; Wed, 13 Mar 2013 15:38:15 -0700 (PDT) Received: (qmail 743 invoked from network); 13 Mar 2013 22:38:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 22:38:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140ffd6.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=NW42jgxpGYUueiVbM92n+lKzY4m87R9iwLBqPiuiGR0=; b=PxONUUTIEAQH1h66PFXWj53YydKxHfK2ZMSZP68s0f/miwDfsXpLxGQq1H9RrMQFQ4Ua7kHJ61YpwktN+55ei3t7pHHIlZJx4LhnEoT0zb4vWSa+0WMLOiha6PXkeCfkI18QX60rttdMggwAXq2dCeN6ELsIs4QxfbdxBxIhYsQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140ffd6.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=NW42jgxpGYUueiVbM92n+lKzY4m87R9iwLBqPiuiGR0=; b=TlNb3y+E5iwwIH4j2wTcwels7uOJEccaQ7bGKPkhqw+HgbHw8bEtyG7yr7xrM1x43tdrNMEUHwG+gzsZM3WXZcz6gM/eEzohw8nGHagXYo8ZduUB4TRYbV8wCLQAiWxI7E6jcfIS458p99QTBqqHBpbwL6HXgFtI4mIBhr81rZs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 22:37:52 -0000 Message-ID: <20130313223752.17140.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF33B4@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:38:16 -0000 >1. If the documents are combined, the basic search features will have to >wait on the advanced search features to be defined. Wasn't one of the >worries being able to show ICANN we could get this done? I'd rather start with one document. If we seem to be bikeshedding about some of the options, we can split them into another document. >3. When people talk about which features they support, a lot of times they >refer to RFC numbers. Being able to say clearly that an implementation >supports RFC XXXX usually helpful. There are a lot of standards with optional parts. Supporting it means you support all of the mandatory parts, and maybe the optional parts. While it is certainly possible that people will provide a zillion kinds of extremely clever sorts, I would push back hard at any that haven't been at least approximately implemented, since history suggests that purely paper designs usually remain that way. From andy@arin.net Wed Mar 13 16:38:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2E11E8135 for ; Wed, 13 Mar 2013 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.199 X-Spam-Level: X-Spam-Status: No, score=-7.199 tagged_above=-999 required=5 tests=[AWL=3.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NapY07G+Ef4p for ; Wed, 13 Mar 2013 16:38:30 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 63DA011E8134 for ; Wed, 13 Mar 2013 16:38:30 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 35FFC164F59; Wed, 13 Mar 2013 19:37:57 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 7D7A1164ECB; Wed, 13 Mar 2013 19:37:56 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 13 Mar 2013 19:37:41 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 19:37:55 -0400 From: Andy Newton To: Simon Perreault Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+ICAAFkpAP//2HqA Date: Wed, 13 Mar 2013 23:37:54 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF34E0@CHAXCH01.corp.arin.net> In-Reply-To: <5140F6BC.2030804@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <360E783FAA4C204BA80849FF9FF4EFE6@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:38:31 -0000 On 3/13/13 5:59 PM, "Simon Perreault" wrote: >Any idea how we could translate that into text? > >"The "description" element's value is an array of strings. Each string >corresponds to a ....?" Paragraph? Item in a list? -andy From simon.perreault@viagenie.ca Wed Mar 13 16:49:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA411E80D5 for ; Wed, 13 Mar 2013 16:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB61EJ+v2WCV for ; Wed, 13 Mar 2013 16:49:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1572311E80C5 for ; Wed, 13 Mar 2013 16:49:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 69B3B40431; Wed, 13 Mar 2013 19:49:26 -0400 (EDT) Message-ID: <51411085.8030000@viagenie.ca> Date: Wed, 13 Mar 2013 19:49:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF34E0@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF34E0@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:49:27 -0000 Le 2013-03-13 19:37, Andy Newton a écrit : > On 3/13/13 5:59 PM, "Simon Perreault" wrote: > >> Any idea how we could translate that into text? >> >> "The "description" element's value is an array of strings. Each string >> corresponds to a ....?" > > Paragraph? Item in a list? Both delve into presentation. We don't want to reinvent HTML. If we can't figure it out, why do we have an array? Why not a single string? I'll go further: make it a single string of HTML. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From marc.blanchet@viagenie.ca Wed Mar 13 16:53:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7A21F8CD4 for ; Wed, 13 Mar 2013 16:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy3sG6gjgqXF for ; Wed, 13 Mar 2013 16:53:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CA21F869A for ; Wed, 13 Mar 2013 16:53:03 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8F7B140431; Wed, 13 Mar 2013 19:52:32 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <51411085.8030000@viagenie.ca> Date: Wed, 13 Mar 2013 19:52:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF34E0@CHAXCH01.corp.arin.net> <51411085.8030000@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:53:04 -0000 Le 2013-03-13 =E0 19:49, Simon Perreault a = =E9crit : > Le 2013-03-13 19:37, Andy Newton a =E9crit : >> On 3/13/13 5:59 PM, "Simon Perreault" = wrote: >>=20 >>> Any idea how we could translate that into text? >>>=20 >>> "The "description" element's value is an array of strings. Each = string >>> corresponds to a ....?" >>=20 >> Paragraph? Item in a list? >=20 > Both delve into presentation. We don't want to reinvent HTML. >=20 > If we can't figure it out, why do we have an array? Why not a single = string? single string. >=20 > I'll go further: make it a single string of HTML. the whole HTML5 spec? that is the problem of the idea... what would be = the tags... we don't want to go there. Marc. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Wed Mar 13 17:04:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B631111E80E0 for ; Wed, 13 Mar 2013 17:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.932 X-Spam-Level: X-Spam-Status: No, score=-110.932 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7stPeDV6dBe for ; Wed, 13 Mar 2013 17:04:14 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AE40C11E80C5 for ; Wed, 13 Mar 2013 17:04:13 -0700 (PDT) Received: (qmail 22136 invoked from network); 14 Mar 2013 00:04:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Mar 2013 00:04:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514113fa.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=aih0vVG0C7zHgBw0bMEDCN4d0uh9I/OMj+5KKq4A9fU=; b=DxOoWSjHv6SPFcJ2SlK3kqNFqsLQRIdPiMrBfvMwrQElINStqh1WSZZiWXrc5EGypXIre6LTkvktq0epGWoslg6X3WWyeCU6nQbfXOENQCiYtLg7jjNiFQ6RFL5q0N1TRW4lT5VuCNQLMpx1I/JOrcIoDGtfOWXEBdx9HDmybhM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514113fa.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=aih0vVG0C7zHgBw0bMEDCN4d0uh9I/OMj+5KKq4A9fU=; b=cTR9NUfdqraBZ66LpzlP5Bctzf3uu/EVEL1RfSvusUqHGbYS8Lug1tJEtnncD00DjXgxxgZbCUsOn8CLjNUe0BakAPpF08I0xHefEmdZCyBPIyRdjmjK0gcR2sPuEGbN+8qA2E7ay9eHKNoPZF8yz1z76Z9E2KTs/z81Cru0E2U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Mar 2013 00:03:48 -0000 Message-ID: <20130314000348.45718.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 00:04:14 -0000 >single string. Unless the divisions have some semantic meaning like the lines of a postal address (yes, I know we're planning to use jcard, it's an example) I don't see any reason to divide it up. From bje@apnic.net Wed Mar 13 18:25:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85CE11E80E6 for ; Wed, 13 Mar 2013 18:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc4wPbQLmCnh for ; Wed, 13 Mar 2013 18:25:06 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id A671A11E80E2 for ; Wed, 13 Mar 2013 18:25:05 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 14 Mar 2013 11:23:47 +1000 (EST) Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67%18]) with mapi id 14.01.0218.012; Thu, 14 Mar 2013 11:25:02 +1000 From: Byron Ellacott To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpijZjAAgAAIBQCAABYcAIAAG4UAgAADOICAAADdAIAAAygAgAC+VIA= Date: Thu, 14 Mar 2013 01:25:02 +0000 Message-ID: In-Reply-To: <20130314000348.45718.qmail@joyce.lan> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.172] Content-Type: text/plain; charset="us-ascii" Content-ID: <015227A9235FDE4A8FD66A94BE6700A6@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 01:25:06 -0000 On 14/03/13 10:03 AM, "John Levine" wrote: >>single string. > >Unless the divisions have some semantic meaning like the lines of a >postal address (yes, I know we're planning to use jcard, it's an >example) I don't see any reason to divide it up. Existing data models have multiple values possible for fields like description. What should a server do if their port 43 data model has, e.g.: description: This a really great description: network block I have here. I can look at that and see it should be a single string, and it can be joined with a space. But what about: description: Customers for which FOO-IX provides global transit description: ** PLEASE CHECK FOR MORE UP-TO-DATE RECORDS IN RADB ** These look like two separate strings, to me. Would it be OK to join them with a space? Semantically, that might not be too bad. But what about: description: Generated by FOO-IX description: Customers in the northern region As two separate pieces of data, this tells me it was generated by FOO-IX, and it is for customers in the northern region, but combined, it tells me it was generated by the customers themselves. I think descriptions need to remain as a list of strings, though I would much prefer if that first example I gave was a single string. I'd rather have an end user have to piece together two strings in a list to get the sentence than have an end user get the wrong information because all strings have been pieced together already. I'd also prefer to be noting the correct behaviour in the draft, such that future data collection work might proceed along lines more suited to this new data model. Byron From bje@apnic.net Wed Mar 13 18:32:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BE11E80A6 for ; Wed, 13 Mar 2013 18:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+lXjQveOylt for ; Wed, 13 Mar 2013 18:32:45 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 8688911E809C for ; Wed, 13 Mar 2013 18:32:43 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 14 Mar 2013 11:31:26 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 14 Mar 2013 11:32:41 +1000 Received: from IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Thu, 14 Mar 2013 11:32:40 +1000 From: Byron Ellacott To: Andy Newton , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikZ4eA Date: Thu, 14 Mar 2013 01:32:39 +0000 Message-ID: In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF322B@CHAXCH01.corp.arin.net> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.172] Content-Type: text/plain; charset="us-ascii" Content-ID: <150B078F52783343BE9E9BB579A2F944@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 01:32:45 -0000 Hi Andy, On 14/03/13 2:54 AM, "Andy Newton" wrote: >{ > "remarks": > [ > { > "title": "Rights of Use Claim", > "description" : > [ > "The following information provides the rights of use information >for this internet resource.", > "Eligibility Type: Company", > "Eligibility Name: Acme Widgets", > "Eligibility ID: BN955912" > ] > } > ] >} I am uncomfortable with this specific example. RDAP gives us structured data, so clients don't have to pull strings apart to get the data they desire. This example puts data back into unstructured strings that clients would have to pull apart again. I'd rather that the eligibility data was a local registry extension, as per the "E" in WEIRDS: { "rdapConformance": [ "rdap_level_0", "eligibility_level_0" ], "remarks": [ { "title": "Rights of Use Claim", "description" : [ "The information contained in the eligibilty extension of this record provides rights of use information for this Internet resource." ] } ], "eligibility_type": "Company", "eligibility_name": "Acme Widgets", "eligibiltiy_id": "BN955912" } Byron From zhoulinlin@cnnic.cn Wed Mar 13 19:44:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DBB21F8E6E for ; Wed, 13 Mar 2013 19:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pym73kB2+Du9 for ; Wed, 13 Mar 2013 19:44:17 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 8DF0921F8E4C for ; Wed, 13 Mar 2013 19:44:14 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 14 Mar 2013 10:44:08 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" , References: In-Reply-To: Date: Thu, 14 Mar 2013 10:44:07 +0800 Message-ID: <01f601ce205d$cd454780$67cfd680$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F7_01CE20A0.DB688780" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4fa7ZBDGZxIOlFQHaxUJJUJ7zX1AA8f68A Content-Language: zh-cn Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 02:44:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01F7_01CE20A0.DB688780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd like to continue the search work after the path settled. Linlin From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, March 13, 2013 5:51 AM To: weirds@ietf.org Subject: [weirds] Search documents I didn't actually do a hum request in the session today, but there seemed to be warm fuzzies in the direction of combining the search drafts into a "basic" set of capabilities and an "extended" set. Does anyone disagree with that being a reasonable path forward? We can select editors and such after we figure out a path here. -MSK ------=_NextPart_000_01F7_01CE20A0.DB688780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d = like to continue the search work after the path = settled.

 =

Linlin=

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Wednesday, March 13, 2013 5:51 = AM
To: weirds@ietf.org
Subject: [weirds] Search = documents

 

I didn't actually do a = hum request in the session today, but there seemed to be warm fuzzies in = the direction of combining the search drafts into a "basic" = set of capabilities and an "extended" set.

Does anyone = disagree with that being a reasonable path forward?  We can select = editors and such after we figure out a path = here.

-MSK

------=_NextPart_000_01F7_01CE20A0.DB688780-- From johnl@taugh.com Wed Mar 13 22:22:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018BD21F8D8E for ; Wed, 13 Mar 2013 22:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGlnXt3X1Hn8 for ; Wed, 13 Mar 2013 22:22:01 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18521F8D76 for ; Wed, 13 Mar 2013 22:21:59 -0700 (PDT) Received: (qmail 99439 invoked from network); 14 Mar 2013 05:21:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1846d.51415e76.k1303; bh=jb8iVy16mtlNszDq51UcvcrkGiNTheoPPUqWRN95aPI=; b=satSBJqFaplR41rxC/weD5JoiCE2d5C4dKAR3jozOVnk4QGslQDWFiAJAGVCsytIH7vysPqjItwVokYpJaIdDwRbzO7FdEgCHSd94YobWAmZ6KkudwmF52Cn3Itlfjj6hZSevkkB91nDmZPgkQiawDm+L4RvaSWLX+i3D14q5Ck= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1846d.51415e76.k1303; bh=jb8iVy16mtlNszDq51UcvcrkGiNTheoPPUqWRN95aPI=; b=bEX/TtQOn5e/YPRybTomPsULvxKJRSitt+Mcggc+ftNWbRiYw7NZj2x5mnf2IY2hbcPn6tEY0jDmMGO3XE4UTkZOrkTaKc22kc5RIiwWZ4HAFRhAJX4Xi6gw6LUamdSi+/wndqVyLn+OJixWvWJNtJXT+Z/LMN5q9DqlFbvUK7A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Mar 2013 05:21:35 -0000 Date: 14 Mar 2013 01:21:56 -0400 Message-ID: From: "John R Levine" To: "Byron Ellacott" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 05:22:02 -0000 > description: This a really great > description: network block I have here. Looks like one string. > description: Customers for which FOO-IX provides global transit > description: ** PLEASE CHECK FOR MORE UP-TO-DATE RECORDS IN RADB ** Looks like two strings. > description: Generated by FOO-IX > description: Customers in the northern region Could be either. Like I said, they should be separate strings if there is some semantic division. I don't think we need to obsess about this, server operators can do whatever seems reasonable. Just please don't break them to try to format them into lines of length 80 or whatever. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From bje@apnic.net Wed Mar 13 22:40:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDD921F8ECA for ; Wed, 13 Mar 2013 22:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd5IK0cpXX+W for ; Wed, 13 Mar 2013 22:40:11 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id E4FE921F8ECB for ; Wed, 13 Mar 2013 22:40:10 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 14 Mar 2013 15:38:51 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Thu, 14 Mar 2013 15:40:07 +1000 From: Byron Ellacott To: John R Levine Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpijZjAAgAAIBQCAABYcAIAAG4UAgAADOICAAADdAIAAAygAgAC+VID//5qPAIAArLEA Date: Thu, 14 Mar 2013 05:40:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.172] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D790B123D6E0749918C0F40A4A45129@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 05:40:12 -0000 Hi John, On 14/03/13 3:21 PM, "John R Levine" wrote: >Like I said, they should be separate strings if there is some semantic >division. I don't think we need to obsess about this, server operators >can do whatever seems reasonable. Just please don't break them to try to >format them into lines of length 80 or whatever. I think we're in agreement, and I misread your last message as suggesting everything should always be one string, sorry! :-) Byron From simon.perreault@viagenie.ca Thu Mar 14 06:36:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED991F0D12 for ; Thu, 14 Mar 2013 06:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdenWkx8ALeD for ; Thu, 14 Mar 2013 06:36:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA61F0D11 for ; Thu, 14 Mar 2013 06:36:32 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1848A4040C for ; Thu, 14 Mar 2013 09:36:01 -0400 (EDT) Message-ID: <5141D241.3090206@viagenie.ca> Date: Thu, 14 Mar 2013 09:36:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:36:40 -0000 Le 2013-03-13 21:25, Byron Ellacott a écrit : > Existing data models have multiple values possible for fields like > description. What should a server do if their port 43 data model has, > e.g.: > > > description: This a really great > description: network block I have here. Please allow me to continue with my heresy for just a bit... If what you have in your database is preformatted text, you should be able to return preformatted text. "description": "
This is a really great\nnetwork block I have 
here.
" Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From andy@arin.net Thu Mar 14 07:04:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6047B11E8131 for ; Thu, 14 Mar 2013 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdfCEgzSowq0 for ; Thu, 14 Mar 2013 07:04:20 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC811E8125 for ; Thu, 14 Mar 2013 07:04:20 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 5A95E21369F; Thu, 14 Mar 2013 10:04:20 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 11CC521368A; Thu, 14 Mar 2013 10:04:15 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Mar 2013 10:03:35 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 10:04:14 -0400 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+ICAAFkpAP//2HqAgABGQ4CAAADcAIAAAygAgAAWswCAAMw8gP//xNeA Date: Thu, 14 Mar 2013 14:04:13 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF369B@CHAXCH01.corp.arin.net> In-Reply-To: <5141D241.3090206@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:04:21 -0000 On 3/14/13 9:36 AM, "Simon Perreault" wrote: >"description": "
This is a really great\nnetwork block I have
>here.
" Simon, As a security measure, we purposefully don't allow HTML tags in our Whois output as we don't want it being a vector for embedding malicious scripts into web sites that redisplay our data. And if we take into account HTML, do we also want to take into account PDF or other formats? I don't think we should worry about the format registries use natively. -andy From andy@arin.net Thu Mar 14 07:04:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B275C11E8141 for ; Thu, 14 Mar 2013 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiQdPa6maeUp for ; Thu, 14 Mar 2013 07:04:47 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 6308511E8134 for ; Thu, 14 Mar 2013 07:04:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 15C5821368A; Thu, 14 Mar 2013 10:04:47 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 1827721369F; Thu, 14 Mar 2013 10:04:42 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Mar 2013 10:04:23 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 10:04:40 -0400 From: Andy Newton To: John R Levine , Byron Ellacott Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+ICAAFkpAP//2HqAgABGQ4CAAADcAIAAAygAgAAWswCAAEIwAIAATv8A Date: Thu, 14 Mar 2013 14:04:39 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF36AA@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:04:49 -0000 On 3/14/13 1:21 AM, "John R Levine" wrote: >Like I said, they should be separate strings if there is some semantic >division. I don't think we need to obsess about this, server operators >can do whatever seems reasonable. Just please don't break them to try to >format them into lines of length 80 or whatever. I agree with this. -andy From andy@arin.net Thu Mar 14 07:08:58 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3821F8C2A for ; Thu, 14 Mar 2013 07:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGJcdQUS1rZb for ; Thu, 14 Mar 2013 07:08:58 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 5466821F8461 for ; Thu, 14 Mar 2013 07:08:58 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E5697165262; Thu, 14 Mar 2013 10:08:57 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 9BBC516528F; Thu, 14 Mar 2013 10:08:53 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Mar 2013 10:08:35 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 10:08:50 -0400 From: Andy Newton To: Byron Ellacott , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikZ4eAgADTSoA= Date: Thu, 14 Mar 2013 14:08:49 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF36BD@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <41862DDC8443B44298BBDC67EBEEE06F@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:08:59 -0000 On 3/13/13 9:32 PM, "Byron Ellacott" wrote: >I am uncomfortable with this specific example. RDAP gives us structured >data, so clients don't have to pull strings apart to get the data they >desire. Byron, This was in response to the notion that generic clients won't display custom JSON attributes. If a registry fears that will happen, they can use the remarks. But I agree with you. -andy From simon.perreault@viagenie.ca Thu Mar 14 07:14:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5429B21F8EA8 for ; Thu, 14 Mar 2013 07:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW8T-Lwr-2Nh for ; Thu, 14 Mar 2013 07:14:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id E743311E80DF for ; Thu, 14 Mar 2013 07:14:11 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4056F425ED; Thu, 14 Mar 2013 10:13:41 -0400 (EDT) Message-ID: <5141DB14.7010601@viagenie.ca> Date: Thu, 14 Mar 2013 10:13:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF369B@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF369B@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:14:18 -0000 Le 2013-03-14 10:04, Andy Newton a écrit : > On 3/14/13 9:36 AM, "Simon Perreault" wrote: > >> "description": "
This is a really great\nnetwork block I have
>> here.
" > > As a security measure, we purposefully don't allow HTML tags in our Whois > output as we don't want it being a vector for embedding malicious scripts > into web sites that redisplay our data. Interesting! > And if we take into account HTML, do we also want to take into account PDF > or other formats? I don't think we should worry about the format > registries use natively. It's all about what people have in their databases. If you have preformatted text, which I suspect many do, it's not clear to me what you're supposed to do with the current proposal. Join all the lines with a single space character? Insert newlines? Use multiple array items? If what you have in your database is paragraphs and bulleted lists, I equally don't know what you're supposed to do to make it fit into the JSON. Multiple array items, I guess, but it still doesn't seem right. The reason we saw very different results with current implementations is that this is underspecified, and it's going to cause interop issues if we don't say something. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From andy@arin.net Thu Mar 14 07:31:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D6111E818F for ; Thu, 14 Mar 2013 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMIs5fFNoncT for ; Thu, 14 Mar 2013 07:31:31 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A26BD11E818A for ; Thu, 14 Mar 2013 07:30:51 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 5205E1652A1; Thu, 14 Mar 2013 10:30:51 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 09478165298; Thu, 14 Mar 2013 10:30:46 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Mar 2013 10:29:53 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 10:30:12 -0400 From: Andy Newton To: Simon Perreault Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+ICAAFkpAP//2HqAgABGQ4CAAADcAIAAAygAgAAWswCAAMw8gP//xNeAAAi1wQD//8GTgA== Date: Thu, 14 Mar 2013 14:30:11 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3721@CHAXCH01.corp.arin.net> In-Reply-To: <5141DB14.7010601@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <1240AB09ABB811458AF9C3BC90E4962A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:31:33 -0000 On 3/14/13 10:13 AM, "Simon Perreault" wrote: >It's all about what people have in their databases. > >If you have preformatted text, which I suspect many do, it's not clear >to me what you're supposed to do with the current proposal. Join all the >lines with a single space character? Insert newlines? Use multiple array >items? If a registry uses EBCDIC or encodes their structures in EDI or MIME, then it is up to them to parse it out and put it into JSON. They will be the best to do it, not the client. If we attempt to take into account how every registry stores their data, we'll never get this to work. -andy From marc.blanchet@viagenie.ca Thu Mar 14 07:49:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE75011E8155 for ; Thu, 14 Mar 2013 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOhjq3PPunxy for ; Thu, 14 Mar 2013 07:49:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B511E8150 for ; Thu, 14 Mar 2013 07:49:38 -0700 (PDT) Received: from dhcp-51e2.meeting.ietf.org (dhcp-51e2.meeting.ietf.org [130.129.81.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4CBB24040C; Thu, 14 Mar 2013 10:49:07 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Marc Blanchet In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3721@CHAXCH01.corp.arin.net> Date: Thu, 14 Mar 2013 10:49:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3721@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:49:52 -0000 Le 2013-03-14 =E0 10:30, Andy Newton a =E9crit : > On 3/14/13 10:13 AM, "Simon Perreault" = wrote: >=20 >> It's all about what people have in their databases. >>=20 >> If you have preformatted text, which I suspect many do, it's not = clear >> to me what you're supposed to do with the current proposal. Join all = the >> lines with a single space character? Insert newlines? Use multiple = array >> items? >=20 > If a registry uses EBCDIC or encodes their structures in EDI or MIME, = then > it is up to them to parse it out and put it into JSON. They will be = the > best to do it, not the client. If we attempt to take into account how > every registry stores their data, we'll never get this to work. right. moreover, what is important is the wire format. I'm against any = presentation tags such as HTML, because it is going to be a rathole: = which tags should be used, which html attributes, etc... overdesign for = a simple string record. Marc. >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From james.mitchell@ausregistry.com.au Thu Mar 14 07:52:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB411E81EA for ; Thu, 14 Mar 2013 07:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew6eteZx+dnG for ; Thu, 14 Mar 2013 07:52:25 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1104B11E8197 for ; Thu, 14 Mar 2013 07:52:23 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 15 Mar 2013 01:52:19 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Fri, 15 Mar 2013 01:52:09 +1100 From: James Mitchell To: "Hollenbeck, Scott" , "weirds@ietf.org" Date: Fri, 15 Mar 2013 01:52:15 +1100 Thread-Topic: [weirds] A-label and U-label Lookups Thread-Index: Ac4gw4CeNhA87VsyRy2SQ2AXY6ezsA== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:52:34 -0000 Scott, Comments below, prefixed with JM. James On 14/03/13 3:29 AM, "Hollenbeck, Scott" wrote: >While on the way home last night I had an interesting conversation with >one of my colleagues while we were waiting for our flights at the >airport. He asked me a question about IDNs that made me think. > >Imagine a web browser being used as an RDAP client. A human user types a >URL that looks like this in the address bar: > >http://example.com/domain/ex=E4mple.com > >If we require the client to convert the domain name into a-label form, >the browser is going to have to parse and process the path portion of the >URL to convert /domain/ex=E4mple.com to /domain/xn--exmple-cua.com). That >means "browser mods needed", which may be an impediment to adoption. JM: Since you are talking about browser clients then we should look at the behaviour of domain (host) names appearing the the URL/IRI. Browsers map Unicode strings into a domain name that can be looked up in the DNS. I am hesitant to use the terms U-label and A-label in this process because the definition of A/U-label is that they are IDNA-valid according to the IDNA 2008 protocol [https://tools.ietf.org/html/rfc5890#page-11], and as far as I am aware browsers are still using IDNA 2003 or equivalent mappings. Considering that, a user types the domain =D6BB.com into their browser and it works (converts it to xn--bb-eka.com, =F6bb.com), however =D6BB is not a U-label. The user then somehow gets to /domain/=D6BB.com and now the weirds server would need to implement the same mapping as the browser or otherwise risk introducing confusion. That said, servers would have some idea of the possible mappings that would occur for the languages/scripts available in their registry and should be able to do a fairly accurate job at mapping the Unicode string into the expected domain name. The way I have implemented this before is to guarantee that LDH-labels (xn--bb-eka.com) and U-labels (=F6bb.com) will work as provided without mapping, and your mileage may vary when using arbitrary Unicode strings (=D6BB.com, o''bb.com - where '' is my kludge for combining diaeresis). On the issue of mapping, I think I would prefer if the IRI changed from /domain/=D6BB.com into /domain/=F6bb.com (redirect?), such that the path always contained only A-labels or U-labels. This would at least be consistent with how my browser renders the domain name (other browsers may do different things). > >As I slept on this last night I kept hearing "be liberal in what you >accept". That's making me think twice about a-labels only. Supporting >U-labels for lookups would mean more work for DNR server operators, but >it may be work that's worth the price if it truly helps the adoption >process. JM: A-labels actually require more work for us if we are to match unallocated variants. > >So should the query/lookup draft include support for both a-labels and >u-labels? I'm seriously thinking it should. JM: Yes, +1. And if you are expecting this service to work for dumb software clients proxying for human users then we should probably mention that there may be usability issues if they do not consider mappings too. > >Scott >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From carlosm3011@gmail.com Thu Mar 14 07:53:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14B311E81E8 for ; Thu, 14 Mar 2013 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvkviSZA-MqE for ; Thu, 14 Mar 2013 07:53:23 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBC71F0D11 for ; Thu, 14 Mar 2013 07:53:08 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id wy12so2309671pbc.21 for ; Thu, 14 Mar 2013 07:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Va+6MHuUHvJvYaT1vMdUlz4/wEbCBlt6B1cYnEuufXw=; b=cGojoet82N4QWPQY9ytUfIH1rpYaX4UKP3ozBeUJEPA7BH7eF00iAnWbxDg4YjQexj Lkld6VQxVJEuv6+t6UQt07lTl2WVWwPgOEl8VAGSt+u5m410Mcl6kWFLlhKu1hsUqgMU fEpOQRbHl2br3i6VvRc2ApeaLypkN3uMiPaAOBBbg5Ztn6h76OmqnwiYWcDTgRBaJhxu GnpWlAU1krAXIP8la6tOWu2WKyN26aEJaY0HWWKLr3THSy277OzMTEJVNOKYzBHjUDUk ChI/QK3QQJ7C61WSlm5KnPU5b37fKbPcA17TUVyNaesLQNtCZQhFGhYZIbNOxW1aRmkq ADkQ== X-Received: by 10.68.196.1 with SMTP id ii1mr6556590pbc.93.1363272787228; Thu, 14 Mar 2013 07:53:07 -0700 (PDT) Received: from dhcp-5540.meeting.ietf.org ([2001:df8:0:80:a0e7:ad98:74e0:6b2b]) by mx.google.com with ESMTPS id 4sm3620785pbn.23.2013.03.14.07.53.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:53:05 -0700 (PDT) Message-ID: <5141E452.7030308@gmail.com> Date: Thu, 14 Mar 2013 10:53:06 -0400 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Marc Blanchet References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3721@CHAXCH01.corp.arin.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:53:28 -0000 On 3/14/13 10:49 AM, Marc Blanchet wrote: > > Le 2013-03-14 à 10:30, Andy Newton a écrit : > >> On 3/14/13 10:13 AM, "Simon Perreault" wrote: >> >>> It's all about what people have in their databases. >>> ... snip ... > > right. moreover, what is important is the wire format. I'm against any presentation tags such as HTML, because it is going to be a rathole: which tags should be used, > which html attributes, etc... overdesign for a simple string record. Agree. Fully. > > Marc. > >> >> -andy >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From james.mitchell@ausregistry.com.au Thu Mar 14 08:07:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5311E8268 for ; Thu, 14 Mar 2013 08:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy+jczdRHfXe for ; Thu, 14 Mar 2013 08:07:06 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 826FE11E8258 for ; Thu, 14 Mar 2013 08:06:16 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 15 Mar 2013 02:06:15 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Fri, 15 Mar 2013 02:06:05 +1100 From: James Mitchell To: Andy Newton , Byron Ellacott , "weirds@ietf.org" Date: Fri, 15 Mar 2013 02:06:13 +1100 Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: Ac4gxXKpN/yLxLOSSRufrr7jBFmDXQ== Message-ID: In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF36BD@CHAXCH01.corp.arin.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:07:10 -0000 Andy, Thanks for putting together the suggestion of using the remarks fields, it looks like a reasonable method of achieving the desired outcome, assuming remarks are rendered to users behind dumb clients. But unfortunately no matter which way you spin it, remarks or custom attributes/names, either the human user or software parser is a potential loser. I'd rather put my money behind a solution where human users behind dumb client software saw all the data with parsers having to deal with semi-structured text (if they so cared about it), than another solution where there exists the possibility that human users behind the same dumb clients missed the data (unknowingly) but gave parsers structured data. Thanks, James On 15/03/13 1:08 AM, "Andy Newton" wrote: >On 3/13/13 9:32 PM, "Byron Ellacott" wrote: > >>I am uncomfortable with this specific example. RDAP gives us structured >>data, so clients don't have to pull strings apart to get the data they >>desire. > >Byron, > >This was in response to the notion that generic clients won't display >custom JSON attributes. If a registry fears that will happen, they can use >the remarks. But I agree with you. > >-andy > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Thu Mar 14 08:10:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF53211E827F for ; Thu, 14 Mar 2013 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wZbTalPGAQq for ; Thu, 14 Mar 2013 08:10:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C011E8289 for ; Thu, 14 Mar 2013 08:10:22 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 694744040C for ; Thu, 14 Mar 2013 11:10:16 -0400 (EDT) Message-ID: <5141E857.5020409@viagenie.ca> Date: Thu, 14 Mar 2013 11:10:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3721@CHAXCH01.corp.arin.net> <5141E452.7030308@gmail.com> In-Reply-To: <5141E452.7030308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:10:38 -0000 Le 2013-03-14 10:53, Carlos M. Martinez a écrit : >> right. moreover, what is important is the wire format. I'm against any presentation tags such as HTML, because it is going to be a rathole: which tags should be used, >> which html attributes, etc... overdesign for a simple string record. > > Agree. Fully. Alright, alright, I'll listen to the voice of reason. My heresy is over. I'm cured, I swear. I feel much better already. I still hope to see some constraining text about the usage of array items that will make interop more probable. I'll wait for the next revision before commenting. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From andy@arin.net Thu Mar 14 08:12:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40BE11E827F for ; Thu, 14 Mar 2013 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bOOeij+82+C for ; Thu, 14 Mar 2013 08:12:39 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 69B2411E8278 for ; Thu, 14 Mar 2013 08:12:39 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 1C3CF16529A; Thu, 14 Mar 2013 11:12:39 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id B25E916528F; Thu, 14 Mar 2013 11:12:38 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 14 Mar 2013 11:12:20 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 11:12:37 -0400 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] remarks and client handling of free form data Thread-Index: AQHOIAt3GYjCkjA9m0GXD+FbuuzrqpikUOIA///E+ICAAFkpAP//2HqAgABGQ4CAAADcAIAAAygAgAAWswCAAMw8gP//xNeAAAi1wQD//8GTgIAASFMAgAABHgCAAATLgP//vZ2A Date: Thu, 14 Mar 2013 15:12:37 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3760@CHAXCH01.corp.arin.net> In-Reply-To: <5141E857.5020409@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <185C8FBB77C4B1418908A94A2D238801@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] remarks and client handling of free form data X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:12:40 -0000 On 3/14/13 11:10 AM, "Simon Perreault" wrote: >I still hope to see some constraining text about the usage of array >items that will make interop more probable. I'll wait for the next >revision before commenting. I'll try to work on some text to provide guidance on this. -andy From behnam@gmail.com Wed Mar 13 10:42:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96221F87E7 for ; Wed, 13 Mar 2013 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMqzeG80v2WD for ; Wed, 13 Mar 2013 10:42:15 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id DAA2621F86D5 for ; Wed, 13 Mar 2013 10:42:15 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so1254932pbc.29 for ; Wed, 13 Mar 2013 10:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iXg1cZQS2b+CIycC+i/i/MQOK10VHlCpg/hQP5RumMM=; b=ycLgg8dynO+cVG0VKjyjLdyB19e1tqeUF0VB7ex/Rn1G6AhfjTzTuGrrKtKl8e351O p+EksuAiQF4mts6u0PNwzcaBAvpSSCV6P3h9zjhTc2ZbeSOlVd1ib9qO0VrKxlUJ0ZY+ wjucSsnHRp6EJzGnF+6+MyDlVScib+ivpsDSfH4sDm7W5F3N4l6n5y2ssEIvOnUHz8ZV 2JGX3tignNo7DRnua0HhWV1KgXdbBpDo9V4nYnde7Ajb8WQ1tLCyH/AjlZ2TVF7nerPf V30a38fg5XO3YUykTEaK8Ke+19pLELrGsc9CvEOkZ2Ot7zXYAgFCRmBw0x+kwrmpFF5Z AF0g== X-Received: by 10.68.196.129 with SMTP id im1mr6861470pbc.206.1363196535273; Wed, 13 Mar 2013 10:42:15 -0700 (PDT) MIME-Version: 1.0 Sender: behnam@gmail.com Received: by 10.68.223.129 with HTTP; Wed, 13 Mar 2013 10:41:35 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3264@CHAXCH01.corp.arin.net> From: Behnam Esfahbod Date: Wed, 13 Mar 2013 13:41:35 -0400 X-Google-Sender-Auth: 7bqnF94LLFaX8QCDwseCz8JDA1A Message-ID: To: Andy Newton Content-Type: multipart/alternative; boundary=e89a8fb208ae3f374804d7d1ed03 X-Mailman-Approved-At: Thu, 14 Mar 2013 09:46:30 -0700 Cc: "weirds@ietf.org" Subject: Re: [weirds] a-labels and u-labels in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:42:17 -0000 --e89a8fb208ae3f374804d7d1ed03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy, Please don't ever do that! At IRNIC, for a short period of time we did a similar thing -- showing U-label of the requested domain and A-labels of the variants -- in our EPP extension and soon we realized it's very confusing for our clients (resellers/registrars). IMHO we need both of them everywhere, as the output is supposed to be understandable by end-users, whether they understand the script of the domain name or not. -Behnam On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton wrote: > Accepting u-labels is only half of the equation. What do people want to d= o > with the json-response? > > Is it it acceptable to say that domain names in the response are always > a-labels? Or is a better approach to say that if the name of the domain > object is a U-label, then the server SHOULD provide a variants section an= d > those MUST be a-labels? > > Opinions? > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F.B4B6.6F4C.A8AB.9BB9.7520.5701.CA40.259E.0F8B --e89a8fb208ae3f374804d7d1ed03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,

Please don't ever do that! At= IRNIC, for a short period of time we did a similar thing -- showing U-labe= l of the requested domain and A-labels of the variants -- in our EPP extens= ion and soon we realized it's very confusing for our clients (resellers= /registrars).

IMHO we need both of them everywhere, as the outp= ut is supposed to be understandable by end-users, whether they understand t= he script of the domain name or not.

-Behnam



=
On Wed, Mar 13, 2013 at 1:00 PM, Andy Newton <andy@= arin.net> wrote:
Accepting u-labels is only half of the equat= ion. What do people want to do
with the json-response?

Is it it acceptable to say that domain names in the response are always
a-labels? Or is a better approach to say that if the name of the domain
object is a U-label, then the server SHOULD provide a variants section and<= br> those MUST be a-labels?

Opinions?

-andy

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds



--
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9= =81=D9=87=D8=A8=D8=AF
ht= tp://behnam.es/
G= PG-FP: 3E7F.B4B6.6F4C.A8AB.9BB9.7520.5701.CA40.259E.0F8B

--e89a8fb208ae3f374804d7d1ed03-- From internet-drafts@ietf.org Thu Mar 14 11:47:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0E11E817C; Thu, 14 Mar 2013 11:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmFBXzMB1unL; Thu, 14 Mar 2013 11:47:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4221F8DDA; Thu, 14 Mar 2013 11:47:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130314184720.2233.33923.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2013 11:47:20 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:47:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Registration Data Access Protocol Lookup Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-03.txt Pages : 12 Date : 2013-03-14 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Thu Mar 14 11:51:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30BB11E81AF for ; Thu, 14 Mar 2013 11:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHTCIlTHpHm9 for ; Thu, 14 Mar 2013 11:51:56 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 812EE11E819C for ; Thu, 14 Mar 2013 11:51:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUUIcSVJKulCaJrwHFsEVEFX1Tp76Cwgt@postini.com; Thu, 14 Mar 2013 11:51:53 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2EIposq004302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 14:51:52 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 14:51:49 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-03.txt Thread-Index: AQHOIORfCEJxB70FNkWj0QTZGidAipilh3qw Date: Thu, 14 Mar 2013 18:51:49 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24331A2D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130314184720.2233.33923.idtracker@ietfa.amsl.com> In-Reply-To: <20130314184720.2233.33923.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:51:56 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Thursday, March 14, 2013 2:47 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Extensible Internet Registration Da= ta > Service Working Group of the IETF. >=20 > Title : Registration Data Access Protocol Lookup Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-03.txt > Pages : 12 > Date : 2013-03-14 Notes from the change summary: -03: Changed 'query' to 'lookup' in document title to better describe the 'exact match lookup' purpose of this document. Included a multitude of minor additions and clarifications provided by Marc Blanchet and Jean-Philippe Dionne. Modified the domain and name server sections to include support for IDN U-labels. Scott=20 From superuser@gmail.com Thu Mar 14 13:40:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C7B11E8158 for ; Thu, 14 Mar 2013 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndGMedmjpAp5 for ; Thu, 14 Mar 2013 13:40:22 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64A11E80D9 for ; Thu, 14 Mar 2013 13:40:22 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so2393346wgb.33 for ; Thu, 14 Mar 2013 13:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=LfRgVLGQvXr3wtgEXum2p1ptDxRoije8vzPlAtcM7Ko=; b=IPi694MTu86Y0kwA5qa1KV8WrZBRe2aALna+6tJ9XEfRmsZVOZzkPLcjVW0Zxq00tC ZhFsbm3olZznuOH8HvTQeNAi+nfBuOoadlnrZ+eOAFVGaqhkoQYK20pevZijMdTxaBHf mtBRWxMMAZN/B/LVsG+zcLss2Zw9Es8jsE0JbrBD3yz+2LPejAzdA1Z6Ge4dl5vkphZf J0yIVUQd8IyTixnhiwGuH6h85RW+jJ215yn3QkVJw3qghvCtUVPnv1gMSDaFiZYMYwXT +G6KSdknG2UvRLMXYr+aVH1uvnVmdfyOJs9UrsrSq4x9NAa7CB1bKHIAtj+sP4VQiK6/ NhHQ== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr6827934wjq.51.1363293621282; Thu, 14 Mar 2013 13:40:21 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Thu, 14 Mar 2013 13:40:21 -0700 (PDT) Date: Thu, 14 Mar 2013 16:40:21 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86cea4056dbb04d7e88832 Subject: [weirds] Agenda for today X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:40:23 -0000 --047d7b86cea4056dbb04d7e88832 Content-Type: text/plain; charset=ISO-8859-1 Starting the agenda bashing early... The leftover agenda items from Tuesday are: - Security and Federated Authentication (10 mins; Ning Kong) - AOB - ICANN's I18N work (10 mins; Steve Sheng) As far as I'm aware, that's what we have to cover in half an hour. Are there any other topics? In particular, am I missing any slide decks I should have ready? -MSK --047d7b86cea4056dbb04d7e88832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Starting the agenda bashing = early...

The leftover agenda items from Tuesday are:

- Security and Federated Authentication (10 mins; Ning Kong)
- AOB
=A0 - ICANN's I18N work (10 mins; Steve Sheng)

As far as I'm aware, that's what we have to cover in half an ho= ur.=A0 Are there any other topics?=A0 In particular, am I missing any slide= decks I should have ready?

-MSK
--047d7b86cea4056dbb04d7e88832-- From simon.perreault@viagenie.ca Thu Mar 14 15:15:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1321F9063 for ; Thu, 14 Mar 2013 15:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAqkFdw3azGj for ; Thu, 14 Mar 2013 15:15:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E521F8F81 for ; Thu, 14 Mar 2013 15:15:46 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30B8340430 for ; Thu, 14 Mar 2013 18:15:16 -0400 (EDT) Message-ID: <51424BF2.5050005@viagenie.ca> Date: Thu, 14 Mar 2013 18:15:14 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:15:47 -0000 I don't remember it being mentioned at the mic, so here's a pointer to HTTP status code 429 that can be used for rate limiting: http://tools.ietf.org/html/rfc6585#section-4 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From aservin@lacnic.net Thu Mar 14 15:42:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486D711E81B0 for ; Thu, 14 Mar 2013 15:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxwe1-V7qneT for ; Thu, 14 Mar 2013 15:41:59 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F411E81AB for ; Thu, 14 Mar 2013 15:41:59 -0700 (PDT) Received: from dhcp-17a4.meeting.ietf.org (unknown [IPv6:2001:df8:0:16:4855:8a8d:d11f:fed1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5647E308456 for ; Thu, 14 Mar 2013 19:41:46 -0300 (UYT) Message-ID: <5142522D.1050508@lacnic.net> Date: Thu, 14 Mar 2013 18:41:49 -0400 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <51424BF2.5050005@viagenie.ca> In-Reply-To: <51424BF2.5050005@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:42:00 -0000 Thanks. We are testing rate-limiting in our server, this is going to be very useful. Regards. as On 3/14/13 6:15 PM, Simon Perreault wrote: > I don't remember it being mentioned at the mic, so here's a pointer to > HTTP status code 429 that can be used for rate limiting: > > http://tools.ietf.org/html/rfc6585#section-4 > > Simon From zwnj.org@gmail.com Thu Mar 14 15:52:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A940711E81BD for ; Thu, 14 Mar 2013 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzrckcpHA3lP for ; Thu, 14 Mar 2013 15:52:36 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55011E81B8 for ; Thu, 14 Mar 2013 15:52:36 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so22209wib.1 for ; Thu, 14 Mar 2013 15:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=cF4mQ6gDZn/dve6H4Gx/zpR4VF0Rg8hc7Rc/RuTDoNY=; b=d9fpj2vSOFVQAMY3CxsWSU4F0mx5ed22saCtzEVoY/YGA5FL93Eg5R2KAouGps6as+ JWWKSoNWwEyIYN6FSE6J3u3eKS4c+pmVpjT+phmRKWN5mAxRreqJSDNLhMbian3B76O+ hJlex1KX53xL38rY0Hlss++uZ0+fJNfgnNHF3UpGTyLtEZ0Ht8HUt7FhpEv4UQCsd0wO DQi7ElpF3S5Xap4gjXnQnTi9sPDAdBDrwpp3N/mSyAML5jXarqtkATghjrvsCL0uby6l Ow49B/GnrBD6w3SQF0x1AKSJ9ngCyrcs/wwRC/RuElzb5aKWbHsCTlzTgFdfYTMyC97r 3BQA== MIME-Version: 1.0 X-Received: by 10.194.5.4 with SMTP id o4mr7305423wjo.40.1363301555266; Thu, 14 Mar 2013 15:52:35 -0700 (PDT) Sender: behnam@gmail.com X-Google-Sender-Delegation: behnam@gmail.com Received: by 10.194.26.4 with HTTP; Thu, 14 Mar 2013 15:52:35 -0700 (PDT) Date: Thu, 14 Mar 2013 18:52:35 -0400 X-Google-Sender-Auth: Vz2JVPefp2Ty1uuDrsxirpMRu1U Message-ID: From: Behnam Esfahbod To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d88edec6ad304d7ea602f Subject: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:52:37 -0000 --047d7b5d88edec6ad304d7ea602f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Scott, Just looked at the latest draft, following are a few comments regarding U-label support. 0. It's generally pretty good and it's great news that A-labels are only allowed under IDNA2008. 1. In section 3.3, It is not clear whether ALL the labels should be in one format (U-label or A-label) or is it allowed to have one label formatted as U-label and another one as A-label. Here are 4 possible representations for one FQDN, all of which must be accepted, IMO. =D9=85=D8=AB=D8=A7=D9=84.=D8=A2=D8=B2=D9=85=D8=A7=DB=8C=D8=B4=DB=8C. =D9=85=D8=AB=D8=A7=D9=84.xn--hgbk6aj7f53bba. xn--mgbh0fb.=D8=A2=D8=B2=D9=85=D8=A7=DB=8C=D8=B4=DB=8C. xn--mgbh0fb.xn--hgbk6aj7f53bba. 2. In sections 3.3 & 3.4 we have: If the client sends the server an IDN U-label, servers that support IDNs MUST convert the IDN into A-label format and perform IDNA processing as specified in RFC 5891 [RFC5891]. The server should perform an exact match lookup using the A-label. I do not understand the rational behind this paragraph. I believe we do not have the intention to tell the server implementation how to work. Some might like to take the proposed approach, but when the server is able to lookup a domain name in U-label format, it should be allowed to do so. If all we care about is the presentation format of domain names in the response document, we should just say so. And again please don't forget that domain names have (in most cases here) more than one U-label. So "an IDN U-label" is not a good way to put it. 3. Instead of "xn--xemple-9ua.com" as an IDNA example domain, I think we should use a subdomain of example.com or something like that. [OT] It's a pity that we do not have reserved FQ IDNs to use in these cases. Is there any chance we can use the example.test names here? Do we need to make it official first, as an RFC? 4. In section 5, it says: [...] but clients of programmatic interfaces may wish to submit and display A-labels or may not be able to input U-labels with their keyboard configuration. I think this part is not clear enough, as these two situations are not the only possible situations where A-labels become handy. In the first part, does "display" refer to the response from server, or just displaying the queried domain name in the UI? And finally, in the last part, it's not clear if the "keyboard configuration" is a "client" limitation or just user's configuration. Thanks, -Behnam --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --047d7b5d88edec6ad304d7ea602f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scott,

Just looked at the latest draft,= following are a few comments regarding U-label support.

0. It's generally pretty good and it's great news that= A-labels are only allowed under IDNA2008.

1. In section 3.3, It is not clear whether ALL the labe= ls should be in one format (U-label or A-label) or is it allowed to have on= e label formatted as U-label and another one as A-label.

Here are 4 possible representations for one FQDN, all of w= hich must be accepted, IMO.
=D9=85=D8=AB=D8=A7=D9=84.=D8=A2=D8=B2= =D9=85=D8=A7=DB=8C=D8=B4=DB=8C.
=D9=85=D8=AB=D8=A7=D9=84.xn--hgbk= 6aj7f53bba.
xn--mgbh0fb.=D8=A2=D8=B2=D9=85=D8=A7=DB=8C=D8=B4=DB= =8C.
xn--mgbh0fb.xn--hgbk6aj7f53bba.


2. In sections 3.3 & 3.4 we have:

=C2=A0 =C2=A0If the client sends the server an IDN U-label= , servers that support
=C2=A0 =C2=A0IDNs MUST convert the IDN int= o A-label format and perform IDNA
=C2=A0 =C2=A0processing as specified in RFC 5891 [RFC5891]. =C2=A0The = server should
=C2=A0 =C2=A0perform an exact match lookup using th= e A-label.

I do not understand the rat= ional behind this paragraph. I believe we do not have the intention to tell= the server implementation how to work. Some might like to take the propose= d approach, but when the server is able to lookup a domain name in U-label = format, it should be allowed to do so.

If all we care about is the presentation fo= rmat of domain names in the response document, we should just say so.
=

And again please don't forget that domain nam= es have (in most cases here) more than one U-label. So "an IDN U-label= " is not a good way to put it.


3. Instead of "xn--xemple-9ua.com" as an IDNA example domain, I= think we should use a subdomain of example.= com or something like that.


[OT] It's a=C2=A0pity=C2=A0tha= t we do not have reserved FQ IDNs to use in these cases. Is there any chanc= e we can use the example.test names here? Do we need to make it official fi= rst, as an RFC?


4. In section 5, it says:

=
=C2=A0 =C2=A0[...] but
=C2=A0 =C2=A0clients of pr= ogrammatic interfaces may wish to submit and display
=C2=A0 =C2= =A0A-labels or may not be able to input U-labels with their keyboard
=C2=A0 =C2=A0configuration.

I think thi= s part is not clear enough, as these two situations are not the only possib= le situations where A-labels become handy.

In the first part, does "display" refer to the response from= server, or just displaying the queried domain name in the UI?

And finally, in the last part, it's not= clear if the "keyboard configuration" is a "client" li= mitation or just user's configuration.


Thanks,
-Behnam


--
Behnam Esfahbod |=C2=A0=D8=A8=D9= =87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

--047d7b5d88edec6ad304d7ea602f-- From shollenbeck@verisign.com Thu Mar 14 16:48:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A55A11E8104 for ; Thu, 14 Mar 2013 16:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+nW2pufjcQD for ; Thu, 14 Mar 2013 16:48:20 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACAA11E80D9 for ; Thu, 14 Mar 2013 16:48:18 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUUJhwhYjsvcCh/jn+eyj4TSGIws91dij@postini.com; Thu, 14 Mar 2013 16:48:19 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2ENmFH1007890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:48:15 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 19:48:14 -0400 From: "Hollenbeck, Scott" To: Behnam Esfahbod , "weirds@ietf.org" Thread-Topic: [weirds] U-label support Thread-Index: AQHOIQahSUF3Xaljl0iew25pnt8hOJil1i/Q Date: Thu, 14 Mar 2013 23:48:14 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F243357C5BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 23:48:21 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243357C5BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogd2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlaG5hbSBFc2ZhaGJvZA0KU2VudDogVGh1cnNkYXksIE1hcmNo IDE0LCAyMDEzIDY6NTMgUE0NClRvOiB3ZWlyZHNAaWV0Zi5vcmcNClN1YmplY3Q6IFt3ZWlyZHNd IFUtbGFiZWwgc3VwcG9ydA0KDQpTY290dCwNCg0KSnVzdCBsb29rZWQgYXQgdGhlIGxhdGVzdCBk cmFmdCwgZm9sbG93aW5nIGFyZSBhIGZldyBjb21tZW50cyByZWdhcmRpbmcgVS1sYWJlbCBzdXBw b3J0Lg0KDQowLiBJdCdzIGdlbmVyYWxseSBwcmV0dHkgZ29vZCBhbmQgaXQncyBncmVhdCBuZXdz IHRoYXQgQS1sYWJlbHMgYXJlIG9ubHkgYWxsb3dlZCB1bmRlciBJRE5BMjAwOC4NCg0KMS4gSW4g c2VjdGlvbiAzLjMsIEl0IGlzIG5vdCBjbGVhciB3aGV0aGVyIEFMTCB0aGUgbGFiZWxzIHNob3Vs ZCBiZSBpbiBvbmUgZm9ybWF0IChVLWxhYmVsIG9yIEEtbGFiZWwpIG9yIGlzIGl0IGFsbG93ZWQg dG8gaGF2ZSBvbmUgbGFiZWwgZm9ybWF0dGVkIGFzIFUtbGFiZWwgYW5kIGFub3RoZXIgb25lIGFz IEEtbGFiZWwuDQoNCkhlcmUgYXJlIDQgcG9zc2libGUgcmVwcmVzZW50YXRpb25zIGZvciBvbmUg RlFETiwgYWxsIG9mIHdoaWNoIG11c3QgYmUgYWNjZXB0ZWQsIElNTy4NCtmF2KvYp9mELtii2LLZ hdin24zYtNuMLg0K2YXYq9in2YQueG4tLWhnYms2YWo3ZjUzYmJhLg0KeG4tLW1nYmgwZmIu2KLY stmF2KfbjNi024wuDQp4bi0tbWdiaDBmYi54bi0taGdiazZhajdmNTNiYmEuDQoNClRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLiBJIHRlbmQgdG8gdGhpbmsgdGhhdCBjbGllbnRzIHdpbGwgcGFzcyBl aXRoZXIgdGhlIGZpcnN0IG9yIGZvdXJ0aCBmb3JtcyB0aHJvdWdoIHRvIHRoZSBzZXJ2ZXIsIGJ1 dCBpZiB0aGUgdHdvIG1pZGRsZSBmb3JtcyBhcmUgcG9zc2libGUgdGhlbiB5ZXMsIHRoZSB0ZXh0 IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhleeKAmXJlIGFjY2VwdGFibGUuDQoNCjIuIElu IHNlY3Rpb25zIDMuMyAmIDMuNCB3ZSBoYXZlOg0KDQogICBJZiB0aGUgY2xpZW50IHNlbmRzIHRo ZSBzZXJ2ZXIgYW4gSUROIFUtbGFiZWwsIHNlcnZlcnMgdGhhdCBzdXBwb3J0DQogICBJRE5zIE1V U1QgY29udmVydCB0aGUgSUROIGludG8gQS1sYWJlbCBmb3JtYXQgYW5kIHBlcmZvcm0gSUROQQ0K ICAgcHJvY2Vzc2luZyBhcyBzcGVjaWZpZWQgaW4gUkZDIDU4OTEgW1JGQzU4OTFdLiAgVGhlIHNl cnZlciBzaG91bGQNCiAgIHBlcmZvcm0gYW4gZXhhY3QgbWF0Y2ggbG9va3VwIHVzaW5nIHRoZSBB LWxhYmVsLg0KDQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbCBiZWhpbmQgdGhpcyBw YXJhZ3JhcGguIEkgYmVsaWV2ZSB3ZSBkbyBub3QgaGF2ZSB0aGUgaW50ZW50aW9uIHRvIHRlbGwg dGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBob3cgdG8gd29yay4gU29tZSBtaWdodCBsaWtlIHRv IHRha2UgdGhlIHByb3Bvc2VkIGFwcHJvYWNoLCBidXQgd2hlbiB0aGUgc2VydmVyIGlzIGFibGUg dG8gbG9va3VwIGEgZG9tYWluIG5hbWUgaW4gVS1sYWJlbCBmb3JtYXQsIGl0IHNob3VsZCBiZSBh bGxvd2VkIHRvIGRvIHNvLg0KDQpBY3R1YWxseSwgd2UgKmRvKiBoYXZlIGEgcmVzcG9uc2liaWxp dHkgdG8gdGVsbCB0aGUgc2VydmVyIGltcGxlbWVudGF0aW9uIGhvdyB0byBjb252ZXJ0IGFuIGlu cHV0IGZvcm1hdCB0aGF0IG5lZWRzIHRvIGJlIGNvbnZlcnRlZCBpbiBvcmRlciB0byBwcm9tb3Rl IGludGVyb3BlcmFiaWxpdHkuIFRoaXMgaXMgcGFydCBvZiB0aGUgcmVhc29uIHRoZSBJRE5BIHNw ZWNzIHZlcnkgY2xlYXJseSBkZWZpbmUgcHJvY2Vzc2luZyBwcm9jZWR1cmVzLg0KDQpJZiBhbGwg d2UgY2FyZSBhYm91dCBpcyB0aGUgcHJlc2VudGF0aW9uIGZvcm1hdCBvZiBkb21haW4gbmFtZXMg aW4gdGhlIHJlc3BvbnNlIGRvY3VtZW50LCB3ZSBzaG91bGQganVzdCBzYXkgc28uDQoNClRoaXMg aXNu4oCZdCBhYm91dCB0aGUgcHJlc2VudGF0aW9uIGZvciBpbiB0aGUgcmVzcG9uc2UuIEl04oCZ cyBhYm91dCBjb25zaXN0ZW50IHNlcnZlci1zaWRlIHByb2Nlc3Npbmcgc28gY2xpZW50cyBrbm93 IHdoYXQgdG8gZXhwZWN0Lg0KDQpBbmQgYWdhaW4gcGxlYXNlIGRvbid0IGZvcmdldCB0aGF0IGRv bWFpbiBuYW1lcyBoYXZlIChpbiBtb3N0IGNhc2VzIGhlcmUpIG1vcmUgdGhhbiBvbmUgVS1sYWJl bC4gU28gImFuIElETiBVLWxhYmVsIiBpcyBub3QgYSBnb29kIHdheSB0byBwdXQgaXQuDQoNCkkg Y291bGQgYWNjZXB0IGEgY2hhbmdlIHRvIOKAnGFuIElETiBpbiBVLWxhYmVsIGZvcm1hdOKAnS4N Cg0KMy4gSW5zdGVhZCBvZiAieG4tLXhlbXBsZS05dWEuY29tPGh0dHA6Ly94bi0teGVtcGxlLTl1 YS5jb20+IiBhcyBhbiBJRE5BIGV4YW1wbGUgZG9tYWluLCBJIHRoaW5rIHdlIHNob3VsZCB1c2Ug YSBzdWJkb21haW4gb2YgZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPiBvciBzb21ldGhp bmcgbGlrZSB0aGF0Lg0KDQoNCltPVF0gSXQncyBhIHBpdHkgdGhhdCB3ZSBkbyBub3QgaGF2ZSBy ZXNlcnZlZCBGUSBJRE5zIHRvIHVzZSBpbiB0aGVzZSBjYXNlcy4gSXMgdGhlcmUgYW55IGNoYW5j ZSB3ZSBjYW4gdXNlIHRoZSBleGFtcGxlLnRlc3QgbmFtZXMgaGVyZT8gRG8gd2UgbmVlZCB0byBt YWtlIGl0IG9mZmljaWFsIGZpcnN0LCBhcyBhbiBSRkM/DQoNCkl04oCZcyBqdXN0IGFuIGV4YW1w bGUuIEnigJltIGluY2xpbmVkIHRvIGxlYXZlIGl0IGFzLWlzLg0KDQo0LiBJbiBzZWN0aW9uIDUs IGl0IHNheXM6DQoNCiAgIFsuLi5dIGJ1dA0KICAgY2xpZW50cyBvZiBwcm9ncmFtbWF0aWMgaW50 ZXJmYWNlcyBtYXkgd2lzaCB0byBzdWJtaXQgYW5kIGRpc3BsYXkNCiAgIEEtbGFiZWxzIG9yIG1h eSBub3QgYmUgYWJsZSB0byBpbnB1dCBVLWxhYmVscyB3aXRoIHRoZWlyIGtleWJvYXJkDQogICBj b25maWd1cmF0aW9uLg0KDQpJIHRoaW5rIHRoaXMgcGFydCBpcyBub3QgY2xlYXIgZW5vdWdoLCBh cyB0aGVzZSB0d28gc2l0dWF0aW9ucyBhcmUgbm90IHRoZSBvbmx5IHBvc3NpYmxlIHNpdHVhdGlv bnMgd2hlcmUgQS1sYWJlbHMgYmVjb21lIGhhbmR5Lg0KDQpJbiB0aGUgZmlyc3QgcGFydCwgZG9l cyAiZGlzcGxheSIgcmVmZXIgdG8gdGhlIHJlc3BvbnNlIGZyb20gc2VydmVyLCBvciBqdXN0IGRp c3BsYXlpbmcgdGhlIHF1ZXJpZWQgZG9tYWluIG5hbWUgaW4gdGhlIFVJPw0KDQpBbmQgZmluYWxs eSwgaW4gdGhlIGxhc3QgcGFydCwgaXQncyBub3QgY2xlYXIgaWYgdGhlICJrZXlib2FyZCBjb25m aWd1cmF0aW9uIiBpcyBhICJjbGllbnQiIGxpbWl0YXRpb24gb3IganVzdCB1c2VyJ3MgY29uZmln dXJhdGlvbi4NCg0KVGhlIGlkZWEgaGVyZSBpcyB0aGF0IGlmIHlvdeKAmXJlIHVzaW5nIGEg4oCc ZHVtYuKAnSBjbGllbnQgaXQgbWF5IGJlIGVhc2llciBmb3IgeW91IHRvIHdvcmsgd2l0aCBhLWxh YmVscy4gU29tZXRoaW5nIGdvdCBtYW5nbGVkIGhlcmUgaW4gY29weWluZyBhbmQgcGFzdGluZy4g SXQgc2hvdWxkIHNheSBzb21ldGhpbmcgbGlrZSDigJxjbGllbnRzIHVzaW5nIHByb2dyYW1tYXRp YyBpbnRlcmZhY2VzIG1heSB3aXNoIHRvIHN1Ym1pdCBhbmQgZGlzcGxheSBBLWxhYmVscyBpZiB0 aGV5IGFyZSB1bmFibGUgdG8gaW5wdXQgVS1sYWJlbHMgd2l0aCB0aGVpciBrZXlib2FyZCBjb25m aWd1cmF0aW9u4oCdLiBJZiB0aGF04oCZcyBub3QgY2xlYXJlciBwbGVhc2Ugc3VnZ2VzdCByZXBs YWNlbWVudCB0ZXh0Lg0KDQpTY290dA0K --_000_831693C2CDA2E849A7D7A712B24E257F243357C5BRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiB3ZWlyZHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndlaXJk cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZWhuYW0gRXNmYWhib2Q8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE0LCAyMDEzIDY6NTMgUE08YnI+DQo8 Yj5Ubzo8L2I+IHdlaXJkc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbd2VpcmRzXSBV LWxhYmVsIHN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2NvdHQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5KdXN0IGxvb2tlZCBhdCB0aGUgbGF0ZXN0IGRyYWZ0LCBmb2xsb3dpbmcgYXJlIGEg ZmV3IGNvbW1lbnRzIHJlZ2FyZGluZyBVLWxhYmVsIHN1cHBvcnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjAuIEl0J3MgZ2VuZXJhbGx5IHBy ZXR0eSBnb29kIGFuZCBpdCdzIGdyZWF0IG5ld3MgdGhhdCBBLWxhYmVscyBhcmUgb25seSBhbGxv d2VkIHVuZGVyIElETkEyMDA4LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4xLiBJbiBzZWN0aW9uIDMuMywgSXQgaXMgbm90IGNsZWFyIHdoZXRo ZXIgQUxMIHRoZSBsYWJlbHMgc2hvdWxkIGJlIGluIG9uZSBmb3JtYXQgKFUtbGFiZWwgb3IgQS1s YWJlbCkgb3IgaXMgaXQgYWxsb3dlZCB0byBoYXZlIG9uZSBsYWJlbCBmb3JtYXR0ZWQgYXMgVS1s YWJlbCBhbmQgYW5vdGhlciBvbmUgYXMgQS1sYWJlbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgNCBwb3NzaWJsZSByZXByZXNl bnRhdGlvbnMgZm9yIG9uZSBGUUROLCBhbGwgb2Ygd2hpY2ggbXVzdCBiZSBhY2NlcHRlZCwgSU1P LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+2YXY q9in2YQu2KLYstmF2KfbjNi024wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj7Zhdir2KfZhC54bi0taGdiazZhajdmNTNiYmEuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj54bi0tbWdiaDBmYi7Yotiy 2YXYp9uM2LTbjC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnhuLS1tZ2JoMGZiLnhuLS1oZ2JrNmFqN2Y1M2JiYS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUg ZmVlZGJhY2suIEkgdGVuZCB0byB0aGluayB0aGF0IGNsaWVudHMgd2lsbCBwYXNzIGVpdGhlciB0 aGUgZmlyc3Qgb3IgZm91cnRoIGZvcm1zIHRocm91Z2ggdG8gdGhlIHNlcnZlciwgYnV0IGlmIHRo ZSB0d28gbWlkZGxlIGZvcm1zIGFyZSBwb3NzaWJsZQ0KIHRoZW4geWVzLCB0aGUgdGV4dCBzaG91 bGQgbWFrZSBpdCBjbGVhciB0aGF0IHRoZXnigJlyZSBhY2NlcHRhYmxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gSW4gc2Vj dGlvbnMgMy4zICZhbXA7IDMuNCB3ZSBoYXZlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0lmIHRoZSBjbGllbnQgc2VuZHMgdGhlIHNl cnZlciBhbiBJRE4gVS1sYWJlbCwgc2VydmVycyB0aGF0IHN1cHBvcnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJRE5zIE1V U1QgY29udmVydCB0aGUgSUROIGludG8gQS1sYWJlbCBmb3JtYXQgYW5kIHBlcmZvcm0gSUROQTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO3Byb2Nlc3NpbmcgYXMgc3BlY2lmaWVkIGluIFJGQyA1ODkxIFtSRkM1ODkxXS4gJm5i c3A7VGhlIHNlcnZlciBzaG91bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtwZXJmb3JtIGFuIGV4YWN0IG1hdGNoIGxvb2t1 cCB1c2luZyB0aGUgQS1sYWJlbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSByYXRpb25h bCBiZWhpbmQgdGhpcyBwYXJhZ3JhcGguIEkgYmVsaWV2ZSB3ZSBkbyBub3QgaGF2ZSB0aGUgaW50 ZW50aW9uIHRvIHRlbGwgdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBob3cgdG8gd29yay4gU29t ZSBtaWdodCBsaWtlIHRvIHRha2UgdGhlIHByb3Bvc2VkIGFwcHJvYWNoLCBidXQgd2hlbiB0aGUg c2VydmVyIGlzIGFibGUgdG8gbG9va3VwIGEgZG9tYWluDQogbmFtZSBpbiBVLWxhYmVsIGZvcm1h dCwgaXQgc2hvdWxkIGJlIGFsbG93ZWQgdG8gZG8gc28uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjdHVhbGx5LCB3ZSAqPGI+ZG88 L2I+KiBoYXZlIGEgcmVzcG9uc2liaWxpdHkgdG8gdGVsbCB0aGUgc2VydmVyIGltcGxlbWVudGF0 aW9uIGhvdyB0byBjb252ZXJ0IGFuIGlucHV0IGZvcm1hdCB0aGF0IG5lZWRzIHRvIGJlIGNvbnZl cnRlZCBpbiBvcmRlciB0byBwcm9tb3RlDQogaW50ZXJvcGVyYWJpbGl0eS4gVGhpcyBpcyBwYXJ0 IG9mIHRoZSByZWFzb24gdGhlIElETkEgc3BlY3MgdmVyeSBjbGVhcmx5IGRlZmluZSBwcm9jZXNz aW5nIHByb2NlZHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhbGwgd2UgY2FyZSBhYm91dCBpcyB0aGUgcHJlc2VudGF0 aW9uIGZvcm1hdCBvZiBkb21haW4gbmFtZXMgaW4gdGhlIHJlc3BvbnNlIGRvY3VtZW50LCB3ZSBz aG91bGQganVzdCBzYXkgc28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXNu4oCZdCBhYm91dCB0aGUgcHJlc2VudGF0aW9u IGZvciBpbiB0aGUgcmVzcG9uc2UuIEl04oCZcyBhYm91dCBjb25zaXN0ZW50IHNlcnZlci1zaWRl IHByb2Nlc3Npbmcgc28gY2xpZW50cyBrbm93IHdoYXQgdG8gZXhwZWN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGFnYWlu IHBsZWFzZSBkb24ndCBmb3JnZXQgdGhhdCBkb21haW4gbmFtZXMgaGF2ZSAoaW4gbW9zdCBjYXNl cyBoZXJlKSBtb3JlIHRoYW4gb25lIFUtbGFiZWwuIFNvICZxdW90O2FuIElETiBVLWxhYmVsJnF1 b3Q7IGlzIG5vdCBhIGdvb2Qgd2F5IHRvIHB1dCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBjb3VsZCBhY2NlcHQgYSBjaGFu Z2UgdG8g4oCcYW4gSUROIGluIFUtbGFiZWwgZm9ybWF04oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gSW5zdGVhZCBvZiAm cXVvdDs8YSBocmVmPSJodHRwOi8veG4tLXhlbXBsZS05dWEuY29tIj54bi0teGVtcGxlLTl1YS5j b208L2E+JnF1b3Q7IGFzIGFuIElETkEgZXhhbXBsZSBkb21haW4sIEkgdGhpbmsgd2Ugc2hvdWxk IHVzZSBhIHN1YmRvbWFpbiBvZg0KPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIj5leGFtcGxl LmNvbTwvYT4gb3Igc29tZXRoaW5nIGxpa2UgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bT1RdIEl0J3MgYSZuYnNwO3BpdHkmbmJz cDt0aGF0IHdlIGRvIG5vdCBoYXZlIHJlc2VydmVkIEZRIElETnMgdG8gdXNlIGluIHRoZXNlIGNh c2VzLiBJcyB0aGVyZSBhbnkgY2hhbmNlIHdlIGNhbiB1c2UgdGhlIGV4YW1wbGUudGVzdCBuYW1l cyBoZXJlPyBEbyB3ZSBuZWVkIHRvIG1ha2UgaXQgb2ZmaWNpYWwgZmlyc3QsIGFzIGFuIFJGQz88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SXTigJlzIGp1c3QgYW4gZXhhbXBsZS4gSeKAmW0gaW5jbGluZWQgdG8gbGVhdmUgaXQgYXMt aXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj40LiBJbiBzZWN0aW9uIDUsIGl0IHNheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Wy4uLl0g YnV0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7Y2xpZW50cyBvZiBwcm9ncmFtbWF0aWMgaW50ZXJmYWNlcyBtYXkgd2lzaCB0 byBzdWJtaXQgYW5kIGRpc3BsYXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBLWxhYmVscyBvciBtYXkgbm90IGJlIGFibGUg dG8gaW5wdXQgVS1sYWJlbHMgd2l0aCB0aGVpciBrZXlib2FyZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NvbmZpZ3VyYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdGhpcyBwYXJ0IGlzIG5vdCBjbGVhciBlbm91Z2gsIGFzIHRoZXNlIHR3byBzaXR1 YXRpb25zIGFyZSBub3QgdGhlIG9ubHkgcG9zc2libGUgc2l0dWF0aW9ucyB3aGVyZSBBLWxhYmVs cyBiZWNvbWUgaGFuZHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIHRoZSBmaXJzdCBwYXJ0LCBkb2VzICZxdW90O2Rpc3BsYXkmcXVvdDsg cmVmZXIgdG8gdGhlIHJlc3BvbnNlIGZyb20gc2VydmVyLCBvciBqdXN0IGRpc3BsYXlpbmcgdGhl IHF1ZXJpZWQgZG9tYWluIG5hbWUgaW4gdGhlIFVJPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgZmluYWxseSwgaW4gdGhlIGxhc3QgcGFy dCwgaXQncyBub3QgY2xlYXIgaWYgdGhlICZxdW90O2tleWJvYXJkIGNvbmZpZ3VyYXRpb24mcXVv dDsgaXMgYSAmcXVvdDtjbGllbnQmcXVvdDsgbGltaXRhdGlvbiBvciBqdXN0IHVzZXIncyBjb25m aWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlkZWEgaGVyZSBpcyB0aGF0IGlmIHlvdeKAmXJlIHVz aW5nIGEg4oCcZHVtYuKAnSBjbGllbnQgaXQgbWF5IGJlIGVhc2llciBmb3IgeW91IHRvIHdvcmsg d2l0aCBhLWxhYmVscy4gU29tZXRoaW5nIGdvdCBtYW5nbGVkIGhlcmUgaW4gY29weWluZyBhbmQg cGFzdGluZy4gSXQNCiBzaG91bGQgc2F5IHNvbWV0aGluZyBsaWtlIOKAnGNsaWVudHMgdXNpbmcg cHJvZ3JhbW1hdGljIGludGVyZmFjZXMgbWF5IHdpc2ggdG8gc3VibWl0IGFuZCBkaXNwbGF5IEEt bGFiZWxzIGlmIHRoZXkgYXJlIHVuYWJsZSB0byBpbnB1dCBVLWxhYmVscyB3aXRoIHRoZWlyIGtl eWJvYXJkIGNvbmZpZ3VyYXRpb27igJ0uIElmIHRoYXTigJlzIG5vdCBjbGVhcmVyIHBsZWFzZSBz dWdnZXN0IHJlcGxhY2VtZW50IHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_831693C2CDA2E849A7D7A712B24E257F243357C5BRN1WNEXMBX01vc_-- From carlosm3011@gmail.com Thu Mar 14 23:09:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96AC21F918F for ; Thu, 14 Mar 2013 23:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ywtIMXGcCxT for ; Thu, 14 Mar 2013 23:09:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DC21F918D for ; Thu, 14 Mar 2013 23:09:42 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so3372880pbc.17 for ; Thu, 14 Mar 2013 23:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iJNJpP5hdQqpluyco+p+OYfNr9y7T3C8yBeIi0DjFUk=; b=GriCUOr5g/6c8eR9i+3QemPTJgA5q4BCVtq1rVazXVXSAmnsGcGRt1dC3Hjkc2arxR B/K4ZfPnWvdDW6XUhb/7wGz0T01PKQenSPdlaA9cHdsYNbyqqIqaxpoOEs5Eft3UFc9Q vrQodKTjCH8WpiRzai2NrNkLjz1NB3TQ6xtNX6Nx5GYn++YBW4nK+IKIvVi3cOby0p3X nWigZ0v4VRYlNBD/QBhG+9aUk0lhRCDVqYAxGy5eeAhzyBBWAE3fxGTsvrM779j1Mfmf Po2S8spOqJt9bpsr+HHbElE1HAE1yAzbKu6fY3ihlOVD47Qu7KZlcLcjBdCHVt6LaJ/L ODUA== X-Received: by 10.68.223.138 with SMTP id qu10mr13159110pbc.89.1363327782630; Thu, 14 Mar 2013 23:09:42 -0700 (PDT) Received: from Carloss-MacBook-Pro.local (dhcp-42a9.meeting.ietf.org. [130.129.66.169]) by mx.google.com with ESMTPS id tm1sm7074765pbc.11.2013.03.14.23.09.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 23:09:41 -0700 (PDT) Message-ID: <5142BB27.6070806@gmail.com> Date: Fri, 15 Mar 2013 02:09:43 -0400 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Simon Perreault References: <51424BF2.5050005@viagenie.ca> In-Reply-To: <51424BF2.5050005@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 06:09:43 -0000 Thanks, this will be indeed useful! ~Carlos On 3/14/13 6:15 PM, Simon Perreault wrote: > I don't remember it being mentioned at the mic, so here's a pointer to > HTTP status code 429 that can be used for rate limiting: > > http://tools.ietf.org/html/rfc6585#section-4 > > Simon From michael@mwyoung.ca Fri Mar 15 06:17:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA5821F9001 for ; Fri, 15 Mar 2013 06:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7GB2Co6GqiD for ; Fri, 15 Mar 2013 06:17:13 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 997E821F8FA4 for ; Fri, 15 Mar 2013 06:17:13 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so4328670iea.27 for ; Fri, 15 Mar 2013 06:17:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=tTxlU04IyL4dNkRoe3wOTstzC3rBNQ05uHN6Z74i/RI=; b=AAZ54hfZGsa7UkaKc93tUUa5gUtUyKUJlPruyzSIa1DWnkUCwH9aLbqXabdGr0QhuR HZgA+Fmr8FvBHn/4UEJ9/IUoQXw9RwMSDFIHV4XuveINJy1oCAPCwIvAzsVuAlKQUv9w paCyGVIo7JucGap3Ys1FIs/MUWQBp0v4jgniYhPaL3eA5QQEa70gNTHfgK4mVMmyN2rx F3VPr3Dax7r5qR6aRzQdFyJq2iM5Kq4SKDopIJI/7jMIBRQ+U7HV49kttiatueH6XWlg Z1ZsEYyQWWtGFReR1F1pEASmvdngpsKRQiVe5O5oqY4KBbJxubApOPFhr2Z7baKJJ7hf oGBg== X-Received: by 10.50.11.138 with SMTP id q10mr1123404igb.5.1363353432944; Fri, 15 Mar 2013 06:17:12 -0700 (PDT) Received: from [10.218.246.131] ([184.151.190.3]) by mx.google.com with ESMTPS id ur12sm1498589igb.8.2013.03.15.06.17.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 06:17:11 -0700 (PDT) References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5142BB27.6070806@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Fri, 15 Mar 2013 09:17:04 -0400 To: "carlos@lacnic.net" X-Gm-Message-State: ALoCoQmo7Ifddrgavr9xvtObSYbVYSMYYIx3sIUyV6ZsqdY9Ckx21MgqKuMamglxDgi6D/NKJ/h9 Cc: "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:17:14 -0000 Just out of curiosity, how would you implement that?=20 Here's my sensibility on poor acting clients, where its a logged in known cl= ient I initially sleep the offending client connection on basis of the known= user. I don't break the connection, I don't provide information in the resp= onse. If they keep going I extend the sleep periods and apply them to other c= lient connections under the same client login. Why? I don't want to work my s= erver hard by responding even with an error message to their likely largely d= istributed computing resources - sleeping their response also idles their co= mputer resources at least a bit. For current Whois I limit based on the source IP address and if they switch t= o near IPs I start to apply the rate limiting to the netblock. I escalate th= e netblock as high as I need to or add other blocks if they keep hopping aro= und. Sleep periods are longer the more the abuse continues. This approach br= eaks down under IPv6, where vast amounts of IPv6 space is assigned I'm not s= o confident there isn't collateral harm in blocking such large swathes of IP= space. This is where I start to believe all public Whois service should req= uire the client to sign up for a user ID and login. Now I can rate limit by t= hat userid versus IP. I don't give error responses due the server resource conservation and becaus= e almost all server pounding is deliberate or it's incompetence with perhaps= a dash of willful ignorance. I'd rather publish a clear policy and descript= ion of what happens if you trigger my rate limiting. Michael Young M:647-289-1220 On 2013-03-15, at 2:09, "Carlos M. Martinez" wrote: > Thanks, this will be indeed useful! >=20 > ~Carlos >=20 > On 3/14/13 6:15 PM, Simon Perreault wrote: >> I don't remember it being mentioned at the mic, so here's a pointer to >> HTTP status code 429 that can be used for rate limiting: >>=20 >> http://tools.ietf.org/html/rfc6585#section-4 >>=20 >> Simon > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Fri Mar 15 06:33:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73B921F8ED5 for ; Fri, 15 Mar 2013 06:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTdF4zKbwV+S for ; Fri, 15 Mar 2013 06:33:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8421F8B9F for ; Fri, 15 Mar 2013 06:33:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C982D40439; Fri, 15 Mar 2013 09:33:26 -0400 (EDT) Message-ID: <51432325.5070204@viagenie.ca> Date: Fri, 15 Mar 2013 09:33:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michael Young References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:33:28 -0000 Le 2013-03-15 09:17, Michael Young a écrit : > Just out of curiosity, how would you implement that? that = ? > Here's my sensibility on poor acting clients, where its a logged in > known client I initially sleep the offending client connection on > basis of the known user. I don't break the connection, I don't > provide information in the response. If they keep going I extend the > sleep periods and apply them to other client connections under the > same client login. Why? I don't want to work my server hard by > responding even with an error message to their likely largely > distributed computing resources - sleeping their response also idles > their computer resources at least a bit. I don't see why you couldn't return 429 after sleeping. > For current Whois I limit based on the source IP address and if they > switch to near IPs I start to apply the rate limiting to the > netblock. I escalate the netblock as high as I need to or add other > blocks if they keep hopping around. Sleep periods are longer the more > the abuse continues. This approach breaks down under IPv6, where vast > amounts of IPv6 space is assigned I'm not so confident there isn't > collateral harm in blocking such large swathes of IP space. This is > where I start to believe all public Whois service should require the > client to sign up for a user ID and login. Now I can rate limit by > that userid versus IP. I don't see why it wouldn't work similarly for IPv6. Just use larger prefixes. > I don't give error responses due the server resource conservation and > because almost all server pounding is deliberate or it's incompetence > with perhaps a dash of willful ignorance. I'd rather publish a clear > policy and description of what happens if you trigger my rate > limiting. So why not return 429 after sleeping? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From michael@mwyoung.ca Fri Mar 15 06:39:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A9E21F8C83 for ; Fri, 15 Mar 2013 06:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeVrf4j7w9yl for ; Fri, 15 Mar 2013 06:39:56 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5021F8C7C for ; Fri, 15 Mar 2013 06:39:56 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id y26so954506iab.34 for ; Fri, 15 Mar 2013 06:39:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=c5006AohdRCBeW0Cyo6L7U16vRdsMPNelIr2ctYEUUY=; b=hyODUP/3cKXYCuwz1h2o8Oxp11SJwni7aYBd3Zes48nDuFAh1rkcRDLCsTE+3isxD7 pAFKmJUlWp/iE8UurwWQdB5mXPK69qP84Vlb3a3n+7t4vMnHhLQ5kGFh4egh7kUluB4U CYEPE50NR4c75HJQosvxBlSEuGRkVcwbIP8F5ebyGfIVN+XiSvkayNZRO63TEV7EFGyP lrluLj70M8PtV51gaBpINO019kJMb6TI8ZKsRGyc0/v+9/pYFN0XPSu8nFgS9CVVjhj0 wHC1f89xtHy6wWnswrq0C5x3ENluZWFZ+Xf/MzEkdTW2z/3gtSXpiSZWVAmaIJoxBjIk Ep8Q== X-Received: by 10.42.91.209 with SMTP id q17mr4632280icm.50.1363354795874; Fri, 15 Mar 2013 06:39:55 -0700 (PDT) Received: from [10.218.246.131] ([184.151.190.3]) by mx.google.com with ESMTPS id xf4sm1292393igb.8.2013.03.15.06.39.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 06:39:54 -0700 (PDT) References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <51432325.5070204@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Fri, 15 Mar 2013 09:39:48 -0400 To: Simon Perreault X-Gm-Message-State: ALoCoQkHheAmJTVTdG+fVmXXs40SkgXWX4Sxi5depR65hUqU8D+dXA6KlMLhcC9xdUg1s/6LAjah Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:39:57 -0000 I actually return the requested response after sleeping, why? It's condition= ing, follow my rules and play nice and you can then have what you asked for,= .... Stick carrot stick carrot and so on But yes you could respond with a 429, I just think if they know that's comin= g after the sleep they will run a very low time-out and hit the server with a= new request again eating server resources "That"=3D your overall approach to rate limiting such as what I just covered= Michael Young M:647-289-1220 On 2013-03-15, at 9:33, Simon Perreault wrote:= > Le 2013-03-15 09:17, Michael Young a =C3=A9crit : >> Just out of curiosity, how would you implement that? >=20 > that =3D ? >=20 >> Here's my sensibility on poor acting clients, where its a logged in >> known client I initially sleep the offending client connection on >> basis of the known user. I don't break the connection, I don't >> provide information in the response. If they keep going I extend the >> sleep periods and apply them to other client connections under the >> same client login. Why? I don't want to work my server hard by >> responding even with an error message to their likely largely >> distributed computing resources - sleeping their response also idles >> their computer resources at least a bit. >=20 > I don't see why you couldn't return 429 after sleeping. >=20 >> For current Whois I limit based on the source IP address and if they >> switch to near IPs I start to apply the rate limiting to the >> netblock. I escalate the netblock as high as I need to or add other >> blocks if they keep hopping around. Sleep periods are longer the more >> the abuse continues. This approach breaks down under IPv6, where vast >> amounts of IPv6 space is assigned I'm not so confident there isn't >> collateral harm in blocking such large swathes of IP space. This is >> where I start to believe all public Whois service should require the >> client to sign up for a user ID and login. Now I can rate limit by >> that userid versus IP. >=20 > I don't see why it wouldn't work similarly for IPv6. Just use larger prefi= xes. >=20 >> I don't give error responses due the server resource conservation and >> because almost all server pounding is deliberate or it's incompetence >> with perhaps a dash of willful ignorance. I'd rather publish a clear >> policy and description of what happens if you trigger my rate >> limiting. >=20 > So why not return 429 after sleeping? >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Mar 15 06:58:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329A521F85B2 for ; Fri, 15 Mar 2013 06:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4K4Po5uVblX for ; Fri, 15 Mar 2013 06:58:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6151921F85CB for ; Fri, 15 Mar 2013 06:58:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0B41840439; Fri, 15 Mar 2013 09:57:41 -0400 (EDT) Message-ID: <514328D5.7050905@viagenie.ca> Date: Fri, 15 Mar 2013 09:57:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michael Young References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> In-Reply-To: <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:58:17 -0000 Le 2013-03-15 09:39, Michael Young a écrit : > I actually return the requested response after sleeping, why? It's > conditioning, follow my rules and play nice and you can then have > what you asked for,.... > > Stick carrot stick carrot and so on The advantage of the 429 response is that the load on the server may actually be lower since it doesn't need to keep connections open. That means less state on the server. See also the Retry-After header that can be used to let the client know when to retry: http://tools.ietf.org/html/rfc2616#section-14.37 > But yes you could respond with a 429, I just think if they know > that's coming after the sleep they will run a very low time-out and > hit the server with a new request again eating server resources Keep in mind that you're not trying to defend against evil clients. Those can just open multiple connections, or open/close a single connection very quickly to try to hurt you. What we're considering here is good-intentioned clients that happen to query too fast by mistake. Returning 429+Retry-After lets them know what is going on so that they can adjust their behaviour. Sleeping does not. It may even trigger timeout conditions in the client, which does not help anyone. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From michael@mwyoung.ca Fri Mar 15 07:15:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D821F86FA for ; Fri, 15 Mar 2013 07:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPMEi-96kILI for ; Fri, 15 Mar 2013 07:15:46 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6B01F21F86F8 for ; Fri, 15 Mar 2013 07:15:46 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so4411792iec.32 for ; Fri, 15 Mar 2013 07:15:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=tWWFfhlHFJdgJmu7TQ57ar+GcTpvebh41QPUEfKiub4=; b=cnpYCLm00dXBSOEv1I+nsSM+Gp+UYJor9oVAayX3LbLbkASUyjgcoq9ezr+cmYJr3e k4M6tdSbUp38vZ3xGb6DiVAOO3mACbmEj6bS7Nt1kRiaBS9LSJsYq8JM0p+RyY+ywztM e3jifUOHeEyUxpfTr+lMx6P69uAJs57cB9BOj/lT59P9aYYF4f0gSYM2num3UgM4gujo z8J2czv4UObvyVM5u52h5UDUB8IUR1hb2V1D3imN0nzr6XIFJoY+VQDLT+6U1PlYM4ev pIbImR9nFaY+tZq/9a3w7W6GKUFWSBkuUNYZt5rMnwSOCGx+JPEb0H9VC87oUf6+KMhI kn2Q== X-Received: by 10.50.188.135 with SMTP id ga7mr1353728igc.58.1363356945849; Fri, 15 Mar 2013 07:15:45 -0700 (PDT) Received: from [10.218.246.131] ([184.151.190.3]) by mx.google.com with ESMTPS id ew5sm1732033igc.2.2013.03.15.07.15.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 07:15:44 -0700 (PDT) References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <514328D5.7050905@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Fri, 15 Mar 2013 10:15:38 -0400 To: Simon Perreault X-Gm-Message-State: ALoCoQnpIyGViffOdGvSYDmJCjMxIunGZenUPsiymxB6bh0p0zGGFU9MaPrjmpHpun2J2x2r/WJC Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:15:48 -0000 Sure I'm defending against evil clients as well,.... Why assume its all well= intentioned? Data mining is huge in our industry Michael Young M:647-289-1220 On 2013-03-15, at 9:57, Simon Perreault wrote:= > Le 2013-03-15 09:39, Michael Young a =C3=A9crit : >> I actually return the requested response after sleeping, why? It's >> conditioning, follow my rules and play nice and you can then have >> what you asked for,.... >>=20 >> Stick carrot stick carrot and so on >=20 > The advantage of the 429 response is that the load on the server may actua= lly be lower since it doesn't need to keep connections open. That means less= state on the server. >=20 > See also the Retry-After header that can be used to let the client know wh= en to retry: > http://tools.ietf.org/html/rfc2616#section-14.37 >=20 >> But yes you could respond with a 429, I just think if they know >> that's coming after the sleep they will run a very low time-out and >> hit the server with a new request again eating server resources >=20 > Keep in mind that you're not trying to defend against evil clients. > Those can just open multiple connections, or open/close a single > connection very quickly to try to hurt you. What we're considering here > is good-intentioned clients that happen to query too fast by mistake. Retu= rning 429+Retry-After lets them know what is going on so that they can adjus= t their behaviour. Sleeping does not. It may even trigger timeout conditions= in the client, which does not help anyone. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Mar 15 07:23:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC15621F8867 for ; Fri, 15 Mar 2013 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pl932diQJ0Z for ; Fri, 15 Mar 2013 07:23:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id C4FD421F8861 for ; Fri, 15 Mar 2013 07:23:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5AF3140439; Fri, 15 Mar 2013 10:22:56 -0400 (EDT) Message-ID: <51432EBF.1060705@viagenie.ca> Date: Fri, 15 Mar 2013 10:22:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michael Young References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> In-Reply-To: <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:23:28 -0000 Le 2013-03-15 10:15, Michael Young a écrit : > Sure I'm defending against evil clients as well,.... Why assume its all well intentioned? Data mining is huge in our industry You misunderstood my point. Let me try again. You *have* to implement a set of defences against evil clients. That doesn't change whether you sleep or send 429, because both of them *do not* defend against evil clients. Evil clients can easily hurt you even if you sleep or send 429. Sleeping and 429 are not defences against evil clients. Something else is needed. Something like progressive blacklisting of IP prefixes, as you described. Now, after you have implemented that set of defences against evil clients, you may then want to address the problem of good-intentioned clients that happen to query too quickly by mistake. That problem is addressed by giving clients *information* about what kind of behaviour is acceptable, so that they can adjust theirs. Status code 429 and the Retry-After header are the HTTP standard ways of conveying that information. Sleeping only gives implicit information, which the client needs to heuristically discover. It is better to provide explicit information because it is more robust and unambiguous. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From aservin@lacnic.net Fri Mar 15 07:42:21 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7588B21F8860 for ; Fri, 15 Mar 2013 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKB2TDhtIM-E for ; Fri, 15 Mar 2013 07:42:20 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8098E21F865D for ; Fri, 15 Mar 2013 07:42:20 -0700 (PDT) Received: from dhcp-12b8.meeting.ietf.org (dhcp-12b8.meeting.ietf.org [130.129.18.184]) by mail.lacnic.net.uy (Postfix) with ESMTP id 9306B30843C for ; Fri, 15 Mar 2013 11:42:00 -0300 (UYT) Message-ID: <5143333E.3050309@lacnic.net> Date: Fri, 15 Mar 2013 10:42:06 -0400 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:42:21 -0000 Michael, Checking the details, I will post something soon. Regards, as On 15/03/2013 09:17, Michael Young wrote: > Just out of curiosity, how would you implement that? > > > > Here's my sensibility on poor acting clients, where its a logged in known client I initially sleep the offending client connection on basis of the known user. I don't break the connection, I don't provide information in the response. If they keep going I extend the sleep periods and apply them to other client connections under the same client login. Why? I don't want to work my server hard by responding even with an error message to their likely largely distributed computing resources - sleeping their response also idles their computer resources at least a bit. > > For current Whois I limit based on the source IP address and if they switch to near IPs I start to apply the rate limiting to the netblock. I escalate the netblock as high as I need to or add other blocks if they keep hopping around. Sleep periods are longer the more the abuse continues. This approach breaks down under IPv6, where vast amounts of IPv6 space is assigned I'm not so confident there isn't collateral harm in blocking such large swathes of IP space. This is where I start to believe all public Whois service should require the client to sign up for a user ID and login. Now I can rate limit by that userid versus IP. > > I don't give error responses due the server resource conservation and because almost all server pounding is deliberate or it's incompetence with perhaps a dash of willful ignorance. I'd rather publish a clear policy and description of what happens if you trigger my rate limiting. > > > Michael Young > > M:647-289-1220 > > On 2013-03-15, at 2:09, "Carlos M. Martinez" wrote: > >> Thanks, this will be indeed useful! >> >> ~Carlos >> >> On 3/14/13 6:15 PM, Simon Perreault wrote: >>> I don't remember it being mentioned at the mic, so here's a pointer to >>> HTTP status code 429 that can be used for rate limiting: >>> >>> http://tools.ietf.org/html/rfc6585#section-4 >>> >>> Simon >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From michael@mwyoung.ca Fri Mar 15 07:47:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334BC21F85DF for ; Fri, 15 Mar 2013 07:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqBtBCzdUp2D for ; Fri, 15 Mar 2013 07:47:08 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7504821F872E for ; Fri, 15 Mar 2013 07:47:08 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id y25so3272001iay.22 for ; Fri, 15 Mar 2013 07:47:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=LZ4kVKYIPKMi0NIy6DTcl7rqE6XcPpfcWE2rJN1BOcY=; b=Rj4NV/83NH9xM4YOUv0Z0vaPyPcVm9XdDo6oW930Qynr3qqCegs+Ne0KMxv20QxjuF PP3TjSbbIAsz/mTjhRnrriB3D6nVzxZwxX7oQmPt4dh/N7cIrkAfH+TYlFDp/J+2jqM8 2rAbwuhZSx91L38NFD9K6prj6NJSG03dTEcLAah+aUyU1UUqzkCugFfKCdL+m44cu57m mwzFjsJleXPWGN22upZRDLALB/DKNi9iI2tBJmbdvc51bvgYPhhBhYTB5K+Uy2eKr/q2 Dj/pTBPOSZhKQhv2Q+he+/qVyDk52Xe4QpkexZFuzaPi++FcKqkJPvN7B+VICTPPUPmU ZAVQ== X-Received: by 10.50.37.132 with SMTP id y4mr1477134igj.61.1363358828101; Fri, 15 Mar 2013 07:47:08 -0700 (PDT) Received: from [10.218.246.131] ([184.151.190.3]) by mx.google.com with ESMTPS id ew5sm1850530igc.2.2013.03.15.07.47.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 07:47:07 -0700 (PDT) References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> <51432EBF.1060705@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <51432EBF.1060705@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6D671966-A280-4D29-A7B2-0F7B8BBF2704@mwyoung.ca> X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Fri, 15 Mar 2013 10:46:59 -0400 To: Simon Perreault X-Gm-Message-State: ALoCoQmv7Nb7RmB/MeCqluJfmv57pfoV1lW888TgD9vRphkUJOQ0Rny0q1snRhlEcGgsoyWJj+/9 Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:47:09 -0000 Ok thanks I understand what you meant now. I'm not sure I agree that sleepi= ng the bad clients isn't effective - it certainly worked for me in the past.= But I do agree its not a solution by itself, progressive behaviors are need= ed.=20 I do think that having authenticated Whois as a standard helps us all identi= fy good and bad actors more easily. You can then vary your behaviors based o= n user profiling - that means you can opt to be more helpful to what you det= ermine to be a genuinely well intentioned but poorly behaving client. It ev= en allows for out of band direction or instruction via contact info gathered= during the user signup process. I don't see any real reason not to go to authenticated Whois - privacy issue= s can still be addressed - you can opt to allow users to remain anonymous an= d we are still way better off than today, IMHO. Btw Good talk Simon, your thoughts have merit. Michael Young M:647-289-1220 On 2013-03-15, at 10:22, Simon Perreault wrote= : > Le 2013-03-15 10:15, Michael Young a =C3=A9crit : >> Sure I'm defending against evil clients as well,.... Why assume its all w= ell intentioned? Data mining is huge in our industry >=20 > You misunderstood my point. Let me try again. >=20 > You *have* to implement a set of defences against evil clients. That doesn= 't change whether you sleep or send 429, because both of them *do not* defen= d against evil clients. Evil clients can easily hurt you even if you sleep o= r send 429. Sleeping and 429 are not defences against evil clients. Somethin= g else is needed. Something like progressive blacklisting of IP prefixes, as= you described. >=20 > Now, after you have implemented that set of defences against evil clients,= you may then want to address the problem of good-intentioned clients that h= appen to query too quickly by mistake. That problem is addressed by giving c= lients *information* about what kind of behaviour is acceptable, so that the= y can adjust theirs. Status code 429 and the Retry-After header are the HTTP= standard ways of conveying that information. Sleeping only gives implicit i= nformation, which the client needs to heuristically discover. It is better t= o provide explicit information because it is more robust and unambiguous. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From carlosm3011@gmail.com Fri Mar 15 07:52:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259E21F87D6 for ; Fri, 15 Mar 2013 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffUbfWXtNrbN for ; Fri, 15 Mar 2013 07:52:22 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id D657521F8821 for ; Fri, 15 Mar 2013 07:52:21 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id ma3so3929090pbc.11 for ; Fri, 15 Mar 2013 07:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aFiyWq/JrrU48t/6uj8iWjf2dlrbDrfEoIxCTtcMVuA=; b=j9HLo+UfS5gYK2iiWGZgYLKSjPTh/tVZTct8sPY9YcX3d/7MDcg2DdKX5L5EqF2kff TBgOUvoE8MIcYeojIkwh2gRVcoxP7nf2EUVoMc0mhPpSqENqhDuDXeQsTvyUGfUEZ+SG bVXjxZozzm0XxpSIQAMMYWJUbfQdDanLX0YAzcmbCFelbdjhcKjeypNVKIcghJubMf6B B6WHjh7diEIdF5yPAZGPLO8M5jQdOY8i316QvXxSHOdJGHzMr/B9NPJVkuPJavM9rADL gwt1nS6uZ1CFrd57nh+EUkaxtnNetrE8PFcn3PzEwmZaV7X+ke3Ea88BdrtCPJpxWNbA E0Pw== X-Received: by 10.68.186.132 with SMTP id fk4mr16953602pbc.18.1363359140775; Fri, 15 Mar 2013 07:52:20 -0700 (PDT) Received: from dhcp-5540.meeting.ietf.org (dhcp-5540.meeting.ietf.org. [130.129.85.64]) by mx.google.com with ESMTPS id hs8sm9123196pbc.27.2013.03.15.07.52.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 07:52:19 -0700 (PDT) Message-ID: <5143359F.1040306@gmail.com> Date: Fri, 15 Mar 2013 10:52:15 -0400 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michael Young References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> <51432EBF.1060705@viagenie.ca> <6D671966-A280-4D29-A7B2-0F7B8BBF2704@mwyoung.ca> In-Reply-To: <6D671966-A280-4D29-A7B2-0F7B8BBF2704@mwyoung.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:52:24 -0000 Our rate limiting implementation deals with database harvesting issues and privacy requirements that were set by our community a long time ago for our legacy port 43 service. It is not meant as a defense against DoS attacks. We have three time windows (1 min, 5 min and 1 day, easily configurable in our RDAP server, not so much in the port 43 server), a different limit for each per source IP and we also have black and white IP lists. For the RDAP server we have introduced API keys, where the limits for the time windows can be set per API key entry. We'll be providing implementation details to the list. regards ~Carlos On 3/15/13 10:46 AM, Michael Young wrote: > Ok thanks I understand what you meant now. I'm not sure I agree that sleeping the bad clients isn't effective - it certainly worked for me in the past. But I do agree its not a solution by itself, progressive behaviors are needed. > > I do think that having authenticated Whois as a standard helps us all identify good and bad actors more easily. You can then vary your behaviors based on user profiling - that means you can opt to be more helpful to what you determine to be a genuinely well intentioned but poorly behaving client. It even allows for out of band direction or instruction via contact info gathered during the user signup process. > > I don't see any real reason not to go to authenticated Whois - privacy issues can still be addressed - you can opt to allow users to remain anonymous and we are still way better off than today, IMHO. > > Btw Good talk Simon, your thoughts have merit. > > Michael Young > > M:647-289-1220 > > On 2013-03-15, at 10:22, Simon Perreault wrote: > >> Le 2013-03-15 10:15, Michael Young a écrit : >>> Sure I'm defending against evil clients as well,.... Why assume its all well intentioned? Data mining is huge in our industry >> >> You misunderstood my point. Let me try again. >> >> You *have* to implement a set of defences against evil clients. That doesn't change whether you sleep or send 429, because both of them *do not* defend against evil clients. Evil clients can easily hurt you even if you sleep or send 429. Sleeping and 429 are not defences against evil clients. Something else is needed. Something like progressive blacklisting of IP prefixes, as you described. >> >> Now, after you have implemented that set of defences against evil clients, you may then want to address the problem of good-intentioned clients that happen to query too quickly by mistake. That problem is addressed by giving clients *information* about what kind of behaviour is acceptable, so that they can adjust theirs. Status code 429 and the Retry-After header are the HTTP standard ways of conveying that information. Sleeping only gives implicit information, which the client needs to heuristically discover. It is better to provide explicit information because it is more robust and unambiguous. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From jean-philippe.dionne@viagenie.ca Fri Mar 15 09:27:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6707821F8887 for ; Fri, 15 Mar 2013 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-tLnZHJ9kOE for ; Fri, 15 Mar 2013 09:27:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8551921F886D for ; Fri, 15 Mar 2013 09:27:39 -0700 (PDT) Received: from dhcp-152b.meeting.ietf.org (dhcp-152b.meeting.ietf.org [130.129.21.43]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94F29469F3 for ; Fri, 15 Mar 2013 12:27:08 -0400 (EDT) Message-ID: <51434BE1.604@viagenie.ca> Date: Fri, 15 Mar 2013 12:27:13 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <20130314184720.2233.33923.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F24331A2D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24331A2D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:27:40 -0000 On 2013-03-14 14:51, Hollenbeck, Scott wrote: > Notes from the change summary: > > -03: Changed 'query' to 'lookup' in document title to better > describe the 'exact match lookup' purpose of this document. > Included a multitude of minor additions and clarifications > provided by Marc Blanchet and Jean-Philippe Dionne. Modified the > domain and name server sections to include support for IDN > U-labels. 'exact match lookup' means it describes a single ressource in the database, but may have multiple url representing the ressource. For example, we allow IPv6 addresses to be in compressed or uncompressed form and domain name are case insensitive. All the identifiers, except the entity handle, described in the draft had a reference to a document describing precisely their format and their equivalence class. The entity handle is special because it can have a format that is local to a registry. For example, it can be case sensitive or insensitive. Should we have any recommendation about the format of the entity handle? If there is no universal namespace for the entity handle, how do we handle name collision in case of redirection? Jean-Philippe From superuser@gmail.com Fri Mar 15 09:29:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEC021F85F3 for ; Fri, 15 Mar 2013 09:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqTmcAHK+rjn for ; Fri, 15 Mar 2013 09:29:54 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 65CFA21F85C2 for ; Fri, 15 Mar 2013 09:29:53 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so3369616obb.22 for ; Fri, 15 Mar 2013 09:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ZqIKPOVerOlRKFCaFIJffUk3nYUtbA4YUn2vDy3LBjs=; b=QpvxV0IlhAmJJ2C42e11n59kNuGjQfkE+MZJQXAeHKAD6HWAwZ1FnEu42cBtaOCdIn JY2/K4g/4QH6n3D4sTY451eWXUkzyYPrIDdrpg2lUmMANJxjI6PR6kQapXgyPETYNT7P aBjRpxm5z96J4ftOZ2baNktyzvcsFlJdgwVjWqwptI/Tg1+lE+7tj3UpiEl9ZZ9Pbxqr YOVF4D2DQedEUZJZ9J4qD1UOlQgVz+OSz/kVDbnbPGZtIe71frHcv6TSw79Ew18qW3m0 XSHGqBPSawbmjckBmqf4egZlQh1oedD5zUCDBGc7QEI4yvJ73ff8igCtJrpW3/qtM6WJ lpcQ== MIME-Version: 1.0 X-Received: by 10.182.113.40 with SMTP id iv8mr3144298obb.12.1363364992462; Fri, 15 Mar 2013 09:29:52 -0700 (PDT) Received: by 10.60.123.35 with HTTP; Fri, 15 Mar 2013 09:29:52 -0700 (PDT) Date: Fri, 15 Mar 2013 12:29:52 -0400 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d04479f9513392f04d7f9260e Subject: [weirds] draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:29:55 -0000 --f46d04479f9513392f04d7f9260e Content-Type: text/plain; charset=ISO-8859-1 Colleagues, I just noticed that our charter shows the above-named draft as a February deliverable. We are therefore late. To the authors especially, but the WG in general: Is this document ready for a WGLC or does it have some things open that would make that premature? -MSK, WEIRDS co-chair --f46d04479f9513392f04d7f9260e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

I just noticed that our chart= er shows the above-named draft as a February deliverable.=A0 We are therefo= re late.

To the authors especially, but the WG in general: Is = this document ready for a WGLC or does it have some things open that would = make that premature?

-MSK, WEIRDS co-chair
--f46d04479f9513392f04d7f9260e-- From jean-philippe.dionne@viagenie.ca Fri Mar 15 09:51:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5521F8548 for ; Fri, 15 Mar 2013 09:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNbaj1egIuzP for ; Fri, 15 Mar 2013 09:51:26 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03F21F8574 for ; Fri, 15 Mar 2013 09:51:26 -0700 (PDT) Received: from dhcp-152b.meeting.ietf.org (dhcp-152b.meeting.ietf.org [130.129.21.43]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0CFF240433 for ; Fri, 15 Mar 2013 12:51:24 -0400 (EDT) Message-ID: <51435192.7040109@viagenie.ca> Date: Fri, 15 Mar 2013 12:51:30 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:51:27 -0000 On 2013-03-15 12:29, Murray S. Kucherawy wrote: > I just noticed that our charter shows the above-named draft as a > February deliverable. We are therefore late. > > To the authors especially, but the WG in general: Is this document ready > for a WGLC or does it have some things open that would make that premature? Hi, I think it is premature. Here's topics that needs to be discussed/included: 1. There is confusion about the default content-type. Either, we say that the accept header is mendatory for rdap client or we say that server must have a 'application/rdap' as the default content-type. 2. Following the security discussion, it was unclear what parts of http must be supported. Some authentication mechanism might rely on cookies and it was proposed on during the last wg session that cookies could be disabled to circumscribe the possible authentication mechanisms. 3. The rate limiting status code proposed by Simon should be added to the section 5. Cheers Jean-Philippe From superuser@gmail.com Fri Mar 15 10:08:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B1621F8896 for ; Fri, 15 Mar 2013 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeBImdagVcNp for ; Fri, 15 Mar 2013 10:08:09 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0163321F8552 for ; Fri, 15 Mar 2013 10:08:07 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ni5so3449324obc.26 for ; Fri, 15 Mar 2013 10:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IY9ZmHMtyXN8WOVwkGmQvkTFF5jJAf6K6pWD9NQg98Y=; b=x8x/aUNmd/nTm4D1kbRHGbwudTLJoGlpu78sOcdYUadiyIs8GeME9qONrvFwyS3gwC TEn7f7R3RhwjoLpUXykbOVIqnhohOb3jFUNhprmJ4DXAuudJqBilMwepHQPmkb/mM1QG GT1OPRHNq1lnFkzsVotW4dNTctCLWSTs4V1SfbfLIJAfS3EqUttwNnVKocU7p9f+4RRb xAstWfH6cAdI+4d3CaMLa72MqCqS37SbM9JZ2Z8Xt9b3sPEqYmWAdII1t0zxzjb/kALM Mo3Gd6c9BqP3+6f5tMH9g7m8oK/gBeKc5qx+4AtgiO+uF6XIaKXHg2IE5bYStSdwC15D qFqg== MIME-Version: 1.0 X-Received: by 10.60.29.194 with SMTP id m2mr3140070oeh.36.1363367287072; Fri, 15 Mar 2013 10:08:07 -0700 (PDT) Received: by 10.60.123.35 with HTTP; Fri, 15 Mar 2013 10:08:06 -0700 (PDT) In-Reply-To: <51435192.7040109@viagenie.ca> References: <51435192.7040109@viagenie.ca> Date: Fri, 15 Mar 2013 13:08:06 -0400 Message-ID: From: "Murray S. Kucherawy" To: Jean-Philippe Dionne Content-Type: multipart/alternative; boundary=e89a8ff252a0d8314b04d7f9aea5 Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:08:10 -0000 --e89a8ff252a0d8314b04d7f9aea5 Content-Type: text/plain; charset=ISO-8859-1 Could you open these issues in the tracker? We need to drive work on this since we're now behind schedule. Let us know if it's inaccessible or misconfigured or otherwise needs attention first. On Fri, Mar 15, 2013 at 12:51 PM, Jean-Philippe Dionne < jean-philippe.dionne@viagenie.ca> wrote: > On 2013-03-15 12:29, Murray S. Kucherawy wrote: > > I just noticed that our charter shows the above-named draft as a > > February deliverable. We are therefore late. > > > > To the authors especially, but the WG in general: Is this document ready > > for a WGLC or does it have some things open that would make that > premature? > > Hi, > > I think it is premature. Here's topics that needs to be > discussed/included: > > 1. There is confusion about the default content-type. Either, we say > that the accept header is mendatory for rdap client or we say that > server must have a 'application/rdap' as the default content-type. > > 2. Following the security discussion, it was unclear what parts of http > must be supported. Some authentication mechanism might rely on cookies > and it was proposed on during the last wg session that cookies could be > disabled to circumscribe the possible authentication mechanisms. > > 3. The rate limiting status code proposed by Simon should be added to > the section 5. > > Cheers > Jean-Philippe > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --e89a8ff252a0d8314b04d7f9aea5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Could you open these issues in the tracker?=A0 We nee= d to drive work on this since we're now behind schedule.=A0 Let us know= if it's inaccessible or misconfigured or otherwise needs attention fir= st.


O= n Fri, Mar 15, 2013 at 12:51 PM, Jean-Philippe Dionne <= ;jean= -philippe.dionne@viagenie.ca> wrote:
On 2013-03-15 12:29, Murra= y S. Kucherawy wrote:
> I just noticed that our charter shows the above-named draft as a
> February deliverable. =A0We are therefore late.
>
> To the authors especially, but the WG in general: Is this document rea= dy
> for a WGLC or does it have some things open that would make that prema= ture?

Hi,

I think it is premature. =A0Here's topics that needs to be discussed/in= cluded:

1. There is confusion about the default content-type. =A0Either, we say
that the accept header is mendatory for rdap client or we say that
server must have a 'application/rdap' as the default content-type.<= br>
2. Following the security discussion, it was unclear what parts of http
must be supported. =A0 Some authentication mechanism might rely on cookies<= br> and it was proposed on during the last wg session that cookies could be
disabled to circumscribe the possible authentication mechanisms.

3. The rate limiting status code proposed by Simon should be added to
the section 5.

Cheers
Jean-Philippe
_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--e89a8ff252a0d8314b04d7f9aea5-- From michael@mwyoung.ca Fri Mar 15 11:23:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D442D21F854F for ; Fri, 15 Mar 2013 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.128 X-Spam-Level: *** X-Spam-Status: No, score=3.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_EQ_CPE=0.979, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzQAtTJ2iFuj for ; Fri, 15 Mar 2013 11:23:49 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F273B21F84E9 for ; Fri, 15 Mar 2013 11:23:48 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so4692362iea.5 for ; Fri, 15 Mar 2013 11:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=oKZ3bZTUOcZGX3wLWKWxMF6qp6jFb2j7sm4UYKMeHzw=; b=GyBo0kBtFt/oAOqYTG0aw0GVjnTL/FK/Wzi0DAKkfeKuwFeScsy4s+xSnfBpKbPhbR uvQuKEmJJMwYJxnnj9Fc3+FdXKtaea00zNxu4R+5A6V/rIrUWfO/RL94b5sgHVMNprtE lzke5wpVjUrq5wJ0XEKnHgkFGE0M3PQIDPUQIO4ES/xaGE2IcJFn28o+U5WPTIoZpWm4 qK2j+X3PZSKRrUKdedI351RxdDAJLVvuUt2OIvOz02j8pXLW7c9TW9/yZjX4tV30tQgt tERr3gPSboi5JueFQiO5LxZjF9CTkA+1XlfBggWwLsPZXRmoAIfQIHNxt7DjWDT0ktB2 Pcbg== X-Received: by 10.50.88.233 with SMTP id bj9mr2031420igb.55.1363371827205; Fri, 15 Mar 2013 11:23:47 -0700 (PDT) Received: from [172.16.1.22] (CPEf87b8c0c1175-CM78cd8ece2635.cpe.net.cable.rogers.com. [99.226.4.150]) by mx.google.com with ESMTPS id wn10sm2328069igb.2.2013.03.15.11.23.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 11:23:45 -0700 (PDT) References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> <51432EBF.1060705@viagenie.ca> <6D671966-A280-4D29-A7B2-0F7B8BBF2704@mwyoung.ca> <5143359F.1040306@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5143359F.1040306@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5E950FF7-4359-41AA-BD8F-BA61D910BBBC@mwyoung.ca> X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Fri, 15 Mar 2013 14:23:43 -0400 To: "carlos@lacnic.net" X-Gm-Message-State: ALoCoQkgwY7HW7J3THQb8PGytgBisAxyISN9eC6fnUdbPkoG619HSonnkeV/b5tean4dJkEHo1cx Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:23:50 -0000 I look forward to seeing those details, particularly what you did with the A= PI keys, thanks Carlos. Michael Young M:647-289-1220 On 2013-03-15, at 10:52, "Carlos M. Martinez" wrote:= > Our rate limiting implementation deals with database harvesting issues > and privacy requirements that were set by our community a long time ago > for our legacy port 43 service. >=20 > It is not meant as a defense against DoS attacks. >=20 > We have three time windows (1 min, 5 min and 1 day, easily configurable > in our RDAP server, not so much in the port 43 server), a different > limit for each per source IP and we also have black and white IP lists. >=20 > For the RDAP server we have introduced API keys, where the limits for > the time windows can be set per API key entry. >=20 > We'll be providing implementation details to the list. >=20 > regards >=20 > ~Carlos >=20 > On 3/15/13 10:46 AM, Michael Young wrote: >> Ok thanks I understand what you meant now. I'm not sure I agree that sle= eping the bad clients isn't effective - it certainly worked for me in the pa= st. But I do agree its not a solution by itself, progressive behaviors are n= eeded.=20 >>=20 >> I do think that having authenticated Whois as a standard helps us all ide= ntify good and bad actors more easily. You can then vary your behaviors base= d on user profiling - that means you can opt to be more helpful to what you d= etermine to be a genuinely well intentioned but poorly behaving client. It e= ven allows for out of band direction or instruction via contact info gathere= d during the user signup process. >>=20 >> I don't see any real reason not to go to authenticated Whois - privacy is= sues can still be addressed - you can opt to allow users to remain anonymous= and we are still way better off than today, IMHO. >>=20 >> Btw Good talk Simon, your thoughts have merit. >>=20 >> Michael Young >>=20 >> M:647-289-1220 >>=20 >> On 2013-03-15, at 10:22, Simon Perreault wr= ote: >>=20 >>> Le 2013-03-15 10:15, Michael Young a =C3=A9crit : >>>> Sure I'm defending against evil clients as well,.... Why assume its all= well intentioned? Data mining is huge in our industry >>>=20 >>> You misunderstood my point. Let me try again. >>>=20 >>> You *have* to implement a set of defences against evil clients. That doe= sn't change whether you sleep or send 429, because both of them *do not* def= end against evil clients. Evil clients can easily hurt you even if you sleep= or send 429. Sleeping and 429 are not defences against evil clients. Someth= ing else is needed. Something like progressive blacklisting of IP prefixes, a= s you described. >>>=20 >>> Now, after you have implemented that set of defences against evil client= s, you may then want to address the problem of good-intentioned clients that= happen to query too quickly by mistake. That problem is addressed by giving= clients *information* about what kind of behaviour is acceptable, so that t= hey can adjust theirs. Status code 429 and the Retry-After header are the HT= TP standard ways of conveying that information. Sleeping only gives implicit= information, which the client needs to heuristically discover. It is better= to provide explicit information because it is more robust and unambiguous. >>>=20 >>> Simon >>> --=20 >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 From fobispo@isc.org Fri Mar 15 11:34:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2395721F89AF for ; Fri, 15 Mar 2013 11:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjdKpqUD4o5f for ; Fri, 15 Mar 2013 11:34:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id ED90F21F898B for ; Fri, 15 Mar 2013 11:34:51 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2C798C94D3; Fri, 15 Mar 2013 18:34:43 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363372491; bh=cagbeZjHyDAftHaRXQ/fglnq6hevh++HJanLNdcvEOg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=e8FyJbHO9XZpRvdvDSrsGEno3i0T3VSaGMVdORMIhCw+ZJQVr46i9OSATMof6OvLt Ss/i2pDaGspCFjme2ZepSoF7+cZaQjEmx7QsvUtnrRe/CL240gQ3SltIz6GrLad1N7 xQojPsQXaiqqkBbrfv9Xz2WbWDCk4glRgFs8DTBs= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 15 Mar 2013 18:34:43 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E7394216C40; Fri, 15 Mar 2013 18:34:42 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <5143359F.1040306@gmail.com> Date: Fri, 15 Mar 2013 11:34:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0592EA48-5F2D-4315-885F-C74B404968AC@isc.org> References: <51424BF2.5050005@viagenie.ca> <5142BB27.6070806@gmail.com> <51432325.5070204@viagenie.ca> <2C8F9419-0820-47ED-8E55-1639C1465D60@mwyoung.ca> <514328D5.7050905@viagenie.ca> <1D5048F9-A208-4F31-8B53-C65875739FCB@mwyoung.ca> <51432EBF.1060705@viagenie.ca> <6D671966-A280-4D29-A7B2-0F7B8BBF2704@mwyoung.ca> <5143359F.1040306@gmail.com> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "weirds@ietf.org" Subject: Re: [weirds] Rate limiting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:34:53 -0000 I think it's all about the design, We only serve whois queries from the database if they are not in the = local cache, and even so, we don't query a master server, we query a = replica. We're implementing the same functionality on the RDAP server, so it = takes advantage of this model as well. This is one of the reason why it's a good idea to keep the objects = separate, because those can be cached individually. If you cache the = full response, you later have to re-fetch an object that already was = used in another response. francisco On Mar 15, 2013, at 7:52 AM, Carlos M. Martinez = wrote: > Our rate limiting implementation deals with database harvesting issues > and privacy requirements that were set by our community a long time = ago > for our legacy port 43 service. >=20 > It is not meant as a defense against DoS attacks. >=20 > We have three time windows (1 min, 5 min and 1 day, easily = configurable > in our RDAP server, not so much in the port 43 server), a different > limit for each per source IP and we also have black and white IP = lists. >=20 > For the RDAP server we have introduced API keys, where the limits for > the time windows can be set per API key entry. >=20 > We'll be providing implementation details to the list. >=20 > regards >=20 > ~Carlos >=20 > On 3/15/13 10:46 AM, Michael Young wrote: >> Ok thanks I understand what you meant now. I'm not sure I agree that = sleeping the bad clients isn't effective - it certainly worked for me in = the past. But I do agree its not a solution by itself, progressive = behaviors are needed.=20 >>=20 >> I do think that having authenticated Whois as a standard helps us all = identify good and bad actors more easily. You can then vary your = behaviors based on user profiling - that means you can opt to be more = helpful to what you determine to be a genuinely well intentioned but = poorly behaving client. It even allows for out of band direction or = instruction via contact info gathered during the user signup process. >>=20 >> I don't see any real reason not to go to authenticated Whois - = privacy issues can still be addressed - you can opt to allow users to = remain anonymous and we are still way better off than today, IMHO. >>=20 >> Btw Good talk Simon, your thoughts have merit. >>=20 >> Michael Young >>=20 >> M:647-289-1220 >>=20 >> On 2013-03-15, at 10:22, Simon Perreault = wrote: >>=20 >>> Le 2013-03-15 10:15, Michael Young a =E9crit : >>>> Sure I'm defending against evil clients as well,.... Why assume its = all well intentioned? Data mining is huge in our industry >>>=20 >>> You misunderstood my point. Let me try again. >>>=20 >>> You *have* to implement a set of defences against evil clients. That = doesn't change whether you sleep or send 429, because both of them *do = not* defend against evil clients. Evil clients can easily hurt you even = if you sleep or send 429. Sleeping and 429 are not defences against evil = clients. Something else is needed. Something like progressive = blacklisting of IP prefixes, as you described. >>>=20 >>> Now, after you have implemented that set of defences against evil = clients, you may then want to address the problem of good-intentioned = clients that happen to query too quickly by mistake. That problem is = addressed by giving clients *information* about what kind of behaviour = is acceptable, so that they can adjust theirs. Status code 429 and the = Retry-After header are the HTTP standard ways of conveying that = information. Sleeping only gives implicit information, which the client = needs to heuristically discover. It is better to provide explicit = information because it is more robust and unambiguous. >>>=20 >>> Simon >>> --=20 >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >>=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From edainow@afilias.info Fri Mar 15 13:32:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E5D21F8765 for ; Fri, 15 Mar 2013 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49P48y602T3W for ; Fri, 15 Mar 2013 13:32:50 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DC64821F86C2 for ; Fri, 15 Mar 2013 13:32:46 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UGbJ0-0004Nc-3W for weirds@ietf.org; Fri, 15 Mar 2013 20:32:46 +0000 Received: from mail-bk0-f70.google.com ([209.85.214.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UGbIz-0005W0-6G for weirds@ietf.org; Fri, 15 Mar 2013 20:32:46 +0000 Received: by mail-bk0-f70.google.com with SMTP id jk7so3380844bkc.5 for ; Fri, 15 Mar 2013 13:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=8Aj1IKz/P03SntkAKDz0Y5Vu8uffNmhOCbMP2Y+rAA0=; b=j4A7za/mW6GPqwJ282665h10RCn04Nc4p5Emr8QWn2fVFH5Eb4ShI2PNaFsCaO7rC2 JaBQno+rIrGBbOoU34FeKyM/MWY/aQJcI/813dxK/Vnt+BYspfOTtCjd5Fe6b5ot85YF jzRbYUCWOsxdHVHzaQ1bAAIK6O+b9ggNsgxiBnMOR7uC6bScojnKTVkE80YU/6AWqWbM 8cqjuZAWav04y20gaGJDWCF111TKlld3OOWCi0hkVxECnhqS8zBxpWtf9AfqsUFjKzME Brp5Wd+EUy5uyqwYQ4dDTwkxf7BMWEya7wy/BwBiE8tjFxLvygfwkH3fXKQGkL5yvaUG lcOA== X-Received: by 10.152.132.138 with SMTP id ou10mr6953898lab.56.1363379559671; Fri, 15 Mar 2013 13:32:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.132.138 with SMTP id ou10mr6953888lab.56.1363379559303; Fri, 15 Mar 2013 13:32:39 -0700 (PDT) Received: by 10.112.155.164 with HTTP; Fri, 15 Mar 2013 13:32:39 -0700 (PDT) Date: Fri, 15 Mar 2013 16:32:39 -0400 Message-ID: From: Ernie Dainow To: weirds@ietf.org Content-Type: multipart/alternative; boundary=f46d042d051c539ebf04d7fc8a90 X-Gm-Message-State: ALoCoQnUJuIbvyXEvgU34WwDdgBhhEbStMRCl6eWMhJiRBWCpfs27biC7DFipXzVue0nBCJLgLNeafXVnVvK/Eh7DSOnDfgh1Xv9lIZdS16N6dWVBIs4+fA+ECJpU772THCk3uTgAKzx Subject: [weirds] links X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:32:51 -0000 --f46d042d051c539ebf04d7fc8a90 Content-Type: text/plain; charset=ISO-8859-1 I found the use of links rather unclear in draft-ietf-weirds-json-response-02. While the syntax and basic concept are well explained, some guidance as to when to use links and what relationship type should be used would be helpful. Most of the examples are of relationship "self". If a client follows such a link, it seems it will get back mostly information that it already has (in the examples). So what is the value of this type of link? I think this type of link should be "rel: alternate", so that a client does not waste time getting duplicate information. A useful guideline would be to use a "self" link where an object has been returned with only its handle (such as in an entity) and not much else. In this case a client knows it can follow the link to get the details of the object. One interesting link is shown in section 10. "value" : "http://example.net/ip/2001:db8::/48", "rel" : "up", "href" : "http://example.net/ip/2001:C00::/23" Presumably this is a link to get the parent network. What is the recommended way to get child networks? The IANA list does not include anything like "down" or "child" http://www.iana.org/assignments/link-relations/link-relations.xml What about the set of relations: first, last, previous, next? Would one expect these to be provided for the IP Network object, or any other RDAP objects? It might be best for people working on client implementations to suggest links they would expect or like to see. If clear guidelines are not provided, it really won't be clear to a client what it should do with a link, especially if different server implementations have a different interpretation of what the different relationships mean in the RDAP context. -Ernie --f46d042d051c539ebf04d7fc8a90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I found the use of links rather unclear in draft-ietf-weirds-json-resp= onse-02. While the syntax and basic concept are well explained, some guidan= ce as to when to use links and what relationship type should be used would = be helpful.

Most of the examples are of relationship "self&quo= t;. If a client follows such a link, it seems it will get back mostly infor= mation that it already has (in the examples). So what is the value of this = type of link? I think this type of link should be "rel: alternate"= ;, so that a client does not waste time getting duplicate information.

A useful guideline would be to use a "self" l= ink where an object has been returned with only its handle (such as in an e= ntity) and not much else. In this case a client knows it can follow the lin= k to get the details of the object.

One interesting link is shown in section 10.
&quo= t;rel" : "up",
"href" : "http://example.net/ip/2001:C00::/23"<= /div>
Presumably this is a link to get the parent network. What is the recom= mended way to get child networks? The IANA list does not include anything l= ike "down" or "child" http://www.iana.org/assignment= s/link-relations/link-relations.xml

What about the set of relations: first, last, previous,= next? Would one expect these to be provided for the IP Network object, or = any other RDAP objects?

It might be best for peopl= e working on client implementations to suggest links they would expect or l= ike to see. If clear guidelines are not provided, it really won't be cl= ear to a client what it should do with a link, especially if different serv= er implementations have a different interpretation of what the different re= lationships mean in the RDAP context.

-Ernie
--f46d042d051c539ebf04d7fc8a90-- From prvs=7799c5f94=fmartin@linkedin.com Fri Mar 15 13:43:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AB321F88B0 for ; Fri, 15 Mar 2013 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMhqQtTeQvMl for ; Fri, 15 Mar 2013 13:43:01 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCF021F889B for ; Fri, 15 Mar 2013 13:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1363380181; x=1394916181; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=9/m1PT7qZ6OKEOaq0qgQme/E1tHIAwEKHwIZMBc98q0=; b=XFfynctS8R3VZGLJrVUo1PbC5WA7g03nxpIDymrUi2RVgBe/rmsPpPTE gvpjaDLksDZaaOcO9NSIE50c9PE08Lf+G8NgwSzNf3Bkzu8PogZ361SOy nrJe8EVJt5kU9hjSVpqr8CazX0LqSwzgx/kMuxTIfiia7NwYro9P1hESy 8=; X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208,217";a="41182366" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 15 Mar 2013 13:42:51 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 13:42:51 -0700 From: Franck Martin To: "weirds@ietf.org" Thread-Topic: Newbie questions Thread-Index: AQHOIb2pgnR8NPZW/EuOb+fOdOClbQ== Date: Fri, 15 Mar 2013 20:42:51 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52E4BA5AESV4MBX01linked_" MIME-Version: 1.0 Subject: [weirds] Newbie questions X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:43:02 -0000 --_000_77426B543150464AA3F30DF1A91365DE52E4BA5AESV4MBX01linked_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9vIG11Y2ggdG8gcmVhZCBzbyBhbGxvdyBtZSB0byBzaG9ydGN1dCB0byBmaW5kIG15IHdheXMu Li4NCg0KSSB0aGluayB0aGUgV0cgY2hhcnRlciBsaW1pdHMgdGhlIHByb3RvY29sIHRvIGh0dHAs IGJ1dCBoYXZlIHlvdSBjb25zaWRlcmVkIHNvbWV0aGluZyBsaWtlIGh0dHA6Ly9hYnVzaXgub3Jn L3NlcnZpY2UvYWJ1c2UtY29udGFjdC1kYg0KRm9yIGEgbWFpbCBzZXJ2ZXIgRE5TIGlzIG1vcmUg bmF0dXJhbCB0aGFuIGh0dHAuIEtub3dpbmcgaW4gYSBxdWVyeSBob3cgb2xkIGlzIHRoZSBkb21h aW4gbmFtZSwgd2hvIGlzIHRoZSByZWdpc3RyYXIsIHJlZ2lzdHJhbnQgYW5kIHdoYXQgaXMgdGhl IGVtYWlsIGFkZHJlc3MgZm9yIGFidXNlIHdvdWxkIEkgdGhpbmsgaGVscCBpbiBhbiBlbWFpbCBy ZXB1dGF0aW9uIHN5c3RlbS9lbWFpbCByZXBvcnRpbmcgc3lzdGVtLg0KDQpXaGljaCBkb2N1bWVu dCBkZWZpbmVzIHRoZSBsaXN0IG9mIGZpZWxkcyBhbmQgdGhlaXIgZm9ybWF0PyBPciBvcyBpdCBv dXQgb2Ygc2NvcGU/IEkgZG9uJ3QgbWVhbiB3aGljaCBmaWVsZHMgYXJlIG1hbmRhdG9yeSwgYnV0 IGlmIHdhbnQgdG8gcmVwb3J0IHdoZW4gdGhlIGRvbWFpbiB3YXMgcmVnaXN0ZXJlZCwgd2hhdCBm aWVsZCBzaG91bGQgSSB1c2UgYW5kIHdoYXQgZm9ybWF0Pw0KDQpUaGFua3MuDQoNCg== --_000_77426B543150464AA3F30DF1A91365DE52E4BA5AESV4MBX01linked_ Content-Type: text/html; charset="utf-8" Content-ID: <35F96C392D7E104C85BDDBC0BEA44CDD@linkedin.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+VG9vIG11Y2gg dG8gcmVhZCBzbyBhbGxvdyBtZSB0byBzaG9ydGN1dCB0byBmaW5kIG15IHdheXMuLi48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsgdGhlIFdHIGNoYXJ0ZXIgbGltaXRzIHRo ZSBwcm90b2NvbCB0byBodHRwLCBidXQgaGF2ZSB5b3UgY29uc2lkZXJlZCBzb21ldGhpbmcgbGlr ZSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9hYnVzaXgub3JnL3NlcnZpY2UvYWJ1c2UtY29udGFjdC1k YiI+aHR0cDovL2FidXNpeC5vcmcvc2VydmljZS9hYnVzZS1jb250YWN0LWRiPC9hPjwvZGl2Pg0K PGRpdj5Gb3IgYSBtYWlsIHNlcnZlciBETlMgaXMgbW9yZSBuYXR1cmFsIHRoYW4gaHR0cC4gS25v d2luZyBpbiBhIHF1ZXJ5IGhvdyBvbGQgaXMgdGhlIGRvbWFpbiBuYW1lLCB3aG8gaXMgdGhlIHJl Z2lzdHJhciwgcmVnaXN0cmFudCBhbmQgd2hhdCBpcyB0aGUgZW1haWwgYWRkcmVzcyBmb3IgYWJ1 c2Ugd291bGQgSSB0aGluayBoZWxwIGluIGFuIGVtYWlsIHJlcHV0YXRpb24gc3lzdGVtL2VtYWls IHJlcG9ydGluZyBzeXN0ZW0uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGljaCBk b2N1bWVudCBkZWZpbmVzIHRoZSBsaXN0IG9mIGZpZWxkcyBhbmQgdGhlaXIgZm9ybWF0PyBPciBv cyBpdCBvdXQgb2Ygc2NvcGU/IEkgZG9uJ3QgbWVhbiB3aGljaCBmaWVsZHMgYXJlIG1hbmRhdG9y eSwgYnV0IGlmIHdhbnQgdG8gcmVwb3J0IHdoZW4gdGhlIGRvbWFpbiB3YXMgcmVnaXN0ZXJlZCwg d2hhdCBmaWVsZCBzaG91bGQgSSB1c2UgYW5kIHdoYXQgZm9ybWF0PzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLjwvZGl2Pg0KPGJyPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_77426B543150464AA3F30DF1A91365DE52E4BA5AESV4MBX01linked_-- From johnl@iecc.com Fri Mar 15 17:02:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCD311E80FB for ; Fri, 15 Mar 2013 17:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.049 X-Spam-Level: X-Spam-Status: No, score=-109.049 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t51jVr8vSxJO for ; Fri, 15 Mar 2013 17:02:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0420611E80F7 for ; Fri, 15 Mar 2013 17:02:36 -0700 (PDT) Received: (qmail 32225 invoked from network); 16 Mar 2013 00:02:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 00:02:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5143b69b.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=3PQM4fNhDiZB2UTtfK3fLuuKcvlCUfuykizoFMnTdTI=; b=XpTrk7Z6GmFqOvh3uXJPcq5N4pg9stkAIaW+15zJwtrqC9O5G4zm969mb6L3Sus5x2msEnj5XOybKtZKpsUF7NFvSNdoM9aD9x/lBiW5/oshuGmKAV71OwsVvptykYLJ/882zRduILJqUw0iLZIg7cYZTglplz5s2qyMy4wh2rM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5143b69b.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=3PQM4fNhDiZB2UTtfK3fLuuKcvlCUfuykizoFMnTdTI=; b=jBvYV3qremHRE8Yl2cHJSnLdWaBmnMQalFQOdrMJvFi6ZKoDCEJryKPlfYO4FlRG00jncWIavj3weSp4l8plQhxL8uXj3Ydz6M38zmXe2KQZRFzZ4tVQv+Q+dhvr3izKg2/HXu90AvVP47nKsk+MdmdLLpMYL5D3fxbWoFv2bm8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 00:02:13 -0000 Message-ID: <20130316000213.9874.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 00:02:38 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Could you open these issues in the tracker? We need to drive work on this >since we're now behind schedule. Let us know if it's inaccessible or >misconfigured or otherwise needs attention first. I'm not J-P, but I added three tracker entries, numbers 3, 4, and 5. Will respond to some of them once I escape from the Cleveland airport. From carlosm3011@gmail.com Fri Mar 15 17:53:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B5121F859B for ; Fri, 15 Mar 2013 17:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDRa8sW7njHq for ; Fri, 15 Mar 2013 17:53:49 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A031221F856F for ; Fri, 15 Mar 2013 17:53:49 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uz6so3795012obc.20 for ; Fri, 15 Mar 2013 17:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+dhFPetwY/c+F9vchWankC9JsZjnVwYx0F0S9deAr58=; b=YCxgdvyYqUJjnRj7G4Vxva0DeEnN1LGVam0wm3yRguFiIHflJEJ9IYpfw7dL53M8QS nrRwRBqzvDtv6NbFvXjes3wqbZ0DD+eZi+tw/vnryHTRikn3nFR2F0qthagOQU3c12eO 6ZGEvaislwItoIn62HaIT1RKru7/SAnt6aOk9kzO1+oQNxWtpEv/z8hs1+WcXPvj38XR NfS9o0a62KDwX+/4jejSCA46qreP5y2XHRKuYxSEi6YIx/nDWQWUi+BrycXaxKffq+c8 NrIMNgsJ58WeQ6655NujQHCnFZ3n+gWwlBGy5pF5LyuW+D4DG3tJKSXxEG+zMfy7yVOR Xx0A== X-Received: by 10.182.157.104 with SMTP id wl8mr3870004obb.79.1363395229123; Fri, 15 Mar 2013 17:53:49 -0700 (PDT) Received: from Carloss-MacBook-Pro.local (ip-64-134-184-208.public.wayport.net. [64.134.184.208]) by mx.google.com with ESMTPS id qk4sm4345960obc.5.2013.03.15.17.53.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 17:53:47 -0700 (PDT) Message-ID: <5143C299.9090503@gmail.com> Date: Fri, 15 Mar 2013 20:53:45 -0400 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Franck Martin References: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Newbie questions X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 00:53:50 -0000 I'm afraid we're a bit to far off in the work of the WG to consider that. Besides, IMO, I really don't think that putting all kinds of information into the DNS is such a great idea. People also can create their DNS <-> RDAP proxies if they really, really want to. s2, ~Carlos On 3/15/13 4:42 PM, Franck Martin wrote: > Too much to read so allow me to shortcut to find my ways... > > I think the WG charter limits the protocol to http, but have you > considered something like http://abusix.org/service/abuse-contact-db > For a mail server DNS is more natural than http. Knowing in a query how > old is the domain name, who is the registrar, registrant and what is the > email address for abuse would I think help in an email reputation > system/email reporting system. > > Which document defines the list of fields and their format? Or os it out > of scope? I don't mean which fields are mandatory, but if want to report > when the domain was registered, what field should I use and what format? > > Thanks. > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From johnl@iecc.com Fri Mar 15 22:54:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304121F8CE5 for ; Fri, 15 Mar 2013 22:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.479 X-Spam-Level: X-Spam-Status: No, score=-109.479 tagged_above=-999 required=5 tests=[AWL=1.720, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZSYkNOwEZQs for ; Fri, 15 Mar 2013 22:54:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5994421F8CE0 for ; Fri, 15 Mar 2013 22:54:42 -0700 (PDT) Received: (qmail 307 invoked from network); 16 Mar 2013 05:54:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 05:54:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51440920.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=cclAhXxAMqkIrsVgBnaaXK+0/P/HdPMnmvTNJTImKhs=; b=Cwo7tOj8cOSs0rgWmNOS2ai/N3vS9cMmaUvmACj3zNSOfD+Poc7EfB5THzsrQ/98k55JLRYzFpUbjGjOMJsxJxaJ/Zw1dZ3j9KTmld7mfi9ohOQHdEplQ3yRS8H3IihJY+bH+BrLysdrE/mIpWlOvaCOTVerRVz8nQKkDWYpOrg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51440920.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=cclAhXxAMqkIrsVgBnaaXK+0/P/HdPMnmvTNJTImKhs=; b=ggoxmfiWQ/+nEzCXOQ6Wk5x0/SDZD6iAmA9a7GB9shgu80xb22ddaI+i/X99ZOwFOn5/+rZQkVV2OzzgjfQPqSo2v/+ySUMZyIj4DNMtrgJwR7eOr11Zstbm+hgBIfsw32ZfB+qOsfVYj+q179CKhqawg+15SbXzcauKJ7r/bM0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 05:54:17 -0000 Message-ID: <20130316055417.8130.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 05:54:43 -0000 >2. In sections 3.3 & 3.4 we have: > > If the client sends the server an IDN U-label, servers that support > IDNs MUST convert the IDN into A-label format and perform IDNA > processing as specified in RFC 5891 [RFC5891]. The server should > perform an exact match lookup using the A-label. > >I do not understand the rational behind this paragraph. I believe we do >not have the intention to tell the server implementation how to work. >Some might like to take the proposed approach, but when the server is >able to lookup a domain name in U-label format -- -- it is non-compliant with all IDNA standards, so whatever it is doing is out of scope for WEIRDS. (Keep in mind the "as if" rule, which allows the server to do whatever it wants internally so long as it gets the same result as converting U- to A- and looking up the latter.) I realize this gets more complicated when we try to do partial matches, but let's burn that bridge next week. I would suggest that each input field either has to be all A-labels or all U-labels. Although it's technically possible to translate input like .. I think it's more likely to be a mistake, so even for us writers of tiny scripts, I don't see any utility in allowing it. For outupt, I'd like to see some thing like { u-label: "fóo"; a-label: "xn--fo-pdq" } wherver an IDN domain name can appear, so the clients can just pick out whatever they need. R's, John From johnl@iecc.com Fri Mar 15 22:59:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638B521F8CE7 for ; Fri, 15 Mar 2013 22:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.766 X-Spam-Level: X-Spam-Status: No, score=-109.766 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv20yBZ280PS for ; Fri, 15 Mar 2013 22:59:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 142F321F887F for ; Fri, 15 Mar 2013 22:59:14 -0700 (PDT) Received: (qmail 1199 invoked from network); 16 Mar 2013 05:59:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 05:59:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51440a2b.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=4QK5h/nIHfAh+MMCDdwMT4P1ry4uR1vOBW43lSc45pE=; b=IM/PwB7xcW39dtBTlcaGMnl7h+T2sg+D89cKCX7t3Rmf2bKSriLQJvPqV/Rbb3s4g0PW+NPkC7AF5A5aRPStLmpMW33+MIFRJ2QL0wfMZ2HcqVp/ra9u9qReETBvgdwY3Sl5kjYAAfHVow9ONx6kKnUQyrrCXPLncF9pYPoIzBA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51440a2b.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=4QK5h/nIHfAh+MMCDdwMT4P1ry4uR1vOBW43lSc45pE=; b=dm775sulQ/Zrw27/esw8ATU4myYjMjuXloxgPlH/7o3yt7WmwyKXC0+2xEXps/bfF+qZTlL4g+gYmxg84d7SJKrooN0cg1R7OzDhwakfhdSK2t1FjeQ0cNUK4iuHGBM5pTx67crG6MjV7cF9sWiDYfBg0AwVodRx2xyCrnZh1ls= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 05:58:45 -0000 Message-ID: <20130316055845.9717.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 05:59:16 -0000 >3. Instead of "xn--xemple-9ua.com" as an IDNA >example domain, I think we should use a subdomain of >example.com or something like that. Feel free to use xn--exmple-qta.com / exámple.com and see if you can sneak it past the IESG. From superuser@gmail.com Sat Mar 16 06:48:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6271421F843F for ; Sat, 16 Mar 2013 06:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+-YCHPwPl+c for ; Sat, 16 Mar 2013 06:48:40 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4339521F83DF for ; Sat, 16 Mar 2013 06:48:40 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so1323331wib.10 for ; Sat, 16 Mar 2013 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R7KX/UGwJliD2lx08GzJlD+KSeb+Kh9ziin4JbRXWXw=; b=GJB/OAEEm6zFg1SBQ13dh54wfUDcqANWuwv6MOGIu3c1L99c8RcfkYllkm4mBBlTM+ jAvYeuCA5gi6BaHARXSJt8ZJ2GJciGrBqlXhAhq6787wjS0eGT62AGaj2pTdN8Gxs6Ep x4btV5Qs8fs0urVVmtt90Rsike4t5+obqK4ylRT3IV5NfAQ9e5en0prVMYFYqAXmn9dL zlsFvXUnS9hskMqD3z0jBdNKT0TVMGPCYFToThQsm2WUgWQizjwZ7URcuC1hfVkpq69n msEiSDzRKHNLscfoygC9ItGdE5Q6auTEjoE0f+Mp4cHK3ZvT8CRdBpm5SJrm7dGjxOZw qt0w== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr16311183wjq.51.1363441719292; Sat, 16 Mar 2013 06:48:39 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sat, 16 Mar 2013 06:48:39 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> Date: Sat, 16 Mar 2013 09:48:39 -0400 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7b86cea459b91104d80b0359 Cc: "weirds@ietf.org" Subject: Re: [weirds] Newbie questions X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 13:48:41 -0000 --047d7b86cea459b91104d80b0359 Content-Type: text/plain; charset=ISO-8859-1 I'm fairly sure RDAP supports responses that include those fields. HTTP is more heavyweight than DNS, of course, but replies are cacheable. The work of the REPUTE WG has resulted in extensions to mail servers that use HTTP and they haven't been a huge problem, though admittedly I don't think it's been tried at large scales yet. -MSK On Fri, Mar 15, 2013 at 4:42 PM, Franck Martin wrote: > Too much to read so allow me to shortcut to find my ways... > > I think the WG charter limits the protocol to http, but have you > considered something like http://abusix.org/service/abuse-contact-db > For a mail server DNS is more natural than http. Knowing in a query how > old is the domain name, who is the registrar, registrant and what is the > email address for abuse would I think help in an email reputation > system/email reporting system. > > Which document defines the list of fields and their format? Or os it out > of scope? I don't mean which fields are mandatory, but if want to report > when the domain was registered, what field should I use and what format? > > Thanks. > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --047d7b86cea459b91104d80b0359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm fairly sure RDAP supports responses that incl= ude those fields.=A0 HTTP is more heavyweight than DNS, of course, but repl= ies are cacheable.=A0 The work of the REPUTE WG has resulted in extensions = to mail servers that use HTTP and they haven't been a huge problem, tho= ugh admittedly I don't think it's been tried at large scales yet.
-MSK


On Fri, Mar 15, 2013 at 4:42 PM, Franck Martin <fmartin@link= edin.com> wrote:
Too much to read so allow me to shortcut to find my ways...

I think the WG charter limits the protocol to http, but have you consi= dered something like=A0http://abusix.org/service/abuse-contact-db
For a mail server DNS is more natural than http. Knowing in a query ho= w old is the domain name, who is the registrar, registrant and what is the = email address for abuse would I think help in an email reputation system/em= ail reporting system.

Which document defines the list of fields and their format? Or os it o= ut of scope? I don't mean which fields are mandatory, but if want to re= port when the domain was registered, what field should I use and what forma= t?

Thanks.


_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds


--047d7b86cea459b91104d80b0359-- From johnl@iecc.com Sat Mar 16 12:09:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646FA21F8831 for ; Sat, 16 Mar 2013 12:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.681 X-Spam-Level: X-Spam-Status: No, score=-107.681 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_SPOOF_COM2COM=2.536, SPOOF_COM2OTH=2.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqyOwRuqB6YS for ; Sat, 16 Mar 2013 12:09:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3684421F881D for ; Sat, 16 Mar 2013 12:09:12 -0700 (PDT) Received: (qmail 77128 invoked from network); 16 Mar 2013 19:09:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 19:09:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144c357.xn--hew.k1303; i=johnl@user.iecc.com; bh=sAdGqdi9bQLfNjWYvBlh1WmSweEech36UW6J2BbnYIs=; b=iQP7NhPjNYqZfAcjC5jCDpHBJMd87K2ABkyLazVdUFD95aE5+YnhVJ4cCBon4mxJiaF9peSGEwMjXXBvcjkaHnaBnqlCPBDvVEyRrsXYlepxw1NLJ4tslwBhMwkp2oWfEu51mnn6bklPaF80D6U54YEt9N65EUwXhs8Hdez691g= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144c357.xn--hew.k1303; olt=johnl@user.iecc.com; bh=sAdGqdi9bQLfNjWYvBlh1WmSweEech36UW6J2BbnYIs=; b=qKZ70F+0s1/94zWUd2iPqNY0wH0ObB7YUNCE4GO1ZPty2brgTEZmy0hZunP+eb3q1e3I/PXpX0+ClXsrfaMTS97x5AckKUEmru0aQyrllsMipniB8DqRZ8PTwcHu6wCgSDQ2b65xOkbP5g32mydmrXHqnExvbWHiNa7OoJHumvo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 19:08:48 -0000 Message-ID: <20130316190848.63709.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52E4BA5A@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Newbie questions X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 19:09:14 -0000 >> I think the WG charter limits the protocol to http, but have you >> considered something like http://abusix.org/service/abuse-contact-db >> For a mail server DNS is more natural than http. abuse.net does the same thing, look up example.com.contacts.abuse.net and my funky DNS server will give you TXT records with the contact addresses and HINFO to say where they came from. But I think this sort of thing would be a severely premature optimization for WEIRDS. Both abuse.net and abusix return very simple results, little more than a list of e-mail addresses, while WEIRDS returns all the junk in a WHOIS record. If we deploy this and find performance bottlenecks in practice, we can consider add-ons to return whatever the critical subset is more efficiently. People in a hurry might also look at the CORE working group, which stands for Constrained Restful Environments. They're defining a scheme called COAP which is intended to run over UDP and be so lightweight that it can be implemented in things like light switches. http://tools.ietf.org/id/draft-ietf-core-coap-14.txt Again, this might make sense as a followon, not a replacement for the existing http design. From johnl@iecc.com Sat Mar 16 12:31:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22121F86DC for ; Sat, 16 Mar 2013 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.838 X-Spam-Level: X-Spam-Status: No, score=-109.838 tagged_above=-999 required=5 tests=[AWL=1.361, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRgxq4leq0BE for ; Sat, 16 Mar 2013 12:31:14 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C93C421F86D8 for ; Sat, 16 Mar 2013 12:31:13 -0700 (PDT) Received: (qmail 82062 invoked from network); 16 Mar 2013 19:31:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 19:31:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144c880.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=/s/FyozU1jc2E5g/OckPSD9/j5GvEh63yjQ0KRKb4Dg=; b=aMIFkul5RkGwDfGSx5O5PAjiU7TebJMA77TUh828Qer5F1laRIQQVD7rX4BHb/YVzjhalJ7UW6kqiQaoEr4hRDR4PiniAu4u14kkbaexYN8+wxW8rp7QeEGyoyCohxlufuYqpGBnevVEtNspWWD+3E2yTGg0ai2oiuD+U3AptCg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144c880.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=/s/FyozU1jc2E5g/OckPSD9/j5GvEh63yjQ0KRKb4Dg=; b=eDWzXjGx7Xsg4pfGwNI6/OgyzLwGj08khTgmEZI9VXXhI93LPeaYIJTcb/yazpp93fSCGJv/aH/EiNZkXz3OACCRTjU0SR5dIKXL4/dICsadljUQMWSPDEjqifwcA1tIVL0rcKoFi8qP3TPjKeY9Jur/gPbJ/aRvYxea7cH0F94= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 19:30:50 -0000 Message-ID: <20130316193050.71198.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [weirds] Issue 4: http media types in RDAP replies X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 19:31:14 -0000 My suggestion for 4.1 is to tighten this up and mandate that clients say what they want: Current: Clients SHOULD put the media type of the format they desire in the Accept header field. Accept: application/rdap Servers SHOULD respond with an appropriate media type in the Content- Type header in accordance with the preference rules for the Accept header in HTTP [RFC2616]. Content-Type: application/rdap Clients MAY use a generic media type for the desired data format of the response (e.g. "application/json"), but servers SHOULD respond with the most appropriate media type (e.g. "application/rdap"). In other words, a client may use "application/json" to express that it desires JSON or "application/rdap" to express that it desires RDAP specific JSON, but the server would respond with "application/rdap". Proposed: RDAP clients MUST include an Accept: header specifying application/rdap, application/json, or both. Servers receiving an RDAP request MUST return an entity with Content-Type application/rdap. This specification does not define the responses a server returns to a request with any other media types in the Accept: header, or with no Accept: header. One possibility would be to return a response in a media type suitable for rendering in a web browser. This is deliberately much less flexible, to make it easier for to interoperate. If anyone has a plausible scenario in which an RDAP client can't provide an Accept header, or a server can't respond with application/rdap content type, please speak up now. R's, John PS: curl and wget have no problem sending Accept: headers. From johnl@iecc.com Sat Mar 16 15:55:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29B21F87A4 for ; Sat, 16 Mar 2013 15:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.989 X-Spam-Level: X-Spam-Status: No, score=-109.989 tagged_above=-999 required=5 tests=[AWL=1.210, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uLcQJ2PZ706 for ; Sat, 16 Mar 2013 15:55:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE021F87A3 for ; Sat, 16 Mar 2013 15:55:38 -0700 (PDT) Received: (qmail 48062 invoked from network); 16 Mar 2013 22:55:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Mar 2013 22:55:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144f86a.xn--9vv.k1303; i=johnl@user.iecc.com; bh=IUQn8jsVusYTE5xDK2gpxKk16RjU/z08ymffDdJeD1I=; b=x8SDc508Vr1W+7rdWSoWsbddnIuu6FwE0BjqzkiC/0rdLe+dO85GhlrCXRmjuqL51jtlcYLPW14MFWAWoAt9MZzUkW+YCKIbQHXoOmqrDB1l3mr6wVzXnhMYTfIhAfRnIJ89dcQuY4sI/6f8K8FDlFPROD/s1w/N7wWrYv8INMI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=5144f86a.xn--9vv.k1303; olt=johnl@user.iecc.com; bh=IUQn8jsVusYTE5xDK2gpxKk16RjU/z08ymffDdJeD1I=; b=Jk0qHpk+JYekmDRq/j81Y9npyz8UHO+lk0RFGUPwgu2+jSrDiq7Y4QamSYaLoSLXm5xbK0+VLdPqUaYtunbu/6g3gJvrqBA93f2NiKjViFduPm7MjLnQG5tYuG3mVUtgWuK9cscRxC80GARTHfR+4/0uytXM28dIyUnniLZN3as= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Mar 2013 22:55:15 -0000 Message-ID: <20130316225515.40047.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [weirds] Issue 5: rate limiting return code X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 22:55:39 -0000 Proposed new section 5.5. Rate Limits Some servers apply rate limits to deter address scraping and other abuses. When a server declines to answer a query due to rate limits, it MAY return a 429 response code as described in [RFC 6585]. A client that receives a 429 response SHOULD decrease its query rate, and honor the Retry-After header if one is present. Note that this is not a defense against denial-of-service attacks, since a malicious client could ignore the code and continue to send queries at a high rate. That's MAY rather than MUST or SHOULD because some servers might not want to disclose their rate limits to random strangers. From andy@arin.net Sun Mar 17 07:48:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A157E21F8915 for ; Sun, 17 Mar 2013 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix9D+BjgcZQs for ; Sun, 17 Mar 2013 07:48:27 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C35B521F8910 for ; Sun, 17 Mar 2013 07:48:27 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4860C21364C; Sun, 17 Mar 2013 10:48:27 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 989EF213640; Sun, 17 Mar 2013 10:48:26 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 17 Mar 2013 10:48:18 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Sun, 17 Mar 2013 10:47:15 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] links Thread-Index: AQHOIbxKktCcz8D8XUuA+2c4/E1nEpip+WuA Date: Sun, 17 Mar 2013 14:48:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF3F6C@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <7EB754E0DA8ED948AE36FCDDBA77EF09@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] links X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 14:48:28 -0000 Ernie, My responses in-line: From: Ernie Dainow >I found the use of links rather unclear in >draft-ietf-weirds-json-response-02. While the syntax and basic concept >are well explained, some guidance as to when to use links and what >relationship type should be used would be helpful. I agree. We should beef this up. > >Most of the examples are of relationship "self". If a client follows such >a link, it seems it will get back mostly information that it already has >(in the examples). So what is the value of this type of link? I think >this type of link should be "rel: alternate", > so that a client does not waste time getting duplicate information. The value of the "self" link is so to formally give the restful url to that object. This is helpful for clients that wish to do smart caching of embedded objects, such as entity objects inside a domain or network object. >A useful guideline would be to use a "self" link where an object has been >returned with only its handle (such as in an entity) and not much else. >In this case a client knows it can follow the link to get the details of >the object. I think we should use the RECOMMENDED 2119 language to encourage the use of self links whenever possible. Does that sound like a good idea? >One interesting link is shown in section 10. >"value" : "http://example.net/ip/2001:db8::/48", >"rel" : "up", >"href" : "http://example.net/ip/2001:C00::/23" >Presumably this is a link to get the parent network. What is the >recommended way to get child networks? The IANA list does not include >anything like "down" or "child" >http://www.iana.org/assignments/link-relations/link-relations.xml I guess that would result in multiple "child" links. Perhaps we ought to see about registering that relationship. Maybe "down" and not "child". >What about the set of relations: first, last, previous, next? Would one >expect these to be provided for the IP Network object, or any other RDAP >objects? I don't think these are applicable to much in the RDAP sphere. >It might be best for people working on client implementations to suggest >links they would expect or like to see. If clear guidelines are not >provided, it really won't be clear to a client what it should do with a >link, especially if different server implementations > have a different interpretation of what the different relationships mean >in the RDAP context. Very good points. If there are no objections, I'll seek to clarify the usage. The "self" might go into the actual section on links for a normative RECOMMENDED and the other relationships in an appendix. Thanks for the questions, Ernie. -andy From zwnj.org@gmail.com Sun Mar 17 13:55:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF021F8A85 for ; Sun, 17 Mar 2013 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxPGUouc2h+Y for ; Sun, 17 Mar 2013 13:55:15 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9668821F8A05 for ; Sun, 17 Mar 2013 13:55:14 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so4334217wey.19 for ; Sun, 17 Mar 2013 13:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=2AVNmFPGr9/rf/Qrk5jqQQJ8z4/6tidt6GP01DvXfGQ=; b=UX7R0lDx/5AAuv9nkMFNUi96V87qqPx5bdderanl31Hl7jje3iazRO9O/OItEao1d0 HrfkNn71w1pP0wK4Jd7TCJK28IZfhZPMNokgcdgIIasS5WUgTIVd0g8kath2s3FrI/1s N9w4XWZzAo5aGJiGiNWQWx+JGdBdlZThxueBqu6L1etLca+84fnUJU7DWf+vnS2rMTQq NpMkhnBf6qWzrPDeHVvKXEOBI0rU9FRtB7GRi+3oHxf08Yz5ydsbil5Rl8WTsrZCOK1e nqYpY1cwRmW+Bh2ms08bf8XgMWmG3jNt87ZrrR2SuNF8RQTaJuriqee84qNEocIDqP6S f54A== MIME-Version: 1.0 X-Received: by 10.180.93.234 with SMTP id cx10mr12772708wib.34.1363553713527; Sun, 17 Mar 2013 13:55:13 -0700 (PDT) Sender: behnam@gmail.com X-Google-Sender-Delegation: behnam@gmail.com Received: by 10.194.26.4 with HTTP; Sun, 17 Mar 2013 13:55:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Mar 2013 16:55:13 -0400 X-Google-Sender-Auth: hH9fbtE5EVl0T0XWzwQwy3rwmUA Message-ID: From: Behnam Esfahbod To: Ernie Dainow Content-Type: multipart/alternative; boundary=f46d04388e17ba260d04d82516c0 Cc: "weirds@ietf.org" Subject: Re: [weirds] links X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 20:55:15 -0000 --f46d04388e17ba260d04d82516c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Looking at the "links" attribute, I also couldn't figure it out whether these "links" are talking about the (ip address, domain name, name server, etc) *objects* themselves or about the WEIRDS *document*. An "up" relationship could be defined very different for each of them. Also, there are serious problems with the level or localization support. Besides the contact information, which will be changed to practice JCARD outpus, it looks like the structure of the objects are designed to only match some specific implementations. Here are a few of these problems: * Attribute "hreflang" is an array, but the semantics of the array is unknown. * Attribute "title" is an array, but the semantics of the array is unknown. Are these titles suppose to match languages mentioned in "hreflang"?! * And there was a discussion about attribute "discussion", and as mentioned in the WG meeting, there is no need to reinvent HTML again. If there's a need for any formatting, let's RECOMMEND an existing one and not create a new one. To make it short, we have a lot of human-readable strings in this APP protocol and IMHO it's exhausting to deal with languages in the lowest-level attributes. Maybe the multipart-MIME approach would be better, with some "links" to other available languages. So, I think the question to answer would be: "Do we want the WEIRDS response be as complete as possible, or targeted for an specific local (language, region, etc)?" I'm not sure if this matter has been discussed already or not. Thanks, -Behnam On Fri, Mar 15, 2013 at 4:32 PM, Ernie Dainow wrote: > I found the use of links rather unclear in > draft-ietf-weirds-json-response-02. While the syntax and basic concept ar= e > well explained, some guidance as to when to use links and what relationsh= ip > type should be used would be helpful. > > Most of the examples are of relationship "self". If a client follows such > a link, it seems it will get back mostly information that it already has > (in the examples). So what is the value of this type of link? I think thi= s > type of link should be "rel: alternate", so that a client does not waste > time getting duplicate information. > > A useful guideline would be to use a "self" link where an object has been > returned with only its handle (such as in an entity) and not much else. I= n > this case a client knows it can follow the link to get the details of the > object. > > One interesting link is shown in section 10. > "value" : "http://example.net/ip/2001:db8::/48", > "rel" : "up", > "href" : "http://example.net/ip/2001:C00::/23" > Presumably this is a link to get the parent network. What is the > recommended way to get child networks? The IANA list does not include > anything like "down" or "child" > http://www.iana.org/assignments/link-relations/link-relations.xml > > What about the set of relations: first, last, previous, next? Would one > expect these to be provided for the IP Network object, or any other RDAP > objects? > > It might be best for people working on client implementations to suggest > links they would expect or like to see. If clear guidelines are not > provided, it really won't be clear to a client what it should do with a > link, especially if different server implementations have a different > interpretation of what the different relationships mean in the RDAP conte= xt. > > -Ernie > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --f46d04388e17ba260d04d82516c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Looking at the "links&qu= ot; attribute, I also couldn't figure it out whether these "links&= quot; are talking about the (ip address, domain name, name server, etc) = objects themselves or about the WEIRDS document. An "up&quo= t; relationship could be defined very different for each of them.

Also, there are serious problems with the level or loca= lization support. Besides the contact information, which will be changed to= practice JCARD outpus, it looks like the structure of the objects are desi= gned to only match some specific implementations. Here are a few of these p= roblems:

* Attribute "hreflang" is an array, but= the semantics of the array is unknown.

* Attribute "title" is an array, but the semantics of the array= is unknown. Are these titles suppose to match languages mentioned in "= ;hreflang"?!

* And there was a discussion about attribut= e "discussion", and as mentioned in the WG meeting, there is no n= eed to reinvent HTML again. If there's a need for any=C2=A0formatting, = let's RECOMMEND an existing one and not create a new one.

To make it short,=C2=A0we have a lot of hum= an-readable strings in this APP protocol and IMHO it's exhausting to de= al with languages in the lowest-level attributes. Maybe the multipart-MIME = approach would be better, with some "links" to other available la= nguages.

So, I think the question to answer would be= : "Do we want the WEIRDS response be as complete as possible, or=C2=A0= targeted=C2=A0for an specific local (language, region, etc)?" I'm = not sure if this matter has been discussed already or not.

Thanks,
-Behnam


On Fri, Mar 15, 2013 at 4:32 PM, Ernie Dainow <edainow@afilias.info<= /a>> wrote:
I found the use of links rather unclear in draft-ietf= -weirds-json-response-02. While the syntax and basic concept are well expla= ined, some guidance as to when to use links and what relationship type shou= ld be used would be helpful.

Most of the examples are of relationship "self&quo= t;. If a client follows such a link, it seems it will get back mostly infor= mation that it already has (in the examples). So what is the value of this = type of link? I think this type of link should be "rel: alternate"= ;, so that a client does not waste time getting duplicate information.

A useful guideline would be to use a "self" l= ink where an object has been returned with only its handle (such as in an e= ntity) and not much else. In this case a client knows it can follow the lin= k to get the details of the object.

One interesting link is shown in section 10.
"rel" : "= up",
Presumably this is a link to get the parent network. What is the recom= mended way to get child networks? The IANA list does not include anything l= ike "down" or "child" http://www.i= ana.org/assignments/link-relations/link-relations.xml

What about the set of relations: first, last, previous,= next? Would one expect these to be provided for the IP Network object, or = any other RDAP objects?

It might be best for peopl= e working on client implementations to suggest links they would expect or l= ike to see. If clear guidelines are not provided, it really won't be cl= ear to a client what it should do with a link, especially if different serv= er implementations have a different interpretation of what the different re= lationships mean in the RDAP context.

-Ernie

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds




--
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3= =D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 = CA40 259E 0F8B

--f46d04388e17ba260d04d82516c0-- From fobispo@isc.org Sun Mar 17 21:11:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE321F884B for ; Sun, 17 Mar 2013 21:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te22F6mFZgie for ; Sun, 17 Mar 2013 21:11:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2A21F8845 for ; Sun, 17 Mar 2013 21:11:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 781A5C941E; Mon, 18 Mar 2013 04:11:31 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363579898; bh=LJnlN8+fvQfIyUXOUao9Or8xvtQY5bCL7NxI4OW5AVI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=db4Y+d0NQDI+QYMb60aVb1KwYu1BZAfKDzvfZ4yM8tMXvP5aEyU/iFeK9g6uQzaXV bpfwqkbU0QcdU0v3SXwt+pUBMff6RUfC5Go5BUb6MVT4BR2cCl02u25IrQbgQLDw2L iR67iwzRVXS98CZTdp14fC2lfFqyAvKy2o1KLhYw= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 18 Mar 2013 04:11:31 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4EB5F216C3B; Mon, 18 Mar 2013 04:11:31 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <00ad01ce1f04$7c1d7a80$74586f80$@cn> Date: Sun, 17 Mar 2013 21:11:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> To: Linlin Zhou X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 04:11:40 -0000 Hi Linlin, would it be possible to also structure the postalAddress from: "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], to something like: "postalAddress":{ "street":["123 Mapple Ave","Suite 90001"], "city":"Vancouver", "sp":"BC", "pc":"12393" "cc":"CA" } Since EPP carries all of these elements, it should be very = straightforward for a names registry to provide the information as = described here. We don't want to lose information, (in this case metadata), unless we = strictly have to. Thanks On Mar 12, 2013, at 2:32 AM, Linlin Zhou wrote: >>=20 >> 3) It is confusing how each object type lays out the information = within >> the format. I personally don't like object attributes at the same = level >> as the protocol spec, makes the resulting output more difficult to > read. >>=20 >> In addition, the concept of: 'roles' in an 'entity' is redundant, = and >> generates additional processing, because entities associated with = an >> object are not longer just 'rendered' they need to be checked to = see >> where in the 'parent' object is referenced in order to set the = field. >>=20 >> Fortunately it is not present in the example of DNR Domain Object, >> and even though I added it to mine, it seems unnecessary. >>=20 > That's what I'm going to point out.=20 > The RIR entity has the object of 'roles' while the DNR entity doesn't.=20= >=20 >> As soon as I have a beta, I'll share the link with the list. >>=20 >>=20 >>=20 >> Francisco Obispo >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D >> B38DB1BE >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From zhoulinlin@cnnic.cn Mon Mar 18 03:17:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F177721F8C93 for ; Mon, 18 Mar 2013 03:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWc2LcofGwRZ for ; Mon, 18 Mar 2013 03:17:24 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id E9BAE21F8C96 for ; Mon, 18 Mar 2013 03:17:21 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 18 Mar 2013 18:17:12 +0800 From: "Linlin Zhou" To: "'Francisco Obispo'" References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> In-Reply-To: <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> Date: Mon, 18 Mar 2013 18:21:47 +0800 Message-ID: <00ef01ce23c2$65e2c0f0$31a842d0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4jjsbrgNS1Yp3wQn28wJ878bruOQAMYf4g Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:17:25 -0000 Hi Francisco, I think this issue has been raised in the list, see http://www.ietf.org/mail-archive/web/weirds/current/msg02005.html. I prefer the structured response rather than the flat format myself. Another question do we reach the common consensus to reuse vcard? If so, which format the rdap server is going to support, structured, flat or both? Regards, Linlin > -----Original Message----- > From: Francisco Obispo [mailto:fobispo@isc.org] > Sent: Monday, March 18, 2013 12:11 PM > To: Linlin Zhou > Cc: weirds@ietf.org > Subject: Re: [weirds] observations so far.... > > Hi Linlin, > > would it be possible to also structure the postalAddress from: > > "postalAddress" : > [ > "123 Maple Ave", > "Suite 90001", > "Vancouver", > "BC", > "12393" > ], > > > > to something like: > > "postalAddress":{ > "street":["123 Mapple Ave","Suite 90001"], > "city":"Vancouver", > "sp":"BC", > "pc":"12393" > "cc":"CA" > } > > Since EPP carries all of these elements, it should be very straightforward for a > names registry to provide the information as described here. > > We don't want to lose information, (in this case metadata), unless we strictly > have to. > > Thanks > > > > > > On Mar 12, 2013, at 2:32 AM, Linlin Zhou wrote: > > >> > >> 3) It is confusing how each object type lays out the information within > >> the format. I personally don't like object attributes at the same level > >> as the protocol spec, makes the resulting output more difficult to > > read. > >> > >> In addition, the concept of: 'roles' in an 'entity' is redundant, and > >> generates additional processing, because entities associated with an > >> object are not longer just 'rendered' they need to be checked to see > >> where in the 'parent' object is referenced in order to set the field. > >> > >> Fortunately it is not present in the example of DNR Domain Object, > >> and even though I added it to mine, it seems unnecessary. > >> > > That's what I'm going to point out. > > The RIR entity has the object of 'roles' while the DNR entity doesn't. > > > >> As soon as I have a beta, I'll share the link with the list. > >> > >> > >> > >> Francisco Obispo > >> Director of Applications and Services - ISC > >> email: fobispo@isc.org > >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE From aservin@lacnic.net Mon Mar 18 04:11:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8141B21F8CD1 for ; Mon, 18 Mar 2013 04:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjicGxHYffXj for ; Mon, 18 Mar 2013 04:11:45 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5E21F8CBB for ; Mon, 18 Mar 2013 04:11:45 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r186-48-225-35.dialup.adsl.anteldata.net.uy [186.48.225.35]) by mail.lacnic.net.uy (Postfix) with ESMTP id 2B87C30844D for ; Mon, 18 Mar 2013 08:11:28 -0300 (UYT) Message-ID: <5146F669.8020807@lacnic.net> Date: Mon, 18 Mar 2013 08:11:37 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> In-Reply-To: <00ef01ce23c2$65e2c0f0$31a842d0$@cn> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:11:46 -0000 I would say both. There are some databases where the data today is flat, so it would be impossible to do structured. I would expect some effort from those registries in the future to convert (by some automatic or manual process, or asking users to update their information) the data from flat to structured, but for today that would be very difficult and a barrier to implement rdap. Abandoning structured would give us perhaps a not very complete protocol. So, as today I would prefer a mean to do any of those depending of the needs of the registry. /as On 3/18/13 7:21 AM, Linlin Zhou wrote: > Hi Francisco, > > I think this issue has been raised in the list, see > http://www.ietf.org/mail-archive/web/weirds/current/msg02005.html. I prefer > the structured response rather than the flat format myself. > Another question do we reach the common consensus to reuse vcard? If so, > which format the rdap server is going to support, structured, flat or both? > > Regards, > Linlin > >> -----Original Message----- >> From: Francisco Obispo [mailto:fobispo@isc.org] >> Sent: Monday, March 18, 2013 12:11 PM >> To: Linlin Zhou >> Cc: weirds@ietf.org >> Subject: Re: [weirds] observations so far.... >> >> Hi Linlin, >> >> would it be possible to also structure the postalAddress from: >> >> "postalAddress" : >> [ >> "123 Maple Ave", >> "Suite 90001", >> "Vancouver", >> "BC", >> "12393" >> ], >> >> >> >> to something like: >> >> "postalAddress":{ >> "street":["123 Mapple Ave","Suite 90001"], >> "city":"Vancouver", >> "sp":"BC", >> "pc":"12393" >> "cc":"CA" >> } >> >> Since EPP carries all of these elements, it should be very straightforward > for a >> names registry to provide the information as described here. >> >> We don't want to lose information, (in this case metadata), unless we > strictly >> have to. >> >> Thanks >> >> >> >> >> >> On Mar 12, 2013, at 2:32 AM, Linlin Zhou wrote: >> >>>> >>>> 3) It is confusing how each object type lays out the information within >>>> the format. I personally don't like object attributes at the same > level >>>> as the protocol spec, makes the resulting output more difficult to >>> read. >>>> >>>> In addition, the concept of: 'roles' in an 'entity' is redundant, and >>>> generates additional processing, because entities associated with an >>>> object are not longer just 'rendered' they need to be checked to see >>>> where in the 'parent' object is referenced in order to set the field. >>>> >>>> Fortunately it is not present in the example of DNR Domain Object, >>>> and even though I added it to mine, it seems unnecessary. >>>> >>> That's what I'm going to point out. >>> The RIR entity has the object of 'roles' while the DNR entity doesn't. >>> >>>> As soon as I have a beta, I'll share the link with the list. >>>> >>>> >>>> >>>> Francisco Obispo >>>> Director of Applications and Services - ISC >>>> email: fobispo@isc.org >>>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE >>>> >>>> _______________________________________________ >>>> weirds mailing list >>>> weirds@ietf.org >>>> https://www.ietf.org/mailman/listinfo/weirds >> >> Francisco Obispo >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Mon Mar 18 07:50:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9E21F8F1F for ; Mon, 18 Mar 2013 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da80Io9t7asC for ; Mon, 18 Mar 2013 07:50:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51821F8F1C for ; Mon, 18 Mar 2013 07:50:26 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id DCF301650BC; Mon, 18 Mar 2013 10:50:25 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 0B6D71650BE; Mon, 18 Mar 2013 10:50:25 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 18 Mar 2013 10:50:07 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 18 Mar 2013 10:50:11 -0400 From: Andy Newton To: Behnam Esfahbod , Ernie Dainow Thread-Topic: [weirds] links Thread-Index: AQHOIbxKktCcz8D8XUuA+2c4/E1nEpiqowWAgADpT4A= Date: Mon, 18 Mar 2013 14:50:10 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF419B@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <548B89F1F1BCC9489D5CCA82A81FFD7E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] links X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:50:27 -0000 Behnam, In-line again=8A :) From: Behnam Esfahbod > >Looking at the "links" attribute, I also couldn't figure it out whether >these "links" are talking about the (ip address, domain name, name >server, etc) >objects themselves or about the WEIRDS document. An "up" relationship >could be defined very different for each of them. I'm not sure what you mean about "the WEIRDS document". But the opening sentence in that section says, "Each object class defined in this document may have links to other resources on the Internet." The links are for each type of object. Obviously, "up" does not apply to everything, such as an entity. >Also, there are serious problems with the level or localization support. >Besides the contact information, which will be changed to practice JCARD >outpus, it looks like the structure of the objects are designed to only >match some specific implementations. > Here are a few of these problems: > >* Attribute "hreflang" is an array, but the semantics of the array is >unknown. > >* Attribute "title" is an array, but the semantics of the array is >unknown. Are these titles suppose to match languages mentioned in >"hreflang"?! Those are taken from RFC5988. I don't think we should start redefining link relationships. If it wasn't properly internationalized, then that is an issue for the IESG to consider. >To make it short, we have a lot of human-readable strings in this APP >protocol and IMHO it's exhausting to deal with languages in the >lowest-level attributes. Maybe the multipart-MIME approach would be >better, with some "links" to other available > languages. > >So, I think the question to answer would be: "Do we want the WEIRDS >response be as complete as possible, or targeted for an specific local >(language, region, etc)?" I'm not sure if this matter has been discussed >already or not. Yes, we have discussed this and the result was the addition of the JSON 'lang' attribute. See section 5.3 of the JSON response draft. -andy From johnl@iecc.com Mon Mar 18 09:28:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4C021F8615 for ; Mon, 18 Mar 2013 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.11 X-Spam-Level: X-Spam-Status: No, score=-110.11 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXXWL+yN9cRt for ; Mon, 18 Mar 2013 09:28:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A401C21F880B for ; Mon, 18 Mar 2013 09:26:07 -0700 (PDT) Received: (qmail 10568 invoked from network); 18 Mar 2013 16:26:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Mar 2013 16:26:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5147401f.xn--hew.k1303; i=johnl@user.iecc.com; bh=n2s8i4bpxkKgVk5stgGXdiuwMpv2mnmerbeN6981fjA=; b=AgJlUyw9V0G7Qd1iSqpT46X1aIOeR6p4MOFBUaj6+OTnuknS8cw8V718Rd48OhwmkW1MAWR4KGmvcRzOdh/Yo/2oaPZCCKT48AeFLgum7VuKn3WKJRplIxFkKnPvAG8YnIXgVC1wq/x7nA/l8jeLXwxPtWXtH+5WpnYxaXFH61g= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5147401f.xn--hew.k1303; olt=johnl@user.iecc.com; bh=n2s8i4bpxkKgVk5stgGXdiuwMpv2mnmerbeN6981fjA=; b=H/58Q+X02JCt7/mtpiFaLdwjZO/FGnQgXhN8mQ7hxZi3E8R1IN5FTcJrqxn9hs1vhj+Q0rdyBbhxnQ23FovaoygtuS+mf85JFc7vOjd2Mu1ucV//KScZ5znnjwD/D9XT65A0Hkpqo7YJeIua4EAPIPkKNbHWVR61FsIvDtSCZUA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Mar 2013 16:25:44 -0000 Message-ID: <20130318162544.64885.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:28:35 -0000 In article <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> you write: >Hi Linlin, > >would it be possible to also structure the postalAddress from: Didn't we address this in December? http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html R's, John From superuser@gmail.com Mon Mar 18 09:32:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1296D21F8FAA for ; Mon, 18 Mar 2013 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QfsGROGXPUd for ; Mon, 18 Mar 2013 09:32:12 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 13D7D11E80DF for ; Mon, 18 Mar 2013 09:15:53 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id 8so1768499wgl.30 for ; Mon, 18 Mar 2013 09:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+IadFyVJuEqtEQGP1YDWT7IlgkBjgWQedbvOsqRBNys=; b=qtzQNcrCnNO1NS4FNfOJ5UOvXzRn+OFsnpEUJupqS9PG/XcHkoTWYiCOoSCATuyGAd ur7oMXACJmBpAgnMiZw8RCJJU+S+bFFJUtaddZZ85UUkH4uXvu5af5mNdoGNUTBaXG7z puYdcGt3nN62wCeagULk3r8JH4iM9fdVh38I/7Uxawm18Ma2+hLiUyuwtbTJ879zxlXy khs4Qe7wT8KkzSILBQSXu4XY5RphASSEW0FAj9sce80xw3TFd4WamdIoKD+yo/OjWIFD AK/BqCGrZgLPzuHZ+vRcE2Er/cnJGeXAhFlaf79RDYStO5XzdK4rkiOApjAQXMtoefGJ mxag== MIME-Version: 1.0 X-Received: by 10.180.11.194 with SMTP id s2mr17778222wib.5.1363623353234; Mon, 18 Mar 2013 09:15:53 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 18 Mar 2013 09:15:53 -0700 (PDT) Date: Mon, 18 Mar 2013 09:15:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c355a293bce804d8354d15 Subject: [weirds] IETF 86 minutes posted X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:32:20 -0000 --001a11c355a293bce804d8354d15 Content-Type: text/plain; charset=ISO-8859-1 The draft minutes from our dual session at IETF 86 in Orlando have been posted. Please review them and let us know if we've missed anything. http://www.ietf.org/proceedings/86/minutes/minutes-86-weirds Many thanks to Andrew Sullivan and John Levine for keeping great notes for us! -MSK, WEIRDS co-chair --001a11c355a293bce804d8354d15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The draft minutes from our dual session at IETF 86 in= Orlando have been posted.=A0 Please review them and let us know if we'= ve missed anything.

http://www.ietf.org/proceedings/86/minutes/minutes= -86-weirds

Many thanks to Andrew Sullivan and John Levine for keeping g= reat notes for us!

-MSK, WEIRDS co-chair

--001a11c355a293bce804d8354d15-- From fobispo@isc.org Mon Mar 18 11:24:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAA21F8801 for ; Mon, 18 Mar 2013 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=4.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kRIW6fT5b6Y for ; Mon, 18 Mar 2013 11:23:50 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9422521F87BA for ; Mon, 18 Mar 2013 11:23:50 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7DF4E5F985D; Mon, 18 Mar 2013 18:22:25 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363630954; bh=tQY5RlN9Jbyio4oqdAJ6KEqoCUR/GtTUs6PkXajew24=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GBotoGhIJJtAZvhHRsaepsnTO6QCqCFG1mMoW4SYaZp3ceIK84BLOd8ZQsxLhI+fs mq7fz6RC1UlIy1kLEa6F01UZIQlKx1E4zvf60ksWRKoPAUtGU8a37ZhDpIyrnJ8IoC yRbTTWUeSFPF06vNuXeO2Zt5Z3sHQCZ8IkWmA+uw= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 09CC6216C47; Mon, 18 Mar 2013 18:22:24 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <20130318162544.64885.qmail@joyce.lan> Date: Mon, 18 Mar 2013 11:22:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9012F215-CEB9-4889-BF01-FD6E68FEB94E@isc.org> References: <20130318162544.64885.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:24:01 -0000 Thanks for sharing the link. I'm glad I came to the same conclusion as Gavin, One thing we could do, instead of dealing with 'flat' or 'structured' = subfields, we could rely on the data type, that is, if it has a hash, we = assume it's a structure, and if it has an array, then it's flat. On Mar 18, 2013, at 9:25 AM, John Levine wrote: > In article <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> you write: >> Hi Linlin, >>=20 >> would it be possible to also structure the postalAddress from: >=20 > Didn't we address this in December? >=20 > http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html >=20 > R's, > John Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From fobispo@isc.org Mon Mar 18 11:31:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAF221F8CEF for ; Mon, 18 Mar 2013 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.373 X-Spam-Level: X-Spam-Status: No, score=-7.373 tagged_above=-999 required=5 tests=[AWL=3.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIBz-DxQm2lO for ; Mon, 18 Mar 2013 11:31:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6921F8D20 for ; Mon, 18 Mar 2013 11:31:08 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6807C5F985D; Mon, 18 Mar 2013 18:29:43 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363631392; bh=QN5lknAkezT6pc/v/BqMTo6Ci0VJXey7qgOY02HWGYY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bttSGbAHb4Mcfx/+WE4sBRZcZ56ezmqCHhMZcJrfjtkGcXqbX9VVMcO+zcvMGUhG8 ozSJObM58FVvEOs0u/3pvAHDSSPGELz8Kw2FINcMDeODNiDOHsqdF2U4FGei/D1Su5 dCe8HKHNQvhzMTEn+ZwgHVoVV/x0ZpWCxCz4+d1E= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E561B216C3B; Mon, 18 Mar 2013 18:29:41 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <5146F669.8020807@lacnic.net> Date: Mon, 18 Mar 2013 11:29:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:31:17 -0000 I remember migrating whois data (back in 2004) from rwhois (flat files) = to a registry system with structured data. Since the data was actually 'there' but in a 'flat' format, we had to = write a whole bunch of code to detect the various fields. We were = actually able to detect the data successfully in about 80% of the = records, the other 15 or so , required a bit of tweaking or even some = writing of custom code, the other 5 was all done by hand :-(. However, if a registry still has this data in a flat form, I'm = envisioning that they will have trouble dealing with other fields as = well, so even though I want to be realistic about making this protocol a = success, we should also encourage those registries to update their = systems, and normalize the data. On Mar 18, 2013, at 4:11 AM, Arturo Servin wrote: > There are some databases where the data today is flat, so it would be > impossible to do structured. I would expect some effort from those > registries in the future to convert (by some automatic or manual > process, or asking users to update their information) the data from = flat > to structured, but for today that would be very difficult and a = barrier > to implement rdap. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From michael@mwyoung.ca Mon Mar 18 11:40:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67D21F9028 for ; Mon, 18 Mar 2013 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFfrE5uVSD1d for ; Mon, 18 Mar 2013 11:40:15 -0700 (PDT) Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2121F9015 for ; Mon, 18 Mar 2013 11:40:15 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id y26so3233313iab.6 for ; Mon, 18 Mar 2013 11:39:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=nyArpkCcnduWVz3QnkOgi0jcUWmuesstKheuyFk0oG8=; b=o6uLA8DLjXOI5r2tAkRYCWsILYFgxciUWbEaIvcuHBGwct59ByOPbEQv5Fr/lfxjWV T/xyDkO7ldP9LA3P0llBvQAIeJgLV18JDiE1qKpPHeUtAO4SPOKtZ6ji3EcKsQ9Sj1aH 5/5xke5N9XkG4CQMHdygpSSqzRx1d2FYtlM6scAM+mwhCpzGic/Eka1vynhsub6FyKqq soA4BNpRhPm6b8WbRsBIJ9EgtGBAVKV8bObLUjRXq8SxP/PFTd9yQmO+RLXvvY7EY+7T PBIWWlP9AfvxcewdvGi+jTh/fWqCVnlM6PE1sH3p1f0B3FKDlkvYO39GgppeOh5QcKrP 0JYg== X-Received: by 10.50.152.230 with SMTP id vb6mr49300igb.23.1363631995388; Mon, 18 Mar 2013 11:39:55 -0700 (PDT) Received: from [10.0.0.148] ([184.175.22.34]) by mx.google.com with ESMTPS id uy13sm11878233igb.7.2013.03.18.11.39.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 11:39:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C1927AB6-1153-4093-AC0F-5D6F832CDD40" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: MICHAEL YOUNG In-Reply-To: <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> Date: Mon, 18 Mar 2013 14:39:51 -0400 Message-Id: References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkkkrvdePqaE+L9qoOIpamKmb1kqzVyEFMBHGLJycXiiwVs4hvS0G2fC+ZxEDPZkFbvDUGe Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:40:23 -0000 --Apple-Mail=_C1927AB6-1153-4093-AC0F-5D6F832CDD40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Francisco, This makes a lot of sense to me, I know it may slow the adoption, but in = terms of net numbers, the vast bulk of the current registry data is = structured already, so I don't think it causes that much harm to = adoption to push for normalized data.=20 -Michael Young On 2013-03-18, at 2:29 PM, Francisco Obispo wrote: > I remember migrating whois data (back in 2004) from rwhois (flat = files) to a registry system with structured data. >=20 > Since the data was actually 'there' but in a 'flat' format, we had to = write a whole bunch of code to detect the various fields. We were = actually able to detect the data successfully in about 80% of the = records, the other 15 or so , required a bit of tweaking or even some = writing of custom code, the other 5 was all done by hand :-(. >=20 > However, if a registry still has this data in a flat form, I'm = envisioning that they will have trouble dealing with other fields as = well, so even though I want to be realistic about making this protocol a = success, we should also encourage those registries to update their = systems, and normalize the data. >=20 >=20 >=20 > On Mar 18, 2013, at 4:11 AM, Arturo Servin wrote: >=20 >> There are some databases where the data today is flat, so it would be >> impossible to do structured. I would expect some effort from those >> registries in the future to convert (by some automatic or manual >> process, or asking users to update their information) the data from = flat >> to structured, but for today that would be very difficult and a = barrier >> to implement rdap. >=20 > Francisco Obispo=20 > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_C1927AB6-1153-4093-AC0F-5D6F832CDD40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii fobispo@isc.org> wrote:

I remember = migrating whois data (back in 2004) from rwhois (flat files) to a = registry system with structured data.

Since the data was actually = 'there' but in a 'flat' format, we had to write a whole bunch of code to = detect the various fields. We were actually able to detect the data = successfully in about 80% of the records, the other 15 or so , required = a bit of tweaking or even some writing of custom code, the other 5 was = all done by hand :-(.

However, if a registry still has this data = in a flat form, I'm envisioning that they will have trouble dealing with = other fields as well, so even though I want to be realistic about making = this protocol a success, we should also encourage those registries to = update their systems, and normalize the data.



On Mar 18, = 2013, at 4:11 AM, Arturo Servin <aservin@lacnic.net> = wrote:

There are some databases where = the data today is flat, so it would be
impossible to do structured. I = would expect some effort from those
registries in the future to = convert (by some automatic or manual
process, or asking users to = update their information) the data from flat
to structured, but for = today that would be very difficult and a barrier
to implement = rdap.

Francisco Obispo
Director of Applications = and Services - ISC
email: fobispo@isc.org
Phone: +1 650 423 = 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D = B38DB1BE

_______________________________________________
weirds = mailing list
weirds@ietf.org
https://www.ietf.or= g/mailman/listinfo/weirds




MICHAEL = YOUNG




= --Apple-Mail=_C1927AB6-1153-4093-AC0F-5D6F832CDD40-- From aservin@lacnic.net Mon Mar 18 11:50:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6152211E809C for ; Mon, 18 Mar 2013 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yflTQbS98pM for ; Mon, 18 Mar 2013 11:49:54 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B250821F8F83 for ; Mon, 18 Mar 2013 11:49:48 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c006:b207:79a1:4fe5]) by mail.lacnic.net.uy (Postfix) with ESMTP id 97A3B30844D; Mon, 18 Mar 2013 15:49:22 -0300 (UYT) Message-ID: <514761B6.7040107@lacnic.net> Date: Mon, 18 Mar 2013 15:49:26 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Francisco Obispo References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> In-Reply-To: <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:50:04 -0000 Eventually, but not now. I am in favor on supporting both approaches as: http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html For only structured, I would object. /as On 3/18/13 3:29 PM, Francisco Obispo wrote: > However, if a registry still has this data in a flat form, I'm envisioning that they will have trouble dealing with other fields as well, so even though I want to be realistic about making this protocol a success, we should also encourage those registries to update their systems, and normalize the data. From fobispo@isc.org Mon Mar 18 12:06:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D821F90A6 for ; Mon, 18 Mar 2013 12:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRNXo9SXAYJo for ; Mon, 18 Mar 2013 12:05:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 413DA11E80FD for ; Mon, 18 Mar 2013 12:03:02 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 45D3DC941E; Mon, 18 Mar 2013 19:02:55 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363633382; bh=sIBnx+JcI+O2PbW0NLIZZL0LO3S4w8lsnX/mObE4LtI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=O9F+/C5KFtESbmYj/2fNK1jfwOpIUvDpW+JON/wEf+7RbV5J2Q5KuJb5GvRhURZDB /sF5w9yEKQEzeAIoIvlR3R6EuonhLUx6UbkKrgSuaM6XaXawf7UOK3oMAB/IUE4nMB /qzc9nbaynQwWqFBz1zeIzEMPnmlkrmyFlj9j85s= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 18 Mar 2013 19:02:55 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2E18C216C3B; Mon, 18 Mar 2013 19:02:55 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <514761B6.7040107@lacnic.net> Date: Mon, 18 Mar 2013 12:02:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> <514761B6.7040107@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:06:23 -0000 Setting a 'structured' subfield in something that has a structure, seems = redundant/inappropriate to me. how about using the type detection? hash -> structured array -> flat=20 ? On Mar 18, 2013, at 11:49 AM, Arturo Servin wrote: >=20 > Eventually, but not now. >=20 > I am in favor on supporting both approaches as: >=20 > http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html >=20 > For only structured, I would object. >=20 > /as >=20 > On 3/18/13 3:29 PM, Francisco Obispo wrote: >> However, if a registry still has this data in a flat form, I'm = envisioning that they will have trouble dealing with other fields as = well, so even though I want to be realistic about making this protocol a = success, we should also encourage those registries to update their = systems, and normalize the data. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From aservin@lacnic.net Mon Mar 18 12:07:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464E421F90B5 for ; Mon, 18 Mar 2013 12:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jalweVPANz0l for ; Mon, 18 Mar 2013 12:07:15 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 557A721F8BE8 for ; Mon, 18 Mar 2013 12:04:37 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c006:b207:79a1:4fe5]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7B604308444; Mon, 18 Mar 2013 16:04:11 -0300 (UYT) Message-ID: <51476534.8060200@lacnic.net> Date: Mon, 18 Mar 2013 16:04:20 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Francisco Obispo References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> <514761B6.7040107@lacnic.net> <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> In-Reply-To: <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:07:38 -0000 No problem with this. .as On 3/18/13 4:02 PM, Francisco Obispo wrote: > Setting a 'structured' subfield in something that has a structure, seems redundant/inappropriate to me. > > how about using the type detection? > > hash -> structured > array -> flat > > ? > > > > On Mar 18, 2013, at 11:49 AM, Arturo Servin wrote: > >> >> Eventually, but not now. >> >> I am in favor on supporting both approaches as: >> >> http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html >> >> For only structured, I would object. >> >> /as >> >> On 3/18/13 3:29 PM, Francisco Obispo wrote: >>> However, if a registry still has this data in a flat form, I'm envisioning that they will have trouble dealing with other fields as well, so even though I want to be realistic about making this protocol a success, we should also encourage those registries to update their systems, and normalize the data. > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > From carlosm3011@gmail.com Mon Mar 18 12:19:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A01D11E80C5 for ; Mon, 18 Mar 2013 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEHWQJ2Wjw8e for ; Mon, 18 Mar 2013 12:18:56 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7443821F84F6 for ; Mon, 18 Mar 2013 12:18:53 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so6075187oag.3 for ; Mon, 18 Mar 2013 12:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EK/g8vg75BnUu950sljh9ztYEy0EpNn07k4/NoFFbuI=; b=ic6yX7Jj3crfH+N1VnA0wYAAMUq4QXICpq0jOz//LE0b3KkyQxwp87PsyYfYA9Eh/3 z485W1rmKlo2cOQZdJ+PMCVy8Ex2F6YjOebuf8RjDwCR/ZDvEmhktDpQ++0GlQcO5n0E revcUTLnLsDEz3WsmqSbSp6+FaKGjqpucSlsMo2EgWVoP+IMXYFQbQ8a60UOWzjX18o3 aeyBdHvfLKasRlCa056sXv5G/WS2LMf1wePND9X0E8JJXvyqvOdYeJifuMS6K//csheH /2QXupjd8zFUCkJiFBNh8HiBXxXXhq9iPhR2Oe203/ucN6bRplfBtU2wg9kevpW7bITo 2f5w== X-Received: by 10.182.52.102 with SMTP id s6mr7286010obo.87.1363634332968; Mon, 18 Mar 2013 12:18:52 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:d8a4:86b5:c61e:432f]) by mx.google.com with ESMTPS id ek4sm7670505obc.6.2013.03.18.12.18.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 12:18:51 -0700 (PDT) Message-ID: <5147688C.70406@gmail.com> Date: Mon, 18 Mar 2013 16:18:36 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Francisco Obispo References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> <514761B6.7040107@lacnic.net> <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> In-Reply-To: <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:19:05 -0000 'Like' On 3/18/13 4:02 PM, Francisco Obispo wrote: > Setting a 'structured' subfield in something that has a structure, seems redundant/inappropriate to me. > > how about using the type detection? > > hash -> structured > array -> flat > > ? > > > > On Mar 18, 2013, at 11:49 AM, Arturo Servin wrote: > >> >> Eventually, but not now. >> >> I am in favor on supporting both approaches as: >> >> http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html >> >> For only structured, I would object. >> >> /as >> >> On 3/18/13 3:29 PM, Francisco Obispo wrote: >>> However, if a registry still has this data in a flat form, I'm envisioning that they will have trouble dealing with other fields as well, so even though I want to be realistic about making this protocol a success, we should also encourage those registries to update their systems, and normalize the data. > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From simon.perreault@viagenie.ca Tue Mar 19 02:16:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEB121F8967 for ; Tue, 19 Mar 2013 02:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id box3gaMB2Ppy for ; Tue, 19 Mar 2013 02:16:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BF11621F8960 for ; Tue, 19 Mar 2013 02:16:46 -0700 (PDT) Received: from [IPv6:::1] (unknown [192.87.38.13]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 19DB8412CB for ; Tue, 19 Mar 2013 05:16:15 -0400 (EDT) Message-ID: <51482D23.8040905@viagenie.ca> Date: Tue, 19 Mar 2013 10:17:23 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <20130316225515.40047.qmail@joyce.lan> In-Reply-To: <20130316225515.40047.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] Issue 5: rate limiting return code X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:16:48 -0000 Le 2013-03-16 23:55, John Levine a écrit : > Proposed new section > > > 5.5. Rate Limits > > Some servers apply rate limits to deter address scraping and other > abuses. When a server declines to answer a query due to rate limits, > it MAY return a 429 response code as described in [RFC 6585]. A > client that receives a 429 response SHOULD decrease its query rate, > and honor the Retry-After header if one is present. > > Note that this is not a defense against denial-of-service attacks, > since a malicious client could ignore the code and continue to send > queries at a high rate. Excellent text! > That's MAY rather than MUST or SHOULD because some servers might not > want to disclose their rate limits to random strangers. In that case, s/MAY/SHOULD unless prohibited by local policy/. Simon From simon.perreault@viagenie.ca Tue Mar 19 02:22:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32A321F896B for ; Tue, 19 Mar 2013 02:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2THOp1mEiPo for ; Tue, 19 Mar 2013 02:22:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEAA21F8959 for ; Tue, 19 Mar 2013 02:22:10 -0700 (PDT) Received: from [IPv6:::1] (unknown [192.87.38.13]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 953EC4044F for ; Tue, 19 Mar 2013 05:21:39 -0400 (EDT) Message-ID: <51482E68.10006@viagenie.ca> Date: Tue, 19 Mar 2013 10:22:48 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <00ad01ce1f04$7c1d7a80$74586f80$@cn> <0086B7C1-0FE6-4E35-A4F0-7A32A1B511EB@isc.org> <00ef01ce23c2$65e2c0f0$31a842d0$@cn> <5146F669.8020807@lacnic.net> <2343733B-2B59-4B3A-81FB-DBBA84B641C3@isc.org> <514761B6.7040107@lacnic.net> <44B10E53-CB03-4F3A-95D7-07E508853563@isc.org> <5147688C.70406@gmail.com> In-Reply-To: <5147688C.70406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] observations so far.... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:22:10 -0000 Did you people all suddenly forget about vCard? This is exactly the kind of stuff that WEIRDS should not bother with. Let's instead reuse what is already in the IETF's toolkit. Simon Le 2013-03-18 20:18, Carlos M. Martinez a écrit : > 'Like' > > On 3/18/13 4:02 PM, Francisco Obispo wrote: >> Setting a 'structured' subfield in something that has a structure, seems redundant/inappropriate to me. >> >> how about using the type detection? >> >> hash -> structured >> array -> flat >> >> ? >> >> >> >> On Mar 18, 2013, at 11:49 AM, Arturo Servin wrote: >> >>> >>> Eventually, but not now. >>> >>> I am in favor on supporting both approaches as: >>> >>> http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html >>> >>> For only structured, I would object. >>> >>> /as >>> >>> On 3/18/13 3:29 PM, Francisco Obispo wrote: >>>> However, if a registry still has this data in a flat form, I'm envisioning that they will have trouble dealing with other fields as well, so even though I want to be realistic about making this protocol a success, we should also encourage those registries to update their systems, and normalize the data. >> >> Francisco Obispo >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID = B38DB1BE >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From jyee@afilias.info Tue Mar 19 05:54:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58E221F8514 for ; Tue, 19 Mar 2013 05:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkq1em9eC89b for ; Tue, 19 Mar 2013 05:54:04 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3521F8511 for ; Tue, 19 Mar 2013 05:54:03 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UHw3H-0002yv-4c for weirds@ietf.org; Tue, 19 Mar 2013 12:54:03 +0000 Received: from mail-ye0-f199.google.com ([209.85.213.199]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UHw3H-0003mj-4J for weirds@ietf.org; Tue, 19 Mar 2013 12:54:03 +0000 Received: by mail-ye0-f199.google.com with SMTP id l8so575104yen.10 for ; Tue, 19 Mar 2013 05:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=OfDVcQKRK10G1NrNRjKbqojJKsC2lOPTTzsbrfwvaI8=; b=Fosc1T6c7mSsF/30innzMst1hZK46LiiBCoyvTJHaSzFbmPnPSAyoRYaDYUaQbjqcz Wr9Y0s4BxF5TnikN7+aFT3GyRkuDlV2MSOAQwSwZktXdYpMNh6403zDzcVMr0WnqBmz9 2HIfQ1+yMJVJUKsX6hQZ1g2Xy+92efwX17KoDict9nZbxdsr9irrwvjBJG9lz6BbxmmD FlEzW7rx2Z2UuQjvREhXPGsKyWgDJm8rDuJUtdpVLN9lWCSYrfDFH6xWpJOZ7vXruxTc bIZ9RnOTcIZccW5GvbjvkmFkIYxuRqA7h93W1AC51gyU57/8NcY97Q74R88GoAtXQvN7 qMdw== X-Received: by 10.58.43.169 with SMTP id x9mr2247384vel.13.1363697637632; Tue, 19 Mar 2013 05:53:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.43.169 with SMTP id x9mr2247375vel.13.1363697637465; Tue, 19 Mar 2013 05:53:57 -0700 (PDT) Received: by 10.58.134.5 with HTTP; Tue, 19 Mar 2013 05:53:57 -0700 (PDT) In-Reply-To: <51482D23.8040905@viagenie.ca> References: <20130316225515.40047.qmail@joyce.lan> <51482D23.8040905@viagenie.ca> Date: Tue, 19 Mar 2013 08:53:57 -0400 Message-ID: From: Joseph Yee To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGAAi9knny1eh96Zv5MCCwE6ZTrQVcNtZLg4q9g7DxUXLPmxx8c7bg0XeetB5nESGaOy1xOd4E3odfatCSXbCYRgT4fk3lidnsgkw+9zhyqMIFheK+I2bFn9SQMtHzvd07KgwU Cc: weirds@ietf.org Subject: Re: [weirds] Issue 5: rate limiting return code X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 12:54:04 -0000 On Tue, Mar 19, 2013 at 5:17 AM, Simon Perreault wrote: > Le 2013-03-16 23:55, John Levine a =C3=A9crit : > >> Proposed new section >> >> >> 5.5. Rate Limits >> >> Some servers apply rate limits to deter address scraping and other >> abuses. When a server declines to answer a query due to rate limits= , >> it MAY return a 429 response code as described in [RFC 6585]. A >> client that receives a 429 response SHOULD decrease its query rate, >> and honor the Retry-After header if one is present. >> >> Note that this is not a defense against denial-of-service attacks, >> since a malicious client could ignore the code and continue to send >> queries at a high rate. > > > Excellent text! > +1 > >> That's MAY rather than MUST or SHOULD because some servers might not >> want to disclose their rate limits to random strangers. > > > In that case, s/MAY/SHOULD unless prohibited by local policy/. > I think MAY is good enough, but if this ensure operator has full control how they intended to deal with rate limiting, I'm for it. Joseph > Simon > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From michael@mwyoung.ca Tue Mar 19 06:08:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D141D21F8265 for ; Tue, 19 Mar 2013 06:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlwGduxmMJHr for ; Tue, 19 Mar 2013 06:08:43 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA821F86B2 for ; Tue, 19 Mar 2013 06:08:35 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id k11so501206iea.24 for ; Tue, 19 Mar 2013 06:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=jm0hbDWfdtck0PFoASCocvEs1xA6DhI0tNQjIIorUvY=; b=gEGM2QO0rw+jpthoOPLPkGW84RLyzxrg5XAaDlr1aof95KHJu4MW5rIptoVpag0QQJ f1n9CiPdV2ePlrPtl/5qi9uqltEoWHEmEP9JSgVyEJKXr0KjtAay3KIhBjE+5BDebTfV 62oNmTUKVHdIWqFAxHOvnN7pBdOreyn9UDmoYb7/n+NddDi7UNB1F4pP86K7jBPD/9jG Ow+uquJK6L9d0F/Dsg8Uuf7cr6kqteZUYZHu1FaniVoMkXkWcqPlafLuPM09NGsOwWi3 Z3LmM1VhWyxEpISq4YNcu2HNN8Y5J4s3+mlRCQuIChAT2Kqg5xDdjpv6/jaoms6Bam/o n/sA== X-Received: by 10.50.202.6 with SMTP id ke6mr1307348igc.30.1363698515294; Tue, 19 Mar 2013 06:08:35 -0700 (PDT) Received: from [10.61.49.5] ([207.164.79.5]) by mx.google.com with ESMTPS id ip2sm333657igc.5.2013.03.19.06.08.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 06:08:34 -0700 (PDT) References: <20130316225515.40047.qmail@joyce.lan> <51482D23.8040905@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: Michael Young Date: Tue, 19 Mar 2013 09:08:24 -0400 To: Joseph Yee X-Gm-Message-State: ALoCoQmvqseR131iJRCIbc2MR4a5j9CZ65VhxeN/0iltr7cBuV61N3naZZgE+B2F0ehHS9FYkUz7 Cc: "weirds@ietf.org" Subject: Re: [weirds] Issue 5: rate limiting return code X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:08:44 -0000 I'm in favour of this addition. Michael Young M:647-289-1220 On 2013-03-19, at 8:53, Joseph Yee wrote: > On Tue, Mar 19, 2013 at 5:17 AM, Simon Perreault > wrote: >> Le 2013-03-16 23:55, John Levine a =C3=A9crit : >>=20 >>> Proposed new section >>>=20 >>>=20 >>> 5.5. Rate Limits >>>=20 >>> Some servers apply rate limits to deter address scraping and other >>> abuses. When a server declines to answer a query due to rate limits,= >>> it MAY return a 429 response code as described in [RFC 6585]. A >>> client that receives a 429 response SHOULD decrease its query rate, >>> and honor the Retry-After header if one is present. >>>=20 >>> Note that this is not a defense against denial-of-service attacks, >>> since a malicious client could ignore the code and continue to send >>> queries at a high rate. >>=20 >>=20 >> Excellent text! > +1 >=20 >>=20 >>> That's MAY rather than MUST or SHOULD because some servers might not >>> want to disclose their rate limits to random strangers. >>=20 >>=20 >> In that case, s/MAY/SHOULD unless prohibited by local policy/. >=20 > I think MAY is good enough, but if this ensure operator has full > control how they intended to deal with rate limiting, I'm for it. >=20 > Joseph >=20 >> Simon >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From jean-philippe.dionne@viagenie.ca Wed Mar 20 08:54:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3858A21F8FD9 for ; Wed, 20 Mar 2013 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frUjXf8UekjQ for ; Wed, 20 Mar 2013 08:54:58 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9809021F8FD8 for ; Wed, 20 Mar 2013 08:54:58 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF3C740334 for ; Wed, 20 Mar 2013 11:54:57 -0400 (EDT) Message-ID: <5149DBD1.8000000@viagenie.ca> Date: Wed, 20 Mar 2013 11:54:57 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <20130316193050.71198.qmail@joyce.lan> In-Reply-To: <20130316193050.71198.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] Issue 4: http media types in RDAP replies X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:54:59 -0000 On 03/16/2013 03:30 PM, John Levine wrote: > Proposed: > > RDAP clients MUST include an Accept: header specifying > application/rdap, application/json, or both. Servers receiving an > RDAP request MUST return an entity with Content-Type application/rdap. > > This specification does not define the responses a server returns to > a request with any other media types in the Accept: header, or with no > Accept: header. One possibility would be to return a response in > a media type suitable for rendering in a web browser. > > This is deliberately much less flexible, to make it easier for to > interoperate. If anyone has a plausible scenario in which an RDAP > client can't provide an Accept header, or a server can't respond with > application/rdap content type, please speak up now. I agree with the proposed text. We must also add a request to IANA for the 'application/rdap' in the 'media-types' registry. See below the filled template taken from draft-ietf-appsawg-media-type-regs-14 What about the +json suffix? From draft-ietf-appsawg-media-type-regs-14#section-3, we can read: "Media types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they are registered. " Type name: application Subtype name: rdap+json Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: none Interoperability considerations: N/A Published specification: draft-ietf-weirds-using-http-01 Applications that use this media type: RDAP Applications Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: Andy Newton Intended usage: COMMON Restrictions on usage: None Author: Andy Newton Change controller: TBD Provisional registration? (standards tree only): Yes Thanks Jean-Philippe From andy@arin.net Wed Mar 20 09:22:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69321F9040 for ; Wed, 20 Mar 2013 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWuoW02o+iJc for ; Wed, 20 Mar 2013 09:22:12 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 2826621F9013 for ; Wed, 20 Mar 2013 09:22:10 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id C60DD165259; Wed, 20 Mar 2013 12:22:09 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 32216165256; Wed, 20 Mar 2013 12:22:09 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 20 Mar 2013 12:21:56 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 20 Mar 2013 12:22:08 -0400 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] Issue 4: http media types in RDAP replies Thread-Index: AQHOInzjY7jpxqASs0CFGWJBQuOjHZivBJ6A///EiAA= Date: Wed, 20 Mar 2013 16:22:07 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF48EE@CHAXCH01.corp.arin.net> In-Reply-To: <5149DBD1.8000000@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <567032E32E8EAC46A42E9488089AC52E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Issue 4: http media types in RDAP replies X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:22:13 -0000 We already do that in json-response, but I'm happy to move it to using-http. Also, we originally had the +json suffix and took it out. But since you've found some guidance on the use of the suffix, it is probably wise to add it back in. -andy On 3/20/13 11:54 AM, "Jean-Philippe Dionne" wrote: >What about the +json suffix? > From draft-ietf-appsawg-media-type-regs-14#section-3, we can read: >"Media types that make use of a named structured syntax SHOULD use the > appropriate registered "+suffix" for that structured syntax when they > are registered. " > From tony@att.com Wed Mar 20 09:59:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814421F88F7 for ; Wed, 20 Mar 2013 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFAOlliDTza4 for ; Wed, 20 Mar 2013 09:59:49 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id A82AD21F88CF for ; Wed, 20 Mar 2013 09:59:48 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 40be9415.0.198003.00-423.555249.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 20 Mar 2013 16:59:48 +0000 (UTC) X-MXL-Hash: 5149eb044107ab4d-734ecec74cf980d1174ca88d390cbb7cd484567a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2KGxmKn002411 for ; Wed, 20 Mar 2013 12:59:48 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2KGxfpV002362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Mar 2013 12:59:42 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Wed, 20 Mar 2013 16:59:28 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r2KGxSM9015419 for ; Wed, 20 Mar 2013 12:59:28 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r2KGxN0u015266 for ; Wed, 20 Mar 2013 12:59:24 -0400 Received: from [135.70.58.174] (vpn-135-70-58-174.vpn.west.att.com[135.70.58.174]) by maillennium.att.com (mailgw1) with ESMTP id <20130320165750gw1000m55ue> (Authid: tony); Wed, 20 Mar 2013 16:57:51 +0000 X-Originating-IP: [135.70.58.174] Message-ID: <5149EAE9.4090903@att.com> Date: Wed, 20 Mar 2013 12:59:21 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF48EE@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF48EE@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------070400000105000704010804" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Pr4kmXw3 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=XQF0PgYYJo4A:10 a=z55uD49gxukA:10 a=p5DJb0AXvPkA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=guoZXqJl] X-AnalysisOut: [uEUA:10 a=IIXG7RsUC-_FV_2grb8A:9 a=wPNLvfGTeEIA:10 a=Hz7Ir] X-AnalysisOut: [DYlS0cA:10 a=IepdWeDwkfhy7EAh:21 a=avzuPbBiUyGjzGK-:21 a=w] X-AnalysisOut: [iYxLJy5AAAA:8 a=r2CbOPE9Jrqaq3tObs8A:9 a=_W_S_7VecoQA:10 a] X-AnalysisOut: [=LyUn2sZr3PNXH4Er:21] Subject: Re: [weirds] Issue 4: http media types in RDAP replies X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:59:49 -0000 This is a multi-part message in MIME format. --------------070400000105000704010804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The draft mentioned below was recently published as RFC 6838: Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013. The actual registration of +json can be found in RFC 6839: Additional Media Type Structured Syntax Suffixes. T. Hansen, A. Melnikov. January 2013. Tony Hansen tony@att.com On 3/20/2013 12:22 PM, Andy Newton wrote: > We already do that in json-response, but I'm happy to move it to > using-http. > > Also, we originally had the +json suffix and took it out. But since you've > found some guidance on the use of the suffix, it is probably wise to add > it back in. > > -andy > > On 3/20/13 11:54 AM, "Jean-Philippe Dionne" > wrote: > >> What about the +json suffix? >> From draft-ietf-appsawg-media-type-regs-14#section-3, we can read: >> "Media types that make use of a named structured syntax SHOULD use the >> appropriate registered "+suffix" for that structured syntax when they >> are registered. " --------------070400000105000704010804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The draft mentioned below was recently published as RFC 6838:
    Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013.

The actual registration of +json can be found in RFC 6839:
    Additional Media Type Structured Syntax Suffixes. T. Hansen, A. Melnikov. January 2013.

        Tony Hansen
        tony@att.com

On 3/20/2013 12:22 PM, Andy Newton wrote:
We already do that in json-response, but I'm happy to move it to
using-http.

Also, we originally had the +json suffix and took it out. But since you've
found some guidance on the use of the suffix, it is probably wise to add
it back in.

-andy

On 3/20/13 11:54 AM, "Jean-Philippe Dionne"
<jean-philippe.dionne@viagenie.ca> wrote:


What about the +json suffix?
>From draft-ietf-appsawg-media-type-regs-14#section-3, we can read:
"Media types that make use of a named structured syntax SHOULD use the
 appropriate registered "+suffix" for that structured syntax when they
 are registered. "
--------------070400000105000704010804-- From edainow@afilias.info Wed Mar 20 12:28:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96621F86E6 for ; Wed, 20 Mar 2013 12:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9+WGFhjqrtm for ; Wed, 20 Mar 2013 12:28:54 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1104111E80FD for ; Wed, 20 Mar 2013 12:28:51 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UIOgs-0001xr-4u for weirds@ietf.org; Wed, 20 Mar 2013 19:28:50 +0000 Received: from mail-ob0-f198.google.com ([209.85.214.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UIOgs-0000L7-4e for weirds@ietf.org; Wed, 20 Mar 2013 19:28:50 +0000 Received: by mail-ob0-f198.google.com with SMTP id dn14so10209353obc.1 for ; Wed, 20 Mar 2013 12:28:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:user-agent:mime-version :to:subject:content-type:content-transfer-encoding :x-gm-message-state; bh=ZgyuX7PAdO3SflhlK2hXTEaNBDK7lDuzIwYLsz6Gk8k=; b=fzNK7Bd1rt+ipfd3jMPxwfM2i4neIdXyt7iwiksMjuZ9/6/lrF2Dkfb0WSuSCcAgBn oJ2w9GaF37NjsOmtkdCqpUO7qxGERSJEi+GMRyLDV516T4ujgPdcY9hyjk4x4osr2ONK Q3smWqrLMP4XYUofmwRqb9vSrxQAukwWuaLIDRLPCQWmPypxd104lwdCvIkkKXvnzfEJ ic8UUgy+ijp+gIjdqOz5bpzjUjORp9e+Tn/jp6Aj8p5iWKfWxUikRYDO29UkAHcumWsZ DiZ8/ol6e2jhSEIEsiNwOG1Vq/sca/Ma0VtJ8UJ0eVkt2z/P4UqbjbGznbrPRyuJdkS7 qwPw== X-Received: by 10.50.6.3 with SMTP id w3mr128672igw.76.1363807724865; Wed, 20 Mar 2013 12:28:44 -0700 (PDT) X-Received: by 10.50.6.3 with SMTP id w3mr128668igw.76.1363807724803; Wed, 20 Mar 2013 12:28:44 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id a17sm398336ign.1.2013.03.20.12.28.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 12:28:43 -0700 (PDT) Message-ID: <514A0DEA.7060701@afilias.info> Date: Wed, 20 Mar 2013 15:28:42 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQlp7dxVh7c3O03KFWgmkECl4ITuKDi/fyXYUuyKxJFSczbOCr5T0U2DSjE9wgKC4fj6ROxa1BdSVcQbwvStqZIgSCZiGtZ0pznIMiMX9pVhmu5aF18qUwONQB2dHj/p5Rrp0Aiy Subject: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:28:56 -0000 It seems there is a consensus to return both u-label and a-label for domain/hostname. In addition, the language of the u-label should be provided, something like { u-label: "füü", a-label: "xn--f-ehaa", lang="de" } (or u-name/a-name, unicode/ascii) This is needed because in many cases the language of an IDN will be different from the language of the top-most object. -Ernie From shollenbeck@verisign.com Wed Mar 20 14:06:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272721F0C36 for ; Wed, 20 Mar 2013 14:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWa3gAQLF9Xu for ; Wed, 20 Mar 2013 14:06:41 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9A11E80E7 for ; Wed, 20 Mar 2013 14:06:20 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUUokzILfShW2dk9/Xp2opY8Nf3ywua7X@postini.com; Wed, 20 Mar 2013 14:06:41 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2KL6Ht9002529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 17:06:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 17:06:16 -0400 From: "Hollenbeck, Scott" To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] IDN language tag Thread-Index: AQHOJaEsffYzy/HVfEOAKJZmzEOzRJivEg6Q Date: Wed, 20 Mar 2013 21:06:15 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24337E60@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <514A0DEA.7060701@afilias.info> In-Reply-To: <514A0DEA.7060701@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:06:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOndlaXJkcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRXJu aWUgRGFpbm93DQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjAsIDIwMTMgMzoyOSBQTQ0KPiBU bzogd2VpcmRzQGlldGYub3JnDQo+IFN1YmplY3Q6IFt3ZWlyZHNdIElETiBsYW5ndWFnZSB0YWcN Cj4gDQo+IEl0IHNlZW1zIHRoZXJlIGlzIGEgY29uc2Vuc3VzIHRvIHJldHVybiBib3RoIHUtbGFi ZWwgYW5kIGEtbGFiZWwgZm9yDQo+IGRvbWFpbi9ob3N0bmFtZS4gSW4gYWRkaXRpb24sIHRoZSBs YW5ndWFnZSBvZiB0aGUgdS1sYWJlbCBzaG91bGQgYmUNCj4gcHJvdmlkZWQsIHNvbWV0aGluZyBs aWtlDQo+ICAgICB7IHUtbGFiZWw6ICJmw7zDvCIsICBhLWxhYmVsOiAieG4tLWYtZWhhYSIsICBs YW5nPSJkZSIgfQ0KPiAgICAgKG9yIHUtbmFtZS9hLW5hbWUsIHVuaWNvZGUvYXNjaWkpDQo+IA0K PiBUaGlzIGlzIG5lZWRlZCBiZWNhdXNlIGluIG1hbnkgY2FzZXMgdGhlIGxhbmd1YWdlIG9mIGFu IElETiB3aWxsIGJlDQo+IGRpZmZlcmVudCBmcm9tIHRoZSBsYW5ndWFnZSBvZiB0aGUgdG9wLW1v c3Qgb2JqZWN0Lg0KDQpPbmUgcHJvYmxlbTogSUROcyBhcmVuJ3QgYXNzb2NpYXRlZCB3aXRoIHNw ZWNpZmljIGxhbmd1YWdlcy4NCg0KU2NvdHQNCg== From jean-philippe.dionne@viagenie.ca Wed Mar 20 14:09:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67791F0D0E for ; Wed, 20 Mar 2013 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqVRPJ7SUBJd for ; Wed, 20 Mar 2013 14:09:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id A67551F0D07 for ; Wed, 20 Mar 2013 14:09:07 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 100CE40334 for ; Wed, 20 Mar 2013 17:08:37 -0400 (EDT) Message-ID: <514A2554.3000805@viagenie.ca> Date: Wed, 20 Mar 2013 17:08:36 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <514A0DEA.7060701@afilias.info> In-Reply-To: <514A0DEA.7060701@afilias.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:09:08 -0000 On 03/20/2013 03:28 PM, Ernie Dainow wrote: > It seems there is a consensus to return both u-label and a-label for > domain/hostname. In addition, the language of the u-label should be > provided, something like > { u-label: "füü", a-label: "xn--f-ehaa", lang="de" } > (or u-name/a-name, unicode/ascii) > A library exists in every languages to converting an a-label to an u-label. It is straightforward and it is not harder to do it on the client side versus the server side. browsers and command line tools already do it. I still wonder why we would want to have redundant information on the wire. The mapping of a-label -> u-label is unique. As the guy who write test cases, I'll have to add a test to see if the two fields are equivalent. A lazy client programmer will just take the label it suits most for his usage, while a prudent programmer will have to write a check that u-label == a-label and have error handling in the strange situation where it would not be equal... > This is needed because in many cases the language of an IDN will be > different from the language of the top-most object. Jean-Philippe From ajs@anvilwalrusden.com Wed Mar 20 14:20:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFE011E80FB for ; Wed, 20 Mar 2013 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVy7ZdB1+cbk for ; Wed, 20 Mar 2013 14:20:48 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0655F11E80F2 for ; Wed, 20 Mar 2013 14:20:47 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 121738A031 for ; Wed, 20 Mar 2013 21:20:47 +0000 (UTC) Date: Wed, 20 Mar 2013 17:20:45 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130320212045.GB348@mx1.yitter.info> References: <514A0DEA.7060701@afilias.info> <831693C2CDA2E849A7D7A712B24E257F24337E60@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24337E60@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:20:50 -0000 On Wed, Mar 20, 2013 at 09:06:15PM +0000, Hollenbeck, Scott wrote: > One problem: IDNs aren't associated with specific languages. That's true, although in many repositories they are. I'd like to suggest this be optional, because if a repository has it we ought to have a standard place to put it. At least the ICANN-contracted registries will have this data in their repositories, because it's part of the IDN implementation guidelines. For it to be useful, I think you need the IANA repository identifier for the policy as well as the language tag. This may change if the ICANN LGR process ever gets adopted. A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Wed Mar 20 14:20:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8A11E80E7 for ; Wed, 20 Mar 2013 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.421 X-Spam-Level: X-Spam-Status: No, score=-110.421 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeKrj3RmMguC for ; Wed, 20 Mar 2013 14:20:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5499911E8103 for ; Wed, 20 Mar 2013 14:20:48 -0700 (PDT) Received: (qmail 5115 invoked from network); 20 Mar 2013 21:20:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Mar 2013 21:20:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514a282f.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=LYiadssy0hM8AfnDzZRDf6tBv140/wMn2I0L+Fi6pBw=; b=KhzY+inpb6HZ+GmBm9cUF5o1ulr55M3J2uppDIkA4OCRgfGwKdKaUB+tz0meF2iebt6U5SQOmvKHF8keO259AoHw1tvXyC4mCaeTqzr89DpTZ1NKAlxQYmOkQ8OGtBCa02GyFl47tcHYkiWws3sYMYa+zTDx+l2n2jkrdWiy6yU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514a282f.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=LYiadssy0hM8AfnDzZRDf6tBv140/wMn2I0L+Fi6pBw=; b=WPWZTYXJHKOOQzsj4TV3tFEO3bty5loThY2xiKDuNE+COUwCR7XiKX27j/5zxggledo61djA8HigJx2XVjs71fk1I0zM3WP2+JxMx2YyfKBefZHNVU1hs9zVHZM9SVVjB9x+RetOppH+wBtqAOJgCM6eoWK2BvRysU5mCCfC5Pk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Mar 2013 21:20:25 -0000 Message-ID: <20130320212025.89317.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24337E60@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:20:50 -0000 >> This is needed because in many cases the language of an IDN will be >> different from the language of the top-most object. > >One problem: IDNs aren't associated with specific languages. Seems to me we could just say that if there's a language tag available, which there should be if the IDN is a registered domain name, the server should include it. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ajs@anvilwalrusden.com Wed Mar 20 14:22:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87AA11E80F2 for ; Wed, 20 Mar 2013 14:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-mN1n1qy1kD for ; Wed, 20 Mar 2013 14:22:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA5311E80E7 for ; Wed, 20 Mar 2013 14:22:03 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8ACAB8A031 for ; Wed, 20 Mar 2013 21:22:02 +0000 (UTC) Date: Wed, 20 Mar 2013 17:22:01 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130320212200.GC348@mx1.yitter.info> References: <514A0DEA.7060701@afilias.info> <514A2554.3000805@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514A2554.3000805@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:22:04 -0000 On Wed, Mar 20, 2013 at 05:08:36PM -0400, Jean-Philippe Dionne wrote: > > A library exists in every languages to converting an a-label to an > u-label. This is only true for IDNA2008. For IDNA2003, it isn't quite so symmetric, and there's the rub. > As the guy who write test cases, I'll have to add a test to see if > the two fields are equivalent. A lazy client programmer will just > take the label it suits most for his usage, while a prudent > programmer will have to write a check that u-label == a-label and > have error handling in the strange situation where it would not be > equal... This is an excellent point, however. A -- Andrew Sullivan ajs@anvilwalrusden.com From fobispo@isc.org Wed Mar 20 14:22:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0CC11E80E7 for ; Wed, 20 Mar 2013 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkWP6twQvDMS for ; Wed, 20 Mar 2013 14:22:50 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 78DA71F0C36 for ; Wed, 20 Mar 2013 14:22:49 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id BC5A65F9908; Wed, 20 Mar 2013 21:22:37 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363814568; bh=MalCccyeALcN3NHQpp0iLQInM87FnKk+DXO8ywnCjFs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UnNpV8UPOZXvIEBwvy1aW0FwOvztWMFXI4I5LGxVLpHvLhGfnwdBFw9cm1xRGPBxO YIdXGwYsnho9tXRn4y7BvfZYENOa1t6hClDZ5ywKSSCQHj6US7xe7Dd/QM8loumlhP qSyVy0ZcgdQmJW1WwNS5jfd0SMuQ/rGBr92f71Vw= Received: from [IPv6:2001:4f8:3:64:c4cd:f1bc:340b:7b23] (unknown [IPv6:2001:4f8:3:64:c4cd:f1bc:340b:7b23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 54B83216C3B; Wed, 20 Mar 2013 21:22:36 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <20130320212025.89317.qmail@joyce.lan> Date: Wed, 20 Mar 2013 14:22:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77DF7E24-78A3-43D6-BA7B-BF3FBD60FE7A@isc.org> References: <20130320212025.89317.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1503) Cc: weirds@ietf.org Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:22:50 -0000 Just for the record, we shouldn't call it "language tag" but "IDN table = identifier", we are preparing a follow up draft to = http://tools.ietf.org/html/obispo-epp-idn to deal with that and = UNAME/ANAME On Mar 20, 2013, at 2:20 PM, "John Levine" wrote: > Seems to me we could just say that if there's a language tag > available, which there should be if the IDN is a registered domain > name, the server should include it. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From shollenbeck@verisign.com Wed Mar 20 14:24:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9421F88ED for ; Wed, 20 Mar 2013 14:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qTxaDZPT-2L for ; Wed, 20 Mar 2013 14:24:40 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 873B121F88DB for ; Wed, 20 Mar 2013 14:24:35 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUUopERzjMS4rYquBhW/Feeacj9V/260r@postini.com; Wed, 20 Mar 2013 14:24:39 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2KLOTRp010450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 17:24:33 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 17:24:28 -0400 From: "Hollenbeck, Scott" To: Francisco Obispo , John Levine Thread-Topic: [weirds] IDN language tag Thread-Index: AQHOJaEsffYzy/HVfEOAKJZmzEOzRJivEg6QgABHN4CAAACdgP//vVww Date: Wed, 20 Mar 2013 21:24:28 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24337F78@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130320212025.89317.qmail@joyce.lan> <77DF7E24-78A3-43D6-BA7B-BF3FBD60FE7A@isc.org> In-Reply-To: <77DF7E24-78A3-43D6-BA7B-BF3FBD60FE7A@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:24:40 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Francisco Obispo > Sent: Wednesday, March 20, 2013 5:23 PM > To: John Levine > Cc: weirds@ietf.org > Subject: Re: [weirds] IDN language tag >=20 > Just for the record, we shouldn't call it "language tag" but "IDN table > identifier", we are preparing a follow up draft to > http://tools.ietf.org/html/obispo-epp-idn to deal with that and > UNAME/ANAME This I feel better about. Scott From olaf@NLnetLabs.nl Thu Mar 21 04:16:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E5621F8F0B for ; Thu, 21 Mar 2013 04:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8DrMg6wx-yc for ; Thu, 21 Mar 2013 04:16:19 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEF121F8F06 for ; Thu, 21 Mar 2013 04:16:18 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2LBGAWk082088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 12:16:13 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.8.0 open.nlnetlabs.nl r2LBGAWk082088 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1363864574; bh=QYsND4cW2PCjxWhjo4eouuvw+qYC+G+FNHrGxRkP2D8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=he/CdXdbfQe79oD1efVc+6SKQRh1tNoNdnYv4VM5BPt5S8CVQ0QEJns60C+hYVQVM nUG/UXk6mtXH6kwxiuYxXdt4/o1LmOYZRwddSWeSKIp0SZDu71hdYrQWurkhyFZOfo ZLurOC8t9Z6BT05lAoHrL+Zk2s2IwifARXOnTwtg= Content-Type: multipart/alternative; boundary="Apple-Mail=_37AEF59E-129E-47AB-8C7A-682455778661" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: <20130312183537.GD39324@mx1.yitter.info> Date: Thu, 21 Mar 2013 12:16:10 +0100 Message-Id: References: <20130312150603.GC39238@mx1.yitter.info> <20130312183537.GD39324@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 21 Mar 2013 12:16:13 +0100 (CET) Cc: weirds@ietf.org Subject: Re: [weirds] A-labels vs U-labels X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 11:16:24 -0000 --Apple-Mail=_37AEF59E-129E-47AB-8C7A-682455778661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 12, 2013, at 7:35 PM, Andrew Sullivan = wrote: > On Tue, Mar 12, 2013 at 11:41:07AM -0400, Behnam Esfahbod wrote: >> And also note that using U-labels would make the protocol transparent = to >> IDNA version, IDNA2003 vs IDNA2008. Unless we want to make IDNA2008 = on the >> client side, using A-labels could be very destructive for >> IDNA2008 adaptation, IMHO. >=20 > This is both true and false. >=20 > For instance, a client might send a query for fa=DF.de. Depending on > what version of IDNA (and preprocessing) the server is operating, > that either matches the domain "fass.de" or "fa=DF.de" or, worst, > {"fass.de","fa=DF.de"}. I don't think U-labels get us out of that = pain. [no-hats] So it seems that the adaptation of a particular IDNA version is registry = policy.=20 Given that premiss (are there still registries that operate on = IDNA2003), I think the question is if we allow the protocol to be = neutral to that policy question?=20 If we want it to be policy neutral then isn't it the case that the = client then could send Unicode strings and allow the server to check = whether the submitted labels are valid U-labels? (Under IDNA2008 they = would be valid A-labels too then, but not under IDNA2003). The alternative would be to standardize clients to use IDNA2008. I am = not sure exactly what the impact would be on registries that use = IDNA2003. An implementation note for the special cases might be what is = needed then? Personally I would have a preference for client side pre-lookup checks = on IDNA2008 but I haven't got a good feel for the consequences. That = said I think that it inside of the IETF scope to not use obsoleted = protocols (and thereby de-facto favoring specific policy choices). --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_37AEF59E-129E-47AB-8C7A-682455778661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ajs@anvilwalrusden.com> = wrote:


 fa=DF.de.  Depending on
that either matches the domain = "
{"

Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_37AEF59E-129E-47AB-8C7A-682455778661-- From jean-philippe.dionne@viagenie.ca Thu Mar 21 06:53:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2B621F906B for ; Thu, 21 Mar 2013 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 034GRIPgMK3k for ; Thu, 21 Mar 2013 06:53:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E0F0521F9079 for ; Thu, 21 Mar 2013 06:53:40 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5514F403E9 for ; Thu, 21 Mar 2013 09:53:40 -0400 (EDT) Message-ID: <514B10E3.80701@viagenie.ca> Date: Thu, 21 Mar 2013 09:53:39 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <514A0DEA.7060701@afilias.info> <514A2554.3000805@viagenie.ca> <20130320212200.GC348@mx1.yitter.info> In-Reply-To: <20130320212200.GC348@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] IDN language tag X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:53:41 -0000 On 03/20/2013 05:22 PM, Andrew Sullivan wrote: > On Wed, Mar 20, 2013 at 05:08:36PM -0400, Jean-Philippe Dionne wrote: >> > >> >A library exists in every languages to converting an a-label to an >> >u-label. > This is only true for IDNA2008. For IDNA2003, it isn't quite so > symmetric, and there's the rub. > Hi Andrew, To my knowledge, from IDNA2003 to IDNA2008, the punycode algorithm has not changed. Applying the punycode algorithm will always lead to a unique unicode representation. This representation might be considered invalid according to IDNA200x. Regards Jean-Philippe From aservin@lacnic.net Thu Mar 21 07:59:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7379A21F9049 for ; Thu, 21 Mar 2013 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YTAHSMbsnpc for ; Thu, 21 Mar 2013 07:59:50 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0121F8825 for ; Thu, 21 Mar 2013 07:59:49 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:edcb:68d5:ee15:3f10]) by mail.lacnic.net.uy (Postfix) with ESMTP id E6A1B308424 for ; Thu, 21 Mar 2013 11:59:33 -0300 (UYT) Message-ID: <514B2060.4060808@lacnic.net> Date: Thu, 21 Mar 2013 11:59:44 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] IETF 86 minutes posted X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:59:50 -0000 Just a nit. In the agenda it says that Andy presented the report, but in the slides are Jean-Philippe, Simon and Marc. I could not attend the meeting, so I am not sure who really presented or if there is a missing document (by Andy). Thanks, as On 3/18/13 1:15 PM, Murray S. Kucherawy wrote: > The draft minutes from our dual session at IETF 86 in Orlando have been > posted. Please review them and let us know if we've missed anything. > > http://www.ietf.org/proceedings/86/minutes/minutes-86-weirds > > Many thanks to Andrew Sullivan and John Levine for keeping great notes > for us! > > -MSK, WEIRDS co-chair > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From olaf@NLnetLabs.nl Thu Mar 21 08:29:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6235321F902E for ; Thu, 21 Mar 2013 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIFPIO2rWR2Y for ; Thu, 21 Mar 2013 08:29:06 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4236721F8D84 for ; Thu, 21 Mar 2013 08:29:05 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2LFSuLc016218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 16:28:58 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.8.0 open.nlnetlabs.nl r2LFSuLc016218 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1363879739; bh=6E4JMztHSM1iUaZI86FFGiTkxq2GB+vQqx3PPMDLMm0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MtqEQBaxvs3CimR8D2PgkqxVyqp2XM/voFM3OH8ZIya1q+4RIswtHpj224hhN1XnL KjnfTC/+/FyhNSCabcVqwWGO4vl+fHesajM1/bv1Yv/Lbg9AgKz5UZbgof8CHkrolQ A/V54oxHK2q71oS+70nuyFabYWY5SoW2yIJZUJIA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 21 Mar 2013 16:28:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: Francisco Obispo X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 21 Mar 2013 16:28:58 +0100 (CET) Cc: "weirds@ietf.org" Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:29:07 -0000 On Mar 13, 2013, at 5:36 PM, Francisco Obispo wrote: > Yes, >=20 > My opinion is that we should be able to take both a-labels and = u-labels. [no hats] One clarification question (similar to the one I asked in a different = thread earlier today). If we say A-Labels and U-Labels we mean that the input is valid under = IDNA2008. Do we want the client to do that validity check? Or do we mean that we allow unicode encoded labels and the server will = sort out whether those are indeed valid U-Lables? --Olaf= From shollenbeck@verisign.com Thu Mar 21 08:35:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062421F8F05 for ; Thu, 21 Mar 2013 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiGceaFHZB5W for ; Thu, 21 Mar 2013 08:35:39 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 43FAE21F8F44 for ; Thu, 21 Mar 2013 08:35:33 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUUsoxEZWlyEN4mawCcXkqKekcc0QWJOn@postini.com; Thu, 21 Mar 2013 08:35:38 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2LFZQKb011671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 11:35:26 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 11:35:25 -0400 From: "Hollenbeck, Scott" To: Olaf Kolkman , Francisco Obispo Thread-Topic: [weirds] A-label and U-label Lookups Thread-Index: AQHOJkjbfwkmy53vqkyWQ0ybYj0ZrZiwRc9g Date: Thu, 21 Mar 2013 15:35:25 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24338951@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> In-Reply-To: <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:35:39 -0000 > -----Original Message----- > From: Olaf Kolkman [mailto:olaf@NLnetLabs.nl] > Sent: Thursday, March 21, 2013 11:29 AM > To: Francisco Obispo > Cc: Hollenbeck, Scott; weirds@ietf.org > Subject: Re: [weirds] A-label and U-label Lookups >=20 >=20 > On Mar 13, 2013, at 5:36 PM, Francisco Obispo wrote: >=20 > > Yes, > > > > My opinion is that we should be able to take both a-labels and u- > labels. >=20 >=20 > [no hats] >=20 > One clarification question (similar to the one I asked in a different > thread earlier today). >=20 > If we say A-Labels and U-Labels we mean that the input is valid under > IDNA2008. Do we want the client to do that validity check? >=20 > Or do we mean that we allow unicode encoded labels and the server will > sort out whether those are indeed valid U-Lables? I'm suggesting the latter. I'm concerned about asking generic http clients = like web browsers to process portions of URLS in ways that they don't curre= ntly. Scott From presnick@qti.qualcomm.com Thu Mar 21 09:31:03 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91621F8D10 for ; Thu, 21 Mar 2013 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvqDaJp5+yPU for ; Thu, 21 Mar 2013 09:31:02 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 571E821F8CF9 for ; Thu, 21 Mar 2013 09:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1363883462; x=1395419462; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+jdzOwmzoizlK+4E2DQdwEyvVxhAdA+e+BccV7hWABk=; b=y7PF5XNJhhDwJ2ft+vrEOeH98iTCftxItsm9JbidjzjIXKyezrR5Xxqo 7Eo8EJIvPIJaUb2t598VpqwRClAhmb4JjEF+xTq5mkI3MdAL6Zodiyjr8 oi3nuyUIu8RVE6V2v3Dvdd7dkW2Y/5pQ8BqopYiuVFJ4ibf3GcixK9EaZ w=; X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="31015747" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 21 Mar 2013 09:30:41 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Mar 2013 09:30:40 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Mar 2013 09:30:40 -0700 Message-ID: <514B35AF.8020305@qti.qualcomm.com> Date: Thu, 21 Mar 2013 11:30:39 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> <831693C2CDA2E849A7D7A712B24E257F24338951@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24338951@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "weirds@ietf.org" Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:31:03 -0000 On 3/21/13 10:35 AM, Hollenbeck, Scott wrote: >> From: Olaf Kolkman [mailto:olaf@NLnetLabs.nl] >> >> If we say A-Labels and U-Labels we mean that the input is valid under >> IDNA2008. Do we want the client to do that validity check? >> >> Or do we mean that we allow unicode encoded labels and the server will >> sort out whether those are indeed valid U-Lables? >> > I'm suggesting the latter. I'm concerned about asking generic http clients like web browsers to process portions of URLS in ways that they don't currently. Things get tricky pretty darn quickly here. I expect you'll want to answer the following questions as well. Is a server allowed to reject things that aren't valid U-Labels because: - they use uppercase characters? - they use IDEOGRAPHIC FULL STOP character (U+3002) instead of U+002E? - they are not in NFC? - they use any characters that are DISALLOWED? - they use percent-encoded characters? - they use ampersand-encoded characters? - they are not in UTF-8 at all? Certainly the server will have to protect itself from bad input, whatever the document says. But do you want the protocol to allow allow any input and not have the client do any processing to validate input? And if they are expected to do any validation/processing, why not expect them to do all of it? I'm not suggesting any particular answers to these questions. I'm only suggesting that the document is going to have to be clear about what the answers to those questions are. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From simon.perreault@viagenie.ca Thu Mar 21 10:26:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1556D21F917A for ; Thu, 21 Mar 2013 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt6IztNZxfwX for ; Thu, 21 Mar 2013 10:26:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2382521F9170 for ; Thu, 21 Mar 2013 10:26:15 -0700 (PDT) Received: from porto.nomis80.org (85-169-43-76.rev.numericable.fr [85.169.43.76]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 82BDE414A9 for ; Thu, 21 Mar 2013 13:25:42 -0400 (EDT) Message-ID: <514B4295.509@viagenie.ca> Date: Thu, 21 Mar 2013 18:25:41 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <514B2060.4060808@lacnic.net> In-Reply-To: <514B2060.4060808@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] IETF 86 minutes posted X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:26:33 -0000 Le 2013-03-21 15:59, Arturo Servin a écrit : > In the agenda it says that Andy presented the report, but in the slides > are Jean-Philippe, Simon and Marc. > > I could not attend the meeting, so I am not sure who really presented > or if there is a missing document (by Andy). The minutes are correct. Andy presented the report. Not sure what slides you are referring to... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From aservin@lacnic.net Thu Mar 21 10:30:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98CB21F913C for ; Thu, 21 Mar 2013 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sANYChKoOuZA for ; Thu, 21 Mar 2013 10:30:41 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7991421F90B9 for ; Thu, 21 Mar 2013 10:30:40 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:edcb:68d5:ee15:3f10]) by mail.lacnic.net.uy (Postfix) with ESMTP id 92F13308437 for ; Thu, 21 Mar 2013 14:30:21 -0300 (UYT) Message-ID: <514B43B6.2020608@lacnic.net> Date: Thu, 21 Mar 2013 14:30:30 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <514B2060.4060808@lacnic.net> <514B4295.509@viagenie.ca> In-Reply-To: <514B4295.509@viagenie.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] IETF 86 minutes posted X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:30:43 -0000 On 3/21/13 2:25 PM, Simon Perreault wrote: > Le 2013-03-21 15:59, Arturo Servin a écrit : >> In the agenda it says that Andy presented the report, but in the >> slides >> are Jean-Philippe, Simon and Marc. >> >> I could not attend the meeting, so I am not sure who really presented >> or if there is a missing document (by Andy). > > The minutes are correct. Andy presented the report. > > Not sure what slides you are referring to... In the agenda page: http://tools.ietf.org/wg/weirds/agenda?item=agenda-86-weirds.html Test Report But no worries. Doubt has been cleared now. > > Simon /as From johnl@iecc.com Thu Mar 21 10:56:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8BC21F8620 for ; Thu, 21 Mar 2013 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooMMhBD6EQ2f for ; Thu, 21 Mar 2013 10:56:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9E21F85DA for ; Thu, 21 Mar 2013 10:56:52 -0700 (PDT) Received: (qmail 95963 invoked from network); 21 Mar 2013 17:56:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Mar 2013 17:56:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514b49e3.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=h3D6iluAhjLDZyCNI4dZMurlK2b7aScWbu6QQx8iGx0=; b=qgRiAlfRfihGbgchpZ8PNzt3dqS69qrei5gSJp9YHcufuZYZWh/Qq5YlxlvHAseBhtAE/f7pPzw7mh5tNa0w9zqbNfwUKM/Zu3ZoswoywReDz1IXjO8tdiWuQx1taZu6Uge0/6dwG34SXwW3XebINZNn7+M+TH4sgE/1fMs5KlU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=514b49e3.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=h3D6iluAhjLDZyCNI4dZMurlK2b7aScWbu6QQx8iGx0=; b=M9Ar1uwTko2ZGi03Nhy6KRmbiy9ZuQxFpGXTeUCdbSHULvtPAJGf02guB0zw5JRv2xRjilLvC0oEXuI1Z2f5WLorv9Tpj3py2RAHuZkvGwc9eOLebCCfJGfysJwHiQKcTNfAtly6SH6Y4AXqYMbD5aEKTFyiCrapQSMS7kHmdys= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 21 Mar 2013 17:56:28 -0000 Message-ID: <20130321175628.97210.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:56:53 -0000 >If we say A-Labels and U-Labels we mean that the input is valid under IDNA2008. Do we want the client >to do that validity check? Yes. >Or do we mean that we allow unicode encoded labels and the server will sort out whether those are >indeed valid U-Labels? Since the server cannot depend on clients to be bug-free, yes. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From shollenbeck@verisign.com Thu Mar 21 12:20:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE821F901D for ; Thu, 21 Mar 2013 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT+CjGDBy+pq for ; Thu, 21 Mar 2013 12:20:16 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 514DA21F901E for ; Thu, 21 Mar 2013 12:20:15 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUUtdbozhVKGICOydBa4IU81FUNq9j2nj@postini.com; Thu, 21 Mar 2013 12:20:16 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2LJKDlc025453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 15:20:14 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 21 Mar 2013 15:20:13 -0400 From: "Hollenbeck, Scott" To: Pete Resnick Thread-Topic: [weirds] A-label and U-label Lookups Thread-Index: AQHOJkjbfwkmy53vqkyWQ0ybYj0ZrZiwRc9ggABThYD//+uV8A== Date: Thu, 21 Mar 2013 19:20:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24338BC0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F2432F0F8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <625222E3-45F1-4EEE-BB5E-63342686A97F@NLnetLabs.nl> <831693C2CDA2E849A7D7A712B24E257F24338951@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <514B35AF.8020305@qti.qualcomm.com> In-Reply-To: <514B35AF.8020305@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] A-label and U-label Lookups X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:20:17 -0000 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qti.qualcomm.com] > Sent: Thursday, March 21, 2013 12:31 PM > To: Hollenbeck, Scott > Cc: Olaf Kolkman; Francisco Obispo; weirds@ietf.org > Subject: Re: [weirds] A-label and U-label Lookups >=20 > On 3/21/13 10:35 AM, Hollenbeck, Scott wrote: > >> From: Olaf Kolkman [mailto:olaf@NLnetLabs.nl] > >> > >> If we say A-Labels and U-Labels we mean that the input is valid > under > >> IDNA2008. Do we want the client to do that validity check? > >> > >> Or do we mean that we allow unicode encoded labels and the server > >> will sort out whether those are indeed valid U-Lables? > >> > > I'm suggesting the latter. I'm concerned about asking generic http > clients like web browsers to process portions of URLS in ways that they > don't currently. >=20 > Things get tricky pretty darn quickly here. I expect you'll want to > answer the following questions as well. Is a server allowed to reject > things that aren't valid U-Labels because: >=20 > - they use uppercase characters? > - they use IDEOGRAPHIC FULL STOP character (U+3002) instead of U+002E? > - they are not in NFC? > - they use any characters that are DISALLOWED? > - they use percent-encoded characters? > - they use ampersand-encoded characters? > - they are not in UTF-8 at all? >=20 > Certainly the server will have to protect itself from bad input, > whatever the document says. But do you want the protocol to allow allow > any input and not have the client do any processing to validate input? > And if they are expected to do any validation/processing, why not > expect them to do all of it? >=20 > I'm not suggesting any particular answers to these questions. I'm only > suggesting that the document is going to have to be clear about what > the answers to those questions are. That's precisely why I included text that requires IDNA processing as speci= fied in 5891. Whether or not that's the right approach is open to debate, b= ut it was an attempt to bound the problem. Scott From maarten.wullink@sidn.nl Sun Mar 24 12:48:38 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07821F8D34 for ; Sun, 24 Mar 2013 12:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDvh5jga2aPC for ; Sun, 24 Mar 2013 12:48:37 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 7622B21F8B19 for ; Sun, 24 Mar 2013 12:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=rB/LH7FK5ulvNrQBkTiYceTbvqqTg+9/x1bxpOqRhlY=; b=gEHfHe+fvrN4qk1+CmVlCIt8kjkQ4tKJgvkUIIn/ELPFqywhxy19xeYPa2mSKZFMaY0or4QmGMRbULSezSIicyJN3D6HwgABBsTVpC2aVEODd/TJBXHpkYKyzjbpnSu2l1DfhvjKEdDB0+ubVYLflxiQ8QZKJLfElHHkPAtzBuo= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r2OJmZmS011057-r2OJmZmU011057 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Sun, 24 Mar 2013 20:48:35 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 24 Mar 2013 20:48:35 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcas1.SIDN.local ([fe80::dff:8232:1563:3a16%14]) with mapi id 14.02.0328.009; Sun, 24 Mar 2013 20:48:35 +0100 From: Maarten Wullink To: "weirds@ietf.org" Thread-Topic: json schema for weirds model Thread-Index: Ac4oyBBZ1b+ksaTvQMOseRPFQXomrw== Date: Sun, 24 Mar 2013 19:48:34 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] json schema for weirds model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 19:48:38 -0000 I don't if this has been asked before but maybe it is good idea to use the = json schema (described in http://tools.ietf.org/html/draft-zyp-json-schema-= 04) to describe the weirds data structures?=0A= =0A= Cheers,=0A= =0A= Maarten Wullink=0A= r&d engineer SIDN.= From andy@hxr.us Sun Mar 24 13:24:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3D21F8B19 for ; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLXWG+wJ52cH for ; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75F21F8A52 for ; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) Received: by mail-da0-f48.google.com with SMTP id p8so2898695dan.7 for ; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+FukCWXvWFIQt8DavLxYXYdvbav9DQtSw0OoaE/CRJU=; b=ihAUcUiHdaTigqg/08az8G+X2HzHs+TftV3HX6tJwOMNxayLcghwZrMI8OyCAutTLC B9DKQswdy7XoiuxUQ8X/x3hoLfhrliS5mw8/Mtr0nb5nV0djqfmhOV4fp6GJyWC+lUj7 NJHL3ywB3FHNAEOXWohjQonogJLYBR59slyvjrrk7jAzBdEUK1f/U4xlBYlTNeBLYN95 uVSeAdoEdIFtGa00cuxhcmhL7NH2XO4cQvRW0g3wDeQf+H9wa1ubx1N8sZoMpoDoZ0N5 H+W4Qa2w/eVvE9swllGfVtV4dmjh4V9SRYx0EqhZv9QPo2OdQCCBYY7bnX/jw514gRu4 t8wg== MIME-Version: 1.0 X-Received: by 10.66.121.98 with SMTP id lj2mr14591173pab.166.1364156688111; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) Received: by 10.68.247.161 with HTTP; Sun, 24 Mar 2013 13:24:48 -0700 (PDT) X-Originating-IP: [71.191.219.28] In-Reply-To: References: Date: Sun, 24 Mar 2013 16:24:48 -0400 Message-ID: From: Andrew Newton To: Maarten Wullink Content-Type: multipart/alternative; boundary=e89a8ffbadddd02f1d04d8b17af5 X-Gm-Message-State: ALoCoQkauCpa47Sc+yUk56yCWMPnNpM9xTsTPSo9ESIp7BpykoLfNlfezj5+SIIIfqlbIR7dub3N Cc: "weirds@ietf.org" Subject: Re: [weirds] json schema for weirds model X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 20:24:49 -0000 --e89a8ffbadddd02f1d04d8b17af5 Content-Type: text/plain; charset=ISO-8859-1 Actually, a good bit of the RDAP JSON response has already been described via JSON Content Rules in Appendix B of draft-newton-json-content-rules ( http://tools.ietf.org/html/draft-newton-json-content-rules-01#appendix-B). Non-normative schema in JSON Schema or JSON Content Rules might be useful as a separate Informational document, but at this time doing either as normative text is probably unwise. There is current debate in the IETF regarding the utility of schema languages for JSON, and we shouldn't hold up WEIRDS waiting for that debate to be resolved. And note that I'm saying this and I'm an author of one of those proposals. -andy On Sun, Mar 24, 2013 at 3:48 PM, Maarten Wullink wrote: > I don't if this has been asked before but maybe it is good idea to use the > json schema (described in > http://tools.ietf.org/html/draft-zyp-json-schema-04) to describe the > weirds data structures? > > Cheers, > > Maarten Wullink > r&d engineer SIDN. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --e89a8ffbadddd02f1d04d8b17af5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, a good bit of the RDAP JSON response has already= been described via JSON Content Rules in Appendix B of draft-newton-json-c= ontent-rules (http://tools.ietf.org/html/draft-newton-json-conten= t-rules-01#appendix-B).

Non-normative schema in JSON Schema or JSON Content Rules mi= ght be useful as a separate Informational document, but at this time doing = either as normative text is probably unwise. There is current debate in the= IETF regarding the utility of schema languages for JSON, and we shouldn= 9;t hold up WEIRDS waiting for that debate to be resolved. And note that I&= #39;m saying this and I'm an author of one of those proposals.

-andy


On Sun, Mar 24, 2013 at 3:48 PM, Maarten Wullink <maarten.wullink@sidn.nl> wrote:
I don't if this has been asked before bu= t maybe it is good idea to use the json schema (described in http://= tools.ietf.org/html/draft-zyp-json-schema-04) to describe the weirds da= ta structures?

Cheers,

Maarten Wullink
r&d engineer SIDN.
_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--e89a8ffbadddd02f1d04d8b17af5-- From internet-drafts@ietf.org Mon Mar 25 10:13:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09B021F8C97; Mon, 25 Mar 2013 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+4lOjgpE099; Mon, 25 Mar 2013 10:13:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1810D21F8904; Mon, 25 Mar 2013 10:13:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130325171356.8500.88390.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 10:13:56 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:13:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Using the Registration Data Access Protocol (RDAP) with = HTTP Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-02.txt Pages : 11 Date : 2013-03-25 Abstract: This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Mon Mar 25 11:05:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4621F9554 for ; Mon, 25 Mar 2013 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miNCHMfnHUBz for ; Mon, 25 Mar 2013 11:05:29 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6856021F9528 for ; Mon, 25 Mar 2013 11:05:25 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id x43so947987wey.0 for ; Mon, 25 Mar 2013 11:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5EH9WQGrSoPQvfOqs1hQgwYSQoCP1SmEJ083tiB1+J4=; b=uLTgoTz+aNSF+s+oE/Ijyh40t4ChQ1FEFMkfP9sgLLgzHmInXc0Z3V8+RhK5WgBAtL hdoWTSf5x7o/JIDI2M3hcoj7ichBAl5qgFcyeuptm0vWIYsWTmQSrhW7OJ/sC+xTCzjQ trBfrqidZdot5Wv1PuRdrt2GjGdtVOg6vGfeHUIW+bdwAmh52/6XaoI8sNWvY56z7+jc XzQpnAGyysKAOibx77gD1cB/wjzjL/lnKrI5eemv/yIwO1LbgqgHg++Se4GG3G+msfhs FDnzJvs+aO1RQVrW280iUsHt9c/yZYSF/K/F/0gYZ60iM98SBlHwEHfO5nsvr9lmY6zz eX3A== MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr8069354wib.21.1364234723620; Mon, 25 Mar 2013 11:05:23 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 25 Mar 2013 11:05:23 -0700 (PDT) In-Reply-To: <20130325171356.8500.88390.idtracker@ietfa.amsl.com> References: <20130325171356.8500.88390.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2013 11:05:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426de6177cac04d8c3a6c9 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 18:05:30 -0000 --f46d04426de6177cac04d8c3a6c9 Content-Type: text/plain; charset=ISO-8859-1 Does this resolve our outstanding issues? Are we ready for WGLC on this one? -MSK, co-chairin' On Mon, Mar 25, 2013 at 10:13 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. > > Title : Using the Registration Data Access Protocol > (RDAP) with HTTP > Author(s) : Andrew Lee Newton > Byron J. Ellacott > Ning Kong > Filename : draft-ietf-weirds-using-http-02.txt > Pages : 11 > Date : 2013-03-25 > > Abstract: > This document describes the usage of the Registration Data Access > Protocol (RDAP) using HTTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-using-http-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --f46d04426de6177cac04d8c3a6c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Does this resolve our outstanding issues?=A0 Are we r= eady for WGLC on this one?

-MSK, co-chairin'


On Mon, Mar 25, 2= 013 at 10:13 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Web Extensible Internet Registration Da= ta Service Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using the Registration Data Acc= ess Protocol (RDAP) with HTTP
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andrew Lee Newton
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Byron J. Ellacott
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ning Kong
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-weirds-using-http-02.t= xt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-03-25

Abstract:
=A0 =A0This document describes the usage of the Registration Data Access =A0 =A0Protocol (RDAP) using HTTP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-using-h= ttp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-using-http-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-= using-http-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--f46d04426de6177cac04d8c3a6c9-- From andy@arin.net Mon Mar 25 11:35:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38621F90C7 for ; Mon, 25 Mar 2013 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o26O91bcnqZC for ; Mon, 25 Mar 2013 11:35:14 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 2003E21F90B1 for ; Mon, 25 Mar 2013 11:35:14 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id AF3C421368C; Mon, 25 Mar 2013 14:35:13 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id E6025213685; Mon, 25 Mar 2013 14:35:12 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 25 Mar 2013 14:34:30 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 25 Mar 2013 14:35:00 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Thread-Index: AQHOKXwlUw0ltxZAWkC+M92bJ4aC7Zi29rmA///FMoA= Date: Mon, 25 Mar 2013 18:35:00 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 18:35:15 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Murray, Do you want the people who opened tickets in the issue tracker to confirm t= he closure of the issues by closing the tickets? -andy From: "Murray S. Kucherawy" > Date: Monday, March 25, 2013 2:05 PM To: "weirds@ietf.org" > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Does this resolve our outstanding issues? Are we ready for WGLC on this on= e? -MSK, co-chairin' On Mon, Mar 25, 2013 at 10:13 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Using the Registration Data Access Protocol (RDAP= ) with HTTP Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-02.txt Pages : 11 Date : 2013-03-25 Abstract: This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Murray,

Do you want the people who opened tickets in the issue tracker to conf= irm the closure of the issues by closing the tickets?

-andy

From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Monday, March 25, 2013 2:05 P= M
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] I-D Action: d= raft-ietf-weirds-using-http-02.txt

Does this resolve our outstanding issues?  Are we ready for WGLC = on this one?

-MSK, co-chairin'


On Mon, Mar 25, 2013 at 10:13 AM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Web Extensible Internet Registration= Data Service Working Group of the IETF.

        Title           : Usin= g the Registration Data Access Protocol (RDAP) with HTTP
        Author(s)       : Andrew Lee New= ton
                     = ;     Byron J. Ellacott
                     = ;     Ning Kong
        Filename        : draft-iet= f-weirds-using-http-02.txt
        Pages           : 11         Date            := 2013-03-25

Abstract:
   This document describes the usage of the Registration Data Acc= ess
   Protocol (RDAP) using HTTP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-using-h= ttp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-using-http-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-= using-http-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds


--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37CHAXCH01corpari_-- From superuser@gmail.com Mon Mar 25 12:04:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9221F9433 for ; Mon, 25 Mar 2013 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h13Ia1K8PgDx for ; Mon, 25 Mar 2013 12:04:57 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C721F9557 for ; Mon, 25 Mar 2013 12:04:54 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k14so2566314wer.41 for ; Mon, 25 Mar 2013 12:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LGh7UU/0YOUKuh5AM//kXTwfDIAj0KWTssiocsQIrto=; b=I/S/SbLR/JpF2EsjPdK0255Gn/ZJWGty1nKzYgQreptNBzLjS9UcpVL8Erxj+hbDlH 6h7eGHIfGw5akFvyJH9TUC6sEXIsGlEKQHmVXHq9h2IswP/zYghD2LxZ6pTMn0nIlzAZ qw016mWdgfdZBZjoSRyFGPyRMN1obaiXeywVrYVQL6OlLsrfi1m27SMwo9mHzt2MyVy1 V+xdrG0Is0xmPEoQxeV+cAttzXtX8fJisl/9bJlpsnh3MzISenThZ/zQmu3Dde2d7NzE 9PxNUtGRdvTdMGwV8reEAAcJj4t7WOC5/WGkhFw8LQgoMb7aZtBH8MrFYrYOF0YRc4Hl fo2w== MIME-Version: 1.0 X-Received: by 10.180.187.129 with SMTP id fs1mr19494739wic.5.1364238285653; Mon, 25 Mar 2013 12:04:45 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 25 Mar 2013 12:04:45 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37@CHAXCH01.corp.arin.net> Date: Mon, 25 Mar 2013 12:04:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=001a11c2672267d0d604d8c47a1d Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 19:04:57 -0000 --001a11c2672267d0d604d8c47a1d Content-Type: text/plain; charset=ISO-8859-1 That would be ideal. On Mon, Mar 25, 2013 at 11:35 AM, Andy Newton wrote: > Murray, > > Do you want the people who opened tickets in the issue tracker to > confirm the closure of the issues by closing the tickets? > > -andy > > From: "Murray S. Kucherawy" > Date: Monday, March 25, 2013 2:05 PM > To: "weirds@ietf.org" > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt > > Does this resolve our outstanding issues? Are we ready for WGLC on > this one? > > -MSK, co-chairin' > > > On Mon, Mar 25, 2013 at 10:13 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Extensible Internet Registration >> Data Service Working Group of the IETF. >> >> Title : Using the Registration Data Access Protocol >> (RDAP) with HTTP >> Author(s) : Andrew Lee Newton >> Byron J. Ellacott >> Ning Kong >> Filename : draft-ietf-weirds-using-http-02.txt >> Pages : 11 >> Date : 2013-03-25 >> >> Abstract: >> This document describes the usage of the Registration Data Access >> Protocol (RDAP) using HTTP. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-weirds-using-http-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> > > > > --001a11c2672267d0d604d8c47a1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That would be ideal.
<= br>
On Mon, Mar 25, 2013 at 11:35 AM, Andy Ne= wton <andy@arin.net> wrote:
Murray,

Do you want the people who opened tickets in the issue tracker to conf= irm the closure of the issues by closing the tickets?

-andy

From: "Murray S. Kucherawy&quo= t; <superuser@g= mail.com>
Date: Monday, March 25, 2013 2:05 P= M
To: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] I-D Action: d= raft-ietf-weirds-using-http-02.txt

Does this resolve our outstanding issues?=A0 Are we ready for WGLC on = this one?

-MSK, co-chairin'


On Mon, Mar 25, 2013 at 10:13 AM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Web Extensible Internet Registration Da= ta Service Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using the Registration Data Acc= ess Protocol (RDAP) with HTTP
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andrew Lee Newton
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Byron J. Ellacott
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ning Kong
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-weirds-using-http-02.t= xt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-03-25

Abstract:
=A0 =A0This document describes the usage of the Registration Data Access =A0 =A0Protocol (RDAP) using HTTP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-using-h= ttp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-using-http-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-= using-http-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds



--001a11c2672267d0d604d8c47a1d-- From johnl@iecc.com Mon Mar 25 14:04:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBD521F90D9 for ; Mon, 25 Mar 2013 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53mi93IMlXS7 for ; Mon, 25 Mar 2013 14:04:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AE21F9092 for ; Mon, 25 Mar 2013 14:04:38 -0700 (PDT) Received: (qmail 98030 invoked from network); 25 Mar 2013 21:04:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Mar 2013 21:04:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5150bbe5.xn--hew.k1303; i=johnl@user.iecc.com; bh=lQWiSaWeR2bp4Q+VGKAW+jCS8L2nh0JXHoNI0/X9cr0=; b=BnUPprmuaa9BIb052dUh6ixr2mcx+JBWNOZD4t/wjo5bx+Zs7cT+IHX7Gb7DUb1JCa7L/h6siCmYcQQhObzzRafSGLaU5O2A7bAg+KdVonE2121GODXe9HdWnJ4r8h0l35bpouhcXN7mDA91TkV5Ty9rzXocvCNuP6nL1lhBT9Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5150bbe5.xn--hew.k1303; olt=johnl@user.iecc.com; bh=lQWiSaWeR2bp4Q+VGKAW+jCS8L2nh0JXHoNI0/X9cr0=; b=evkvOQUNxEDrwQwI/RK1RIMOyp/NDbLwJn949kZUyNZ8xcDmYdGsqAh7QHdqRDGLsCcUhIVemNPh4p0VlFItwaLjC7cycF0xazcsuGQRG9vhAMqOeHzKO9qOsu8t1jO7NhLT011WugghJJJeg2X+TGNnmVWoeSkOpKOtjA66sBI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Mar 2013 21:04:15 -0000 Message-ID: <20130325210415.21947.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF5F37@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 21:04:40 -0000 >Do you want the people who opened tickets in the issue tracker to confirm the closure of the >issues by closing the tickets? They would be me. Ticket 4, about the content type, is fixed, so I'll close it. Ticket 5, about rate limiting, is fixed, so I'll close it. R's, John From johnl@iecc.com Mon Mar 25 14:05:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A828821F9416 for ; Mon, 25 Mar 2013 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1RwVbPTLTkg for ; Mon, 25 Mar 2013 14:05:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0A21F93D1 for ; Mon, 25 Mar 2013 14:05:09 -0700 (PDT) Received: (qmail 98171 invoked from network); 25 Mar 2013 21:05:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Mar 2013 21:05:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5150bc05.xn--i8sz2z.k1303; i=johnl@user.iecc.com; bh=jCVXfMbqu9GT4I4RVuB9+8iSBV0E31yHjgeWBMcGHuo=; b=SQzKezyFW5ZlNsk57JKfhuawmAnQ15c8S0cGBBp17a8bcn8SlUgsFi+3jmVE+Gd3t12TeBeiSZtPDmNR8egPT2DGwvlp5Lo4yuaCq5KCN6VhWuT/94CCqlANxLmdUXJ2u8vfL/Ig8QboGHPy8J75Ff/ypOdRAJM4pwmCSwbMK7w= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5150bc05.xn--i8sz2z.k1303; olt=johnl@user.iecc.com; bh=jCVXfMbqu9GT4I4RVuB9+8iSBV0E31yHjgeWBMcGHuo=; b=NQBIQDpVYn2K6vk3210oMV/xSJLhECHFAk51jX38/P1gNTr1gaKy5mSJthZPORYYiSXoR9fif9pU5/++TgUXtyeXcna7FOr9ErJNBhs3BGjolGMLHjAmMKB1LcXt3PsLkV71pLS+mZ9VROL/XoZUykMLfmkCNOKtdP2pxDlEUT0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Mar 2013 21:04:46 -0000 Message-ID: <20130325210446.21971.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 21:05:10 -0000 >Does this resolve our outstanding issues? Are we ready for WGLC on this >one? Both of the tickets are closed and I see no issues in the other changes. From Ray.Bellis@nominet.org.uk Tue Mar 26 06:10:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD121F8B6E for ; Tue, 26 Mar 2013 06:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TYitkl+2OcN for ; Tue, 26 Mar 2013 06:10:09 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A32021F8AF0 for ; Tue, 26 Mar 2013 06:10:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=ButRbMWKrbmq4gbZaaYWWwSJPAidUZRjSNWO3sYOvpcq0P3EC7goqUCW ge6MmrfxMxnoAB4xZ+IDJRIH39SviaF26BsNsc8xIBmkUps64XE6wquFd /T+ONNXhTOOOIQo; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1364303409; x=1395839409; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20I-D=20Action:=20draft-ietf-w eirds-using-http-02.txt|Date:=20Tue,=2026=20Mar=202013=20 13:10:05=20+0000|Message-ID:=20<53F00E5CD8B2E34C81C0C89EB 0B4FE73105BFD44@wds-exc1.okna.nominet.org.uk>|To:=20"Murr ay=20S.=20Kucherawy"=20|CC:=20"weird s@ietf.org=20Group"=20|MIME-Version:=201 .0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<5021611768AADF4391DF900B2C25CBBE@okna.nom inet.org.uk>|In-Reply-To:=20|References:=20<20 130325171356.8500.88390.idtracker@ietfa.amsl.com>=0D=0A =20; bh=1EDDVJwPKL4cAkOblN5KcKza7r998hKTxOzwfQAqvjE=; b=tJsiYRSvCQdnRV+CbrV5qHHGgJ/yYhdH+iVO7SOCZv8Mxuuz40rSoPAi oFiEI+D0qjMJg2kM3NZXp64rjz1FwN0R9RnB0MDdAvPnmVpbR6zzexz0C 5eNcWz+RCFx4Ql4; X-IronPort-AV: E=Sophos;i="4.87,352,1363132800"; d="scan'208";a="47455447" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 26 Mar 2013 13:10:06 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 13:10:06 +0000 From: Ray Bellis To: "Murray S. Kucherawy" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Thread-Index: AQHOKXwmwFhCAtVEPUidtU/E7Hyyr5i2s6uAgAE/04A= Date: Tue, 26 Mar 2013 13:10:05 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73105BFD44@wds-exc1.okna.nominet.org.uk> References: <20130325171356.8500.88390.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5021611768AADF4391DF900B2C25CBBE@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 13:10:10 -0000 On 25 Mar 2013, at 18:05, Murray S. Kucherawy wrote: > Does this resolve our outstanding issues? Are we ready for WGLC on this = one? Should my general comment about CORS handling be addressed in this document= ? Ray From andy@arin.net Tue Mar 26 07:56:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9C721F8B8D for ; Tue, 26 Mar 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUXWrt+vkalL for ; Tue, 26 Mar 2013 07:56:57 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92B21F8B0C for ; Tue, 26 Mar 2013 07:56:57 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B2F1F213675; Tue, 26 Mar 2013 10:56:56 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 2FD6A213595; Tue, 26 Mar 2013 10:56:56 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 26 Mar 2013 10:56:22 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 26 Mar 2013 10:56:55 -0400 From: Andy Newton To: Ray Bellis , "Murray S. Kucherawy" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Thread-Index: AQHOKXwlUw0ltxZAWkC+M92bJ4aC7Zi29rmAgAE/04D//9rIAA== Date: Tue, 26 Mar 2013 14:56:54 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6438@CHAXCH01.corp.arin.net> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE73105BFD44@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:56:57 -0000 On 3/26/13 9:10 AM, "Ray Bellis" wrote: > >On 25 Mar 2013, at 18:05, Murray S. Kucherawy wrote: > >> Does this resolve our outstanding issues? Are we ready for WGLC on >>this one? > >Should my general comment about CORS handling be addressed in this >document ? Can you open a ticket for this? That's the best way to ensure I don't miss it. In general, I think CORS should be RECOMMENDED. -andy From Ray.Bellis@nominet.org.uk Tue Mar 26 08:02:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FF821F8C3B for ; Tue, 26 Mar 2013 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W74WGdPoxhT2 for ; Tue, 26 Mar 2013 08:02:07 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA7B21F8C49 for ; Tue, 26 Mar 2013 08:01:55 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=YbJ0V1PqkEID0eTaj8s9XqTugIpUK6WVj4BW1i7aAD7506QWeC5qWQcK x94+p1erCUyNPCFljdLoP+3eOYBEXrgoDRHDoJPC/NEH98Ix0JtyxsSXE KsUMiBPpXr/MpGM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1364310116; x=1395846116; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20I-D=20Action:=20draft-ietf-w eirds-using-http-02.txt|Date:=20Tue,=2026=20Mar=202013=20 15:01:53=20+0000|Message-ID:=20<53F00E5CD8B2E34C81C0C89EB 0B4FE73105C053C@wds-exc1.okna.nominet.org.uk>|To:=20Andy =20Newton=20|CC:=20"weirds@ietf.org=20Grou p"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20|In-Reply-To:=20<62D9228640AC7F49B2DD9ED0C9CE 60E58BBF6438@CHAXCH01.corp.arin.net>|References:=20<62D92 28640AC7F49B2DD9ED0C9CE60E58BBF6438@CHAXCH01.corp.arin.ne t>; bh=G9dVvyt8Odpj5QEMjOXgRVPGUW7Va31qp697IKDFU2c=; b=Zzk4chARcQb+r3zlmO2CRWjSWgTe03DO4Aj+fM+u9hWUIzRp4dINm8fD 4pbEdFbNufL7lBxd7rP/0i6CPquRrRy5Ykhbel/EoSYwD4tHPFzrn2IvS NQCJt2Yt8oOkqbU; X-IronPort-AV: E=Sophos;i="4.87,352,1363132800"; d="scan'208";a="47457365" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 26 Mar 2013 15:01:55 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 15:01:54 +0000 From: Ray Bellis To: Andy Newton Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Thread-Index: AQHOKXwmwFhCAtVEPUidtU/E7Hyyr5i2s6uAgAE/04CAAB3YAIAAAWWA Date: Tue, 26 Mar 2013 15:01:53 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73105C053C@wds-exc1.okna.nominet.org.uk> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6438@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6438@CHAXCH01.corp.arin.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:02:08 -0000 On 26 Mar 2013, at 14:56, Andy Newton wrote: > Can you open a ticket for this? That's the best way to ensure I don't mis= s > it. OK, if I can remember how :) > In general, I think CORS should be RECOMMENDED. agreed - strictly speaking it's a policy decision for the registry, but if = it's not mentioned they'll forget to think about it. Ray From jean-philippe.dionne@viagenie.ca Tue Mar 26 08:42:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCF21F8C78 for ; Tue, 26 Mar 2013 08:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZQFR-VmClV8 for ; Tue, 26 Mar 2013 08:42:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id B941121F8C72 for ; Tue, 26 Mar 2013 08:42:34 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3C9C54041E for ; Tue, 26 Mar 2013 11:42:04 -0400 (EDT) Message-ID: <5151C1CB.3030503@viagenie.ca> Date: Tue, 26 Mar 2013 11:42:03 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: <20130325171356.8500.88390.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:42:36 -0000 Hi, I have a few more comments about the relation between this document and draft-ietf-weirds-json-response. Section 6 "Extensibility" (and 7.1) reserves a namespace inside the json response. I would move it to draft-ietf-weirds-json-response. In section 7.1, the requested prefix is "lunarNic". However, the examples in draft-ietf-weirds-json-response are "lunarNic_". Given the variable name called "lunarNicName", is it under the "lunarNic" namespace or not? Section 8.2 refers to [draft-ietf-weirds-json-response], it creates cross-references, which I don't think is necessary. Regards Jean-Philippe On 03/25/2013 02:05 PM, Murray S. Kucherawy wrote: > Does this resolve our outstanding issues? Are we ready for WGLC on this > one? > > -MSK, co-chairin' > > > On Mon, Mar 25, 2013 at 10:13 AM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet > Registration Data Service Working Group of the IETF. > > Title : Using the Registration Data Access > Protocol (RDAP) with HTTP > Author(s) : Andrew Lee Newton > Byron J. Ellacott > Ning Kong > Filename : draft-ietf-weirds-using-http-02.txt > Pages : 11 > Date : 2013-03-25 > > Abstract: > This document describes the usage of the Registration Data Access > Protocol (RDAP) using HTTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-using-http-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Tue Mar 26 12:40:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66AE21F8DB7 for ; Tue, 26 Mar 2013 12:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWWWK6DQ1umU for ; Tue, 26 Mar 2013 12:40:11 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34221F8CC2 for ; Tue, 26 Mar 2013 12:40:11 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id A35DD213678; Tue, 26 Mar 2013 15:39:40 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 195142135FD; Tue, 26 Mar 2013 15:39:40 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 26 Mar 2013 15:39:29 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 26 Mar 2013 15:39:39 -0400 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt Thread-Index: AQHOKXwlUw0ltxZAWkC+M92bJ4aC7Zi29rmAgAFqSYD///9PgA== Date: Tue, 26 Mar 2013 19:39:38 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6664@CHAXCH01.corp.arin.net> In-Reply-To: <5151C1CB.3030503@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 19:40:11 -0000 Jean-Philippe, My responses in line: On 3/26/13 11:42 AM, "Jean-Philippe Dionne" wrote: >Hi, > >Section 6 "Extensibility" (and 7.1) reserves a namespace inside the json >response. I would move it to draft-ietf-weirds-json-response. That namespace registry is used by both the response and query drafts. It is not specific only to json_response, therefore having it in this document is appropriate. >In section 7.1, the requested prefix is "lunarNic". However, the >examples in draft-ietf-weirds-json-response are "lunarNic_". Given the >variable name called "lunarNicName", is it under the "lunarNic" >namespace or not? The registration is for "lunarNic". The use in json-response is "lunarNic_" as specified in Section 4.2 of json-response: "Insertion of unspecified values into JSON responses SHOULD have names prefixed with a short identifier followed by an underscore followed by a meaningful name." Likewise for rdap-query: "Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F)." In the example above, the JSON name should be "lunarNic_name". > >Section 8.2 refers to [draft-ietf-weirds-json-response], it creates >cross-references, which I don't think is necessary. I agree. That paragraph could be moved to json-response and the cross-reference can be avoided. -andy From jean-philippe.dionne@viagenie.ca Tue Mar 26 13:10:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31121F8CAE for ; Tue, 26 Mar 2013 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk60JnGdp30D for ; Tue, 26 Mar 2013 13:10:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC28521F8A7E for ; Tue, 26 Mar 2013 13:10:00 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4244446FD2; Tue, 26 Mar 2013 16:10:00 -0400 (EDT) Message-ID: <51520097.6000709@viagenie.ca> Date: Tue, 26 Mar 2013 16:09:59 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6664@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF6664@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 20:10:01 -0000 Hi, On 03/26/2013 03:39 PM, Andy Newton wrote: > Jean-Philippe, > > My responses in line: > > On 3/26/13 11:42 AM, "Jean-Philippe Dionne" > wrote: > >> Hi, >> >> Section 6 "Extensibility" (and 7.1) reserves a namespace inside the json >> response. I would move it to draft-ietf-weirds-json-response. > > That namespace registry is used by both the response and query drafts. It > is not specific only to json_response, therefore having it in this > document is appropriate. > I did not relalize that was the same namespace used in the query path segment. >> In section 7.1, the requested prefix is "lunarNic". However, the >> examples in draft-ietf-weirds-json-response are "lunarNic_". Given the >> variable name called "lunarNicName", is it under the "lunarNic" >> namespace or not? > > The registration is for "lunarNic". The use in json-response is > "lunarNic_" as specified in Section 4.2 of json-response: "Insertion of > unspecified values into JSON responses SHOULD have names prefixed with a > short identifier followed by an underscore followed by a meaningful name." > > Likewise for rdap-query: "Custom path segments can be created by prefixing > the segment with a > unique identifier followed by an underscore character (0x5F)." > > In the example above, the JSON name should be "lunarNic_name". > Sorry about that, I missed this one. Thank you for the clarification Jean-Philippe >> >> Section 8.2 refers to [draft-ietf-weirds-json-response], it creates >> cross-references, which I don't think is necessary. > > I agree. That paragraph could be moved to json-response and the > cross-reference can be avoided. > > -andy > From internet-drafts@ietf.org Wed Mar 27 07:07:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF221F9138; Wed, 27 Mar 2013 07:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBUDw+Jtg75b; Wed, 27 Mar 2013 07:07:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FB121F9134; Wed, 27 Mar 2013 07:07:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130327140708.12151.20856.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2013 07:07:08 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:07:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Using the Registration Data Access Protocol (RDAP) with = HTTP Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-03.txt Pages : 11 Date : 2013-03-27 Abstract: This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Wed Mar 27 09:53:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26FE21F91D1 for ; Wed, 27 Mar 2013 09:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXnRL4dj+XFE for ; Wed, 27 Mar 2013 09:53:26 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 27E1321F91C7 for ; Wed, 27 Mar 2013 09:53:22 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2552290wiw.4 for ; Wed, 27 Mar 2013 09:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=mIDCVtaL9PAojLz7vPIUGtE7FWqtKzjD0i5dsFUKF3c=; b=i7aURskO/ix9KK/s6NrgG26yqXqD9nTOiGtI9wDoNiH7fOdw9bogB5gOzONW7XkDRk DSq/if3p0SdDOQChuujvu338Udo3Lbv9QPhsGmt97ici+GxtTCSLqljIt0ubT5FVPr+V I+C8Zt65J5LA1NgI1Hfe+sCzIaeKCg1M7aj8+N3xaXy6b0z5/p1epLPiWGSADCBK8fLZ rwHhu6860Tyj97gTX9HPghx1IeOeNZ4TuboNICk2hTd3JYMECDYSZeww/jQ/PW9I+hKL +YZcuDsgLDyq10uWng6qG/yS3nMrxuqLec8dB+6ULXJLMoEqDlhjpQhL+rUPQYSFvM+R xUww== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr10872787wib.33.1364403202332; Wed, 27 Mar 2013 09:53:22 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Wed, 27 Mar 2013 09:53:22 -0700 (PDT) Date: Wed, 27 Mar 2013 17:53:22 +0100 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba6e334a0cb04d8eae079 Subject: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:53:27 -0000 --e89a8f3ba6e334a0cb04d8eae079 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, We would like to initiate a two-week Working Group Last Call on draft-ietf-weirds-http. A version 03 was just pushed to the datatracker: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ Last call will end Wednesday, April 10th. Please review and comment on the draft, even if it is only to say on the record "I have reviewed this document thoroughly and it looks good." We would like to have no fewer than five people report that they have taken a look at the whole document and reported their findings, and will be reticent to send it to the IESG without that. We're also keen to hear from people that have implemented the specification as to their views on clarity, correctness, and completeness. Thanks, -MSK and Olaf, your co-chairs --e89a8f3ba6e334a0cb04d8eae079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

We would like to initiate a t= wo-week Working Group Last Call on draft-ietf-weirds-http.=A0 A version 03 = was just pushed to the datatracker:

https://datatracker.ietf.org/doc= /draft-ietf-weirds-using-http/

Last call will end Wednesday, April 10th.

Please review an= d comment on the draft, even if it is only to say on the record "I hav= e reviewed this document thoroughly and it looks good."=A0 We would li= ke to have no fewer than five people report that they have taken a look at = the whole document and reported their findings, and will be reticent to sen= d it to the IESG without that.=A0 We're also keen to hear from people t= hat have implemented the specification as to their views on clarity, correc= tness, and completeness.

Thanks,

-MSK and Olaf, your co-chairs

--e89a8f3ba6e334a0cb04d8eae079-- From jean-philippe.dionne@viagenie.ca Wed Mar 27 10:09:36 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0221F9250 for ; Wed, 27 Mar 2013 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSod-tiqO2uQ for ; Wed, 27 Mar 2013 10:09:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C421F9227 for ; Wed, 27 Mar 2013 10:09:34 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 539A34149E for ; Wed, 27 Mar 2013 13:09:04 -0400 (EDT) Message-ID: <515327AF.3020905@viagenie.ca> Date: Wed, 27 Mar 2013 13:09:03 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <20130327140708.12151.20856.idtracker@ietfa.amsl.com> In-Reply-To: <20130327140708.12151.20856.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:09:36 -0000 Hi, It is required to have "Security Consideration" section. Some security measures have already been included in this document (5.5. Rate Limits and 5.6. Cross-Origin Resource Sharing) while the rest is in draft-hollenbeck-weirds-rdap-sec-00. Here's some text suggestion: " This document does not pose strong security requirements to the RDAP protocol. However, it does not restrict against the use of security mechanisms offerred by the HTTP protocol. This document made recommendations for server implementations against denial-of-service (section 5.5) and interreroperability with existing security mechanism in HTTP clients (section 5.6). Additional security considerations to the RDAP protocol are coverred in [draft-hollenbeck-weirds-rdap-sec-00]. " Jean-Philippe On 03/27/2013 10:07 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. > > Title : Using the Registration Data Access Protocol (RDAP) with HTTP > Author(s) : Andrew Lee Newton > Byron J. Ellacott > Ning Kong > Filename : draft-ietf-weirds-using-http-03.txt > Pages : 11 > Date : 2013-03-27 > > Abstract: > This document describes the usage of the Registration Data Access > Protocol (RDAP) using HTTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-using-http-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From sm@resistor.net Wed Mar 27 10:32:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62521F920E for ; Wed, 27 Mar 2013 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T50UehqrLm7Y for ; Wed, 27 Mar 2013 10:32:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 610D921F9208 for ; Wed, 27 Mar 2013 10:32:47 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2RHWd8i017857; Wed, 27 Mar 2013 10:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364405564; bh=ic5BcLSDvKx1ClogRG6Sszd8BZV1627Dt1UtixJgWVU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YlWUz5jzcY59Gd6j0ZM0+zBwFdygXOQzuNfPjW70mN/5L7shFRciwopwxkwfGwPdF MLZoADbPZj1x7HFAxtpPjatBXzmtP80ql+pC1zFeQwCbgIadtmaWohPtkoTxu8nARQ mefs3cgL6oQf3CbvrADYNi3YTOnefy2x7+ZEF6uk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364405564; i=@resistor.net; bh=ic5BcLSDvKx1ClogRG6Sszd8BZV1627Dt1UtixJgWVU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s0ZafhzfpF3L/SPJzvRWWSvpRcsiaVewPV2YAX43M2n7O9Yn0x8SL/wij1/x/6BkP 2KIpyM+cBndXGTmbduUhzKlsSCROlomImc/8oXlUtDgiTHrC9bIDAAG9y0yBakTHak AeWVpsrAmef+pSnzxrCcszYIFpy1BToPzEDnAD4s= Message-Id: <6.2.5.6.2.20130327101012.0c52b348@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Mar 2013 10:15:07 -0700 To: "Hollenbeck, Scott" From: SM In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vco rp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:32:51 -0000 At 16:48 14-03-2013, Hollenbeck, Scott wrote: >[OT] It's a pity that we do not have reserved FQ IDNs to use in >these cases. Is there any chance we can use the example.test names >here? Do we need to make it official first, as an RFC? There are a few IDNs which appear as reserved. There was an effort to get it through a RFC. The draft did not gain traction. Regards, -sm From shollenbeck@verisign.com Wed Mar 27 12:10:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C713421F8FF2 for ; Wed, 27 Mar 2013 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkhvL6RHxgl7 for ; Wed, 27 Mar 2013 12:10:48 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id EC80121F8FF0 for ; Wed, 27 Mar 2013 12:10:40 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUVNEL21xswUsUQrDgzHlHf3TtrB3+Dgz@postini.com; Wed, 27 Mar 2013 12:10:48 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r2RJAZtf032355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Mar 2013 15:10:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 27 Mar 2013 15:10:35 -0400 From: "Hollenbeck, Scott" To: SM Thread-Topic: [weirds] U-label support Thread-Index: AQHOIQahSUF3Xaljl0iew25pnt8hOJil1i/QgBQJ/JKAABshgA== Date: Wed, 27 Mar 2013 19:10:34 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243499EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> In-Reply-To: <6.2.5.6.2.20130327101012.0c52b348@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:10:50 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, March 27, 2013 1:15 PM > To: Hollenbeck, Scott > Cc: weirds@ietf.org > Subject: Re: [weirds] U-label support >=20 > At 16:48 14-03-2013, Hollenbeck, Scott wrote: > >[OT] It's a pity that we do not have reserved FQ IDNs to use in these > >cases. Is there any chance we can use the example.test names here? Do > >we need to make it official first, as an RFC? >=20 > There are a few IDNs which appear as reserved. There was an effort to > get it through a RFC. The draft did not gain traction. Minor point, but that's not my text. Scott From superuser@gmail.com Wed Mar 27 19:57:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92421F943E for ; Wed, 27 Mar 2013 19:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaefN9h61l2A for ; Wed, 27 Mar 2013 19:57:53 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2083D21F943A for ; Wed, 27 Mar 2013 19:57:52 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so2842858wiw.7 for ; Wed, 27 Mar 2013 19:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=7ZdIM3xO3RcYfYiZYvXXvTHK5FVQN92W2I5BCckMHVk=; b=Gi7z5W+Vdce6aBcmFKM/UDUjsY1SVRAQxa7NLEUT7hhZX/8CoaejX278jqo2SfZ7rO 1Jo6Z2JvBxEvHnkwuhgC62o0PHAvruzm7xCpzQfxjbQ/y/f6ZQhpWRd40Qu6GyXJx1Hh 3ZDnmsBmqwqfAahh/TEZpEKsENNxrAF9p+t2owhedKr77t8q13XFWnH+mngKu9kCC9Dj nWvEaOeDYrtF94w8SuQSv2hgQ7qZK/5DYLDAIwJI4VrNMzdY4f9q9lxd/NLkQLCWVMvc +DbcOvA7bDUsyI5mExxXeQuA6MD7t2NOmqW8f/o07Z1w9Up3drlPMWvT70p8xo8oLqao DeZw== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr35404739wjc.39.1364439472312; Wed, 27 Mar 2013 19:57:52 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Wed, 27 Mar 2013 19:57:52 -0700 (PDT) Date: Thu, 28 Mar 2013 03:57:52 +0100 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1f281096b504d8f35238 Subject: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 02:57:53 -0000 --089e013d1f281096b504d8f35238 Content-Type: text/plain; charset=ISO-8859-1 The Orlando minutes reflect that we batted around some ideas about how to move forward with documents covering the topic of search, but the issue wasn't formally resolved. I'd like to take a moment to have that discussion now. The idea I thought had general support based on the working group and some hallway chatter afterwards is the notion of creating two search documents, one covering basic or core search syntax and capabilities, and one covering extended search. John Levine remarked that the former would generally try to match the search capabilities that WHOIS servers offer now while the latter would cover things we'd like to see, and there would be some pressure to have implementation experience with the proposals of the latter before we let the document proceed. Can we get some indications of support or objection to proceeding that way? -MSK --089e013d1f281096b504d8f35238 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The Orlando minutes reflect that we batted aroun= d some ideas about how to move forward with documents covering the topic of= search, but the issue wasn't formally resolved.=A0 I'd like to tak= e a moment to have that discussion now.

The idea I thought had general support based on the working group= and some hallway chatter afterwards is the notion of creating two search d= ocuments, one covering basic or core search syntax and capabilities, and on= e covering extended search.=A0 John Levine remarked that the former would g= enerally try to match the search capabilities that WHOIS servers offer now = while the latter would cover things we'd like to see, and there would b= e some pressure to have implementation experience with the proposals of the= latter before we let the document proceed.

Can we get some indications of support or objection to proce= eding that way?

-MSK
--089e013d1f281096b504d8f35238-- From johnl@iecc.com Wed Mar 27 21:18:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3C21F941C for ; Wed, 27 Mar 2013 21:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUUYJbW0apzG for ; Wed, 27 Mar 2013 21:18:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77921F940B for ; Wed, 27 Mar 2013 21:18:29 -0700 (PDT) Received: (qmail 76483 invoked from network); 28 Mar 2013 04:18:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Mar 2013 04:18:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5153c494.xn--3zv.k1303; i=johnl@user.iecc.com; bh=8OW4R1Q44+BBTewKpxdx23mVHfoVB//wEahU47uFfrA=; b=JkWmmVw3w75UPuSQqgI9HXWaFnn3PaTw1N0rPoZuJLjK+GDYS32itQjqABf+aNdHjeO4IM/CAEmkw/wiE8kP8iITpIK8rFJVOcz0yenSaNyvoY2N7hjggNPEjkwb5MouWWRfgQBCEoFie1aU+b9SllbFScxpqS36wFaYs291O9w= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5153c494.xn--3zv.k1303; olt=johnl@user.iecc.com; bh=8OW4R1Q44+BBTewKpxdx23mVHfoVB//wEahU47uFfrA=; b=JmsKMXqjUNwiBER33ioe8t82k2KOrrUFF7uPF3y09eBCC0p2w72BDW8KGDKJjt/VkOkPJdHIHoYwqA38RGcyENo/u7wKe2o/vCwHPiMcF/IX/LzRpHlKELOrtNBlVRc9ZCtiRRfEMKWU8zuC0Fq3TaYKq6dqRHceO7rTxMivsKE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Mar 2013 04:18:05 -0000 Message-ID: <20130328041805.93726.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 04:18:31 -0000 I reread the whole think and it looks ready to ship. I haven't implemented it, but I've done enough web applications to be confident that when I do, it'll work. From johnl@iecc.com Wed Mar 27 21:24:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268E21F9369 for ; Wed, 27 Mar 2013 21:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvpqA5FXd11T for ; Wed, 27 Mar 2013 21:24:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D8FFD11E80A3 for ; Wed, 27 Mar 2013 21:24:33 -0700 (PDT) Received: (qmail 78118 invoked from network); 28 Mar 2013 04:24:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Mar 2013 04:24:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5153c5ff.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=9QqklXeCpNEiKs4JxjIjGmKpujhCq/rOvpNzVUpebYY=; b=GRouepMHJMXF5WIJwzFvAIgbz7FP57T7r018wOi6LwT33WhaZhZDh5toJ3BSQ/ga2KcSjSt4LjhjyxhQ8/Vu9xWrtlX29Q079XC6E9CcEjarz0P+7dyhLpB4wjoGs8StzzEJ53sQqb+e2PdutLVpHeQY6KImFKUlUC9NC7elPII= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5153c5ff.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=9QqklXeCpNEiKs4JxjIjGmKpujhCq/rOvpNzVUpebYY=; b=BQdvJZ0rsyUkf4jeNGDk7PSg6P2LddYD9FyQpuI/C34jtHrS9c5GyR4ISmz6vV4vjwUMAoEeG2x72V50jyDjacsHJWBZPRu/dzh01VRqEDw2sMNKAPUapf9UXTe/QP1DhzHQtE0Yfo0RjItSta9zqU9d7aVc0JpNKF2YzEhRZ+E= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Mar 2013 04:24:09 -0000 Message-ID: <20130328042409.93766.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 04:24:39 -0000 >The idea I thought had general support based on the working group and some >hallway chatter afterwards is the notion of creating two search documents, >one covering basic or core search syntax and capabilities, and one covering >extended search. John Levine remarked that the former would generally try >to match the search capabilities that WHOIS servers offer now while the >latter would cover things we'd like to see, and there would be some >pressure to have implementation experience with the proposals of the latter >before we let the document proceed. > >Can we get some indications of support or objection to proceeding that way? Steve Sheng and I have an informal work item to survey the existing WHOIS servers to see what core search would involve. I've been looking at some ccTLDs and for the few I've found that provide any search at all, it's pretty simple. You give it a string and an entity type (domain, nameserver, registrar, etc.) and it tells you the entities whose names that start with the string, limited to a small number of results if your string matches a lot of names. R's, John From alexander.mayrhofer@nic.at Thu Mar 28 05:32:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C785A21F8BE2 for ; Thu, 28 Mar 2013 05:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.83 X-Spam-Level: X-Spam-Status: No, score=-8.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiqdzoNM3XUF for ; Thu, 28 Mar 2013 05:32:54 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5021F81FE for ; Thu, 28 Mar 2013 05:32:52 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Thu, 28 Mar 2013 13:32:51 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Thu, 28 Mar 2013 13:32:49 +0100 From: Alexander Mayrhofer To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4rq8gkSNvk1hNaQbSOOMrrX6LYdA== Date: Thu, 28 Mar 2013 12:32:48 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982EF4D@NICS-EXCH.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 12:32:54 -0000 I've taken the opportunity of the WGLC to perform a review of the using-htt= p draft (i haven't followed all discussions during the development of this = draft, so some of my points might have been discussed before, or are too la= te in the process): - Title: If i would start the document, i would have called it "HTTP usage = in RDAP" instead of the other way around [might be personal taste, though] - Abstract: "usage" and "using" in the same sentence sounds weird(s) to me = [but English is not my first language] - Introduction: Would change first sentence into "... describes the RESTful= usage of HTTP .... running on web servers...", since i the RESTfulness is = imho a property of the HTTP usage, rather then the HTTP server (as the tech= nical contraption that's being used for RESTful usage). - Intorduction: The last paragraph would probably fit better before the "ba= sic usage pattern" bullet list? - Introduction, 3rd bullet point: use "HTTP(s) URL" instead of "HTTP URL"? - Introduction: Additional bullet point that servers can refuse queries fo= r policy reasons with response code out of the 4xx range (eg. 403, 429) - Section 4.1: I understand that clients not designating themselves as "RDA= P clients" may still send Accept: headers - correct? - Section 4.2: Add text about *known* query parameters, since the Section t= itle says "Query Parameters" in general? Eg. that they are defined in the r= espective protocol-level document... Implementors need to understand how to= identify the set of "unknown" parameters. - Section 5: The "Negative Answer" section only describes the case where th= e server has no information about the query. However, there's no text about= the case where the server wishes to respond that it *has* the requested in= formation, but cannot return it due to server policy for the specific clien= t (for example, that [additional] authentication is required in order to re= trieve the information - or the client ip range has been blocked because if= misuse of the service). This case does neither fit the "positive answer" d= efinition, nor the "negative answer". Therefore, i think that either the "N= egative Answer" section should be extended, or a seperate section ("Policy = prohibits answer"?) should be added, with text such as If a server wishes to inform the client that information about the query is= available, but cannot include the information in the response to the clien= t for policy reasons, the server SHOULD respond with an adequate response c= ode out of HTTP's 4xx range. Clients MAY retry the query based on the respe= ctive response code. (I'm trying to say that servers may request authenication [401], might refu= se a client completely [403], ... hmm.. what about 402... ;-) 410 could als= o be useful in certain scenarios, particularly with entities where identifi= ers are not re-used) What's hard to cover is the case where basic information is available with = no authentication, but additional information (such as full entity address = information) would be availabe if the client authenticated. Worse, even, if= the authentication scheme was not HTTP-based (but, for example, based on c= lient certificates, or cookies).. - The security considerations section is missing. - Section 8.1: I do understand that this does not prevent RDAP to use perce= nt-encoded non-ASCII characters in URIs, correct? - Section 8.3: I'm a bit unsure whether the SHOULD in this section violates= RFC2616? Specifically, RFC2616 says " If an Accept-Language header is pre= sent, then all languages which are assigned a quality factor greater than = 0 are acceptable." To me, this says that an Accept-Language header can't be= ignored, because languages not listed are not acceptable? (I understand th= at in practice, it might be desireable to ignore the header - but it would = by tricky for the document to contradict an RFC that is references as norma= tive... - Section 8.3: What about Accept-Encoding and Accept-Charset, which are rel= ated to Accept-Language? tia, Alex Mayrhofer Head of R&D nic.at From shollenbeck@verisign.com Thu Mar 28 07:12:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9E21F8EC6 for ; Thu, 28 Mar 2013 07:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1sCrKzHPGJd for ; Thu, 28 Mar 2013 07:12:24 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id D29E921F8CAE for ; Thu, 28 Mar 2013 07:12:22 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUVRPxbYSHTwnC/9PMfDZcv7mOvuNuhuO@postini.com; Thu, 28 Mar 2013 07:12:24 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r2SECLIn007490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Mar 2013 10:12:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 10:12:20 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Search documents Thread-Index: AQHOK2AMeKSmfVg66k29eJZRVbzo3pi7JaeA Date: Thu, 28 Mar 2013 14:12:17 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24349F8F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F24349F8FBRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:12:25 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24349F8FBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support proceeding this way. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Wednesday, March 27, 2013 10:58 PM To: weirds@ietf.org Subject: [weirds] Search documents The Orlando minutes reflect that we batted around some ideas about how to m= ove forward with documents covering the topic of search, but the issue wasn= 't formally resolved. I'd like to take a moment to have that discussion no= w. The idea I thought had general support based on the working group and some = hallway chatter afterwards is the notion of creating two search documents, = one covering basic or core search syntax and capabilities, and one covering= extended search. John Levine remarked that the former would generally try= to match the search capabilities that WHOIS servers offer now while the la= tter would cover things we'd like to see, and there would be some pressure = to have implementation experience with the proposals of the latter before w= e let the document proceed. Can we get some indications of support or objection to proceeding that way? -MSK --_000_831693C2CDA2E849A7D7A712B24E257F24349F8FBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support proceeding this= way.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, March 27, 2013 10:58 PM
To: weirds@ietf.org
Subject: [weirds] Search documents

 

The Orlando minutes r= eflect that we batted around some ideas about how to move forward with docu= ments covering the topic of search, but the issue wasn't formally resolved.=   I'd like to take a moment to have that discussion now.

The idea I thought ha= d general support based on the working group and some hallway chatter after= wards is the notion of creating two search documents, one covering basic or= core search syntax and capabilities, and one covering extended search.  John Levine remarked that the form= er would generally try to match the search capabilities that WHOIS servers = offer now while the latter would cover things we'd like to see, and there w= ould be some pressure to have implementation experience with the proposals of the latter before we let the document pro= ceed.

Can we get some indic= ations of support or objection to proceeding that way?

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F24349F8FBRN1WNEXMBX01vc_-- From aservin@lacnic.net Thu Mar 28 08:35:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3621F88B0 for ; Thu, 28 Mar 2013 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.618 X-Spam-Level: * X-Spam-Status: No, score=1.618 tagged_above=-999 required=5 tests=[AWL=-4.068, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dsjt0oLY0g0 for ; Thu, 28 Mar 2013 08:35:09 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 503DF21F8461 for ; Thu, 28 Mar 2013 08:35:06 -0700 (PDT) Received: from dhcp100-44-97-107.hil-miama.mia.wayport.net (dhcp100-44-97-107.hil-miama.mia.wayport.net [100.44.97.107]) by mail.lacnic.net.uy (Postfix) with ESMTP id AE1CF30844D for ; Thu, 28 Mar 2013 12:34:43 -0300 (UYT) Message-ID: <51546319.4090105@lacnic.net> Date: Thu, 28 Mar 2013 11:34:49 -0400 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:35:15 -0000 I support this way forward. Regards, as On 3/27/13 10:57 PM, Murray S. Kucherawy wrote: > The Orlando minutes reflect that we batted around some ideas about how > to move forward with documents covering the topic of search, but the > issue wasn't formally resolved. I'd like to take a moment to have that > discussion now. > > The idea I thought had general support based on the working group and > some hallway chatter afterwards is the notion of creating two search > documents, one covering basic or core search syntax and capabilities, > and one covering extended search. John Levine remarked that the former > would generally try to match the search capabilities that WHOIS servers > offer now while the latter would cover things we'd like to see, and > there would be some pressure to have implementation experience with the > proposals of the latter before we let the document proceed. > > Can we get some indications of support or objection to proceeding that way? > > -MSK > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From kranjbar@ripe.net Thu Mar 28 08:42:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B70F21F9023 for ; Thu, 28 Mar 2013 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaHvJ3yZoPSr for ; Thu, 28 Mar 2013 08:42:05 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4B421F8788 for ; Thu, 28 Mar 2013 08:42:05 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ULExn-00069B-Gb; Thu, 28 Mar 2013 16:42:04 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-152.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1ULExn-0003EQ-DI; Thu, 28 Mar 2013 16:42:03 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kaveh Ranjbar In-Reply-To: Date: Thu, 28 Mar 2013 16:42:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" , "weirds@ietf.org" X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130328 clean X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.2 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5b4e144e7fe948d2a5addcca13998f0521 Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:42:06 -0000 I support the proposed path forward. Regards, Kaveh. On Mar 28, 2013, at 3:57 AM, Murray S. Kucherawy = wrote: > The Orlando minutes reflect that we batted around some ideas about how = to move forward with documents covering the topic of search, but the = issue wasn't formally resolved. I'd like to take a moment to have that = discussion now. >=20 > The idea I thought had general support based on the working group and = some hallway chatter afterwards is the notion of creating two search = documents, one covering basic or core search syntax and capabilities, = and one covering extended search. John Levine remarked that the former = would generally try to match the search capabilities that WHOIS servers = offer now while the latter would cover things we'd like to see, and = there would be some pressure to have implementation experience with the = proposals of the latter before we let the document proceed. >=20 > Can we get some indications of support or objection to proceeding that = way? >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Thu Mar 28 11:38:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F57321F8DD6 for ; Thu, 28 Mar 2013 11:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgSU0NgGd40D for ; Thu, 28 Mar 2013 11:38:26 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id D139D21F8DDD for ; Thu, 28 Mar 2013 11:38:25 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 38A402136A3; Thu, 28 Mar 2013 14:38:25 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id B09E8213695; Thu, 28 Mar 2013 14:38:24 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Mar 2013 14:37:43 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 14:38:23 -0400 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-03.txt Thread-Index: AQHOKvRmjBtzFVLKHUSJTFa01DW7kpi6CLWAgAFoOwA= Date: Thu, 28 Mar 2013 18:38:22 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7CB1@CHAXCH01.corp.arin.net> In-Reply-To: <515327AF.3020905@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <0599FF183855E8448702526164C6680B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 18:38:26 -0000 On 3/27/13 1:09 PM, "Jean-Philippe Dionne" wrote: >Hi, > >It is required to have "Security Consideration" section. Some security >measures have already been included in this document (5.5. Rate Limits >and 5.6. Cross-Origin Resource Sharing) while the rest is in >draft-hollenbeck-weirds-rdap-sec-00. Here's some text suggestion: > >" >This document does not pose strong security requirements to the RDAP >protocol. However, it does not restrict against the use of security >mechanisms offerred by the HTTP protocol. > >This document made recommendations for server implementations against >denial-of-service (section 5.5) and interreroperability with existing >security mechanism in HTTP clients (section 5.6). > >Additional security considerations to the RDAP protocol are coverred in >[draft-hollenbeck-weirds-rdap-sec-00]. >" Jean-Philippe, Thanks for pointing out this oversight. I agree with your text, though the last paragraph creates a future reference. Would you be fine with the following: "Additional security considerations to the RDAP protocol will be covered in future RFCs specifying specific security mechanisms and schemes." -andy From jean-philippe.dionne@viagenie.ca Thu Mar 28 12:02:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C2821F9109 for ; Thu, 28 Mar 2013 12:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4U5jwaFDNB5 for ; Thu, 28 Mar 2013 12:02:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2461A21F90BB for ; Thu, 28 Mar 2013 12:02:24 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB3C24048E; Thu, 28 Mar 2013 15:01:49 -0400 (EDT) Message-ID: <5154939D.2010100@viagenie.ca> Date: Thu, 28 Mar 2013 15:01:49 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7CB1@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7CB1@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:02:25 -0000 On 03/28/2013 02:38 PM, Andy Newton wrote: > On 3/27/13 1:09 PM, "Jean-Philippe Dionne" > wrote: > >> Hi, >> >> It is required to have "Security Consideration" section. Some security >> measures have already been included in this document (5.5. Rate Limits >> and 5.6. Cross-Origin Resource Sharing) while the rest is in >> draft-hollenbeck-weirds-rdap-sec-00. Here's some text suggestion: >> >> " >> This document does not pose strong security requirements to the RDAP >> protocol. However, it does not restrict against the use of security >> mechanisms offerred by the HTTP protocol. >> >> This document made recommendations for server implementations against >> denial-of-service (section 5.5) and interreroperability with existing >> security mechanism in HTTP clients (section 5.6). >> >> Additional security considerations to the RDAP protocol are coverred in >> [draft-hollenbeck-weirds-rdap-sec-00]. >> " > > Jean-Philippe, > > Thanks for pointing out this oversight. > > I agree with your text, though the last paragraph creates a future > reference. Would you be fine with the following: > > "Additional security considerations to the RDAP protocol will be covered > in future RFCs specifying specific security mechanisms and schemes." > Hi, I think that's fine. I was puzzled by this future reference too, we must not defer all considerations to a future document. Regards Jean-Philippe From AMaitland@Commerco.Com Thu Mar 28 12:11:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BCF21F8BDD for ; Thu, 28 Mar 2013 12:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws9+sE4jIvmh for ; Thu, 28 Mar 2013 12:11:37 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4035021F8D0D for ; Thu, 28 Mar 2013 12:11:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=X4WIrFQ7fB+cGhEkyj9EvO0nqh1UxjcgIr3A0Z6xebRWyN+5l2UwheI8Xr6j7BoI27G+Z/7eL7QauywBtwvnckiugOj2lz95QlnSg119H9X37JgVXbKpocScJkRXJk87NnteokSbStBC8u/ipGP0EHKy38U6nF5lmkOV4pmkmSY= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]) for ; Thu, 28 Mar 2013 19:11:19 +0000 Message-ID: <515495D1.8070807@Commerco.Com> Date: Thu, 28 Mar 2013 13:11:13 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:11:39 -0000 This appears to make good sense. On 3/27/2013 8:57 PM, Murray S. Kucherawy wrote: > The Orlando minutes reflect that we batted around some ideas about how > to move forward with documents covering the topic of search, but the > issue wasn't formally resolved. I'd like to take a moment to have that > discussion now. > > The idea I thought had general support based on the working group and > some hallway chatter afterwards is the notion of creating two search > documents, one covering basic or core search syntax and capabilities, > and one covering extended search. John Levine remarked that the former > would generally try to match the search capabilities that WHOIS servers > offer now while the latter would cover things we'd like to see, and > there would be some pressure to have implementation experience with the > proposals of the latter before we let the document proceed. > > Can we get some indications of support or objection to proceeding that way? > > -MSK > Could or should the registries then choose to implement their wierds systems in a phased approach? In other words, if registries were to roll wierds using the two document strategy, then the whois functionality gets replaced and people can begin to develop and test implementations of the "whois like" wierds client code, which presumably would be a bit easier to implement. This strategy might suggest a first document being a wierds v1.0 spec with the second being a wierds v1.1 spec, but releasing both specs pretty much in coterminous manner and referencing each other, with the understanding that implementers are not fully wierds compliant unless and until they have rolled out their v1.1 service. Is that the idea? Alan From andy@arin.net Thu Mar 28 12:13:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3F21F8FD1 for ; Thu, 28 Mar 2013 12:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYEbu2KS6bco for ; Thu, 28 Mar 2013 12:13:45 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4A21F8F0B for ; Thu, 28 Mar 2013 12:13:44 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 75ADA165274; Thu, 28 Mar 2013 15:13:44 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 71351165278; Thu, 28 Mar 2013 15:13:41 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Mar 2013 15:13:19 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 15:13:37 -0400 From: Andy Newton To: Alexander Mayrhofer , "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4rq8gkQGdqA1SD+02gDEqb/EAX/wAPI/qA Date: Thu, 28 Mar 2013 19:13:36 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7D69@CHAXCH01.corp.arin.net> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982EF4D@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <893525E75DC8364E8C5A0D2EB05343EE@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:13:45 -0000 Alexander, My responses are in-line: On 3/28/13 8:32 AM, "Alexander Mayrhofer" wrote: >- Title: If i would start the document, i would have called it "HTTP >usage in RDAP" instead of the other way around [might be personal taste, >though] >- Abstract: "usage" and "using" in the same sentence sounds weird(s) to >me [but English is not my first language] The title change works, and I'll work on the abstract. > >- Introduction: Would change first sentence into "... describes the >RESTful usage of HTTP .... running on web servers...", since i the >RESTfulness is imho a property of the HTTP usage, rather then the HTTP >server (as the technical contraption that's being used for RESTful usage). > >- Intorduction: The last paragraph would probably fit better before the >"basic usage pattern" bullet list? > >- Introduction, 3rd bullet point: use "HTTP(s) URL" instead of "HTTP URL"? > >- Introduction: Additional bullet point that servers can refuse queries >for policy reasons with response code out of the 4xx range (eg. 403, 429) All of these make sense. > >- Section 4.1: I understand that clients not designating themselves as >"RDAP clients" may still send Accept: headers - correct? That is correct. The intent is that one of the URLs could be plugged into a web browser, which probably defaults to asking for HTML, and that the server could respond appropriately. >- Section 4.2: Add text about *known* query parameters, since the Section >title says "Query Parameters" in general? Eg. that they are defined in >the respective protocol-level document... Implementors need to understand >how to identify the set of "unknown" parameters. I think this is a code point. >- Section 5: The "Negative Answer" section only describes the case where >the server has no information about the query. However, there's no text >about the case where the server wishes to respond that it *has* the >requested information, but cannot return it due to server policy for the >specific client (for example, that [additional] authentication is >required in order to retrieve the information - or the client ip range >has been blocked because if misuse of the service). This case does >neither fit the "positive answer" definition, nor the "negative answer". >Therefore, i think that either the "Negative Answer" section should be >extended, or a seperate section ("Policy prohibits answer"?) should be >added, with text such as > >If a server wishes to inform the client that information about the query >is available, but cannot include the information in the response to the >client for policy reasons, the server SHOULD respond with an adequate >response code out of HTTP's 4xx range. Clients MAY retry the query based >on the respective response code. > >(I'm trying to say that servers may request authenication [401], might >refuse a client completely [403], ... hmm.. what about 402... ;-) 410 >could also be useful in certain scenarios, particularly with entities >where identifiers are not re-used) > >What's hard to cover is the case where basic information is available >with no authentication, but additional information (such as full entity >address information) would be availabe if the client authenticated. >Worse, even, if the authentication scheme was not HTTP-based (but, for >example, based on client certificates, or cookies).. I think this makes sense. Thanks for the text. >- The security considerations section is missing. Jean-Philippe has suggested text for that. Please see his email. >- Section 8.1: I do understand that this does not prevent RDAP to use >percent-encoded non-ASCII characters in URIs, correct? Correct. > >- Section 8.3: I'm a bit unsure whether the SHOULD in this section >violates RFC2616? Specifically, RFC2616 says " If an Accept-Language >header is present, then all languages which are assigned a quality >factor greater than 0 are acceptable." To me, this says that an >Accept-Language header can't be ignored, because languages not listed are >not acceptable? (I understand that in practice, it might be desireable to >ignore the header - but it would by tricky for the document to contradict >an RFC that is references as normative... That last sentence should probably be changed from "when formulating response" to "when formulating HTTP entity responses". This section says that the Accept-Language header does not influence the JSON responses. This was the decision of the working group following the meeting in Atlanta. >- Section 8.3: What about Accept-Encoding and Accept-Charset, which are >related to Accept-Language? I'm torn between the need to say anything about these or not. Servers are free to support any encoding/charset so long as the support UTF-8 with our JSON responses. What would you suggest. -andy From alexander.mayrhofer@nic.at Thu Mar 28 12:56:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4332421F8D5F for ; Thu, 28 Mar 2013 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.13 X-Spam-Level: X-Spam-Status: No, score=-9.13 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9Ql59gci35Z for ; Thu, 28 Mar 2013 12:56:26 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4054421F8D0E for ; Thu, 28 Mar 2013 12:56:25 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Thu, 28 Mar 2013 20:56:24 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Thu, 28 Mar 2013 20:56:23 +0100 From: Alexander Mayrhofer To: Andy Newton , "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4rq8gkSNvk1hNaQbSOOMrrX6LYdAANC68AAANPaOA= Date: Thu, 28 Mar 2013 19:56:22 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982F138@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE0750982EF4D@NICS-EXCH.sbg.nic.at> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7D69@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7D69@CHAXCH01.corp.arin.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:56:27 -0000 Andy, thanks for the quick feedback. Please take my comments as suggestions rathe= r than blocking issues (didn't clarify that). Comments on some points inlin= e: [...] > >- Section 8.3: I'm a bit unsure whether the SHOULD in this section > >violates RFC2616? Specifically, RFC2616 says " If an Accept-Language > >header is present, then all languages which are assigned a quality > >factor greater than 0 are acceptable." To me, this says that an > >Accept-Language header can't be ignored, because languages not listed > >are not acceptable? (I understand that in practice, it might be > >desireable to ignore the header - but it would by tricky for the > >document to contradict an RFC that is references as normative... >=20 > That last sentence should probably be changed from "when formulating > response" to "when formulating HTTP entity responses". This section says > that the Accept-Language header does not influence the JSON responses. > This was the decision of the working group following the meeting in Atlan= ta. [Alexander Mayrhofer]=20 Ok, fine with me if that was the decision of the WG - honestly, i didn't ev= en read the minutes - sorry! > >- Section 8.3: What about Accept-Encoding and Accept-Charset, which are > >related to Accept-Language? >=20 > I'm torn between the need to say anything about these or not. Servers are > free to support any encoding/charset so long as the support UTF-8 with ou= r > JSON responses. What would you suggest. [Alexander Mayrhofer]=20 Well, obviously the Accept-Language has more of a "user-visible" implicatio= n on the presentation of the content, while the Encoding and Charset negoti= ation happens mostly behind the scenes - therefore i guess that most people= focus on the Language negotiation only. I'm fine with not saying anything about Encoding and Charset, if the author= s (and WGs) accept that this means the normal negotiation mechanisms of HTT= P apply.=20 thanks, Alex From andy@arin.net Thu Mar 28 14:28:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1308B21F9007 for ; Thu, 28 Mar 2013 14:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q7sTKslCyww for ; Thu, 28 Mar 2013 14:28:07 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8221F9001 for ; Thu, 28 Mar 2013 14:28:07 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 1D00C1652A0; Thu, 28 Mar 2013 17:28:07 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 5A55A16528D; Thu, 28 Mar 2013 17:28:06 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Mar 2013 17:27:25 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 17:28:05 -0400 From: Andy Newton To: Alexander Mayrhofer , "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: AW: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4rq8gkQGdqA1SD+02gDEqb/EAX/wAPI/qAAAngSAD//9aQAA== Date: Thu, 28 Mar 2013 21:28:05 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7EF4@CHAXCH01.corp.arin.net> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F138@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.34.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <468DE235DDD96746818226EF3C83B277@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:28:08 -0000 On 3/28/13 3:56 PM, "Alexander Mayrhofer" wrote: > >[Alexander Mayrhofer] >Well, obviously the Accept-Language has more of a "user-visible" >implication on the presentation of the content, while the Encoding and >Charset negotiation happens mostly behind the scenes - therefore i guess >that most people focus on the Language negotiation only. > >I'm fine with not saying anything about Encoding and Charset, if the >authors (and WGs) accept that this means the normal negotiation >mechanisms of HTTP apply. In my opinion that's what it means. But other feedback would be helpful. Thanks Alexander. -andy From andy@arin.net Thu Mar 28 14:29:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0F21F9001 for ; Thu, 28 Mar 2013 14:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-+Rc0eyrrvA for ; Thu, 28 Mar 2013 14:29:54 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 9958621F8FD1 for ; Thu, 28 Mar 2013 14:29:54 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 4973F1652A8; Thu, 28 Mar 2013 17:29:54 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id BE57216529F; Thu, 28 Mar 2013 17:29:53 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Mar 2013 17:29:34 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 17:29:52 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Search documents Thread-Index: AQHOK2AjtMRBPdqICkairG2vBzvmL5i7n/2A Date: Thu, 28 Mar 2013 21:29:52 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF7F19@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.34.130] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF7F19CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:29:56 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF7F19CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Wednesday, March 27, 2013 10:57 PM To: "weirds@ietf.org" > Subject: [weirds] Search documents The Orlando minutes reflect that we batted around some ideas about how to m= ove forward with documents covering the topic of search, but the issue wasn= 't formally resolved. I'd like to take a moment to have that discussion no= w. The idea I thought had general support based on the working group and some = hallway chatter afterwards is the notion of creating two search documents, = one covering basic or core search syntax and capabilities, and one covering= extended search. John Levine remarked that the former would generally try= to match the search capabilities that WHOIS servers offer now while the la= tter would cover things we'd like to see, and there would be some pressure = to have implementation experience with the proposals of the latter before w= e let the document proceed. Can we get some indications of support or objection to proceeding that way? -MSK I'm support having two documents, one for basic/core search and one for adv= anced/extended search. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF7F19CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <153F3CD9E45B114A9F1A90BF603AD2C1@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Wednesday, March 27, 2013 10:= 57 PM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Search documents<= br>

The Orlando minutes reflect that we batted around some ideas about how= to move forward with documents covering the topic of search, but the issue= wasn't formally resolved.  I'd like to take a moment to have that dis= cussion now.

The idea I thought had general support based on the working group and some = hallway chatter afterwards is the notion of creating two search documents, = one covering basic or core search syntax and capabilities, and one covering= extended search.  John Levine remarked that the former would generally try to match the search capabilities that = WHOIS servers offer now while the latter would cover things we'd like to se= e, and there would be some pressure to have implementation experience with = the proposals of the latter before we let the document proceed.

Can we get some indications of support or objection to proceeding that= way?

-MSK

I'm support having two documents, one for basic/core search and one fo= r advanced/extended search.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF7F19CHAXCH01corpari_-- From pieter.vandepitte@dns.be Thu Mar 28 14:43:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B3021F8E63 for ; Thu, 28 Mar 2013 14:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmeiPF6BYbPS for ; Thu, 28 Mar 2013 14:43:46 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 681A421F8D0D for ; Thu, 28 Mar 2013 14:43:43 -0700 (PDT) Received: from [192.168.0.142] (d54C282F1.access.telenet.be [84.194.130.241]) by nug.nucleus.be (Postfix) with ESMTPSA id 748594260006 for ; Thu, 28 Mar 2013 22:43:41 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pieter Vandepitte In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982EF4D@NICS-EXCH.sbg.nic.at> Date: Thu, 28 Mar 2013 22:43:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19F54F2956911544A32543B8A9BDE0750982EF4D@NICS-EXCH.sbg.nic.at> To: weirds@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:43:47 -0000 Hi, First of all, to all people actively involved in this working draft: = congratulations!=20 All my remarks are rather small, are more or less a matter of taste and = don't contribute to the fundamental stuff of the working draft. That being said, here are my remarks and comments On 28 Mar 2013, at 13:32, Alexander Mayrhofer = wrote: > I've taken the opportunity of the WGLC to perform a review of the = using-http draft (i haven't followed all discussions during the = development of this draft, so some of my points might have been = discussed before, or are too late in the process): >=20 > - Title: If i would start the document, i would have called it "HTTP = usage in RDAP" instead of the other way around [might be personal taste, = though] IMHO the current title fits best, but that's a matter of taste as you = suggested. My personal favourite for example is "HTTP Binding for RDAP" > - Abstract: "usage" and "using" in the same sentence sounds weird(s) = to me [but English is not my first language] Agree, suggestions for a better abstract? Based on my favourite title, I = would suggest: "This document describes a HTTP binding for the RDAP = protocol" (but that doesn't add much value to my proposed title) >=20 > - Introduction: Would change first sentence into "... describes the = RESTful usage of HTTP .... running on web servers...", since i the = RESTfulness is imho a property of the HTTP usage, rather then the HTTP = server (as the technical contraption that's being used for RESTful = usage). =85 describes a RESTful API over HTTP. [period] 'Web servers' is = redundant to me (I like short and clear protocols without too much = clutter) >=20 > - Intorduction: The last paragraph would probably fit better before = the "basic usage pattern" bullet list? >=20 > - Introduction, 3rd bullet point: use "HTTP(s) URL" instead of "HTTP = URL"? What about: URL instead of HTTP URL. I would not restrict the scheme to = http or https. Suppose next week there's a new standard HTTPVS ( very = secure ) then this RFC is outdated. Or suppose a new RDAP binding is = being developed (e.g. RDAP over FTP), one could redirect to an FTP URL = (I don't think there's a restriction on scheme for the location header) >=20 > - Introduction: Additional bullet point that servers can refuse = queries for policy reasons with response code out of the 4xx range (eg. = 403, 429) +1 >=20 > - Section 4.1: I understand that clients not designating themselves as = "RDAP clients" may still send Accept: headers - correct? >=20 > - Section 4.2: Add text about *known* query parameters, since the = Section title says "Query Parameters" in general? Eg. that they are = defined in the respective protocol-level document... Implementors need = to understand how to identify the set of "unknown" parameters. >=20 > - Section 5: The "Negative Answer" section only describes the case = where the server has no information about the query. However, there's no = text about the case where the server wishes to respond that it *has* the = requested information, but cannot return it due to server policy for the = specific client (for example, that [additional] authentication is = required in order to retrieve the information - or the client ip range = has been blocked because if misuse of the service). This case does = neither fit the "positive answer" definition, nor the "negative answer". = Therefore, i think that either the "Negative Answer" section should be = extended, or a seperate section ("Policy prohibits answer"?) should be = added, with text such as >=20 > If a server wishes to inform the client that information about the = query is available, but cannot include the information in the response = to the client for policy reasons, the server SHOULD respond with an = adequate response code out of HTTP's 4xx range. Clients MAY retry the = query based on the respective response code. >=20 > (I'm trying to say that servers may request authenication [401], might = refuse a client completely [403], ... hmm.. what about 402... ;-) 410 = could also be useful in certain scenarios, particularly with entities = where identifiers are not re-used) >=20 > What's hard to cover is the case where basic information is available = with no authentication, but additional information (such as full entity = address information) would be availabe if the client authenticated. = Worse, even, if the authentication scheme was not HTTP-based (but, for = example, based on client certificates, or cookies).. >=20 > - The security considerations section is missing. >=20 > - Section 8.1: I do understand that this does not prevent RDAP to use = percent-encoded non-ASCII characters in URIs, correct? >=20 > - Section 8.3: I'm a bit unsure whether the SHOULD in this section = violates RFC2616? Specifically, RFC2616 says " If an Accept-Language = header is present, then all languages which are assigned a quality = factor greater than 0 are acceptable." To me, this says that an = Accept-Language header can't be ignored, because languages not listed = are not acceptable? (I understand that in practice, it might be = desireable to ignore the header - but it would by tricky for the = document to contradict an RFC that is references as normative... >=20 > - Section 8.3: What about Accept-Encoding and Accept-Charset, which = are related to Accept-Language? Agree on all of this 5.2. Redirects There are several redirect http response codes: 301, 302, 307 and 308. = The last two are more or less the equivalents of the first two, except = that they do not allow the the client to change the request method = (could be important if there would be POST, PUT,=85 RDAP methods in the = future) The sentence "In other words, when generating the redirect url, the = server will only alter the base of the URL. It will not attempt to = normalize or modify the path segment." =3D> Shouldn't that be: "The path segment of the URL MAY be appended = with a redirect info if none is provided or MUST be altered to reflect = the redirect status in case the URL contains redirect info as specified = in draft-ietf-weirds-redirects" ?=20 5.3 Negative Answers I only recently followed the list, but I can imagine there have been = long debates about MUST, SHOULD, =85.: "it SHOULD return a 404 response = code" =3D> SHOULDn't that be a MUST? Or do situations exist where a = server can ignore this recommendation and do it's own thing? same for 5.4 8.2. Language Identifiers in Queries and Responses What do we mean with "the data should be annotated with language = identifiers"? HTTP response headers like Content-Language and = Content-Type (with its charset parameter)? Shouldn't we mention them? = And aren't 8.2 and 8.3 strongly related and shouldn't these two sections = be merged? Additional remarks: * What about the recent discussion on Search documents. i.e. searching = and returning multiple results: then the first design intent ( 3. Design = Intents) doesn't hold anymore. Can't we relax this statement? * The link to http://www.w3.org/TR/2012/WD-cors-20130129 doesn't work. = http://www.w3.org/TR/2013/CR-cors-20130129/ or = http://www.w3.org/TR/cors/ (but dangerous to link to the latest version = i suppose) kr, Pieter= From maarten.wullink@sidn.nl Thu Mar 28 15:04:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2A321F8EE6 for ; Thu, 28 Mar 2013 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXYAVdzVU3Fu for ; Thu, 28 Mar 2013 15:04:27 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4C21F8ED6 for ; Thu, 28 Mar 2013 15:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=GVxC6Q231rxRfQ1CFNa1SEJNG+FbAk7/On6TZrZmaWg=; b=BYEHNcwF3GcUsFiL6dP8xkVaLIYsopyGK2i4iLBpJTpWUkRmJx/LOjE9Um4hS3wfIxxg6yx93rorZCs0l1Z50zDjFCfR637qM+lj6iHq72YYWkT+owVz4SEwbGZbc54hmfFSfKc7vL3YlMCCJmiNTQFscoLZF9Fecx6xOdFMeXQ= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r2SM4PTa011451-r2SM4PTc011451 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 28 Mar 2013 23:04:25 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 23:04:25 +0100 From: Maarten Wullink To: "'Murray S. Kucherawy'" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwueNOzJerUevUuVl+0s7SqmJ5i7qG7A Date: Thu, 28 Mar 2013 22:04:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:04:28 -0000 Here's my 2 cents Versioning: I am missing a section about api versioning, it might be desirable for a cl= ient to signal the server which version of the api it would like to use. Th= is would enable registries to add new features to the server code in a back= wards compatible way. =20 This could be done by integrating the version in the url, like: example.com/weirds/v1.0/domain/weird.com or by using the MIME type for this= . The client could also add the version identifier to the accept header lik= e: Accept: application/rdap+json;version=3D2 4.1 Accept header=20 " This specification does not define the responses a server returns to a request with any other media types in the Accept: header, or with no Accept: header. One possibility would be to return a response in a media type suitable for rendering in a web browser."=20 It would be useful if the server always returns the result in rdap+json for= mat if the client has not specified the requested type with the Accept head= er. The json reponse should be the default response type, this way the cli= ent would not have to retry the request. This would prevent needless querie= s. 5.1 Positive answers " it SHOULD encode the answer in the format most appropriate according to the standard and defined rules for processing the HTTP Accept header, and return that answer in the body of a 200 response." I would change this to "it MUST encode the answer"=20 The server MUST use the type specified by the client in the Accept header, = unless the server has no support for the type. 5.2 Redirects "If a server wishes to inform a client that the answer to a given query can be found elsewhere, it SHOULD return either a 301 or a 307 response code and an HTTP URL in the Location: header. The client is expected to issue a subsequent query using the given URL without any processing of the URL. " The "subsequent query" implies that any query after the 301 or 307 response= must be sent to the url found in the Location header. This is only the cas= e for the original query. a subsequent query could also be an entirely diff= erent query for which this does not apply.=20 I would change it to: "The query for which a 301 or 307 response has been r= eceived MUST be retried at the URL found in the Location: header." =20 5.3 Negative answers "If a server wishes to respond that it has no information regarding the que= ry, it SHOULD return a 404 response code. Optionally, it MAY include addit= ional information regarding the negative answer in the HTTP entity body."=20 This will introduce an ambiguous situation if the server does not add addit= ional information to the 404 response it is not possible for the client to = dermine which of the following situations applies: a) The url for the restful resource is incorrect and the error is from the = http protocol b) the restful url is a correct url but the resource it points to does not = exists in the registry database. There are multiple ways to fix this ambiguity the simplest would be to requ= ire the server to always send additional explanatory information with a 404= response. Therefore change "it MAY include additional information regarding the negat= ive answer in the HTTP entity body." To: "it MUST include additional information regarding the negative answer i= n the HTTP entity body." 7.1. RDAP Extensions Registry This would require each registry to register probably multiple json extensi= on identifiers with iana? Would it not be easier to create a RESTful resource for the extension used = by the server, the client can then query this resource to discover the exte= nsion(s) supported by the server? 8.3. Language Identifiers in HTTP Headers Given the description of the use of language identifiers in Section 8.2, un= less otherwise specified servers SHOULD ignore the HTTP [RFC2616] Accept-La= nguage header when formulating responses. At the .nl ccTLD we currently have a whois service which supports multiple = languages, the client can request the desired response luangue with the acc= ept-language header in the request. This should be changed to something like: "The server MUST return a respons= e encoded in the language requested by the client. Unless the server has no= support for the client. Cheers, Maarten From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: woensdag 27 maart 2013 17:53 To: weirds@ietf.org Subject: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Colleagues, We would like to initiate a two-week Working Group Last Call on draft-ietf-= weirds-http.=A0 A version 03 was just pushed to the datatracker: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ Last call will end Wednesday, April 10th. Please review and comment on the draft, even if it is only to say on the re= cord "I have reviewed this document thoroughly and it looks good."=A0 We wo= uld like to have no fewer than five people report that they have taken a lo= ok at the whole document and reported their findings, and will be reticent = to send it to the IESG without that.=A0 We're also keen to hear from people= that have implemented the specification as to their views on clarity, corr= ectness, and completeness. Thanks, -MSK and Olaf, your co-chairs From pieter.vandepitte@dns.be Thu Mar 28 15:33:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1821F8EFD for ; Thu, 28 Mar 2013 15:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdGdo+4RBVpA for ; Thu, 28 Mar 2013 15:33:38 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id E12F221F8F1F for ; Thu, 28 Mar 2013 15:33:34 -0700 (PDT) Received: from [192.168.0.142] (d54C282F1.access.telenet.be [84.194.130.241]) by nug.nucleus.be (Postfix) with ESMTPSA id 499274260006 for ; Thu, 28 Mar 2013 23:33:33 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pieter Vandepitte In-Reply-To: Date: Thu, 28 Mar 2013 23:33:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <089965E4-681B-4D5A-BFE8-116CC8E9EDA1@dns.be> References: To: "weirds@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:33:39 -0000 And I was thinking right away of something else: wouldn't it be a good = idea to introduce a HEAD method? A lot of / some registries currently = have some kind of Domain Availability Service which simply returns = whether the domain which is looked up, is still available (yes or no). A = "HEAD /domains/example.com" would e.g. return a "200 OK" if the domain = name exists, and a "404 NOT FOUND" if the domain name is still available = (i.e. the same result code as if the client performed a GET) Okay, this could questionably be called REST, but this feature could be = useful for registrars or other instances to have a uniform way to = anonymously check whether a domain name is still available for different = TLD's (by performing some kind of distributed query) Just thinking out loud... Pieter On 28 Mar 2013, at 23:04, Maarten Wullink = wrote: > Here's my 2 cents >=20 > Versioning: > I am missing a section about api versioning, it might be desirable for = a client to signal the server which version of the api it would like to = use. This would enable registries to add new features to the server code = in a backwards compatible way. >=20 > This could be done by integrating the version in the url, like: > example.com/weirds/v1.0/domain/weird.com or by using the MIME type for = this. The client could also add the version identifier to the accept = header like: Accept: application/rdap+json;version=3D2 >=20 >=20 > 4.1 Accept header=20 > " This specification does not define the responses a server returns to > a request with any other media types in the Accept: header, or with > no Accept: header. One possibility would be to return a response in > a media type suitable for rendering in a web browser."=20 >=20 > It would be useful if the server always returns the result in = rdap+json format if the client has not specified the requested type with = the Accept header. The json reponse should be the default response type, = this way the client would not have to retry the request. This would = prevent needless queries. >=20 >=20 > 5.1 Positive answers > " it SHOULD encode the answer in the format most appropriate according > to the standard and defined rules for processing the HTTP Accept > header, and return that answer in the body of a 200 response." >=20 > I would change this to "it MUST encode the answer"=20 > The server MUST use the type specified by the client in the Accept = header, unless the server has no support for the type. >=20 >=20 > 5.2 Redirects > "If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it SHOULD return either a 301 or a 307 > response code and an HTTP URL in the Location: header. The client = is > expected to issue a subsequent query using the given URL without any > processing of the URL. " >=20 > The "subsequent query" implies that any query after the 301 or 307 = response must be sent to the url found in the Location header. This is = only the case for the original query. a subsequent query could also be = an entirely different query for which this does not apply.=20 >=20 > I would change it to: "The query for which a 301 or 307 response has = been received MUST be retried at the URL found in the Location: header." = =20 >=20 >=20 > 5.3 Negative answers > "If a server wishes to respond that it has no information regarding = the query, it SHOULD return a 404 response code. Optionally, it MAY = include additional information regarding the negative answer in the HTTP = entity body."=20 >=20 > This will introduce an ambiguous situation if the server does not add = additional information to the 404 response it is not possible for the = client to dermine which of the following situations applies: >=20 > a) The url for the restful resource is incorrect and the error is from = the http protocol > b) the restful url is a correct url but the resource it points to does = not exists in the registry database. >=20 > There are multiple ways to fix this ambiguity the simplest would be to = require the server to always send additional explanatory information = with a 404 response. >=20 > Therefore change "it MAY include additional information regarding the = negative answer in the HTTP entity body." >=20 > To: "it MUST include additional information regarding the negative = answer in the HTTP entity body." >=20 >=20 > 7.1. RDAP Extensions Registry >=20 > This would require each registry to register probably multiple json = extension identifiers with iana? > Would it not be easier to create a RESTful resource for the extension = used by the server, the client can then query this resource to discover = the extension(s) supported by the server? >=20 >=20 > 8.3. Language Identifiers in HTTP Headers >=20 > Given the description of the use of language identifiers in Section = 8.2, unless otherwise specified servers SHOULD ignore the HTTP [RFC2616] = Accept-Language header when formulating responses. >=20 > At the .nl ccTLD we currently have a whois service which supports = multiple languages, the client can request the desired response luangue = with the accept-language header in the request. >=20 > This should be changed to something like: "The server MUST return a = response encoded in the language requested by the client. Unless the = server has no support for the client. >=20 >=20 > Cheers, >=20 > Maarten >=20 >=20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf Of Murray S. Kucherawy > Sent: woensdag 27 maart 2013 17:53 > To: weirds@ietf.org > Subject: [weirds] Working Group Last Call: = draft-ietf-weirds-using-http >=20 > Colleagues, >=20 > We would like to initiate a two-week Working Group Last Call on = draft-ietf-weirds-http. A version 03 was just pushed to the = datatracker: >=20 > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > Last call will end Wednesday, April 10th. >=20 > Please review and comment on the draft, even if it is only to say on = the record "I have reviewed this document thoroughly and it looks good." = We would like to have no fewer than five people report that they have = taken a look at the whole document and reported their findings, and will = be reticent to send it to the IESG without that. We're also keen to = hear from people that have implemented the specification as to their = views on clarity, correctness, and completeness. >=20 > Thanks, > -MSK and Olaf, your co-chairs > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From pieter.vandepitte@dns.be Thu Mar 28 15:44:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0C21F8F0B for ; Thu, 28 Mar 2013 15:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-SqA9mJ-kGA for ; Thu, 28 Mar 2013 15:43:58 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id CA41D21F8ED6 for ; Thu, 28 Mar 2013 15:43:57 -0700 (PDT) Received: from [192.168.0.142] (d54C282F1.access.telenet.be [84.194.130.241]) by nug.nucleus.be (Postfix) with ESMTPSA id C85D04260022; Thu, 28 Mar 2013 23:43:55 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Pieter Vandepitte In-Reply-To: Date: Thu, 28 Mar 2013 23:43:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <091DC631-5F39-4A98-A250-329208B67984@dns.be> References: To: Maarten Wullink X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:44:00 -0000 On versioning: this is indeed something what's missing. Good point. The option to put the version in the URL is OK only if there's a = version-less URL redirecting to the latest version api: a client should = not know in advance which version a server supports (in an ideal world). = Let's hope newer versions will be backwards compatible ;-) Pieter On 28 Mar 2013, at 23:04, Maarten Wullink = wrote: > Here's my 2 cents >=20 > Versioning: > I am missing a section about api versioning, it might be desirable for = a client to signal the server which version of the api it would like to = use. This would enable registries to add new features to the server code = in a backwards compatible way. >=20 > This could be done by integrating the version in the url, like: > example.com/weirds/v1.0/domain/weird.com or by using the MIME type for = this. The client could also add the version identifier to the accept = header like: Accept: application/rdap+json;version=3D2 >=20 >=20 > 4.1 Accept header=20 > " This specification does not define the responses a server returns to > a request with any other media types in the Accept: header, or with > no Accept: header. One possibility would be to return a response in > a media type suitable for rendering in a web browser."=20 >=20 > It would be useful if the server always returns the result in = rdap+json format if the client has not specified the requested type with = the Accept header. The json reponse should be the default response type, = this way the client would not have to retry the request. This would = prevent needless queries. >=20 >=20 > 5.1 Positive answers > " it SHOULD encode the answer in the format most appropriate according > to the standard and defined rules for processing the HTTP Accept > header, and return that answer in the body of a 200 response." >=20 > I would change this to "it MUST encode the answer"=20 > The server MUST use the type specified by the client in the Accept = header, unless the server has no support for the type. >=20 >=20 > 5.2 Redirects > "If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it SHOULD return either a 301 or a 307 > response code and an HTTP URL in the Location: header. The client = is > expected to issue a subsequent query using the given URL without any > processing of the URL. " >=20 > The "subsequent query" implies that any query after the 301 or 307 = response must be sent to the url found in the Location header. This is = only the case for the original query. a subsequent query could also be = an entirely different query for which this does not apply.=20 >=20 > I would change it to: "The query for which a 301 or 307 response has = been received MUST be retried at the URL found in the Location: header." = =20 >=20 >=20 > 5.3 Negative answers > "If a server wishes to respond that it has no information regarding = the query, it SHOULD return a 404 response code. Optionally, it MAY = include additional information regarding the negative answer in the HTTP = entity body."=20 >=20 > This will introduce an ambiguous situation if the server does not add = additional information to the 404 response it is not possible for the = client to dermine which of the following situations applies: >=20 > a) The url for the restful resource is incorrect and the error is from = the http protocol > b) the restful url is a correct url but the resource it points to does = not exists in the registry database. >=20 > There are multiple ways to fix this ambiguity the simplest would be to = require the server to always send additional explanatory information = with a 404 response. >=20 > Therefore change "it MAY include additional information regarding the = negative answer in the HTTP entity body." >=20 > To: "it MUST include additional information regarding the negative = answer in the HTTP entity body." >=20 >=20 > 7.1. RDAP Extensions Registry >=20 > This would require each registry to register probably multiple json = extension identifiers with iana? > Would it not be easier to create a RESTful resource for the extension = used by the server, the client can then query this resource to discover = the extension(s) supported by the server? >=20 >=20 > 8.3. Language Identifiers in HTTP Headers >=20 > Given the description of the use of language identifiers in Section = 8.2, unless otherwise specified servers SHOULD ignore the HTTP [RFC2616] = Accept-Language header when formulating responses. >=20 > At the .nl ccTLD we currently have a whois service which supports = multiple languages, the client can request the desired response luangue = with the accept-language header in the request. >=20 > This should be changed to something like: "The server MUST return a = response encoded in the language requested by the client. Unless the = server has no support for the client. >=20 >=20 > Cheers, >=20 > Maarten >=20 >=20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf Of Murray S. Kucherawy > Sent: woensdag 27 maart 2013 17:53 > To: weirds@ietf.org > Subject: [weirds] Working Group Last Call: = draft-ietf-weirds-using-http >=20 > Colleagues, >=20 > We would like to initiate a two-week Working Group Last Call on = draft-ietf-weirds-http. A version 03 was just pushed to the = datatracker: >=20 > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > Last call will end Wednesday, April 10th. >=20 > Please review and comment on the draft, even if it is only to say on = the record "I have reviewed this document thoroughly and it looks good." = We would like to have no fewer than five people report that they have = taken a look at the whole document and reported their findings, and will = be reticent to send it to the IESG without that. We're also keen to = hear from people that have implemented the specification as to their = views on clarity, correctness, and completeness. >=20 > Thanks, > -MSK and Olaf, your co-chairs > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Thu Mar 28 17:39:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFA121F87FB for ; Thu, 28 Mar 2013 17:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.899 X-Spam-Level: X-Spam-Status: No, score=-110.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_44=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u09AW49+J0jg for ; Thu, 28 Mar 2013 17:38:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB621F87D0 for ; Thu, 28 Mar 2013 17:38:58 -0700 (PDT) Received: (qmail 85119 invoked from network); 29 Mar 2013 00:38:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 00:38:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5154e29f.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=aqEzpQaph2SbIfY04iCkZmgDUuVm67Z6aZ9eAOmkl+I=; b=nLTP68SLTn9aHqquL8bLs1qmcx8VEuduSPrf+4bstDkVF3aU6SkG6AAdgySeH4SwsyEe2gzmr/sfQFCAnrkPZcht4kRe17gye78eY1DJ456rQ/VtOo4G03y1+ttBCW4I/zYDdFpnMX8HLE+E59CuYVuNmbkYxjLzSyUenR/DzdQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5154e29f.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=aqEzpQaph2SbIfY04iCkZmgDUuVm67Z6aZ9eAOmkl+I=; b=DMibdoEbYXr7gLKxQ00G5g4FshQtnTfLu34rx1VYk5oZJ7IBVnNzXLkxvOhEfLkA3sEYV/kYYTWGHEctCFdajmc4WbFNxIPCzSwMkTrlbqBTDbtDcJ9UUDcF+vL4w0nVgOpfmLbKM1l+BfqO0mX+Ygnes+hgiieoKEsCCDSdlyA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 00:38:33 -0000 Message-ID: <20130329003833.3256.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 00:39:00 -0000 Not to be unduly negative, but these are not good ideas. >Versioning: We're carefully making this design extensible, with ways to put added stuff in the json and so forth. If we fail so badly that we need to start over with an incompatible version 2,0, I would very much prefer that the new version uses different URLs, so the existing 1.0 clients don't break. >I am missing a section about api versioning, it might be desirable for a >client to signal the server which version of the api it would like to >use. Good lord no. There lies major interop failures. We define one spec and tell people to implement that. >It would be useful if the server always returns the result in rdap+json >format if the client has not specified the requested type with the >Accept header. No. A client that doesn't send an Accept: header is not an rdap client, so it makes sense to return a generic format that a generic client (e.g. a web browser) can render. >The "subsequent query" implies that any query after the 301 or 307 >response must be sent to the url found in the Location header. This is >only the case for the original query. a subsequent query could also be >an entirely different query for which this does not apply. This sits on top of http, that's part of the http semantics of 3xx responses. It is not good standards design to try to reiterate stuff defined in another spec, since the two versions never quite match. >5.3 Negative answers > >This will introduce an ambiguous situation if the server does not add >additional information to the 404 response it is not possible for the >client to dermine which of the following situations applies: > >a) The url for the restful resource is incorrect and the error is from >the http protocol >b) the restful url is a correct url but the resource it points to does >not exists in the registry database. Again, see the http spec. This is not ambiguous. Malformed requests get a 400 return code. >7.1. RDAP Extensions Registry > >This would require each registry to register probably multiple json >extension identifiers with iana? >Would it not be easier to create a RESTful resource for the extension >used by the server, the client can then query this resource to discover >the extension(s) supported by the server? No. It's not a bug that it is somewhat hard to invent extensions. etc. R's, John From superuser@gmail.com Thu Mar 28 19:28:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119E21F89B2 for ; Thu, 28 Mar 2013 19:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwRLyr5dy7Yw for ; Thu, 28 Mar 2013 19:28:29 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 55C2E21F86C4 for ; Thu, 28 Mar 2013 19:28:29 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so113806wib.4 for ; Thu, 28 Mar 2013 19:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yQZS29FRbb611dgP69wo4Time8BCTVQs/A/QhG3ATRA=; b=LliTKkilUJ05lzh/D97+4AaiFBxQgLqIollKAYj6d1wORtztI1dvgSYbgATGxboCSY Rmupq6uUtur2lJwJwE4fG6EaLEusctCAZbiDiBC7fxF7/Z2ze1P2D+6mIDxPG7hex+ce BpGEg89avuwj36UlDHlSn7p5O99NAqExpWgCoYvW8P4DcW0SALBfWW8QFWUWlWW7mA0K oxMtCdd6AHvGG6YtgEr9R0gKaZU7rKjTzc5x/ygU4LRFQyhYiWBShI9HXkt6Xs1+/tyw csWQdAUPnKRzNKl2TsLhO8GJbfaXXCJYtcZmfBQbeqqbtY5m5dh5m1vduK2xMUBViPSx zeOw== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr1049861wjc.35.1364524108541; Thu, 28 Mar 2013 19:28:28 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Thu, 28 Mar 2013 19:28:28 -0700 (PDT) In-Reply-To: <515495D1.8070807@Commerco.Com> References: <515495D1.8070807@Commerco.Com> Date: Fri, 29 Mar 2013 03:28:28 +0100 Message-ID: From: "Murray S. Kucherawy" To: Alan Maitland Content-Type: multipart/alternative; boundary=089e013d1da8c6f52f04d9070676 Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 02:28:30 -0000 --089e013d1da8c6f52f04d9070676 Content-Type: text/plain; charset=ISO-8859-1 Alan, Just to be clear, the core search document is not the entire WEIRDS specification. There are currently a set of five documents in total that describe WEIRDS. The two we're talking about here only describe the search capability which is part of a larger whole. I believe the intent would be that all WEIRDS implementations would have to comply with the core search document (in addition to the others already in the set), and then could optionally also implement what the extended search document describes. Someone should yell now if that doesn't match what everyone else is thinking. -MSK On Thu, Mar 28, 2013 at 8:11 PM, Alan Maitland wrote: > This appears to make good sense. > > > On 3/27/2013 8:57 PM, Murray S. Kucherawy wrote: > >> The Orlando minutes reflect that we batted around some ideas about how >> to move forward with documents covering the topic of search, but the >> issue wasn't formally resolved. I'd like to take a moment to have that >> discussion now. >> >> The idea I thought had general support based on the working group and >> some hallway chatter afterwards is the notion of creating two search >> documents, one covering basic or core search syntax and capabilities, >> and one covering extended search. John Levine remarked that the former >> would generally try to match the search capabilities that WHOIS servers >> offer now while the latter would cover things we'd like to see, and >> there would be some pressure to have implementation experience with the >> proposals of the latter before we let the document proceed. >> >> Can we get some indications of support or objection to proceeding that >> way? >> >> -MSK >> >> > Could or should the registries then choose to implement their wierds > systems in a phased approach? > > In other words, if registries were to roll wierds using the two document > strategy, then the whois functionality gets replaced and people can begin > to develop and test implementations of the "whois like" wierds client code, > which presumably would be a bit easier to implement. > > This strategy might suggest a first document being a wierds v1.0 spec with > the second being a wierds v1.1 spec, but releasing both specs pretty much > in coterminous manner and referencing each other, with the understanding > that implementers are not fully wierds compliant unless and until they have > rolled out their v1.1 service. Is that the idea? > > Alan > > > > ______________________________**_________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/**listinfo/weirds > --089e013d1da8c6f52f04d9070676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alan,

Just to be clear, the core se= arch document is not the entire WEIRDS specification.=A0 There are currentl= y a set of five documents in total that describe WEIRDS.=A0 The two we'= re talking about here only describe the search capability which is part of = a larger whole.=A0 I believe the intent would be that all WEIRDS implementa= tions would have to comply with the core search document (in addition to th= e others already in the set), and then could optionally also implement what= the extended search document describes.

Someone should yell now if that doesn't match what every= one else is thinking.

-MSK


On Thu, Mar 28, 2013 at 8:11= PM, Alan Maitland <AMaitland@commerco.com> wrote:
This appears to make good sense.


On 3/27/2013 8:57 PM, Murray S. Kucherawy wrote:
The Orlando minutes reflect that we batted around some ideas about how
to move forward with documents covering the topic of search, but the
issue wasn't formally resolved. =A0I'd like to take a moment to hav= e that
discussion now.

The idea I thought had general support based on the working group and
some hallway chatter afterwards is the notion of creating two search
documents, one covering basic or core search syntax and capabilities,
and one covering extended search. =A0John Levine remarked that the former would generally try to match the search capabilities that WHOIS servers
offer now while the latter would cover things we'd like to see, and
there would be some pressure to have implementation experience with the
proposals of the latter before we let the document proceed.

Can we get some indications of support or objection to proceeding that way?=

-MSK


Could or should the registries then choose to implement their wierds system= s in a phased approach?

In other words, if registries were to roll wierds using the two document st= rategy, then the whois functionality gets replaced and people can begin to = develop and test implementations of the "whois like" wierds clien= t code, which presumably would be a bit easier to implement.

This strategy might suggest a first document being a wierds v1.0 spec with = the second being a wierds v1.1 spec, but releasing both specs pretty much i= n coterminous manner and referencing each other, with the understanding tha= t implementers are not fully wierds compliant unless and until they have ro= lled out their v1.1 service. Is that the idea?

Alan



_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds

--089e013d1da8c6f52f04d9070676-- From superuser@gmail.com Thu Mar 28 19:51:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7663621F90EC for ; Thu, 28 Mar 2013 19:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZIyCoDCtAnT for ; Thu, 28 Mar 2013 19:51:10 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6E33B21F898B for ; Thu, 28 Mar 2013 19:51:06 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so165475wiw.0 for ; Thu, 28 Mar 2013 19:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SFjE9KileEp16eTG6bnlgEJEH9DLdfk8DZaUgGGrLs0=; b=GWawLHNC6xHwbZT6Z75NNGEHnZlWUK3RGK/lu25DL6ap0CQ8L73Emumh0VxSYzFypZ oMG1h4Yay5umd13FcAcVNdG6rxab3AZlVsr4zljVSR8xZkX0sOWRzAZz7RmkZHWdLFWE rXgpZJc3gxb/w8B4gOnO5Lnp6ZmJhpzWKXxDsZd2Bb16jDTb/lie3DtEOtqpOqO8SU1c u1IJfiBM+wG8gEn/uHefxOb6SI9npaYotnC5bjI1APhoPV592T+t9wFQqscMDkU0zsM9 jrFJmn+AaJfS8xjcw1JopUVeSuV3pilKvKWYni9mqjXQrH5X+SiVBoTxI6EpfHHJSAvf OjFQ== MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr19710754wiw.33.1364525465530; Thu, 28 Mar 2013 19:51:05 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Thu, 28 Mar 2013 19:51:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Mar 2013 03:51:05 +0100 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f1aa8f77b04d90757c9 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 02:51:11 -0000 --f46d043c7f1aa8f77b04d90757c9 Content-Type: text/plain; charset=ISO-8859-1 A quick note about the IANA Considerations section: 1) "COMMON" doesn't strike me as a "brief reason for a registry entry". (Or perhaps it's overly brief.) Either the name for that field should change to something like "Brief description" and the example updated accordingly, or the definition of "Intended usage" should be updated to match the intent. RFC6838 is the new media type registration document which we could use as a reference here. 2) The contact person in the registration template in 7.2 appears to include a malformed email address. I suspect "<" and ">" have been mis-rendered. 3) We are going to be asked to explain why Specification Required and not some less stringent registry rule is being chosen. I don't have a strong preference for any of them at this point, but we should be sure before sending this upwards that we really can't accept First Come First Served or Expert Review, and be prepared to explain why. I would even suggest including a sentence or two defending the choice that's there if we're sure it's right. I'll do a more complete review soon (traveling this week) but I wanted to get that last point out for discussion right away. On Wed, Mar 27, 2013 at 5:53 PM, Murray S. Kucherawy wrote: > Colleagues, > > We would like to initiate a two-week Working Group Last Call on > draft-ietf-weirds-http. A version 03 was just pushed to the datatracker: > > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > > Last call will end Wednesday, April 10th. > > Please review and comment on the draft, even if it is only to say on the > record "I have reviewed this document thoroughly and it looks good." We > would like to have no fewer than five people report that they have taken a > look at the whole document and reported their findings, and will be > reticent to send it to the IESG without that. We're also keen to hear from > people that have implemented the specification as to their views on > clarity, correctness, and completeness. > > Thanks, > > -MSK and Olaf, your co-chairs > > --f46d043c7f1aa8f77b04d90757c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A quick note about the IANA Considerat= ions section:

1) "COMMON" doesn't strike me as a= "brief reason for a registry entry".=A0 (Or perhaps it's ove= rly brief.)=A0 Either the name for that field should change to something li= ke "Brief description" and the example updated accordingly, or th= e definition of "Intended usage" should be updated to match the i= ntent.=A0 RFC6838 is the new media type registration document which we coul= d use as a reference here.

2) The contact person in the registration template in 7.2 appears= to include a malformed email address.=A0 I suspect "&lt;" an= d "&gt;" have been mis-rendered.

3) We are going= to be asked to explain why Specification Required and not some less string= ent registry rule is being chosen.=A0 I don't have a strong preference = for any of them at this point, but we should be sure before sending this up= wards that we really can't accept First Come First Served or Expert Rev= iew, and be prepared to explain why.=A0 I would even suggest including a se= ntence or two defending the choice that's there if we're sure it= 9;s right.

I'll do a more complete review soon (traveling this week) but= I wanted to get that last point out for discussion right away.


On Wed, Mar 27, 2013 at 5:53 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
Colleagues,

We would like to initiate a t= wo-week Working Group Last Call on draft-ietf-weirds-http.=A0 A version 03 = was just pushed to the datatracker:

https://datatr= acker.ietf.org/doc/draft-ietf-weirds-using-http/

Last call will end Wednesday, April 10th.

Please review an= d comment on the draft, even if it is only to say on the record "I hav= e reviewed this document thoroughly and it looks good."=A0 We would li= ke to have no fewer than five people report that they have taken a look at = the whole document and reported their findings, and will be reticent to sen= d it to the IESG without that.=A0 We're also keen to hear from people t= hat have implemented the specification as to their views on clarity, correc= tness, and completeness.

Thanks,

-MSK and Olaf, your co-chairs


--f46d043c7f1aa8f77b04d90757c9-- From olaf@NLnetLabs.nl Fri Mar 29 02:32:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F521F9394 for ; Fri, 29 Mar 2013 02:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+wZg-xAmVmN for ; Fri, 29 Mar 2013 02:32:09 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717721F938F for ; Fri, 29 Mar 2013 02:32:08 -0700 (PDT) Received: from [192.168.178.34] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2T9W1ao046388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 10:32:05 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.8.0 open.nlnetlabs.nl r2T9W1ao046388 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1364549527; bh=HFgXCmUCMEWS3QCErCe/Zsh/dRjkshfvjc9a5brzmWM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=d05p/+FCw0IN2+ghH5bjZqhwIaLWauaqvj8xfIOe4ptH2nbxTuB01Q9aD/FNjwofo fb1s35KnufZmLSjg2xsXQNNixURg7787VObfkaN0EfL2EEPnL9qIgeuXsnTljtgHXa 7gQ8tc8lIVK0eGdpqUOadxZKe6YX7f/WHYePP2yA= Content-Type: multipart/alternative; boundary="Apple-Mail=_5539EB37-00DA-4DE3-8FC3-E7937E8582CF" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: <6.2.5.6.2.20130327101012.0c52b348@resistor.net> Date: Fri, 29 Mar 2013 10:32:01 +0100 Message-Id: <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> To: SM X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (open.nlnetlabs.nl [213.154.224.1]); Fri, 29 Mar 2013 10:32:05 +0100 (CET) Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 09:32:11 -0000 --Apple-Mail=_5539EB37-00DA-4DE3-8FC3-E7937E8582CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 27, 2013, at 6:15 PM, SM wrote: > There are a few IDNs which appear as reserved.=20 Pointer please? I am not a big fan of 'sneaking past the IESG', that introduces delays = at a point where you can do without, so lets make sure we do not have an = issue before sending to the IESG. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_5539EB37-00DA-4DE3-8FC3-E7937E8582CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sm@resistor.net> wrote:

There are a few IDNs which = appear as reserved. 

Pointer please?

I am not a big fan of = 'sneaking past the IESG', that introduces delays at a point where you = can do without, so lets make sure we do not have an issue before sending = to the IESG.

--Olaf


Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_5539EB37-00DA-4DE3-8FC3-E7937E8582CF-- From maarten.wullink@sidn.nl Fri Mar 29 03:03:25 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF17B21F85C9 for ; Fri, 29 Mar 2013 03:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SypiPjp7jbek for ; Fri, 29 Mar 2013 03:03:24 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6E821F856C for ; Fri, 29 Mar 2013 03:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-originating-ip; bh=IYt9hCqMhB8Ep/WaJlvIeiN5zBdKaAaI59lpv7vfA7s=; b=VKA/ECLL7nvQGHlSTr5WVt+j0OZfxPD7Ggjz3MPil4A7yUaReju6KKDrcoUmEDWQ3+YnT89KZ+gpuhRjWjy6ClS0l2KheD4WLaCoH41tM1nkKODQPj07E9GAWezYfKwAJ/WZByVTC3/evQDExUVFD3narYD/dk/BLIY2jdDc74I= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r2TA3NGS021645-r2TA3NGU021645 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Fri, 29 Mar 2013 11:03:23 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 11:03:23 +0100 Received: from [94.198.152.215] (94.198.152.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 11:03:22 +0100 Message-ID: <515566EA.4000201@sidn.nl> Date: Fri, 29 Mar 2013 11:03:22 +0100 From: Maarten Wullink User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: John Levine References: <20130329003833.3256.qmail@joyce.lan> In-Reply-To: <20130329003833.3256.qmail@joyce.lan> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.215] Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 10:03:26 -0000 On 03/29/2013 01:38 AM, John Levine wrote: > Not to be unduly negative, but these are not good ideas. > thanks for your reply, i still have some comments/questions. >> Versioning: > > We're carefully making this design extensible, with ways to put added > stuff in the json and so forth. If we fail so badly that we need to > start over with an incompatible version 2,0, I would very much prefer > that the new version uses different URLs, so the existing 1.0 clients > don't break. > >> I am missing a section about api versioning, it might be desirable for a >> client to signal the server which version of the api it would like to >> use. > > Good lord no. There lies major interop failures. We define one spec > and tell people to implement that. > >> It would be useful if the server always returns the result in rdap+json >> format if the client has not specified the requested type with the >> Accept header. > > No. A client that doesn't send an Accept: header is not an rdap > client, so it makes sense to return a generic format that a generic > client (e.g. a web browser) can render. > This generic format (probably html based) is described in an other (future) weirds document? >> The "subsequent query" implies that any query after the 301 or 307 >> response must be sent to the url found in the Location header. This is >> only the case for the original query. a subsequent query could also be >> an entirely different query for which this does not apply. > > This sits on top of http, that's part of the http semantics of 3xx > responses. It is not good standards design to try to reiterate stuff > defined in another spec, since the two versions never quite match. In that case i would remove the text about what the client is expected to do when receiving a redirect in section "5.2. Redirects". The user-agent behaviour is defined in rfc 2616. > >> 5.3 Negative answers >> >> This will introduce an ambiguous situation if the server does not add >> additional information to the 404 response it is not possible for the >> client to dermine which of the following situations applies: >> >> a) The url for the restful resource is incorrect and the error is from >> the http protocol >> b) the restful url is a correct url but the resource it points to does >> not exists in the registry database. > > Again, see the http spec. This is not ambiguous. Malformed requests > get a 400 return code. A malformed request will get a 400 code but a request with a syntacly correct url for a resource will get a 404 when the resource does not exist on the server. This 404 is a http protocol code which is reused in the rdap protocol. If the server does not add additional information to the response, how is the client to determine the difference between a) url does not exist on the server and response is 404 (but url has valid syntax, so no 400 response) and b) the url is valid and is accepted by the weirds application, but there is no data for the requested resource in the database. the response will be a 404. > >> 7.1. RDAP Extensions Registry >> >> This would require each registry to register probably multiple json >> extension identifiers with iana? >> Would it not be easier to create a RESTful resource for the extension >> used by the server, the client can then query this resource to discover >> the extension(s) supported by the server? > > No. It's not a bug that it is somewhat hard to invent extensions. > > etc. > > R's, > John > From sm@resistor.net Fri Mar 29 03:35:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7FA21F93B0 for ; Fri, 29 Mar 2013 03:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63IyeSG8q1TB for ; Fri, 29 Mar 2013 03:35:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D585F21F93BA for ; Fri, 29 Mar 2013 03:35:16 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2TAZAac022752; Fri, 29 Mar 2013 03:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364553315; bh=KpmxLIDM+xDZAyoe6usUor5Oozwb1CI7yi5+Dm11kBI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=U+Vvy9je8udpLI6OLSuWWKYwq71OBBqgfSr8s+Toes8zJYZxEj4yE50+HnrXc5z/9 dqfTfsT9j2QRPhhNYCp1V6MZJNvGZXWtKrD8p0tJbGhE+zcXdWd1I5+O9RD9wH4tCl ERFjkHwCBDuNdbG3SQi6YK+hPOS5C39tJIYDT6WI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364553315; i=@resistor.net; bh=KpmxLIDM+xDZAyoe6usUor5Oozwb1CI7yi5+Dm11kBI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eOhwFgEeSuiGzByHkEXuCPNoqhHVAVUm0v4HI2I2AfbvG9/xGX8xek0VmTtTM46bC UWeJM0QHLYKDsj+8eqwbvA4ng4VuIfRntQRi67D1PLKnpnhC66IcTsM3wXiGo4XjTI 7dvrpRna9brzUG2acXI455GKXrkVucW3mOkkti2c= Message-Id: <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Mar 2013 03:32:17 -0700 To: Olaf Kolkman From: SM In-Reply-To: <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 10:35:17 -0000 Hi Olaf, At 02:32 29-03-2013, Olaf Kolkman wrote: >Pointer please? See http://www.iana.org/domains/special >I am not a big fan of 'sneaking past the IESG', that introduces >delays at a point where you can do without, so lets make sure we do >not have an issue before sending to the IESG. I don't know whether these examples could be used they don't have the same status as the RFC 2606 examples. Regards, -sm From maarten.wullink@sidn.nl Fri Mar 29 03:48:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F621F91BD for ; Fri, 29 Mar 2013 03:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK1nU0gAqkU3 for ; Fri, 29 Mar 2013 03:48:04 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 203CD21F91B6 for ; Fri, 29 Mar 2013 03:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=JiNMuOMFQ4DK9IChzbXBvuCAX9O2h4vdCyreJOh4ngY=; b=LR6cj2PXnnKeAw0qROOP4bDSz8E3jNlHWDYwU3eEZWcHq8tGSDqZFpIJ+Uu4rIt+p3+3lFnaw91bnDhrjMNpFxY2W9Op/gBIs7ptIm0O+qVSZKBlv6WShZCwXiAuXl5MfCoP3ZgODcBVgob7RTAmyiwGT7YJLKu5SKBkbsgoRno= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r2TAm2Jp022973-r2TAm2Jr022973 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Fri, 29 Mar 2013 11:48:02 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 11:48:02 +0100 Received: from [94.198.152.215] (94.198.152.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 11:48:02 +0100 Message-ID: <51557162.5010101@sidn.nl> Date: Fri, 29 Mar 2013 11:48:02 +0100 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Pieter Vandepitte References: <089965E4-681B-4D5A-BFE8-116CC8E9EDA1@dns.be> In-Reply-To: <089965E4-681B-4D5A-BFE8-116CC8E9EDA1@dns.be> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.215] Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 10:48:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/2013 11:33 PM, Pieter Vandepitte wrote: > And I was thinking right away of something else: wouldn't it be a > good idea to introduce a HEAD method? A lot of / some registries > currently have some kind of Domain Availability Service which > simply returns whether the domain which is looked up, is still > available (yes or no). A "HEAD /domains/example.com" would e.g. > return a "200 OK" if the domain name exists, and a "404 NOT FOUND" > if the domain name is still available (i.e. the same result code as > if the client performed a GET) > > Okay, this could questionably be called REST, but this feature > could be useful for registrars or other instances to have a uniform > way to anonymously check whether a domain name is still available > for different TLD's (by performing some kind of distributed query) > Good one, at the .nl ccTLD we currently have a "lightweight" whois (IS) service which enables a client to check if a domain exists or not. This "IS" service is used to offload requests which would otherwise go to the more "resource intensive" whois service. The query/response for the IS also use much less network bandwidth. We drafted a proposal for a RESTful EPP a while ago, in that proposal we suggested the use of the http HEAD method to do a check if a resource exists. The response could be as short as only a http 200. see: http://tools.ietf.org/html/draft-wullink-restful-epp-00#section-9.4.1 This is something we would definitely require. > Just thinking out loud... > > Pieter > > On 28 Mar 2013, at 23:04, Maarten Wullink > wrote: > >> Here's my 2 cents >> >> Versioning: I am missing a section about api versioning, it might >> be desirable for a client to signal the server which version of >> the api it would like to use. This would enable registries to add >> new features to the server code in a backwards compatible way. >> >> This could be done by integrating the version in the url, like: >> example.com/weirds/v1.0/domain/weird.com or by using the MIME >> type for this. The client could also add the version identifier >> to the accept header like: Accept: >> application/rdap+json;version=2 >> >> >> 4.1 Accept header " This specification does not define the >> responses a server returns to a request with any other media >> types in the Accept: header, or with no Accept: header. One >> possibility would be to return a response in a media type >> suitable for rendering in a web browser." >> >> It would be useful if the server always returns the result in >> rdap+json format if the client has not specified the requested >> type with the Accept header. The json reponse should be the >> default response type, this way the client would not have to >> retry the request. This would prevent needless queries. >> >> >> 5.1 Positive answers " it SHOULD encode the answer in the format >> most appropriate according to the standard and defined rules for >> processing the HTTP Accept header, and return that answer in the >> body of a 200 response." >> >> I would change this to "it MUST encode the answer" The server >> MUST use the type specified by the client in the Accept header, >> unless the server has no support for the type. >> >> >> 5.2 Redirects "If a server wishes to inform a client that the >> answer to a given query can be found elsewhere, it SHOULD return >> either a 301 or a 307 response code and an HTTP URL in the >> Location: header. The client is expected to issue a subsequent >> query using the given URL without any processing of the URL. " >> >> The "subsequent query" implies that any query after the 301 or >> 307 response must be sent to the url found in the Location >> header. This is only the case for the original query. a >> subsequent query could also be an entirely different query for >> which this does not apply. >> >> I would change it to: "The query for which a 301 or 307 response >> has been received MUST be retried at the URL found in the >> Location: header." >> >> >> 5.3 Negative answers "If a server wishes to respond that it has >> no information regarding the query, it SHOULD return a 404 >> response code. Optionally, it MAY include additional information >> regarding the negative answer in the HTTP entity body." >> >> This will introduce an ambiguous situation if the server does not >> add additional information to the 404 response it is not possible >> for the client to dermine which of the following situations >> applies: >> >> a) The url for the restful resource is incorrect and the error is >> from the http protocol b) the restful url is a correct url but >> the resource it points to does not exists in the registry >> database. >> >> There are multiple ways to fix this ambiguity the simplest would >> be to require the server to always send additional explanatory >> information with a 404 response. >> >> Therefore change "it MAY include additional information regarding >> the negative answer in the HTTP entity body." >> >> To: "it MUST include additional information regarding the >> negative answer in the HTTP entity body." >> >> >> 7.1. RDAP Extensions Registry >> >> This would require each registry to register probably multiple >> json extension identifiers with iana? Would it not be easier to >> create a RESTful resource for the extension used by the server, >> the client can then query this resource to discover the >> extension(s) supported by the server? >> >> >> 8.3. Language Identifiers in HTTP Headers >> >> Given the description of the use of language identifiers in >> Section 8.2, unless otherwise specified servers SHOULD ignore the >> HTTP [RFC2616] Accept-Language header when formulating >> responses. >> >> At the .nl ccTLD we currently have a whois service which supports >> multiple languages, the client can request the desired response >> luangue with the accept-language header in the request. >> >> This should be changed to something like: "The server MUST return >> a response encoded in the language requested by the client. >> Unless the server has no support for the client. >> >> >> Cheers, >> >> Maarten >> >> >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Murray S. Kucherawy Sent: woensdag 27 maart 2013 17:53 >> To: weirds@ietf.org Subject: [weirds] Working Group Last Call: >> draft-ietf-weirds-using-http >> >> Colleagues, >> >> We would like to initiate a two-week Working Group Last Call on >> draft-ietf-weirds-http. A version 03 was just pushed to the >> datatracker: >> >> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ >> Last call will end Wednesday, April 10th. >> >> Please review and comment on the draft, even if it is only to say >> on the record "I have reviewed this document thoroughly and it >> looks good." We would like to have no fewer than five people >> report that they have taken a look at the whole document and >> reported their findings, and will be reticent to send it to the >> IESG without that. We're also keen to hear from people that have >> implemented the specification as to their views on clarity, >> correctness, and completeness. >> >> Thanks, -MSK and Olaf, your co-chairs >> _______________________________________________ weirds mailing >> list weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ weirds mailing > list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds > - -- Maarten Wullink MSc|Technical advisor / R&D engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05 maarten.wullink@sidn.nl | www.sidn.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRVXFiAAoJEHZPQ3qFDFN1X2IH/RIa1xEihuC994e5aHcvTiSt aAlkr6EXO65tBlhdT8KzlkkcJqdb6nwEjtnDzQAGQX34WlCIyIJ6Nh1fV7QaVCNu BfmXK98Wb7APHG6Tc9jrpK1F5dqsVRYAvVgeYtD6XiYVfwy7h6u6wJDi4h+sHCBq NSc8BfklXkvDqqbsWqbUII/H1oQzGoWu12uFOwm62Lf+1lKqmlv12ZNsWmkZa8el 47Rgzx/ldW/MpOkvbd2drt4wytg5/jChyzbhLghmCly8AM1x1BC5KvFBxEqwjwuL vgxrROO82azNKZku7OF2JqXmWvgFkxrpdNTWZsYNmeNUpzOKxsHFjTzjDcHOPFM= =FZnF -----END PGP SIGNATURE----- From olaf@NLnetLabs.nl Fri Mar 29 04:48:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AECC21F933F for ; Fri, 29 Mar 2013 04:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN7NySmp+hfg for ; Fri, 29 Mar 2013 04:48:07 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFF21F92E2 for ; Fri, 29 Mar 2013 04:48:06 -0700 (PDT) Received: from [IPv6:2001:980:2282:1:f544:188a:4b69:16f] ([IPv6:2001:980:2282:1:f544:188a:4b69:16f]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2TBlrt4041615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 12:47:57 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.8.0 open.nlnetlabs.nl r2TBlrt4041615 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1364557681; bh=mXQYWgSfwFGF7zWknIf3SC3HclL21QQVL1lQcNQekvo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=RahkmDKPVQZX2EkF0XVQ6Rc7zK9MOQYajEE5RxdyRnLhyxMfI9bZTqda4/efEsy+0 BvgXkGe/MuMakefBaermDmJ1V2YRe9rmBGBXaSjjA3DWXRoRPBsTVdDh2FQadtXRJo KarsiHCd5RL4illVu1Q4n72Nf2FQcTdLxCztc8TE= Content-Type: multipart/alternative; boundary="Apple-Mail=_063B364B-3880-4A63-9D53-15C07B086893" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> Date: Fri, 29 Mar 2013 12:47:53 +0100 Message-Id: <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> To: SM X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 29 Mar 2013 12:47:58 +0100 (CET) Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 11:48:08 -0000 --Apple-Mail=_063B364B-3880-4A63-9D53-15C07B086893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 29, 2013, at 11:32 AM, SM wrote: > Hi Olaf, > At 02:32 29-03-2013, Olaf Kolkman wrote: >> Pointer please? >=20 > See http://www.iana.org/domains/special That page documents a temporary experiment. The names on that page seem = to be associated with a mnemonic seems to translate to 'test' (according = to a quick google-translate experiment). Personally I think we should = not step on them without coordination. > I don't know whether these examples could be used they don't have the = same status as the RFC 2606 examples. As netizen I am pushing back. I think it is bad practice to squat in the = Domain name space without appropriate coordination.=20 That 'appropriate coordination' is something that I would need to do = with my chair hat on and since I am not looking forward digging up the = worm-can opener I have a very strong preference to pragmatically use = something 'under' example.com. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_063B364B-3880-4A63-9D53-15C07B086893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sm@resistor.net> wrote:

Hi Olaf,
Pointer please?

 I don't = know whether these examples could be used they don't have the same = status as the RFC 2606 = examples.




=
--Olaf


Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_063B364B-3880-4A63-9D53-15C07B086893-- From alexander.mayrhofer@nic.at Fri Mar 29 06:03:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D00521F9415 for ; Fri, 29 Mar 2013 06:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.28 X-Spam-Level: X-Spam-Status: No, score=-9.28 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG3kFTn0TY6C for ; Fri, 29 Mar 2013 06:03:55 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC121F9406 for ; Fri, 29 Mar 2013 06:03:53 -0700 (PDT) Received: from smtp.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Fri, 29 Mar 2013 14:03:51 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 29 Mar 2013 14:03:49 +0100 From: Alexander Mayrhofer To: Maarten Wullink , Pieter Vandepitte Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwue5Zoxq1BWXk25CcORrCdypJi7mY8AgAAIIoCAAM05AIAAMovA Date: Fri, 29 Mar 2013 13:03:48 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982F5E6@NICS-EXCH.sbg.nic.at> References: <089965E4-681B-4D5A-BFE8-116CC8E9EDA1@dns.be> <51557162.5010101@sidn.nl> In-Reply-To: <51557162.5010101@sidn.nl> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 13:03:56 -0000 > > And I was thinking right away of something else: wouldn't it be a good > > idea to introduce a HEAD method? A lot of / some registries currently > > have some kind of Domain Availability Service which simply returns > > whether the domain which is looked up, is still available (yes or no). > > A "HEAD /domains/example.com" would e.g. > > return a "200 OK" if the domain name exists, and a "404 NOT FOUND" > > if the domain name is still available (i.e. the same result code as if > > the client performed a GET) [Alexander Mayrhofer]=20 >From the DNR perspective, i fully agree. We (.at) have a lightweight availa= bility check based on the "finger" protocol, and would definitely need a si= milar lightweight method in WIERDS if we considered the protocol for deploy= ment.=20 >From the WEIRDS/protocol perspectiv:=20 RFC 2616 says that HEAD MUST be supported anyways. However, it also says th= at (see section 9.4) "The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request" which means that, for example if the GET response includes a Content-Length= header field, the respective HEAD response should also include this header= field. Which, in turn, means that the HEAD method would also need to fully= evaluate the query, fetch the data, and calculate the response body, just = because it needs to provide the header filed - and this would contradict th= e purpose of HEAD resembling a light-weight alternative to GET (at least on= the server side). Of course, we could leave out the various problematic header fields in the = HEAD response, but this would stretch the purpose of SHOULD a bit. Alternat= ively, we could strip the headers from both the GET and HEAD responses - wh= ich probably doesn't make sense either. Practically, i would probably simply leave out the problematic headers in t= he HEAD responses, and bend the HTTP specs, rather than losing the advantag= e of the "lightweight" method. We can solve this in the document by simply saying that servers SHOULD also= support HEAD, and leave the decision whether or not to provide GET-identic= al headers to the implementors. Alex From stpeter@stpeter.im Fri Mar 29 08:26:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484E121F93E7 for ; Fri, 29 Mar 2013 08:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LFsDNPMkjGm for ; Fri, 29 Mar 2013 08:26:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8972E21F93CE for ; Fri, 29 Mar 2013 08:26:23 -0700 (PDT) Received: from [10.129.24.115] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E49EB40D47; Fri, 29 Mar 2013 09:35:50 -0600 (MDT) Message-ID: <5155B29D.3000301@stpeter.im> Date: Fri, 29 Mar 2013 09:26:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Olaf Kolkman References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> In-Reply-To: <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 15:26:24 -0000 On 3/29/13 5:47 AM, Olaf Kolkman wrote: > > On Mar 29, 2013, at 11:32 AM, SM wrote: > >> Hi Olaf, >> At 02:32 29-03-2013, Olaf Kolkman wrote: >>> Pointer please? >> >> See http://www.iana.org/domains/special > > That page documents a temporary experiment. The names on that page seem to be associated with a mnemonic seems to translate to 'test' (according to a quick google-translate experiment). Personally I think we should not step on them without coordination. > >> I don't know whether these examples could be used they don't have the same status as the RFC 2606 examples. > > > As netizen I am pushing back. I think it is bad practice to squat in the Domain name space without appropriate coordination. > > That 'appropriate coordination' is something that I would need to do with my chair hat on and since I am not looking forward digging up the worm-can opener I have a very strong preference to pragmatically use something 'under' example.com. Are we looking for documentation examples or examples for real-world testing? Peter -- Peter Saint-Andre https://stpeter.im/ From andy@arin.net Fri Mar 29 09:20:44 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2C21F91DB for ; Fri, 29 Mar 2013 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItMCi-f+w4dQ for ; Fri, 29 Mar 2013 09:20:44 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 169CC21F91AC for ; Fri, 29 Mar 2013 09:20:44 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B5C9421367C; Fri, 29 Mar 2013 12:20:43 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 35DEC213643; Fri, 29 Mar 2013 12:20:43 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:20:20 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:20:40 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4rq8gkQGdqA1SD+02gDEqb/EAX/wAcw3KAAB6hIwA= Date: Fri, 29 Mar 2013 16:20:39 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF81C2@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F5B6B699C746647A21D2F6123AC806C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:20:44 -0000 On 3/28/13 5:43 PM, "Pieter Vandepitte" wrote: >* What about the recent discussion on Search documents. i.e. searching >and returning multiple results: then the first design intent ( 3. Design >Intents) doesn't hold anymore. Can't we relax this statement? That should probably be changed to mean HTTP entities instead of results. >* The link to http://www.w3.org/TR/2012/WD-cors-20130129 doesn't >work.http://www.w3.org/TR/2013/CR-cors-20130129/ or >http://www.w3.org/TR/cors/ (but dangerous to link to the latest version i >suppose) Thanks. -andy From andy@arin.net Fri Mar 29 09:25:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2921F922D for ; Fri, 29 Mar 2013 09:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzCfpMK9q67J for ; Fri, 29 Mar 2013 09:25:16 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2C21F93B7 for ; Fri, 29 Mar 2013 09:25:15 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 83B892136AA; Fri, 29 Mar 2013 12:25:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id E9642213698; Fri, 29 Mar 2013 12:25:13 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:24:29 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:25:13 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i77WAAgAArEoCAAMVyAA== Date: Fri, 29 Mar 2013 16:25:12 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF81E5@CHAXCH01.corp.arin.net> In-Reply-To: <20130329003833.3256.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <634486C87C183B40B278129B1C103A22@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:25:16 -0000 On 3/28/13 8:38 PM, "John Levine" wrote: >Not to be unduly negative, but these are not good ideas. > >>Versioning: > >We're carefully making this design extensible, with ways to put added >stuff in the json and so forth. If we fail so badly that we need to >start over with an incompatible version 2,0, I would very much prefer >that the new version uses different URLs, so the existing 1.0 clients >don't break. > >>I am missing a section about api versioning, it might be desirable for a >>client to signal the server which version of the api it would like to >>use. > >Good lord no. There lies major interop failures. We define one spec >and tell people to implement that. Just so everyone knows the history here, we had versioning in the media type and Accept headers via the level parameter. This was taken out for the reasons John states above. Additionally, there was concern that media types, etc. wouldn't be expressive enough to deal with extensions. There is versioning however, it is just in Section 5.1 of draft-ietf-weirds-json-response (http://tools.ietf.org/html/draft-ietf-weirds-json-response-02#section-5.1) -andy From olaf@NLnetLabs.nl Fri Mar 29 09:33:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9D221F9188 for ; Fri, 29 Mar 2013 09:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-STZO9rbH-B for ; Fri, 29 Mar 2013 09:33:39 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114721F915B for ; Fri, 29 Mar 2013 09:33:38 -0700 (PDT) Received: from [192.168.178.34] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r2TGXVr2057050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 17:33:34 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.8.0 open.nlnetlabs.nl r2TGXVr2057050 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1364574817; bh=BW8Mr5rIt5sewq00qB1V4iyDFh88suLIJnd1ib6TkOg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OS2AxFFkH0qLCFwP/1CzKjtueOcbN0HehbT3viI2Ih24OL2dG3xKa5bFcpSKkuc2H Dzlqug1eMOSdpNpS5Mca4u3fp51nXvb4ddxLEUQc2muHVHmOHgEBnEk8gnpgPOyBty HJ5DS5nTEKNxjYmW4+E//zIVGUnD2y87nOafXKfI= Content-Type: multipart/alternative; boundary="Apple-Mail=_75698339-1AF4-4C19-B7BC-5E79CE86AA85" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: <5155B29D.3000301@stpeter.im> Date: Fri, 29 Mar 2013 17:33:31 +0100 Message-Id: <48791875-50CB-4D54-9A36-DBAD8700E453@NLnetLabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> <5155B29D.3000301@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.1 (open.nlnetlabs.nl [213.154.224.1]); Fri, 29 Mar 2013 17:33:35 +0100 (CET) Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:33:40 -0000 --Apple-Mail=_75698339-1AF4-4C19-B7BC-5E79CE86AA85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 29, 2013, at 4:26 PM, Peter Saint-Andre = wrote: > On 3/29/13 5:47 AM, Olaf Kolkman wrote: >>=20 >> On Mar 29, 2013, at 11:32 AM, SM wrote: >>=20 >>> Hi Olaf, >>> At 02:32 29-03-2013, Olaf Kolkman wrote: >>>> Pointer please? >>>=20 >>> See http://www.iana.org/domains/special >>=20 >> That page documents a temporary experiment. The names on that page = seem to be associated with a mnemonic seems to translate to 'test' = (according to a quick google-translate experiment). Personally I think = we should not step on them without coordination. >>=20 >>> I don't know whether these examples could be used they don't have = the same status as the RFC 2606 examples. >>=20 >>=20 >> As netizen I am pushing back. I think it is bad practice to squat in = the Domain name space without appropriate coordination.=20 >>=20 >> That 'appropriate coordination' is something that I would need to do = with my chair hat on and since I am not looking forward digging up the = worm-can opener I have a very strong preference to pragmatically use = something 'under' example.com. >=20 > Are we looking for documentation examples or examples for real-world > testing? Documentation. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_75698339-1AF4-4C19-B7BC-5E79CE86AA85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii stpeter@stpeter.im> = wrote:

On 3/29/13 5:47 AM, Olaf Kolkman wrote:

On Mar 29, 2013, at 11:32 AM, SM <sm@resistor.net> = wrote:

Hi Olaf,
At 02:32 29-03-2013, = Olaf Kolkman wrote:
Pointer = please?

See http://www.iana.org/domains/s= pecial

That page documents a temporary = experiment. The names on that page seem to be associated with a mnemonic = seems to translate to 'test' (according to a quick google-translate = experiment). Personally I think we should not step on them without = coordination.

I don't know whether = these examples could be used they don't have the same status as the RFC = 2606 examples.


As netizen I am pushing back. I = think it is bad practice to squat in the Domain name space without = appropriate coordination.

That 'appropriate coordination' is = something that I would need to do with my chair hat on and since I am = not looking forward digging up the worm-can opener I have a very strong = preference to pragmatically use something 'under' example.com.

Are we = looking for documentation examples or examples for = real-world
testing?


Documentation.

--Olaf

Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_75698339-1AF4-4C19-B7BC-5E79CE86AA85-- From andy@arin.net Fri Mar 29 09:39:27 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0A121F9402 for ; Fri, 29 Mar 2013 09:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFKdhRnAmCOX for ; Fri, 29 Mar 2013 09:39:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 35ED921F9405 for ; Fri, 29 Mar 2013 09:39:26 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 7871A16536D; Fri, 29 Mar 2013 12:39:19 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id C43DA16535C; Fri, 29 Mar 2013 12:39:18 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:38:28 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:39:12 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i8PXmAgACkUYA= Date: Fri, 29 Mar 2013 16:39:10 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:39:27 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Thursday, March 28, 2013 10:51 PM To: "weirds@ietf.org" > Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http 1) "COMMON" doesn't strike me as a "brief reason for a registry entry". (O= r perhaps it's overly brief.) Either the name for that field should change= to something like "Brief description" and the example updated accordingly,= or the definition of "Intended usage" should be updated to match the inten= t. RFC6838 is the new media type registration document which we could use = as a reference here. >From RFC 6838: Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE.) Are you saying we should use something else? 2) The contact person in the registration template in 7.2 appears to includ= e a malformed email address. I suspect "<" and ">" have been mis-ren= dered. Thought I fixed that. Thanks. 3) We are going to be asked to explain why Specification Required and not s= ome less stringent registry rule is being chosen. I don't have a strong pr= eference for any of them at this point, but we should be sure before sendin= g this upwards that we really can't accept First Come First Served or Exper= t Review, and be prepared to explain why. I would even suggest including a= sentence or two defending the choice that's there if we're sure it's right= . I don't have a strong opinion either way, either. However, the extensions r= egistry is a place where developers of clients will go to find extensions. = Having registry publish a document describing their extensions would probab= ly be helpful to developers, much more helpful than just a listing of the p= refix value. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <482321DD3D97EC42BBF31383E0A9B952@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Thursday, March 28, 2013 10:5= 1 PM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] Working Group= Last Call: draft-ietf-weirds-using-http

1) "COMMON" doesn't strike me as a "brief reason for a = registry entry".  (Or perhaps it's overly brief.)  Either th= e name for that field should change to something like "Brief descripti= on" and the example updated accordingly, or the definition of "In= tended usage" should be updated to match the intent.  RFC6838 is the ne= w media type registration document which we could use as a reference here.<= /div>


From RFC 6838:

Intended usage:

   (One of COMMON, LIMITED USE, or OBSOLETE.)


Are you saying we should use something else?

2) The contact person in the registration template in 7.2 appears to i= nclude a malformed email address.  I suspect "&lt;" and = "&gt;" have been mis-rendered.

Thought I fixed that. Thanks.

3) We are going to be asked to explain why Specification Required and = not some less stringent registry rule is being chosen.  I don't have a= strong preference for any of them at this point, but we should be sure bef= ore sending this upwards that we really can't accept First Come First Served or Expert Review, and be prepared to = explain why.  I would even suggest including a sentence or two defendi= ng the choice that's there if we're sure it's right.

I don't have a strong opinion either way, either. However, the extensi= ons registry is a place where developers of clients will go to find extensi= ons. Having registry publish a document describing their extensions would p= robably be helpful to developers, much more helpful than just a listing of the prefix value.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218CHAXCH01corpari_-- From andy@arin.net Fri Mar 29 09:40:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A3921F9405 for ; Fri, 29 Mar 2013 09:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=3.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIgBpbV6DrD3 for ; Fri, 29 Mar 2013 09:40:28 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3607A21F9402 for ; Fri, 29 Mar 2013 09:40:28 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id DF22D165371; Fri, 29 Mar 2013 12:39:57 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 7BF7B16536D; Fri, 29 Mar 2013 12:39:57 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:39:34 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:39:56 -0400 From: Andy Newton To: Maarten Wullink , John Levine Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i77WAAgAArEoCAAJ3PAIAAK74A Date: Fri, 29 Mar 2013 16:39:56 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> In-Reply-To: <515566EA.4000201@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:40:57 -0000 On 3/29/13 6:03 AM, "Maarten Wullink" wrote: >>No. A client that doesn't send an Accept: header is not an rdap >>client, so it makes sense to return a generic format that a generic >>client (e.g. a web browser) can render. >> >This generic format (probably html based) is described in an other >(future) weirds document? > > It is JSON, specified in draft-ietf-weirds-json-response. -andy From andy@arin.net Fri Mar 29 09:45:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063921F9431 for ; Fri, 29 Mar 2013 09:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eje2qZShFdtA for ; Fri, 29 Mar 2013 09:45:09 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7642A21F941F for ; Fri, 29 Mar 2013 09:45:08 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2940C2136AE; Fri, 29 Mar 2013 12:45:08 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 80BDF2136AA; Fri, 29 Mar 2013 12:45:07 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:44:12 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:44:57 -0400 From: Andy Newton To: Alexander Mayrhofer , Maarten Wullink , Pieter Vandepitte Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i77WAAgAAII4CAAM05AIAAJe4A///6uoA= Date: Fri, 29 Mar 2013 16:44:54 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8263@CHAXCH01.corp.arin.net> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F5E6@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:45:10 -0000 On 3/29/13 9:03 AM, "Alexander Mayrhofer" wrote: >> > And I was thinking right away of something else: wouldn't it be a good >> > idea to introduce a HEAD method? A lot of / some registries currently >> > have some kind of Domain Availability Service which simply returns >> > whether the domain which is looked up, is still available (yes or no). >> > A "HEAD /domains/example.com" would e.g. >> > return a "200 OK" if the domain name exists, and a "404 NOT FOUND" >> > if the domain name is still available (i.e. the same result code as if >> > the client performed a GET) > >[Alexander Mayrhofer] >From the DNR perspective, i fully agree. We (.at) have a lightweight >availability check based on the "finger" protocol, and would definitely >need a similar lightweight method in WIERDS if we considered the protocol >for deployment.=20 This working group is chartered for a replacement of Whois, not the standardization of a lightweight domain name availability check. That being said, we probably should support HEAD and if it solves the problem then so be it. :) >From the WEIRDS/protocol perspectiv: > >RFC 2616 says that HEAD MUST be supported anyways. However, it also says >that (see section 9.4) > >"The metainformation contained > in the HTTP headers in response to a HEAD request SHOULD be identical > to the information sent in response to a GET request" > >which means that, for example if the GET response includes a >Content-Length header field, the respective HEAD response should also >include this header field. Which, in turn, means that the HEAD method >would also need to fully evaluate the query, fetch the data, and >calculate the response body, just because it needs to provide the header >filed - and this would contradict the purpose of HEAD resembling a >light-weight alternative to GET (at least on the server side). > >Of course, we could leave out the various problematic header fields in >the HEAD response, but this would stretch the purpose of SHOULD a bit. >Alternatively, we could strip the headers from both the GET and HEAD >responses - which probably doesn't make sense either. > >Practically, i would probably simply leave out the problematic headers in >the HEAD responses, and bend the HTTP specs, rather than losing the >advantage of the "lightweight" method. > >We can solve this in the document by simply saying that servers SHOULD >also support HEAD, and leave the decision whether or not to provide >GET-identical headers to the implementors. I agree. We should just say that HEAD should be supported. Now is that a SHOULD or a MUST. I think MUST given 2616's language. -andy From johnl@taugh.com Fri Mar 29 09:50:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4721F9447 for ; Fri, 29 Mar 2013 09:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH33az3iRdy4 for ; Fri, 29 Mar 2013 09:50:19 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8368921F944B for ; Fri, 29 Mar 2013 09:50:17 -0700 (PDT) Received: (qmail 28720 invoked from network); 29 Mar 2013 16:50:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=702f.5155c640.k1303; bh=vbheDBoC78q5XLoG9iEoXjeKch4R5gakHDn4MMFCQso=; b=CHxYtbLu8gGvGboaF4EtEGIxGGGbV13subaql7xKrzNlUxbjU848kzmW7/xe4DEAOSW1HsQW5PvrAFUy/We38BcgPEG9KP67xPNzYB/9auKxuzclt5B0+A52+xMPkjCfK2km0j7F3B0lrQHAJWObfeyxw0+6HotfCz/0jnHL7tA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=702f.5155c640.k1303; bh=vbheDBoC78q5XLoG9iEoXjeKch4R5gakHDn4MMFCQso=; b=iUGvd7zjpkQqU7QpbW3nhxcO2tA8fRUvOboBwK40X9oJRgjawLsph4MPoUXR0H8Yoo2o+5uSdRnL08+CAgUaORgHSiRBmmnYSsJuzNICrWl6es2eavnbsXE3VJ74pdkHY0/W4Ba6MUHR+sZfXPU+GBD9T86O1eNiXcp+djjUljE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 29 Mar 2013 16:49:46 -0000 Date: 29 Mar 2013 12:50:08 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-575718973-1364575808=:7038" Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:50:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-575718973-1364575808=:7038 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >>> No. A client that doesn't send an Accept: header is not an rdap >>> client, so it makes sense to return a generic format that a generic >>> client (e.g. a web browser) can render. >>> >> This generic format (probably html based) is described in an other >> (future) weirds document? > It is JSON, specified in draft-ietf-weirds-json-response. Other way around. An rdap client asks for a json response, and gets a json response. A non-rdap client asks for something else. Since it's not rdap, the server can return whatever it wants. This is not an interoperability issue, so there's no reason to define it further. The non-normative note suggests that since the non-rdap clients is likely to be a web browser, something a browser could render would be nice. This is in fact what Andy's protoype does. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-575718973-1364575808=:7038 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI5MTY1MDA4WjAjBgkqhkiG 9w0BCQQxFgQUnvf9VSJd4Nr9qBK9TR7Fa9XvKOAweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAHgKbw0ODMgny m8JFUQ+jLj6yVjC5nwhRyg3iCUvws7QksWNSkx07wc+mh1axwu8T0HCc6zsl BmFtkTN9HCG/0HOYUfauCI+cwNydjzZJdmtLKUGe1NgZTM56MDp0/B1Yk1yr vqZ/hqhaxSGlzVOx+fLWRETiZONZ+dVQAzamYNBOS+D2k/FWa5n7BxYvWLc2 PMBa0nvSHseFHkbshHo/JwI6IWe1IRr7R8WM7IE1pz0L2dIZ2wIGfnMG6U5f pErUFjTT8aC9czzUeTylf8sRDQ//pVMgpvpLwwdKUhvgTkKhiWhg/m9pPNgq SC+RH8rlBN1ooCWOxEDUwpj1+Kw8TQ== --3825401791-575718973-1364575808=:7038-- From andy@arin.net Fri Mar 29 09:51:13 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A0C21F944B for ; Fri, 29 Mar 2013 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5VnTDS-nQkE for ; Fri, 29 Mar 2013 09:51:10 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 741A821F944D for ; Fri, 29 Mar 2013 09:51:07 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 9D3CC2136AE; Fri, 29 Mar 2013 12:51:07 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 12BB72136AA; Fri, 29 Mar 2013 12:51:07 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 12:50:44 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 12:51:06 -0400 From: Andy Newton To: "Murray S. Kucherawy" , Alan Maitland Thread-Topic: [weirds] Search documents Thread-Index: AQHOK2AjtMRBPdqICkairG2vBzvmL5i7vFSAgAB6KwCAAK33gA== Date: Fri, 29 Mar 2013 16:51:05 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284CHAXCH01corpari_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:51:14 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Thursday, March 28, 2013 10:28 PM To: Alan Maitland > Cc: "weirds@ietf.org" > Subject: Re: [weirds] Search documents I believe the intent would be that all WEIRDS implementations would have to= comply with the core search document (in addition to the others already in= the set), and then could optionally also implement what the extended searc= h document describes. I think we need to be careful with the first part of you sentence. Not all = searches apply equally across the space so "comply" might have multiple mea= nings to multiple people. For example, a partial word match for domain name= s makes a lot of sense in the DNR area as they deal with forward DNS, but i= t doesn't seem particularly interesting in the RIR area with reverse DNS. N= o matter basic or advanced search, there needs to be proper signaling from = a server to a client say "I don't support that". -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <5A151224F93D3D40B96E64AC32820FA8@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Thursday, March 28, 2013 10:2= 8 PM
To: Alan Maitland <AMaitland@commerco.com>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] Search docume= nts

I believe the intent would be that all WEIRDS implementations would have to = comply with the core search document (in addition to the others already in = the set), and then could optionally also implement what the extended search= document describes.

I think we need to be careful with the first part of you sentence. Not= all searches apply equally across the space so "comply" might ha= ve multiple meanings to multiple people. For example, a partial word match = for domain names makes a lot of sense in the DNR area as they deal with forward DNS, but it doesn't seem particularly i= nteresting in the RIR area with reverse DNS. No matter basic or advanced se= arch, there needs to be proper signaling from a server to a client say &quo= t;I don't support that".

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284CHAXCH01corpari_-- From stpeter@stpeter.im Fri Mar 29 09:51:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EADD21F9453 for ; Fri, 29 Mar 2013 09:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhy6gILIjnzi for ; Fri, 29 Mar 2013 09:51:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A121F9452 for ; Fri, 29 Mar 2013 09:51:20 -0700 (PDT) Received: from [10.129.24.115] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D46240D48; Fri, 29 Mar 2013 11:00:47 -0600 (MDT) Message-ID: <5155C685.9070609@stpeter.im> Date: Fri, 29 Mar 2013 10:51:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Olaf Kolkman References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> <5155B29D.3000301@stpeter.im> <48791875-50CB-4D54-9A36-DBAD8700E453@NLnetLabs.nl> In-Reply-To: <48791875-50CB-4D54-9A36-DBAD8700E453@NLnetLabs.nl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 16:51:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/29/13 10:33 AM, Olaf Kolkman wrote: > > On Mar 29, 2013, at 4:26 PM, Peter Saint-Andre > wrote: >> Are we looking for documentation examples or examples for >> real-world testing? > > Documentation. In that case just do names of the form *.example (from RFC 2606). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVcaEAAoJEOoGpJErxa2pnh4P/32YSAUhZmxB5uEPPezxNc1U wn0jGOOLv5CGnbM9ayXc/rxnh/0JaJFxUwUQoCuWeDN+Tc6Bd+iGfduZvNaNbqVO VlBl+Lame3Pm8CBrrf2jLihqLufZ0qgyKK/NeF2cPKWSmyrsO/pV9gdkUfbNmeJP 4ZEVmc6Q1s9NIB6lagamTlUsvBx7y4ZdkMuJY+ibD23BLF4lyq/bcHKxZP+7kWJY /sRhr5TYrmH0lH/+pTJgaNC0oGvwvhjt9hubCIQOIRWPeJfcbqahF6zb2s4FbB3D 1EVFeOWzJq/2fU9X4quxOKao/1ARpgLXItuA/QF5KLQ6dUf8lG1TlYXpuXw7h/4G FEgeiU+kS0SqYhU01vOgLnAlu/O5dT3pQDiwJB4R+qN6PSKIjdlFwdojLb8Mzjs1 3Cy8HIJib9c3o19GEgvFIopD5M4iF5biiXQoWFHp64kb1uxlZqPx6RRXHH+rueoM gqRf089AOJAJq8Soohfojf/Rish+nxy4fXSNmM/z6GOQMzr4Ij2j9pP6FrbTVlyv bNTEWiibavCdwEHPzz5SeOeG3iwA8HzIH35V4RGq95FFTD0cuSnJsQBB5fLEGbbA lMj57gEVisbJRgagvJxEwYCTeMqEXO+EsRe2lMnbHgmuWRSAxob7OyGkhAvDidpF Bme1+dSXx3DvXTX3L7P7 =Axo9 -----END PGP SIGNATURE----- From andy@arin.net Fri Mar 29 10:07:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD221F9439 for ; Fri, 29 Mar 2013 10:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMywXxftC8BJ for ; Fri, 29 Mar 2013 10:07:14 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id AC63021F9431 for ; Fri, 29 Mar 2013 10:07:13 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 5F0C1165376; Fri, 29 Mar 2013 13:07:13 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id E4671165372; Fri, 29 Mar 2013 13:07:12 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 13:06:50 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 13:07:13 -0400 From: Andy Newton To: John R Levine Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i77WAAgAArEoCAAJ3PAIAAK74AgABF6AD//8G0AA== Date: Fri, 29 Mar 2013 17:07:11 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF82DB@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CC5AC089935EC42AC2DE2C78255176A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:07:14 -0000 On 3/29/13 12:50 PM, "John R Levine" wrote: >>>>No. A client that doesn't send an Accept: header is not an rdap >>>>client, so it makes sense to return a generic format that a generic >>>>client (e.g. a web browser) can render. >>>> >>>This generic format (probably html based) is described in an other >>>(future) weirds document? > >>It is JSON, specified in draft-ietf-weirds-json-response. > >Other way around. An rdap client asks for a json response, and gets a >json response. Sorry. I misread. You are right. -andy From johnl@iecc.com Fri Mar 29 10:13:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832F21F86B9 for ; Fri, 29 Mar 2013 10:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.169 X-Spam-Level: X-Spam-Status: No, score=-111.169 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBnLv4f8vbA8 for ; Fri, 29 Mar 2013 10:13:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4F21F8696 for ; Fri, 29 Mar 2013 10:13:25 -0700 (PDT) Received: (qmail 35146 invoked from network); 29 Mar 2013 17:13:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 17:13:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155cbb3.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=WCsZRgRZp+VsGR3MJAANo5TRCovKjp6i+uwKRE/gJOg=; b=E7o7s/qxMIS0dwzs0zCrblf78bnu3oFmLfW8cqudnsjKBz5S6MqLNEMF47SIsP8Jp2MgVHUPkV3BplATK9/ewD3XO+aRnuaqc/jwil1goG8se5WTOElRYeyjaEKxakcK9GqO2tz0q65Gs56U6AdjgseQw6YvXpQae6jjs3be8kI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155cbb3.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=WCsZRgRZp+VsGR3MJAANo5TRCovKjp6i+uwKRE/gJOg=; b=O8IRUEwT0DHlXxEwPZ363+X6PYWXkeumpS35hZu1Du7bImrAWYISKEOyB8LtNw6WMMQhjYWx6O4iIdzcqInyizrf+bpSHFPnDhLkaRuRdDit/s/DK9rEdw0jTdd0GCmhpTpFOSBTsa2nox5BLxmR3iossz8JhLtL7DgfwdOl92w= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 17:13:01 -0000 Message-ID: <20130329171301.7489.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <48791875-50CB-4D54-9A36-DBAD8700E453@NLnetLabs.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] reserved names, was U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:13:26 -0000 >> Are we looking for documentation examples or examples for real-world >> testing? > >Documentation. The only reserved TLDs are the ones listed in RFC 2606: .test. .example, .invalid, and .localhost. RFC 6761 created a registry and the process for adding new ones, but there have not yet been any new ones. ICANN's new TLD applicant guidebook has a list of reserved TLDs on pages 2-9 and 2-10, including those four and 30 others, all ASCII. They have an additional list on page 2-11 of reserved names related to the Red Cross and Olympics, both ASCII and IDN. Regretably, they didn't (as far as I know) consult with the IETF on any of them so it's unclear how reserved they really are beyond the current round of TLD applications. So I agree, use .example. If you want to use exámple.com for a sample IDN, the registrant probably won't object. From johnl@iecc.com Fri Mar 29 10:17:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EF321F9434 for ; Fri, 29 Mar 2013 10:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.172 X-Spam-Level: X-Spam-Status: No, score=-111.172 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTxFtO+Bi882 for ; Fri, 29 Mar 2013 10:17:31 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6F21F86CE for ; Fri, 29 Mar 2013 10:17:30 -0700 (PDT) Received: (qmail 36426 invoked from network); 29 Mar 2013 17:17:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 17:17:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155ccaa.xn--3zv.k1303; i=johnl@user.iecc.com; bh=Xl7GiOiA5J4c30IB8IW/SBPb3QldXMwiCCn+0cB5dwU=; b=x1V1CcaCG5ubZK4x+PiL6q9yxrrX+oIPGG8HkmAupgV9yim3pskeCX914Pa5aVoc4cxOqV1D6xEZHTC3zlH0IM8tczxWqrYW3ASXT3HZ35jj/xPK3KjncAjgeDToWizAjvLfu6NjtVWSKMGRMc5ctgSiJIMqbhPhfjtns6HAqYg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155ccaa.xn--3zv.k1303; olt=johnl@user.iecc.com; bh=Xl7GiOiA5J4c30IB8IW/SBPb3QldXMwiCCn+0cB5dwU=; b=gIjQe4A9sAak5KuqiQ9ySOfLV7kKwYm/1Q9zvZ3KdqpmoHMd6yUsNsszv7ppULPRDNa9NmFaI6VmvmyRQa6M+0DeSapbuP6zMLJ4HmBQ5W/4ayqNffoMD3/IA+bHeiR7lHpAhyfy1AO8kRQBvBHSn82nwJJsUkEhxFuO6Gbn+l0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 17:17:07 -0000 Message-ID: <20130329171707.7514.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8263@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:17:32 -0000 >This working group is chartered for a replacement of Whois, not the >standardization of a lightweight domain name availability check. That >being said, we probably should support HEAD and if it solves the problem >then so be it. :) I agree, HEAD is harmless and a lot of servers will probably support it for free anyway. On the other hand, from the point of view of network traffic, there's no interesting difference between a finger request and an http GET. Each opens a TCP circuit, sends some text for the request, gets back a chunk of text in the response, and closes the circuit. The amount of text in a GET is larger, but we're not using 1200 bps modems any more, and the request and response can both likely fit in a single packet with typical MTUs. From johnl@iecc.com Fri Mar 29 10:28:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6821F8712 for ; Fri, 29 Mar 2013 10:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.174 X-Spam-Level: X-Spam-Status: No, score=-111.174 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z81eQvEtIdjP for ; Fri, 29 Mar 2013 10:28:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88121F86D9 for ; Fri, 29 Mar 2013 10:28:10 -0700 (PDT) Received: (qmail 39291 invoked from network); 29 Mar 2013 17:28:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 17:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155cf28.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=bpXH1X/p3qvHmgb9IceshZ3nIf87pl3Iv8g3Hh57aEM=; b=k9XXqTdOx0uhm/KySSI+y3P7PpWduYKLtOGytTE3LNVvTmJ5IgtqfMS885VopMIlXqLIM43RI/0XK9iewJp4FYmCChI81Tb9F0I7pzbrsO3iU8NHHcLPDJfQ4bKC9D5MhtuhV78WUpt9nfF0+xNL2a7ndQAiw3d9rUhEk2BywSU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5155cf28.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=bpXH1X/p3qvHmgb9IceshZ3nIf87pl3Iv8g3Hh57aEM=; b=Xza1BdNxC+vQyfV83sgPNa2A09Jbb9xO4/THfFMmiTJlpBnsKgmLQTgjxJ3cGzptnOsrboUqxPp3hwCSgtaoxk7QkbiO6qcIpMjtHNlTnjDw8PwhQ+s15wpMf/4YZJQgJdqThXOicjAse/IDRrsa0ad6V6v8ZiT9087uSAgfYoY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 17:27:46 -0000 Message-ID: <20130329172746.7552.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284@CHAXCH01.corp.arin.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:28:11 -0000 >I believe the intent would be that all WEIRDS implementations would have to comply >with the core search document (in addition to the others already in the set), and >then could optionally also implement what the extended search document describes. So long as comply with means understand the syntax of rather than implement the semantics of, I think we're OK. There are plenty of ccTLD WHOIS servers that provide no search at all, and I don't expect that to change. An implementation that returned "403 No search for you" to any search request would comply. From superuser@gmail.com Fri Mar 29 12:29:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF2F21F85B2 for ; Fri, 29 Mar 2013 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8+95HSOP5gV for ; Fri, 29 Mar 2013 12:29:28 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3121F859A for ; Fri, 29 Mar 2013 12:29:28 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id n12so652170wgh.31 for ; Fri, 29 Mar 2013 12:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f8Woc/qaJD2tY10yMpjjDbil8z9b84S294wKqQJetPs=; b=KkXlqWethqo0JNp7FnM8p6SlgXkQ6X12MTgFk83X8aBcRJZ7GI5H+916BH8V6blb4y 20bnmpUZv21kIhW6BTL6gIBFab/KSwsnBCFAdOwr0r+orNF4uJ7EptrYiHdWibRHQ79k Y58oWjPRMX4Rtaw3YHFO6JfZM5shX22EzUanDuEx83c76wb1nHi4d7B3hDyFCiKhAQWl P2xtPt0WMN4LcDI9RYKMc7srPitgJRIfhAXe//MGfIp0F2d0ELXLohVJUhUSnGNs4mHc Ecy75VscTxkYxQzXStdfzv5UKA1JKgpecmORCDuS3uHfqNnUf2hEXbB/UiTgqfNEyv2x 4WCw== MIME-Version: 1.0 X-Received: by 10.194.134.66 with SMTP id pi2mr5173786wjb.51.1364585367383; Fri, 29 Mar 2013 12:29:27 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 12:29:27 -0700 (PDT) In-Reply-To: <20130329172746.7552.qmail@joyce.lan> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284@CHAXCH01.corp.arin.net> <20130329172746.7552.qmail@joyce.lan> Date: Fri, 29 Mar 2013 20:29:27 +0100 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01228fbe16b9c404d9154a75 Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:29:29 -0000 --089e01228fbe16b9c404d9154a75 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the corrections. I think we're still in the ballpark I was intending; a base WEIRDS implementation would have to do what the basic search document says even if that means a way to reply "I don't support that search", while the same implementation could completely ignore the extended search document's ideas. We might want to have the capability to ask a WEIRDS server for a capabilities list. Would that be hard to add to the documents we have now, or is it already in there someplace? -MSK On Fri, Mar 29, 2013 at 6:27 PM, John Levine wrote: > >I believe the intent would be that all WEIRDS implementations would have > to comply > >with the core search document (in addition to the others already in the > set), and > >then could optionally also implement what the extended search document > describes. > > So long as comply with means understand the syntax of rather than > implement the semantics of, I think we're OK. > > There are plenty of ccTLD WHOIS servers that provide no search at all, > and I don't expect that to change. An implementation that returned > "403 No search for you" to any search request would comply. > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --089e01228fbe16b9c404d9154a75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the corrections.=A0 I think we're stil= l in the ballpark I was intending; a base WEIRDS implementation would have = to do what the basic search document says even if that means a way to reply= "I don't support that search", while the same implementation= could completely ignore the extended search document's ideas.=A0 We mi= ght want to have the capability to ask a WEIRDS server for a capabilities l= ist.=A0 Would that be hard to add to the documents we have now, or is it al= ready in there someplace?

-MSK


On Fri, Mar 29, 2013 at 6:27 PM, John Levine &= lt;johnl@taugh.com= > wrote:
>I believe the intent w= ould be that all WEIRDS implementations would have to comply
>with the core search document (in addition to the others already in the= set), and
>then could optionally also implement what the extended search document = describes.

So long as comply with means understand the syntax of rather than
implement the semantics of, I think we're OK.

There are plenty of ccTLD WHOIS servers that provide no search at all,
and I don't expect that to change. =A0An implementation that returned "403 No search for you" to any search request would comply.

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--089e01228fbe16b9c404d9154a75-- From superuser@gmail.com Fri Mar 29 12:42:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018B521F8EA7 for ; Fri, 29 Mar 2013 12:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUfWglnSq4DR for ; Fri, 29 Mar 2013 12:42:47 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7C21F8E6D for ; Fri, 29 Mar 2013 12:42:46 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id x43so564025wey.14 for ; Fri, 29 Mar 2013 12:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VnwjixgyjWFBegPU9plqPRVJpuzgasqCKkNMmwPjhDY=; b=p+TYwu74RnyceYk3/MEnBPqJ2HmwoTsJRenV2kU6lw+FVwIXnIOH2lo4BQY48EXAye irJrb3LiqWgkY7s8+itQlwzHz7I42JPI6f6YXjoUiH0/fxWNZOKZhUYvADBNEquVslJM otSQadX+3pEf/fBBYDX8OVXYIfrmfabAsDFKq0c9d1ju0U72jv/sxh7shXaHofTIKnAr 3/Z+DS2NUQ0OQspLc7fpphUh9ncynk0bwtSGvXHAIFmSqHxkINiJnKaRQPxliqC0jaoj O/CsA3aAog+xdXmmbHDZxqKBx8HOa9m2Pbo7PWgxHSat08dAxhchRwYObL/dDnvVNZ6q ifgA== MIME-Version: 1.0 X-Received: by 10.194.134.66 with SMTP id pi2mr5215182wjb.51.1364586165824; Fri, 29 Mar 2013 12:42:45 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 12:42:45 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8218@CHAXCH01.corp.arin.net> Date: Fri, 29 Mar 2013 20:42:45 +0100 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=089e01228fbeadf67104d9157931 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:42:48 -0000 --089e01228fbeadf67104d9157931 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 29, 2013 at 5:39 PM, Andy Newton wrote: > From: "Murray S. Kucherawy" > Date: Thursday, March 28, 2013 10:51 PM > To: "weirds@ietf.org" > Subject: Re: [weirds] Working Group Last Call: > draft-ietf-weirds-using-http > > 1) "COMMON" doesn't strike me as a "brief reason for a registry > entry". (Or perhaps it's overly brief.) Either the name for that field > should change to something like "Brief description" and the example updated > accordingly, or the definition of "Intended usage" should be updated to > match the intent. RFC6838 is the new media type registration document > which we could use as a reference here. > > > > From RFC 6838: > > Intended usage: > > (One of COMMON, LIMITED USE, or OBSOLETE.) > > > > Are you saying we should use something else? > I think the sample is fine, but the description (above that in the same section) is bogus. I think Specification Required is fine, personally. I just know that this is a current pet peeve of at least one current IESG member, so I want us to be prepared if the question comes. I can't think of any specific text other than perhaps your own text just now that we could add to get out in front of the question. -MSK --089e01228fbeadf67104d9157931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 29, 2013 at 5:39 PM, Andy Newton <andy@arin.net> wrote:
From: "Murray S. Kucherawy&quo= t; <superuser@g= mail.com>
Date: Thursday, March 28, 2013 10:5= 1 PM
To: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Working Group= Last Call: draft-ietf-weirds-using-http

1) "COMMON" doesn't strike me as a "brief reason fo= r a registry entry".=A0 (Or perhaps it's overly brief.)=A0 Either = the name for that field should change to something like "Brief descrip= tion" and the example updated accordingly, or the definition of "= Intended usage" should be updated to match the intent.=A0 RFC6838 is the new m= edia type registration document which we could use as a reference here.


From RFC 6838:

Intended usage:

   (One of COMMON, LIMITED USE, or OBSOLETE.)


Are you saying we should use something else?
<= div>
I think the sample is fine, but the description (above t= hat in the same section) is bogus.

I think Specification = Required is fine, personally.=A0 I just know that this is a current pet pee= ve of at least one current IESG member, so I want us to be prepared if the = question comes.=A0 I can't think of any specific text other than perhap= s your own text just now that we could add to get out in front of the quest= ion.

-MSK
--089e01228fbeadf67104d9157931-- From andy@arin.net Fri Mar 29 13:19:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857C021F8BEB for ; Fri, 29 Mar 2013 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Se3YeOwaml for ; Fri, 29 Mar 2013 13:19:08 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 797F021F8BE9 for ; Fri, 29 Mar 2013 13:19:08 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 1BBF61653B1; Fri, 29 Mar 2013 16:19:08 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 585161653AB; Fri, 29 Mar 2013 16:19:07 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 29 Mar 2013 16:18:44 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 29 Mar 2013 16:19:06 -0400 From: Andy Newton To: "Murray S. Kucherawy" , John Levine Thread-Topic: [weirds] Search documents Thread-Index: AQHOK2AjtMRBPdqICkairG2vBzvmL5i7vFSAgAB6KwCAAK33gIAATUwAgAAh/4D//8rUAA== Date: Fri, 29 Mar 2013 20:19:05 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AA@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.34.130] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AACHAXCH01corpari_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:19:09 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AACHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Friday, March 29, 2013 3:29 PM To: John Levine > Cc: "weirds@ietf.org" > Subject: Re: [weirds] Search documents Thanks for the corrections. I think we're still in the ballpark I was inte= nding; a base WEIRDS implementation would have to do what the basic search = document says even if that means a way to reply "I don't support that searc= h", while the same implementation could completely ignore the extended sear= ch document's ideas. We might want to have the capability to ask a WEIRDS = server for a capabilities list. Would that be hard to add to the documents= we have now, or is it already in there someplace? No, there is no capabilities query. It is easy enough to add with a new pat= h in the unified-queries document and a simple JSON object containing only = the rdapConformance structure would satisfy it. However, how granular do you want to go with this? Should support for each = query path be listed? With regards to search, should partial matching on pr= efixes be listed separately from partial matching on suffixes? How complica= ted do we want to get with it? Also, what does a client really do with this information? Do we envision th= e client asking for capabilities first and the making a yes/no decision abo= ut issuing a query? I would think the interaction pattern would actually be= that the client issues the query regardless, and if it gets back an "I don= 't do that" message it reports that back. Fewer round trips and less logic. It also strikes me that if we don't have a clear idea of what we want with = a capabilities query, we can always add it later when we have a much better= idea. On Fri, Mar 29, 2013 at 6:27 PM, John Levine > wrote: [..snip..] There are plenty of ccTLD WHOIS servers that provide no search at all, and I don't expect that to change. An implementation that returned "403 No search for you" to any search request would comply. Do we need to add this to draft-ietf-weirds-using-http? Even with lookups i= t is unlikely that DNRs will support IP address and ASN lookups. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AACHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <34D14C2AC20F0843958716B4AA04A39C@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Friday, March 29, 2013 3:29 P= M
To: John Levine <johnl@taugh.com>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] Search docume= nts

Thanks for the corrections.  I think we're still in the ballpark = I was intending; a base WEIRDS implementation would have to do what the bas= ic search document says even if that means a way to reply "I don't sup= port that search", while the same implementation could completely ignore the extended search document's ideas.  We mig= ht want to have the capability to ask a WEIRDS server for a capabilities li= st.  Would that be hard to add to the documents we have now, or is it = already in there someplace?

No, there is no capabilities query. It is easy enough to add with a ne= w path in the unified-queries document and a simple JSON object containing = only the rdapConformance structure would satisfy it.

However, how granular do you want to go with this? Should support for = each query path be listed? With regards to search, should partial matching = on prefixes be listed separately from partial matching on suffixes? How com= plicated do we want to get with it?

Also, what does a client really do with this information? Do we envisi= on the client asking for capabilities first and the making a yes/no decisio= n about issuing a query? I would think the interaction pattern would actual= ly be that the client issues the query regardless, and if it gets back an "I don't do that" messa= ge it reports that back. Fewer round trips and less logic.

It also strikes me that if we don't have a clear idea of what we want = with a capabilities query, we can always add it later when we have a much b= etter idea.

On Fri, Mar 29, 2013 at 6:27 PM, John Levine <johnl@taugh.com> wrote:

[..snip..]


There are plenty of ccTLD WHOIS servers that provide no search at all,
and I don't expect that to change.  An implementation that returned "403 No search for you" to any search request would comply.

Do we need to add this to draft-ietf-weirds-using-http? Even with look= ups it is unlikely that DNRs will support IP address and ASN lookups.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AACHAXCH01corpari_-- From johnl@taugh.com Fri Mar 29 14:06:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C621F926A for ; Fri, 29 Mar 2013 14:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HVdaWLNr5r9 for ; Fri, 29 Mar 2013 14:06:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4756D21F8F70 for ; Fri, 29 Mar 2013 14:06:32 -0700 (PDT) Received: (qmail 99250 invoked from network); 29 Mar 2013 21:06:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=183b1.51560258.k1303; bh=hI+x4uRVYSInPYNAPY9j351p/gAmgwwiofSaQwXfOu4=; b=vuyju70JZID/DKMVkYajG+4Ao7U8srA7b3UU1iOheUvkkKydWa1qZk8ZbGGDHT4a5+8cAj3bXEMg9ZuIJWP3mJUrNwHiTaNm2OMJwFjUJliNQ3jXp+DgMRhhtbsh0aDKJIH/kCgEZLt0mnVMVPG8xSPpR6UBxAYUkXnD8yCuIHg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=183b1.51560258.k1303; bh=hI+x4uRVYSInPYNAPY9j351p/gAmgwwiofSaQwXfOu4=; b=S1We5bxatbFrwAaOXSvPKUN4zKXqtmlRCoAOkZLlUaTuF6z6Q2acBk/s61NwTFWx8HDmXL3roKi7Zx2FonseVzPQVpch68kRFVz+GMmPgK3lKKAwGJ0uDKLOsQghxXoDnWFgoMCTExIJe01fPo5w2wwBgFckqVn9CzUNKmzZfwk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 29 Mar 2013 21:06:09 -0000 Date: 29 Mar 2013 17:06:31 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AA@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF84AA@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1510559654-1364591191=:8645" Cc: "weirds@ietf.org" Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:06:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1510559654-1364591191=:8645 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Also, what does a client really do with this information? Do we envision > the client asking for capabilities first and the making a yes/no > decision about issuing a query? I would think the interaction pattern > would actually be that the client issues the query regardless, and if it > gets back an "I don't do that" message it reports that back. Fewer round > trips and less logic. That was my thought. I really don't want WEIRDS to end up as complicated as IMAP, or even as POP. Ask a question, either you get the answer or you don't, and a relatively smart client might remember not to ask the kinds of questions that have gotten rejected before. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1510559654-1364591191=:8645 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI5MjEwNjMxWjAjBgkqhkiG 9w0BCQQxFgQUCsfESqUV6fGaacEcdD7A77MzrLAweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAn/udRAYLS0Ay Y0iA3SiLBx9wkmWZ8OxdPcrTjJto/59ntAwoSclt3AIki9oXGypR3ft0q/kS HZhWFvWRQRWrBYo5OCz2Z6CsnrrDEebl2SzkoinAfs4RQshLb1yV0fDVFAD4 WzUxSJ1t5gu6zHI7QI+8p3/My7Lf7v7Mcz9CjQ/JecTLQOrQoMW8PtfamjiR MBWvpbktbqo0XRTwOf05rvALZqiutwvDCAhsAvrdnvi/ljKJ08/97rFqD6R1 FIa9z8iNxUkdQ4bXbJFYU43Qdr94qQCnnOy3+Bd/kxaxvxw1Qrokq0Nd/oiX F6AinHQvml26hObc2CJBrHWn5NEBFg== --3825401791-1510559654-1364591191=:8645-- From alexander.mayrhofer@nic.at Fri Mar 29 14:39:19 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5592221E808D for ; Fri, 29 Mar 2013 14:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.247 X-Spam-Level: X-Spam-Status: No, score=-9.247 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTq3kFkY-VrU for ; Fri, 29 Mar 2013 14:39:18 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5900821E808C for ; Fri, 29 Mar 2013 14:39:14 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Fri, 29 Mar 2013 22:39:13 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 29 Mar 2013 22:39:11 +0100 From: Alexander Mayrhofer To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Search documents Thread-Index: AQHOK2AN0m5iLFnn00CPyWBy/Qst2pi7aIOAgAB6KgCAAPEDgIAACkAAgABUKgA= Date: Fri, 29 Mar 2013 21:39:10 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982F887@NICS-EXCH.sbg.nic.at> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8284@CHAXCH01.corp.arin.net> <20130329172746.7552.qmail@joyce.lan> In-Reply-To: <20130329172746.7552.qmail@joyce.lan> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:39:19 -0000 > >I believe the intent would be that all WEIRDS implementations would > >have to comply with the core search document (in addition to the others > >already in the set), and then could optionally also implement what the > extended search document describes. >=20 > So long as comply with means understand the syntax of rather than > implement the semantics of, I think we're OK. >=20 > There are plenty of ccTLD WHOIS servers that provide no search at all, an= d I > don't expect that to change. An implementation that returned > "403 No search for you" to any search request would comply. [Alexander Mayrhofer]=20 I think we need to go one step further - *any* type of search needs to be O= PTIONAL (allowing servers to return eg. 404 for the respective path, rather= than 403) in order to gain broad adoption. 403 could be interpreted as "oh= , i just need a different identity or trust relation with the operator in o= rder to gain access", which could be dangerously misleading.=20 Alex From alexander.mayrhofer@nic.at Fri Mar 29 14:50:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE821F94A4 for ; Fri, 29 Mar 2013 14:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.273 X-Spam-Level: X-Spam-Status: No, score=-9.273 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi+MX-l100Jy for ; Fri, 29 Mar 2013 14:50:40 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 44B4221F94A6 for ; Fri, 29 Mar 2013 14:50:39 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Fri, 29 Mar 2013 22:50:38 +0100 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 29 Mar 2013 22:50:36 +0100 From: Alexander Mayrhofer To: Andy Newton , Maarten Wullink , Pieter Vandepitte Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwue5Zoxq1BWXk25CcORrCdypJi7mY8AgAAIIoCAAM05AIAAMovAgAAxKgCAAGOdIA== Date: Fri, 29 Mar 2013 21:50:35 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750982F8B2@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE0750982F5E6@NICS-EXCH.sbg.nic.at> <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8263@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8263@CHAXCH01.corp.arin.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:50:41 -0000 > >We can solve this in the document by simply saying that servers SHOULD > >also support HEAD, and leave the decision whether or not to provide > >GET-identical headers to the implementors. >=20 > I agree. We should just say that HEAD should be supported. Now is that a > SHOULD or a MUST. I think MUST given 2616's language. [Alexander Mayrhofer]=20 I think it's a MUST. However, we might want to clarify it comes from the HT= TP specs, rather than from the RDAP specs. Maybe something along the lines = of : "GET and HEAD are REQUIRED methods in HTTP. Therefore, RDAP servers M= UST implement at least those two methods".=20 Alex From johnl@iecc.com Fri Mar 29 14:51:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D117F21F95F2 for ; Fri, 29 Mar 2013 14:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.176 X-Spam-Level: X-Spam-Status: No, score=-111.176 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRQSmFBGtkAd for ; Fri, 29 Mar 2013 14:51:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9AD21F95F0 for ; Fri, 29 Mar 2013 14:51:07 -0700 (PDT) Received: (qmail 11233 invoked from network); 29 Mar 2013 21:51:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 21:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51560cca.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=0ttvk52/2vsYORwicRWybSptKS6trS4o/XclAEa4Ki0=; b=RtNJTOEjDgOnJTzDqC6LEqJVXgA+HPRG57/Kzgd7DoOMUVKMzMeNMV1Cds1Wu388cK8Hx9FAOgN9TU6PcmVJpFMWEad4URjBrTLbQVGLPow9Y97+/zyDjjiAQFDTmgS0jG+MqYepJpcili4W8AzaZ78JhQx5gicStUZ4+RSxiG4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51560cca.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=0ttvk52/2vsYORwicRWybSptKS6trS4o/XclAEa4Ki0=; b=jkonQwCI96idcS0CQVSfBeo9OrivOfFS+nmtZyIvQnecCtqgKkfuroYKsKoEQ94+wgtDlYs/Tc9MGqHTlTdAgXa0yKdmC7inDd3t+iH8MtMs6vkY6PvuaGuKS0LSBS3QutFrc6ZzwhAcR1tczNxRyReZjBiNheup71eCQ85x9QE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 21:50:44 -0000 Message-ID: <20130329215044.9162.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F887@NICS-EXCH.sbg.nic.at> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Search documents X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:51:09 -0000 >> There are plenty of ccTLD WHOIS servers that provide no search at all, and I >> don't expect that to change. An implementation that returned >> "403 No search for you" to any search request would comply. > >[Alexander Mayrhofer] >I think we need to go one step further - *any* type of search needs to be OPTIONAL (allowing >servers to return eg. 404 for the respective path, rather than 403) in order to gain broad >adoption. 403 could be interpreted as "oh, i just need a different identity or trust relation with >the operator in order to gain access", which could be dangerously misleading. >From RFC 2616: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. There are HTTP codes that mean you can get the answer with more authority, but 403 is not one of them. From johnl@iecc.com Fri Mar 29 15:23:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9144411E80A5 for ; Fri, 29 Mar 2013 15:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.178 X-Spam-Level: X-Spam-Status: No, score=-111.178 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7gqW2yTKVuQ for ; Fri, 29 Mar 2013 15:23:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4205B11E80A3 for ; Fri, 29 Mar 2013 15:23:30 -0700 (PDT) Received: (qmail 20573 invoked from network); 29 Mar 2013 22:23:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Mar 2013 22:23:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5156145f.xn--i8sz2z.k1303; i=johnl@user.iecc.com; bh=08tTMFqYGuMCXdtkIQVZzmcuhPd7w01n+nQwgKQnORU=; b=uU9JJVwsz6Dsz80IrO9oPcBkpN1wB/NmsBdd09z5ZVPdboT1eDmPFCeEuMmdqND4HCArkijW8n6j177xQTDJDFYys0F4QphJIBp5FsARq/puxzVl4AvOzhkr2n2YY+FGM0E5NJaXu4SFWCuwtuHackfLO3XDMhHDH6JWC1CqCUs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5156145f.xn--i8sz2z.k1303; olt=johnl@user.iecc.com; bh=08tTMFqYGuMCXdtkIQVZzmcuhPd7w01n+nQwgKQnORU=; b=FxfNX29s5YCHhmf+RrejQKiYwfx1CvIGMnZT2Mnyl1s1BMn6VVtRvWfhJSXkXEHvKDz+5kcwZPS4l0NqfTxmRuXq82oprHj7qPld1dZ3yZP5rI8Hxn4R0PMhMaR8CKcZNRMe3Z6iM3/DA+Qop9k8RYqn7Q6UHBElCNr3Zoig/Bg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Mar 2013 22:23:05 -0000 Message-ID: <20130329222305.9301.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F8B2@NICS-EXCH.sbg.nic.at> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 22:23:40 -0000 >> I agree. We should just say that HEAD should be supported. Now is that a >> SHOULD or a MUST. I think MUST given 2616's language. > >[Alexander Mayrhofer] >I think it's a MUST. However, we might want to clarify it comes from the HTTP specs, rather than >from the RDAP specs. Maybe something along the lines of : "GET and HEAD are REQUIRED methods in >HTTP. Therefore, RDAP servers MUST implement at least those two methods". Since RFC 2616 already makes GET and HEAD mandatory, the correct thing for us to say about that is nothing. It is rarely a good idea for one standards document to restate bits of another document, since the two statements never quite say the same thing. R's, John From sm@resistor.net Sat Mar 30 00:01:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3830121E804A for ; Sat, 30 Mar 2013 00:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibYcD7F+jMqF for ; Sat, 30 Mar 2013 00:01:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2DA21E8045 for ; Sat, 30 Mar 2013 00:01:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2U70i5k011561 for ; Sat, 30 Mar 2013 00:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364626852; bh=mTzy8TahHhFAY1qbhFRpBLLfZbnHvzcyKB/98zuR4AQ=; h=Date:To:From:Subject:In-Reply-To:References; b=D0M/I4T0lqDNS3y8YyGihggYa+aO+XzJj1pSwWpqb2eSGmXJhtD+iFOyqdtkaZH/S rkj8WTQHY2B7CSVjfMV3Ac2evST2UTLX1TGXyhAb42WWDSzILZPV4fcrRVzUPCkG14 lDuAxjFvQgJztenOKmu5SosSczJhvs45T37S5SBg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364626852; i=@resistor.net; bh=mTzy8TahHhFAY1qbhFRpBLLfZbnHvzcyKB/98zuR4AQ=; h=Date:To:From:Subject:In-Reply-To:References; b=DIvhm0aIfQtmKr8cey4pdLLFKLVc7ZIXp5R753Uo+9I31cnO+O47h+dI1Q2DHd/Au vU6ZjdLThv/m2N4yDoeVBGk/heRrJu2ft7U2D2Hn5o1Dw4pzZGFDGTO6BSaNgCvttL Qgesxud01rrIBqgPUXw8XbFyRlJ1SaVHZOBu6t+Y= Message-Id: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Mar 2013 23:44:02 -0700 To: weirds@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:01:04 -0000 At 09:53 27-03-2013, Murray S. Kucherawy wrote: >We would like to initiate a two-week Working Group Last Call on >draft-ietf-weirds-http. A version 03 was just pushed to the datatracker: Please note that I am commenting as an individual. The Abstract mentions that: "This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP." The Introduction Section mentions that: "This document describes the usage of HTTP for Registration Data Directory Services running on RESTful web servers." I guess that the Abstract needs to be updated. In the Introduction Section: "In designing these common usage patterns, this draft endeavours to satisfy requirements for a Registration Data Access Protocol (RDAP)." As a nit, "draft". I read the Introduction Section and I did not find anything explicit about the Registration Data Access Protocol. There is however an example which tries to explain how this protocol works. Where is this Registration Data Access Protocol specified? In Section 2: "[SAC-051] describes a protocol profile of RDAP for Domain Name Registries (DNRs), DNRD-AP." Please "expand on first use". "This document and others from the IETF WEIRDS working group describe a single protocol, RDAP, for access to the data of both DNRs and Regional Internet Registries (RIRs)." What does this have to do with terminology? "RIRs are also often referred to as number resource registries and are responsible for the registration of IP address networks and autonomous system numbers." What does this have to do with terminology? In Section 3: "Third, HTTP offers a number of transport protocol mechanisms not described further in this document. Operators are able to make use of these mechanisms according to their local policy, including cache control, authorization, compression, and redirection." Hmm, that does not sound like transport protocol mechanisms to me. "HTTP also benefits from widespread investment in scalability, reliability, and performance, and widespread programmer understanding of client behaviours for RESTful web services, reducing the cost to deploy Registration Data Directory Services and clients." I heard that one before. :-) Section 3 starts with "query" and ends with HTTP for the naive programmer argument. I suggest reordering the design intent starting from the "top". In Section 4.1: "RDAP clients MUST include an Accept: header specifying application/ rdap+json, application/json, or both. Servers receiving an RDAP request MUST return an entity with Content-Type application/ rdap+json." What are RDAP clients? I guess that the problem is that the draft explains it by example (Section 1) instead of specifying it. In Section 4.2: "Servers SHOULD ignore unknown query parameters. Use of unknown query parameters for cache-busting is described in Appendix A." Why is there a "MAY" in the Appendix? When should servers not ignore "unknown query parameters"? What are "servers"? In Section 5: "While no standard HTTP response code is forbidden in usage, at a minimum clients SHOULD understand the response codes described in this section." Why is this a SHOULD? In Section 5.1: "If a server has the information requested by the client and wishes to respond to the client with the information according to its policies, it SHOULD encode the answer in the format most appropriate according to the standard and defined rules for processing the HTTP Accept header, and return that answer in the body of a 200 response." I can understand that this working group feels strongly about policy. The question of whether the server is willing to provide the information is irrelevant. If the server is providing the information, it returns a body with a 200 response code. The specification does not have to put policy in every place. In Section 5.2: "If a server wishes to inform a client that the answer to a given query can be found elsewhere, it SHOULD return either a 301 or a 307 response code and an HTTP URL in the Location: header." I see two response codes in the above? I see a "SHOULD". I suggest being clear or else it will lead to diverging implementations. The above can be restated in terms of what the response code means. "A server SHOULD use a 301 response to inform the client of a permanent move and a 307 response otherwise." This makes it two SHOULDs. Why can't that be explained with one SHOULD? In Section 5.3: "If a server wishes to respond that it has no information regarding the query, it SHOULD return a 404 response code." Why is this a SHOULD? In Section 5.4: "If a server receives a query which it cannot understand, it SHOULD return a 400 response code." Why is this a SHOULD? By the way, on reading of the sentence only I would say that the 400 response code is not appropriate. In Section 5.5: "When a server declines to answer a query due to rate limits, it MAY return a 429 response code as described in [RFC6585]." Why is this a MAY? In Section 6: "First, client implementers using modern programming languages such as Ruby or Java may use libraries that automatically promote JSON names to first order object attributes or members." It's not the purpose of this working group to be the marketing arm of Java or Ruby. :-) In Section 7.1: "In accordance with RFC5226, the IANA policy for assigning new values shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible." Note that this is IANA considerations. I suggest not calling it "IANA policy". I suggest not restating what is in RFC 5226 as it may end up being problematic in future (nothing to do with the working group). Why is the policy "specification required"? In Section 8.2: "Depending on the data format of the response, servers MAY include data in character sets other than ASCII and languages other than English (the data format will most likely be in Unicode and almost certainly languages other than English will be encountered)." This comes out as hand-waving the internationalization question. From the charter: "WHOIS has never been internationalized. In the absence of formal specification, ad hoc solutions to signal internationalized registration data have been adopted and deployed. Providing a standards-based solution that scales well could minimize further proliferation of ad hoc solutions." It seems to me that the working group has been working on Whois over HTTP instead of internationalization. draft-ietf-weirds-using-http-03 is well-written. My reading of it is that it is under-specified. I suggest framing the draft in terms of HTTP. It will give everyone what he or she wants while disguising the draft as an IETF specification. :-) There isn't a Security Considerations section in the draft. My hypothesis [1] is that a draft intended to be published on the Standards Track to make it there is very low if there isn't any consideration to security. Regards, -sm 1. http://www.madamandeve.co.za/cartoons/me005105.jpg From johnl@iecc.com Sat Mar 30 10:22:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E221F8691 for ; Sat, 30 Mar 2013 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.179 X-Spam-Level: X-Spam-Status: No, score=-111.179 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtQTLNdDA0xN for ; Sat, 30 Mar 2013 10:22:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5203221F8682 for ; Sat, 30 Mar 2013 10:22:21 -0700 (PDT) Received: (qmail 92634 invoked from network); 30 Mar 2013 17:22:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Mar 2013 17:22:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51571f4c.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=owj2pAxa+fyUijPZzgsfO4oAKf6V8tH286vkflB88Js=; b=C2bidAz4mp7dpozwnoH0E5mWDv7nNiVCJlpl+oFev1WcmpWhz91eGqwRf6zC7QO3QxwtHU2xB/ptpklcfw5UKrRxEVDfybVHaOM+KVqHbyldXijk4YxGOtm0LPfhryk24JidpO6E3l4x3K7J62YHGpNAx0UnP2E4P7/ppkp6XyA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51571f4c.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=owj2pAxa+fyUijPZzgsfO4oAKf6V8tH286vkflB88Js=; b=ELABI5t8pverLTM6UdU33+xs706jgRs3yttq4TEpmrqNRV6kvLkG2TK64etNOAyfUZ0MRSEnFhVeWT9E3iuxkkE/Sq95fc1t9q8IZi0x9hpbxmfmGItf/JQTLMNtyleTcRSDZEbKwFh0KsJCwYl82nQB0WtBi8qik1pwHVJb3uw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Mar 2013 17:21:57 -0000 Message-ID: <20130330172157.4969.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 17:22:23 -0000 To pick on the bits that have my fingerprints on them: > "When a server declines to answer a query due to rate limits, > it MAY return a 429 response code as described in [RFC6585]." > >Why is this a MAY? Servers aren't required to disclose their rate limiting rules to hostile clients. It might return 503 or just reject the connection. > "Depending on the data format of the response, servers MAY include > data in character sets other than ASCII and languages other than > English (the data format will most likely be in Unicode and almost > certainly languages other than English will be encountered)." > >This comes out as hand-waving the internationalization >question. From the charter: I agree that we should either say UTF-8 or nothing. This isn't a policy issue, it's an interop issue. R's, John From sm@resistor.net Sat Mar 30 18:06:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A973F21F8930 for ; Sat, 30 Mar 2013 18:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxyq2F9Bz5t2 for ; Sat, 30 Mar 2013 18:06:13 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54C21F857A for ; Sat, 30 Mar 2013 18:06:13 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2V167x7005907; Sat, 30 Mar 2013 18:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364691972; bh=EcIRMCf+vnwwVJryDFn3Uf03wQawrfKOaN1uXv1PRx8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0VsPcLuz1zSk1utJwo4IvZOtBenYqr36GO67gdUL991I9pLFbZSpf+xSEhpDz7ZtB Xgs/A2AF2ynUBqiqUCCHDzhvtyWa/3Xv+lK7mVsMoemey04+mC0+W+7Pkb+l7C2oRs hPml9vFyzPzSaPQx2LM/tmWg/mjBoDqBmfAiPGro= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364691972; i=@resistor.net; bh=EcIRMCf+vnwwVJryDFn3Uf03wQawrfKOaN1uXv1PRx8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2Jw80UWFBEu6hyyG1nu5YbyQSuGaUIwELP2s6tsoorOuzd/t+28EQiLCVXKgpHf0Z yE4gOAdIDeG08s0C8j/WfEe7Hmxh6/FK+2xDQZiu3MZ0g0MHTuCTtVbE72q4oDljAH SRUefack7nMqO1zQS+XeePHLYijDYogLHDXrzmdU= Message-Id: <6.2.5.6.2.20130330173603.0c790e20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 Mar 2013 18:05:56 -0700 To: John Levine From: SM In-Reply-To: <20130330172157.4969.qmail@joyce.lan> References: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> <20130330172157.4969.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 01:06:14 -0000 Hi John, At 10:21 30-03-2013, John Levine wrote: >Servers aren't required to disclose their rate limiting rules to >hostile clients. It might return 503 or just reject the connection. Using a MAY takes the discussion into the internals on the server side. The text can be restated in terms of what the status code means. The server does not have to disclosure its rate limiting rules. For what it is worth RFC 6585 explains that nicely. I'll elaborate if what I wrote is not clear. >I agree that we should either say UTF-8 or nothing. This isn't a policy >issue, it's an interop issue. Yes. Here's some text from Section 8.1: "Clients MAY use IRIs as they see fit, but MUST transform them to URIs [RFC3986] for interaction with RDAP servers. RDAP servers MUST use URIs in all responses, and clients MAY transform these URIs to IRIs." By the way there isn't any definition for IRIs in the draft. As there are several implementations of draft-ietf-weirds-using-http-03 maybe the individuals who have written the code could explain how they interpreted the above. Regards, -sm From johnl@taugh.com Sat Mar 30 18:29:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81821F8539 for ; Sat, 30 Mar 2013 18:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVx3NfNRWaXH for ; Sat, 30 Mar 2013 18:29:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5386A21F8673 for ; Sat, 30 Mar 2013 18:29:32 -0700 (PDT) Received: (qmail 14388 invoked from network); 31 Mar 2013 01:29:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=3833.5157917c.k1303; bh=eyy8bnLNFecsvz5Va2vdnn65tA4BTyBsSubdgZjOeKs=; b=uBNE+90KYLEnLD6RluB1R4vyYkZ6DWjjuBRdUVLCsijbfJxtcWTIps102p9TI7bdH1IptboU3OdR924hFECpV/Z7Gk//3FAlBTxTKcPiflq0kLoJCv08a+YmaXE43tlSZkn+grufByE8QTgWMqnR8aku29gg8Nne4X/W14GOyRM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=3833.5157917c.k1303; bh=eyy8bnLNFecsvz5Va2vdnn65tA4BTyBsSubdgZjOeKs=; b=OjJp6gQXrP9761aNHVF1B4GPFxnMBIQFpPTIeYqvVd+0QKjeBJPVNH2K1MZnBhhxtvD5cZ/pP0p4dfRMT99Sq+duZ8AGlbPFRppCl4ofkh3wlEH6JzIJ7MVS0kRvq8EXZPk/f07G0kBPcxbCb/PMTztnUYxrsVbuPZVCefUUYYE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 31 Mar 2013 01:29:10 -0000 Date: 30 Mar 2013 21:29:31 -0400 Message-ID: From: "John R Levine" To: "SM" In-Reply-To: <6.2.5.6.2.20130330173603.0c790e20@resistor.net> References: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> <20130330172157.4969.qmail@joyce.lan> <6.2.5.6.2.20130330173603.0c790e20@resistor.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-761040191-1364693371=:7647" Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 01:29:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-761040191-1364693371=:7647 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> Servers aren't required to disclose their rate limiting rules to >> hostile clients. It might return 503 or just reject the connection. > > Using a MAY takes the discussion into the internals on the server side. The > text can be restated in terms of what the status code means. The server does > not have to disclosure its rate limiting rules. For what it is worth RFC > 6585 explains that nicely. I'll elaborate if what I wrote is not clear. RFC 6585 says in the introduction that everything in it is optional. MAY is correct here. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-761040191-1364693371=:7647 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzMxMDEyOTMxWjAjBgkqhkiG 9w0BCQQxFgQU09+VIPMMtXvD7o1FqDz6uaujlNIweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAuQGz7gk7BtK8 NCaGPq8gGIObPiKp5jW6hG5Vkk4+v0+T3FGYMMHHFoKIRuCHXsfxdyB3xQ/p pxTwpyLxQHBNG/pNV0CdaswlraUPMNgxzXbuW8u0MNy0P4lIS8DLWOaYR4dQ FCIMBwGK3OovEVGYBBVh5DO2uUwwdfLRULo06dlQRHWXhOCGXmF2rVNFAuAQ SmYZWejwLZSuF36g6TEJkU1FuaRfB3cOUHxVA+v+Ax60+q/OecZCU7pWE8pO /kHfQeYFspUOM/MN1dWimLyxxLPAmtPT6e48lmsLpfovtpJv252AIhqXrxCH g+2X7yGhJDa43vlTHxa8AxBmVurqCQ== --3825401791-761040191-1364693371=:7647-- From sm@resistor.net Sat Mar 30 19:21:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9055E21F8970 for ; Sat, 30 Mar 2013 19:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4MZncHu0Fzj for ; Sat, 30 Mar 2013 19:21:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6321F8934 for ; Sat, 30 Mar 2013 19:21:32 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2V2LKv5019092; Sat, 30 Mar 2013 19:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364696491; bh=4Zyt71Q2fkvVrExVCpzY2IzOz71lA106kGWhOfQT5t4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ithmFZ7doga+/a6kRn2ylAJtqkgUFdBCC4bVKUBLUgRAH5KUVqeRP0ep/wI8uzOXD tpWy9mDZcPTxf6zG6o1RmfwEReoYC85ZgK/k43RDBPTiMfIFUvim4zHQjpiNmQB+KY jlrxA/O1PrnfPArnotI2u9WbTT5H5g/OhX6/Xlb0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364696491; i=@resistor.net; bh=4Zyt71Q2fkvVrExVCpzY2IzOz71lA106kGWhOfQT5t4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vUX0q9c7k0VUIOMHzqqy44ck2JiXOHwyw5Rzoiwu/mDqhdJvl/kr2qY/pb7xmjyCc cd6KaVBbmg7B3kVtxh2/Md483/TZ/y9Xi+wFN5QaKQlPM8CuTwK1LeHrVUuL2KMYE7 mGpB5pphbZMKCRS9BwWI5aIwN0PZG4MRONya7uyw= Message-Id: <6.2.5.6.2.20130330190045.0c2fcf18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 Mar 2013 19:21:07 -0700 To: John R Levine From: SM In-Reply-To: References: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> <20130330172157.4969.qmail@joyce.lan> <6.2.5.6.2.20130330173603.0c790e20@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 02:21:33 -0000 Hi John, At 18:29 30-03-2013, John R Levine wrote: >RFC 6585 says in the introduction that everything in it is >optional. MAY is correct here. The point is that optional does not help from status code perspective. If my client receives a 429 I take it that I am rate-limited. The intent is clearly conveyed. If I look at this from the server side I can send any status code I wish instead of telling the client that it is rate-limited. My reading of RFC 6585 is that is the angle it discusses about (I agree that the code is optional). Regards, -sm