From shollenbeck@verisign.com Fri Feb 1 04:15: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 A464221F86A8 for ; Fri, 1 Feb 2013 04:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Q7W++ZuYRige for ; Fri, 1 Feb 2013 04:15:29 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id DC98921F85CE for ; Fri, 1 Feb 2013 04:14:51 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUQuxu1mAMsVGUH902IiLUYJeHFFyHRGw@postini.com; Fri, 01 Feb 2013 04:15:29 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 r11CEmOO013153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 07:14:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 07:14:14 -0500 From: "Hollenbeck, Scott" To: Linlin Zhou , "weirds@ietf.org" Thread-Topic: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-search-00.txt Thread-Index: AQHN+wxM/1rE+Kl0N0m2r/e0WjrGgJhaIuuggAprSHCAAGX1QA== Date: Fri, 1 Feb 2013 12:14:31 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6F711E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6F4473@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <00e901ce0043$d6bc0c20$84342460$@cn> In-Reply-To: <00e901ce0043$d6bc0c20$84342460$@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 Subject: Re: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-search-00.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 Feb 2013 12:15:30 -0000 > -----Original Message----- > From: Linlin Zhou [mailto:zhoulinlin@cnnic.cn] > Sent: Friday, February 01, 2013 1:18 AM > To: Hollenbeck, Scott; weirds@ietf.org > Subject: RE: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap- > search-00.txt >=20 > Thanks Scott. I have two questions. > 1. Since there are 5 types of queries defined in the query draft, such > as IP, AS number, domain, name server and entity. Are there any other > types of search except domain and entity? Not currently, no. > 2. Do you take any consideration about the combination of search > parameters and Boolean search function described in AGB? I'm aware of what's currently in the Applicant Guidebook, and no, we haven'= t done anything to address the Boolean search capabilities it describes. Scott From shollenbeck@verisign.com Fri Feb 15 07:58: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 907B221F8895 for ; Fri, 15 Feb 2013 07:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 Bc5adhUYhTB2 for ; Fri, 15 Feb 2013 07:58:18 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id E6CEC21F870E for ; Fri, 15 Feb 2013 07:58:17 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUR5bGdtf8miQc46T9cV3c8frS/KSvDRF@postini.com; Fri, 15 Feb 2013 07:58:18 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 r1FFwEX8017390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Feb 2013 10:58:16 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 10:58:14 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: I-D Action: draft-hollenbeck-weirds-rdap-search-01.txt Thread-Index: AQHOC5UOGT/E41QseUW1sANT6glFa5h7Ew2A Date: Fri, 15 Feb 2013 15:58:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F1990A018@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-search-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, 15 Feb 2013 15:58:21 -0000 Andy and I updated this draft to change the HTTP response code per list dis= cussion. We'll queue up open questions for discussion in Orlando. Scott -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, February 15, 2013 10:56 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-hollenbeck-weirds-rdap-search-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Registration Data Access Protocol Search Processing Author(s) : Scott Hollenbeck Andrew Lee Newton Filename : draft-hollenbeck-weirds-rdap-search-01.txt Pages : 8 Date : 2013-02-15 Abstract: This document describes path segments and query parameters needed to construct HTTP URLs that may be used to search for and retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. It also describes a method of encoding responses using Javascript Object Notation (JSON). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-search There's also a htmlized version available at: http://tools.ietf.org/html/draft-hollenbeck-weirds-rdap-search-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-hollenbeck-weirds-rdap-search-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From zhoulinlin@cnnic.cn Mon Feb 18 16:56: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 856ED21F8AD4 for ; Mon, 18 Feb 2013 16:56:48 -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 LCngI3ZeUqhP for ; Mon, 18 Feb 2013 16:56:48 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 4AB7E21F88F0 for ; Mon, 18 Feb 2013 16:56:26 -0800 (PST) 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, 19 Feb 2013 08:56:19 +0800 From: "Linlin Zhou" To: Date: Tue, 19 Feb 2013 08:56:19 +0800 Message-ID: <009401ce0e3b$ee4f8050$caee80f0$@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: Ac4NxmgC0HHr8iOGReqLAw6zXESqCAAAWtiA Content-Language: zh-cn Subject: [weirds] FW: I-D Action: draft-zhou-weirds-rdap-restful-search-00.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, 19 Feb 2013 00:56:48 -0000 Dear colleagues, We have some ideas about the rdap search service. There may be several things should be considered about searchable rdap, such as Boolean search, abuse problem, result ordering and paging etc. We did some work focusing on the above issues in this individual draft. So this draft is submitted for list discussion. Any comments are appreciated. We also hope that it could be a reference for future WG document. Linlin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, February 18, 2013 6:55 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-zhou-weirds-rdap-restful-search-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration Data Access Protocol RESTful Searching Author(s) : Linlin Zhou Ning Kong Sean Shen Filename : draft-zhou-weirds-rdap-restful-search-00.txt Pages : 10 Date : 2013-02-18 Abstract: This document describes the searchability details of the Registration Data Access Protocol (RDAP). It specifies basic and extended searching parameters, defines the JSON (JavaScript Object Notation) formats of searching and responding data structure and also proposes the specification of boolean search functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhou-weirds-rdap-restful-search There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhou-weirds-rdap-restful-search-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From marc.blanchet@viagenie.ca Fri Feb 22 12:42: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 0CE0221F8CE3 for ; Fri, 22 Feb 2013 12:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_37=0.6, NORMAL_HTTP_TO_IP=0.001, 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 ohrQJ1dFg7RA for ; Fri, 22 Feb 2013 12:42:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6421F8713 for ; Fri, 22 Feb 2013 12:42:17 -0800 (PST) Received: from [172.20.10.2] (out-on-255.wireless.telus.com [207.219.69.255]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 23B6446FBE; Fri, 22 Feb 2013 15:41:46 -0500 (EST) From: Marc Blanchet Content-Type: multipart/mixed; boundary="Apple-Mail=_038D6651-BC8A-487E-B807-252B0F0A2FD6" Date: Fri, 22 Feb 2013 15:41:45 -0500 Message-Id: <23C97473-FFB0-4686-B3EA-BDC043AB9B6A@viagenie.ca> To: draft-ietf-weirds-rdap-query@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: [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: Fri, 22 Feb 2013 20:42:20 -0000 --Apple-Mail=_038D6651-BC8A-487E-B807-252B0F0A2FD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hello, please find my comments embedded in the copy of the draft and tagged = with . credit: Few of the comments are also from my colleague = Jean-Philippe Dionne. Regards, Marc. --Apple-Mail=_038D6651-BC8A-487E-B807-252B0F0A2FD6 Content-Disposition: attachment; filename=draft-ietf-weirds-rdap-query-02-mb.txt Content-Type: text/plain; name="draft-ietf-weirds-rdap-query-02-mb.txt" Content-Transfer-Encoding: quoted-printable =0D =0D =0D Network Working Group A. Newton=0D= Internet-Draft ARIN=0D= Intended status: Standards Track S. Hollenbeck=0D= Expires: June 21, 2013 Verisign Labs=0D= December 18, 2012=0D= =0D =0D Registration Data Access Protocol Query Format=0D draft-ietf-weirds-rdap-query-02=0D =0D Abstract=0D =0D This document describes uniform patterns to construct HTTP URLs that=0D= may be used to retrieve registration information from registries=0D (including both Regional Internet Registries (RIRs) and Domain Name=0D= Registries (DNRs)) using "RESTful" web access patterns.=0D =0D Status of this Memo=0D =0D This Internet-Draft is submitted in full conformance with the=0D provisions of BCP 78 and BCP 79.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF). Note that other groups may also distribute=0D working documents as Internet-Drafts. The list of current Internet-=0D= Drafts is at http://datatracker.ietf.org/drafts/current/.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than as "work in progress."=0D =0D This Internet-Draft will expire on June 21, 2013.=0D =0D Copyright Notice=0D =0D Copyright (c) 2012 IETF Trust and the persons identified as the=0D document authors. All rights reserved.=0D =0D This document is subject to BCP 78 and the IETF Trust's Legal=0D Provisions Relating to IETF Documents=0D (http://trustee.ietf.org/license-info) in effect on the date of=0D publication of this document. Please review these documents=0D carefully, as they describe your rights and restrictions with respect=0D= to this document. Code Components extracted from this document must=0D= include Simplified BSD License text as described in Section 4.e of=0D the Trust Legal Provisions and are provided without warranty as=0D described in the Simplified BSD License.=0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 1]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D Table of Contents=0D =0D 1. Conventions Used in This Document . . . . . . . . . . . . . . 3=0D= 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3=0D= 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0D= 3. Path Segment Specification . . . . . . . . . . . . . . . . . . 4=0D= 3.1. IP Network Path Segment Specification . . . . . . . . . . 4=0D= 3.2. Autonomous System Path Segment Specification . . . . . . . 5=0D= 3.3. Domain Path Segment Specification . . . . . . . . . . . . 5=0D= 3.4. Name Server Path Segment Specification . . . . . . . . . . 6=0D= 3.5. Entity Path Segment Specification . . . . . . . . . . . . 6=0D= 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6=0D= 5. Internationalization Considerations . . . . . . . . . . . . . 7=0D= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7=0D= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7=0D= 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7=0D= 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8=0D= 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8=0D= 9.2. Informative References . . . . . . . . . . . . . . . . . . 9=0D= Appendix A. Path Segment Specification for Search Queries . . . . 9=0D= Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10=0D= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 2]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D 1. Conventions Used in This Document=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D= document are to be interpreted as described in RFC 2119 [RFC2119].=0D =0D 1.1. Acronyms and Abbreviations=0D =0D DNR: Domain Name Registry=0D RDAP: Registration Data Access Protocol=0D RIR: Regional Internet Registry=0D Add "RESTful" into this set and a reference for definition=0D =0D =0D 2. Introduction=0D =0D This document describes a specification for querying registration=0D data using a RESTful web service and uniform query patterns. The=0D service is implemented using the Hypertext Transfer Protocol (HTTP)=0D= [RFC2616].=0D =0D The protocol described in this specification is intended to address=0D= deficiencies with the WHOIS protocol [RFC3912] that have been=0D identified over time, including:=0D =0D o Lack of standardized command structures,=0D o lack of standardized output and error structures,=0D o lack of support for internationalization and localization, and=0D o lack of support for user identification, authentication, and=0D access control.=0D =0D The patterns described in this document purposefully do not encompass=0D= all of the methods employed in the WHOIS and RESTful web services of=0D= all of the RIRs and DNRs. The intent of the patterns described here=0D= are to enable lookups of networks by IP address, autonomous system=0D numbers by number, reverse DNS meta-data by domain, domains by name,=0D= name servers by name, registrars by name, and entities (such as=0D contacts) by identifier. =0D =0D This list above is very important to define the scope of the = document. For viewing perspective, I would prefer seeing a bullet = list.=0D =0D It is envisioned that each registry will=0D continue to maintain NICNAME/WHOIS and/or RESTful web services=0D specific to their needs and those of their constituencies, and the=0D information retrieved through the patterns described here may=0D reference such services.=0D =0D Likewise, future IETF standards may add additional patterns for=0D additional query types (for example, "/domains" for a domain search=0D= query). And Section 4 defines a simple pattern namespacing scheme to=0D= accomodate custom extensions that will not interfere with the=0D patterns defined in this document or patterns defined in future IETF=0D= standards.=0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 3]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D WHOIS services, in general, are read-only services. Therefore URL=0D [RFC3986] patterns presented here are only applicable to the HTTP=0D [RFC2616] GET and HEAD methods.=0D I think this is strong enough to state it more clearly. Suggesting:=0D= OLD: patterns presented here=0D NEW: patterns specified in this document=0D =0D =0D This document does not describe the results or entities returned from=0D= issuing the described URLs with an HTTP GET. It is envisioned that=0D= other documents will describe these entities in various serialization=0D= formats, such as JavaScript Object Notation (JSON, [RFC4627]).=0D =0D Additionally, resource management, provisioning and update functions=0D= are out of scope for this document. Registries have various and=0D divergent methods covering these functions, and it is unlikely a=0D uniform approach for these functions will ever be possible.=0D =0D HTTP contains mechanisms for servers to authenticate clients and for=0D= clients to authenticate servers (from which authorization schemes may=0D= be built) so such mechanisms are not described in this document.=0D Policy, provisioning, and processing of authentication and=0D authorization are out-of-scope for this document as deployments will=0D= have to make choices based on local criteria. So long as the=0D solution chosen makes use of the HTTP mechanisms, implementations=0D ought to be interoperable.=0D =0D Should we say that authentication MUST use HTTP? i.e. do we really = want another authentication channel? I guess that might be out of scope = too. Asking. Since this may be repeating the requirements that are = discussed in -sec draft, maybe cut that text and refer to the -sec = draft? =0D =0D 3. Path Segment Specification=0D =0D The uniform patterns start with a base URL [RFC3986] specified by=0D each registry or any other service provider offering this service.=0D The base URL is followed by a resource-type-specific path segment.=0D The base URL may contain its own path segments (e.g.=0D http://example.com/... or http://example.com/restful-WHOIS/... ).=0D =0D The resource type path segments are:=0D o 'ip': IP networks and associated data referenced using either an=0D= IPv4 or IPv6 address.=0D o 'autnum': Autonomous system registrations and associated data=0D referenced using an AS Plain autonomous system number.=0D o 'domain': Reverse DNS (RIR) or domain name (DNR) information and=0D= associated data referenced using a fully-qualified domain name.=0D o 'nameserver': Used to identify a name server information query.=0D =0D Since this document talks about multiple kinds of registries and = that RIR may have names, I suggest to state "DNS name server" here to be = more precise, since that is the intent.=0D o 'entity': Used to identify an entity information query.=0D =0D 3.1. IP Network Path Segment Specification=0D =0D Syntax: ip/ or ip//=0D =0D Queries for information about IP networks are of the form /ip/XXX/...=0D= or /ip/XXX/YY/... where the path segment following 'ip' is either an=0D= =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 4]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D IPv4 [RFC1166] or IPv6 [RFC5952] address (i.e. XXX) or an IPv4 or=0D IPv6 CIDR [RFC4632] notation address block (i.e. XXX/YY).=0D Semantically, the simpler form using the address can be thought of as=0D= a CIDR block with a bitmask length of 32 for IPv4 and a bitmask=0D length of 128 for IPv6. A given specific address or CIDR may fall=0D within multiple IP networks in a hierarchy of networks, therefore=0D this query targets the "most-specific" or smallest IP network which=0D= completely encompasses it in a hierarchy of IP networks.=0D =0D This is an example URL for the most specific network containing=0D 192.0.2.0:=0D =0D /ip/192.0.2.0=0D =0D This is an example of a URL the most specific network containing=0D 192.0.2.0/24:=0D =0D /ip/192.0.2.0/24=0D =0D This section could be more detailed. For example, are shorten IPv4 = addresses allowed (i.e. 0.1)?. Are RFC5952 compliant IPv6 addresses the = only supported address (which is not what typical IPv6 applications are = doing)?=0D =0D Here is a suggested text contribution:=0D =0D ADD:=0D The IPv4 and IPv6 address formats supported in this query are described = in section 3.2.2 of , as IPv4address and = IPv6address ABNF definitions.=0D =0D Any valid IPv6 text address format can be = used, compressed or not compressed. The restricted rules to write a text = representation of an IPv6 address are not = mandatory. However, the zone id is not = appropriate in this context and therefore prohibited.=0D =0D This is an example URL for the most specific network containing = 2001:db8:1:1::1=0D /ip/2001:db8:1:1::1=0D =0D =0D =0D 3.2. Autonomous System Path Segment Specification=0D =0D Syntax: autnum/=0D =0D Queries for information regarding autonomous system number=0D registrations are of the form /autnum/XXX/... where XXX is an asplain=0D= autonomous system number [RFC5396]. In some registries, registration=0D= of autonomous system numbers is done on an individual number basis,=0D= while other registries may register blocks of autonomous system=0D numbers. The semantics of this query are such that if a number falls=0D= within a range of registered blocks, the target of the query is the=0D= block registration, and that individual number registrations are=0D considered a block of numbers with a size of 1.=0D =0D For example, to find information on autonomous system number 65551,=0D= the following path would be used:=0D =0D /autnum/65551=0D =0D An example of a 4 bytes AS might be also useful. Here is a suggested = contribution:=0D =0D ADD:=0D For example, to find information on autonomous system 4 bytes number = 65538,=0D the following path would be used:=0D =0D /autnum/65538=0D =0D =0D 3.3. Domain Path Segment Specification=0D =0D Syntax: domain/=0D =0D Queries for domain information are of the form /domain/XXXX/...,=0D where XXXX is a fully-qualified domain name [RFC4343] in either the=0D= in-addr.arpa or ip6.arpa zones (for RIRs) or a fully-qualified domain=0D= name in a zone administered by the server operator (for DNRs).=0D Internationalized domain names represented in A-label format=0D [RFC5890] are also valid domain names.=0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 5]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D The following path would be used to find information describing the=0D= zone serving the network 192.0.2/24:=0D =0D /domain/2.0.192.in-addr.arpa=0D =0D The following path would be used to find information for the=0D example.com domain name:=0D =0D /domain/example.com=0D =0D An example for the IPv6 reverse zone would be useful. Here is a = suggested contribution:=0D =0D ADD:=0D The following path would be used to find information describing the=0D= zone serving the network 2001:db8:1::/48:=0D =0D /domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa=0D =0D =0D 3.4. Name Server Path Segment Specification=0D =0D Syntax: nameserver/=0D =0D The parameter represents a fully qualified name as=0D= specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123].=0D Internationalized names represented in A-label format [RFC5890] are=0D= also valid name server names.=0D Should we say something about what the server is not expected to = do?: we don't want the server developers to look into the whole set of = IDNA documents to find that they have nothing to do. Moreover, it could = be useful to provide an example. Here is a suggested contribution.=0D =0D ADD:=0D The client should put the target idn in A-label format and therefore = should do the IDNA processing if the input name was not in A-label = format. The server should do an exact match and should not do any IDNA = processing on the received idn.=0D =0D =0D The following path would be used to find information for the=0D ns1.example.com name server:=0D =0D /nameserver/ns1.example.com=0D =0D Here is a suggested contribution.=0D ADD:=0D The following path would be used to find information for the idn=0D ns1.xn--xemple-9ua.com name server:=0D =0D /nameserver/ns1.xn--xemple-9ua.com=0D =0D =0D 3.5. Entity Path Segment Specification=0D =0D Syntax: entity/=0D =0D The parameter represents an entity (such as a contact,=0D registrant, or registrar) identifier. For example, for some DNRs=0D contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733=0D= [RFC5733].=0D =0D The following path would be used to find information for the entity=0D= associated with handle CID-4005:=0D =0D /entity/CID-4005=0D =0D The allowed characters should be defined here, or we should point to = http spec for percent-encoding the unallowed by http=0D =0D 4. Extensibility=0D =0D This document describes path segment specifications for a limited=0D number of objects commonly registered in both RIRs and DNRs. It does=0D= not attempt to describe path segments for all of the objects=0D registered in all registries. Custom path segments can be created=0D for objects not specified here using the process described in Section=0D= TBD of "Using HTTP for RESTful Whois Services by Internet Registries"=0D= [I-D.ietf-weirds-using-http].=0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 6]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D Custom path segments can be created by prefixing the segment with a=0D= unique identifier followed by an underscore character (0x5F). For=0D example, a custom entity path segment could be created by prefixing=0D= "entity" with "custom_", producing "custom_entity". Servers MUST=0D return an appropriate failure status code for a request with an=0D unrecognized path segment.=0D =0D ADD:=0D =0D A new query definition should be registered in the IANA registry = described in Section 6.=0D =0D =0D 5. Internationalization Considerations=0D =0D There is value in supporting the ability to submit either a U-label=0D= (Unicode form of an IDN label) or an A-label (ASCII form of an IDN=0D label) as a query argument to an RDAP service. Clients with=0D graphical user interfaces may prefer a U-label since this is more=0D =0D I don't think a graphical user interface has anything to do with = inputing unicode codepoints. Suggesting:=0D =0D Clients capable of inputing non-ascii characters ...=0D =0D See also suggested text about idn in previous comment.=0D =0D visually recognizable and familiar than A-label strings, but clients=0D= of programmatic interfaces may wish to submit and display A-labels or=0D= may not be able to input U-labels with their keyboard configuration.=0D= In the interest of protocol simplicity, A-labels (the "wire format"=0D= of IDNs) are the only labels supported by this specification.=0D =0D Internationalized domain and name server names can contain character=0D= variants and variant labels as described in RFC 4290 [RFC4290].=0D Clients that support queries for internationalized domain and name=0D server names MUST accept service provider responses that describe=0D variants as specified in "JSON Responses for the Registration Data=0D Access Protocol" [I-D.ietf-weirds-json-response].=0D =0D =0D 6. IANA Considerations=0D =0D This document does not specify any IANA actions.=0D =0D =0D 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:=0D =0D IANA is requested to setup a "Registration Data Access Protocol Queries" = registry with the following characteristics.=0D - Registration policy: RFC required=0D - columns: =0D + query string=0D + reference=0D - initial content:=0D ip [this Document]=0D autnum [this Document]=0D domain [this Document]=0D nameserver [this Document]=0D entity [this Document]=0D =0D =0D 7. Security Considerations=0D =0D Security services for the operations specified in this document are=0D= described in "Security Services for the Registration Data Access=0D Protocol" [I-D.ietf-weirds-rdap-sec]. As we identify specific use=0D cases for which security services are needed they will be described=0D= here.=0D =0D =0D 8. Acknowledgements=0D =0D This document is derived from original work on RIR query formats=0D developed by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC,=0D= Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN.=0D Additionally, this document incorporates DNR query formats originally=0D= =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 7]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D described by Francisco Arias and Steve Sheng of ICANN and Scott=0D Hollenbeck of Verisign.=0D =0D The authors would like to acknowledge the following individuals for=0D= their contributions to this document: Francisco Arias, Edward Lewis,=0D= and John Levine.=0D =0D =0D 9. References=0D =0D 9.1. Normative References=0D =0D [I-D.ietf-weirds-json-response]=0D Newton, A. and S. Hollenbeck, "JSON Responses for the=0D Registration Data Access Protocol (RDAP)",=0D draft-ietf-weirds-json-response-01 (work in progress),=0D December 2012.=0D =0D [I-D.ietf-weirds-rdap-sec]=0D Hollenbeck, S. and N. Kong, "Security Services for the=0D Registration Data Access Protocol",=0D draft-ietf-weirds-rdap-sec-01 (work in progress),=0D November 2012.=0D =0D [I-D.ietf-weirds-using-http]=0D Newton, A., Ellacott, B., and N. Kong, "Using the=0D Registration Data Access Protocol (RDAP) with HTTP",=0D draft-ietf-weirds-using-http-01 (work in progress),=0D December 2012.=0D =0D [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet=0D= host table specification", RFC 952, October 1985.=0D =0D [RFC1123] Braden, R., "Requirements for Internet Hosts - Application=0D= and Support", STD 3, RFC 1123, October 1989.=0D =0D [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet=0D numbers", RFC 1166, July 1990.=0D =0D [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0D Requirement Levels", BCP 14, RFC 2119, March 1997.=0D =0D [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0D Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0D Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0D =0D [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=0D= Resource Identifier (URI): Generic Syntax", STD 66,=0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 8]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D RFC 3986, January 2005.=0D =0D [RFC4290] Klensin, J., "Suggested Practices for Registration of=0D Internationalized Domain Names (IDN)", RFC 4290,=0D December 2005.=0D =0D [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity=0D= Clarification", RFC 4343, January 2006.=0D =0D [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing=0D (CIDR): The Internet Address Assignment and Aggregation=0D Plan", BCP 122, RFC 4632, August 2006.=0D =0D [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of=0D= Autonomous System (AS) Numbers", RFC 5396, December 2008.=0D= =0D [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",=0D= STD 69, RFC 5730, August 2009.=0D =0D [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)=0D Contact Mapping", STD 69, RFC 5733, August 2009.=0D =0D [RFC5890] Klensin, J., "Internationalized Domain Names for=0D Applications (IDNA): Definitions and Document Framework",=0D= RFC 5890, August 2010.=0D =0D [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6=0D= Address Text Representation", RFC 5952, August 2010.=0D =0D 9.2. Informative References=0D =0D [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,=0D September 2004.=0D =0D [RFC4627] Crockford, D., "The application/json Media Type for=0D JavaScript Object Notation (JSON)", RFC 4627, July 2006.=0D= =0D URIs=0D =0D [1] =0D =0D [2] =0D =0D [3] =0D =0D [4] =0D =0D =0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 9]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D Appendix A. Path Segment Specification for Search Queries=0D =0D All of the path segments described in this document identify patterns=0D= for exact-match lookups of data elements. We have explicitly omitted=0D= specifications for search queries in the interest of first focusing=0D= on more basic protocol operations. Once we understand how exact-=0D match queries will work we will attempt to define specifications for=0D= search queries.=0D =0D It is important to note that there are already multiple=0D implementations of RESTful RDAP-like prototypes that provide search=0D= capabilities. For example:=0D =0D ARIN: The American Registry for Internet Numbers (ARIN) has=0D published an API [1] (see Section 4.4.2) that describes using=0D plural forms of path segment identifiers (e.g. "domains") and=0D Matrix URIs [2] to indicate that a client is requesting a list of=0D= values when searching for RIR registration data. A prototype=0D service [3] that implements this API is up and running.=0D Verisign: Verisign has deployed a prototype service [4] that=0D implements searches for DNR registration data using HTML query=0D strings (e.g. "?_PRE") to identify search parameters. For=0D example,=0D "http://dnrd.verisignlabs.com/dnrd-ap/domain/verisign?_PRE"=0D performs a search for domain names with a "verisign" prefix.=0D =0D =0D Appendix B. Change Log=0D =0D Initial -00: Adopted as working group document.=0D -01: Added "Conventions Used in This Document" section. Added=0D normative reference to draft-ietf-weirds-rdap-sec and some=0D wrapping text in the Security Considerations section.=0D -02: Removed "unified" from the title. Rewrote the last paragraph=0D= of section 2. Edited the first paragraph of section 3 to more=0D clearly note that only one path segement is provided. Added=0D "bitmask" to "length" in section 3.1. Changed "lowest IP network"=0D= to "smallest IP network" in section 3.1. Added "asplain" to the=0D= description of autonomous system numbers in section 3.2. Minor=0D change from "semantics is" to "semantics are" in section 3.2.=0D Changed the last sentence in section 4 to more clearly specify=0D error response behavior. Added acknowledgements. Added a=0D paragraph in the introduction regarding future IETF standards and=0D= extensibility.=0D =0D =0D =0D =0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 10]=0D= =0C=0D Internet-Draft RDAP Query Format December 2012=0D= =0D =0D Authors' Addresses=0D =0D Andrew Lee Newton=0D American Registry for Internet Numbers=0D 3635 Concorde Parkway=0D Chantilly, VA 20151=0D US=0D =0D Email: andy@arin.net=0D URI: http://www.arin.net=0D =0D =0D Scott Hollenbeck=0D Verisign Labs=0D 12061 Bluemont Way=0D Reston, VA 20190=0D US=0D =0D Email: shollenbeck@verisign.com=0D URI: http://www.verisignlabs.com/=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Newton & Hollenbeck Expires June 21, 2013 [Page 11]=0D= =0C=0D --Apple-Mail=_038D6651-BC8A-487E-B807-252B0F0A2FD6-- From marc.blanchet@viagenie.ca Fri Feb 22 12:43: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 95B8321E804B for ; Fri, 22 Feb 2013 12:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.601, 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 dEy-lGGsr3Cl for ; Fri, 22 Feb 2013 12:43:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id D4BFD21F8CE3 for ; Fri, 22 Feb 2013 12:43:18 -0800 (PST) Received: from [172.20.10.2] (out-on-255.wireless.telus.com [207.219.69.255]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 854AA41498; Fri, 22 Feb 2013 15:42:47 -0500 (EST) From: Marc Blanchet Content-Type: multipart/mixed; boundary="Apple-Mail=_48CCDB78-D2BC-4973-B4DF-D32263659C99" Date: Fri, 22 Feb 2013 15:42:46 -0500 Message-Id: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> To: draft-ietf-weirds-rdap-sec@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: [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, 22 Feb 2013 20:43:20 -0000 --Apple-Mail=_48CCDB78-D2BC-4973-B4DF-D32263659C99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hello, please find my comments embedded in the copy of the draft and tagged = with . credit: Few of the comments are also from my colleague = Jean-Philippe Dionne. Regards, Marc. --Apple-Mail=_48CCDB78-D2BC-4973-B4DF-D32263659C99 Content-Disposition: attachment; filename=draft-ietf-weirds-rdap-sec-01-mb.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-weirds-rdap-sec-01-mb.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force S. Hollenbeck Internet-Draft Verisign Labs Intended status: Standards Track N. Kong Expires: May 30, 2013 CNNIC November 26, 2012 Security Services for the Registration Data Access Protocol draft-ietf-weirds-rdap-sec-01 Abstract The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services, specific requirements for RDAP, and approaches to provide RDAP security services. 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 May 30, 2013. Copyright Notice Copyright (c) 2012 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 Hollenbeck & Kong Expires May 30, 2013 [Page 1] =0C Internet-Draft RDAP Security Services November 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3 3. Information Security Services and RDAP . . . . . . . . . . . . 3 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Federated Authentication . . . . . . . . . . . . . . . 4 3.2. Authorization . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Data Confidentiality . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Hollenbeck & Kong Expires May 30, 2013 [Page 2] =0C Internet-Draft RDAP Security Services November 2012 1. Introduction The Registration Data Access Protocol (RDAP) core is specified in two documents: "Unified Registration Data Access Protocol Query Format" [I-D.ietf-weirds-rdap-query] and "JSON Responses for the Registry Data Access Protocol" [I-D.ietf-weirds-json-response]. One goal of RDAP is to provide security services that do not exist in the WHOIS [RFC3912] protocol, including authentication, authorization, availability, and data confidentiality. This document describes each of these security services from the perspective of RDAP requirements and applicability. Where applicable, informational references to requirements for a WHOIS replacement service [RFC3707] are noted. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.1. Acronyms and Abbreviations DNR: Domain Name Registry RDAP: Registration Data Access Protocol RIR: Regional Internet Registry 3. Information Security Services and RDAP RDAP itself does not include native security services. Instead, RDAP relies on features that are available in other protocol layers to provide needed security services including authentication, authorization, availability, and data confidentiality. A description of each of these security services can be found in RFC 4949 [RFC4949]. No requirements have been identified for other security services. 3.1. Authentication WHOIS does not provide features to identify and authenticate clients. As noted in section 3.1.4.2 of RFC 3707 [RFC3707], there is utility in allowing server operators to offer "varying degrees of access depending on policy and need". Clients have to be identified and authenticated to provide that utility. Hollenbeck & Kong Expires May 30, 2013 [Page 3] =0C Internet-Draft RDAP Security Services November 2012 REQUIREMENT: RDAP MUST include an authentication framework that can accommodate anonymous access as well as verification of identities using a range of authentication methods and credential services. REQUIREMENT: The RDAP authentication framework MUST use authentication methods that are fully specified and available to existing HTTP clients and servers. REQUIREMENT: The RDAP authentication framework MUST be capable of supporting future authentication methods defined for use with HTTP. APPROACH: RDAP clients and servers MUST implement the authentication framework specified in RFC 2617 [RFC2617]. The "basic" scheme can be used to send a client's user name and password to a server in plaintext, based64-encoded form. The "digest" scheme can be used to authenticate a client without exposing the client's plaintext password. If the "basic" scheme is used another protocol (such as HTTP Over TLS [RFC2818]) MUST be used to protect the client's credentials from disclosure while in transit (see Section 3.4). 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. The Transport Layer Security Protocol [RFC5246] includes an optional feature to identify and authenticate clients who possess and present a valid X.509 digital certificate [RFC5280]. Support for this feature is OPTIONAL. 3.1.1. Federated Authentication The traditional client-server authentication model requires clients to maintain distinct credentials for every RDAP server. This situation can become unwieldy as the number of RDAP servers increases. Federated authentication mechanisms allow clients to use one credential to access multiple RDAP servers and reduce client credential management complexity. RDAP MAY include a federated authentication mechanism that permits a client to access multiple RDAP servers in the same federation with one credential. REQUIREMENT: Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP. but federated authentication is optional. So small change to = clarify: NEW: REQUIREMENT: Federated authentication mechanisms used by RDAP are = optional. However, if used, they MUST be fully supported by HTTP. POSSIBLE APPROACH: The OAuth authorization framework [RFC6749] describes a method for users to access protected web resources without having to hand out their credentials. Instead, clients supply access tokens issued by an authorization server with the permission of the resource owner. Using OAuth, multiple RDAP servers can form a federation and the clients can access any server in the same federation by providing one credential registered in any server in that federation. The OAuth authorization framework is designed for use with HTTP and thus can be used with RDAP. Hollenbeck & Kong Expires May 30, 2013 [Page 4] =0C Internet-Draft RDAP Security Services November 2012 POSSIBLE APPROACH: OpenID [OpenID] is a decentralized single sign-on authentication system that allows users to log in at web sites with one ID instead of having to create multiple unique accounts. OpenID is decentralized. An end user can freely choose which OpenID provider to use, and can preserve their Identifier if they switch OpenID providers. [To be discussed: Is it possible to introduce OpenID into RDAP?] POSSIBLE APPROACH: Section 7.4.6 of the Transport Layer Security Protocol [RFC5246] describes the specification of a client certificate. Clients who possess and present a valid X.509 digital certificate, issued by an entity called "Certification Authority" (CA), could be identified and authenticated by a server who trusts the corresponding CA. A certificate authentication method can be used to achieve federated authentication in which multiple RDAP servers all trust the same CAs and then any client with a certificate issued by a trusted CA can access any RDAP server in the federation. This certificate-based mechanism is supported by HTTPS and can be introduced into RDAP. 3.2. Authorization WHOIS does not provide services to grant different levels of access to clients based on a client's authenticated identity. As noted in section 3.1.4.2 of RFC 3707 [RFC3707], there is utility in allowing server operators to offer "varying degrees of access depending on policy and need". Access control decisions can be made once a client's identity has been authenticated (see Section 3.1). REQUIREMENT: RDAP MUST include an authorization framework that is capable of providing granular (per registration data object) access controls according to the policies of the operator. APPROACH: Server operators will offer varying degrees of access depending on policy and need in conjunction with the authentication methods described in Section 3.1. Some examples: - Clients will be allowed access only to data for which they have a relationship. - Unauthenticated or anonymous access status may not yield any contact information. - Full access may be granted to a special group of authenticated clients. The type of access allowed by a server will most likely vary from one operator to the next. Hollenbeck & Kong Expires May 30, 2013 [Page 5] =0C Internet-Draft RDAP Security Services November 2012 3.3. Availability An RDAP service has to be available to be useful. There are no RDAP- unique requirements to provide availability, but as a general security consideration a service operator needs to be aware of the issues associated with denial of service. A thorough reading of RFC 4732 [RFC4732] is RECOMMENDED. One thing related to availability, especially from the client point = of view, is query throttling, commonly used. I think it should be = mentionned here. Moreover, it could be appropriate to define a standard = way to signal the client about that fact, so all clients may respond = correctly, instead of throwing the error message to the user. Suggested text: An RDAP service may use a throttling mechanism to limit the number of = queries a single client may be sending in a given period of time. In = this case, the server should send a 503 Service Unavailable message: http://tools.ietf.org/html/rfc2616#section-10.5.4 The Retry-After response-header field can be used to give an hint to the = client http://tools.ietf.org/html/rfc2616#section-14.37 3.4. Data Confidentiality WHOIS does not provide the ability to encrypt data while in transit to protect it from inadvertent disclosure. Web services commonly use HTTP Over TLS [RFC2818] to provide that protection. REQUIREMENT: RDAP or a protocol layer used by RDAP MUST include features to protect plaintext client credentials used for client authentication. REQUIREMENT: The data confidentiality methods used by RDAP MUST be fully specified and available to existing HTTP clients and servers. REQUIREMENT: RDAP MUST be capable of supporting future data confidentiality methods defined for use with HTTP. OPTION: RDAP or a protocol layer used by RDAP MAY include features to encrypt client-server data exchanges. APPROACH: As noted in Section 3.1, the HTTP "basic" authentication scheme can be used to authenticate a client. When this scheme is used HTTP Over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit. HTTP Over TLS MAY also be used to protect client-server data exchanges if the policy of the server operator requires encryption. There are no current requirements for object-level encryption, but RDAP MUST NOT preclude support for this feature in the future. 4. IANA Considerations This document does not specify any IANA actions. This section can be removed if this document is published as an RFC. 5. Security Considerations One of the goals of RDAP is to provide security services that do not exist in the WHOIS protocol. This document describes the security services provided by RDAP and associated protocol layers, including Hollenbeck & Kong Expires May 30, 2013 [Page 6] =0C Internet-Draft RDAP Security Services November 2012 authentication, authorization, availability, and data confidentiality. Data integrity and non-repudiation services were also considered and ultimately rejected. Data integrity: No requirements for data integrity have been identified. This security service is often mistakenly associated with policy requirements focused on data accuracy, but those requirements are out of scope for this protocol. Data integrity could be provided by signing JSON-encoded objects. RDAP MUST NOT preclude support for this feature in the future. Non-repudiation: No requirements for non-repudiation with proof or origin or proof of delivery have been identified. There are, however, currently-deployed WHOIS servers that can return signed responses that provide non-repudiation with proof of origin. RDAP MUST NOT preclude support for this feature in the future. 6. Acknowledgements The authors would like to acknowledge the following individuals for their contributions to this document: Andrew Newton. 7. References 7.1. Normative References [I-D.ietf-weirds-json-response] Newton, A. and S. Hollenbeck, "JSON Responses for the Registy Data Access Protocol (RDAP)", draft-ietf-weirds-json-response-00 (work in progress), September 2012. [I-D.ietf-weirds-rdap-query] Newton, A. and S. Hollenbeck, "Unified Registration Data Access Protocol Query Format", draft-ietf-weirds-rdap-query-01 (work in progress), November 2012. [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Hollenbeck & Kong Expires May 30, 2013 [Page 7] =0C Internet-Draft RDAP Security Services November 2012 Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. 7.2. Informative References [RFC3707] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. Appendix A. Change Log Initial -00: Adopted as working group document. -01: Extensive text additions and revisions based on in-room discussion at IETF-85. Sections for data integrity and non- repudiation have been removed due to a lack of requirements, but both topics are now addressed in the Security Considerations section. Hollenbeck & Kong Expires May 30, 2013 [Page 8] =0C Internet-Draft RDAP Security Services November 2012 Authors' Addresses Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Hollenbeck & Kong Expires May 30, 2013 [Page 9] =0C --Apple-Mail=_48CCDB78-D2BC-4973-B4DF-D32263659C99-- From marc.blanchet@viagenie.ca Fri Feb 22 12:43: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 83A2921F8E98 for ; Fri, 22 Feb 2013 12:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 dS5dMRMcBExy for ; Fri, 22 Feb 2013 12:43:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 74ED521F8E7E for ; Fri, 22 Feb 2013 12:43:53 -0800 (PST) Received: from [172.20.10.2] (out-on-255.wireless.telus.com [207.219.69.255]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9195241498; Fri, 22 Feb 2013 15:43:41 -0500 (EST) From: Marc Blanchet Content-Type: multipart/mixed; boundary="Apple-Mail=_83A6D8EB-B9CE-4814-B2C5-1C68AB84A52C" Date: Fri, 22 Feb 2013 15:43:41 -0500 Message-Id: To: draft-ietf-weirds-rdap-using-http@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: [weirds] review comments on draft-ietf-weirds-rdap-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, 22 Feb 2013 20:43:55 -0000 --Apple-Mail=_83A6D8EB-B9CE-4814-B2C5-1C68AB84A52C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hello, please find my comments embedded in the copy of the draft and tagged = with . credit: Few of the comments are also from my colleague = Jean-Philippe Dionne. Regards, Marc. --Apple-Mail=_83A6D8EB-B9CE-4814-B2C5-1C68AB84A52C Content-Disposition: attachment; filename=draft-ietf-weirds-using-http-01-mb.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-weirds-using-http-01-mb.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. Newton Internet-Draft ARIN Intended status: Standards Track B. Ellacott Expires: June 8, 2013 APNIC N. Kong CNNIC December 5, 2012 Using the Registration Data Access Protocol (RDAP) with HTTP draft-ietf-weirds-using-http-01 Abstract This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. 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 June 8, 2013. Copyright Notice Copyright (c) 2012 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 described in the Simplified BSD License. Newton, et al. Expires June 8, 2013 [Page 1] =0C Internet-Draft RDAP over HTTP December 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Internationalization Considerations . . . . . . . . . . . . . 10 8.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Language Identifiers in Queries and Responses . . . . . . 10 8.3. Language Identifiers in HTTP Headers . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Newton, et al. Expires June 8, 2013 [Page 2] =0C Internet-Draft RDAP over HTTP December 2012 1. Introduction This document describes the usage of HTTP for Registration Data Directory Services running on RESTful web servers. The goal of this document is to tie together the usage patterns of HTTP into a common profile applicable to the various types of Directory Services serving Registration Data using RESTful styling. By giving the various Directory Services common behavior, a single client is better able to retrieve data from Directory Services adhering to this behavior. In designing these common usage patterns, this draft endeavours to satisfy requirements for a Registration Data Access Protocol (RDAP) that is documented in [draft-kucherawy-weirds-requirements]. This draft also introduces an additional design consideration to define a simple use of HTTP. Where complexity may reside, it is the goal of this specification to place it upon the server and to keep the client as simple as possible. A client implementation should be possible using common operating system scripting tools. This is the basic usage pattern for this protocol: 1. A client issues an HTTP query using GET. As an example, a query for the network registration 192.0.2.0 might be http://example.com/ip/192.0.2.0. 2. If the receiving server has the information for the query, it examines the Accept header field of the query and returns a 200 response with a response entity appropriate for the requested format. 3. If the receiving server does not have the information for the query but does have knowledge of where the information can be found, it will return a redirection response (3xx) with the Location: header containing an HTTP URL pointing to the information or another server known to have knowledge of the location of the information. The client is expected to re-query using that HTTP URL. 4. If the receiving server does not have the information being requested and does not have knowledge of where the information can be found, it should return a 404 response. It is important to note that it is not the intent of this document to redefine the meaning and semantics of HTTP. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. Newton, et al. Expires June 8, 2013 [Page 3] =0C Internet-Draft RDAP over HTTP December 2012 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. As is noted in SSAC Report on WHOIS Terminology and Structure [SAC-051], the term "Whois" is overloaded, often referring to a protocol, a service and data. In accordance with [SAC-051], this document describes the base behavior for a Registration Data Access Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for Doman Name Registries (DNRs), DNRD-AP. 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). RIRs are also often referred to as number resource registries and are responsible for the registration of IP address networks and autonomous system numbers. Newton, et al. Expires June 8, 2013 [Page 4] =0C Internet-Draft RDAP over HTTP December 2012 3. Design Intents There are a few design criteria this document attempts to support. First, each query is meant to return either zero or one result. With the maximum upper bound being set to one, the issuance of redirects is simplified to the known query/respone model used by HTTP [RFC2616]. Should a result contain more than one result, some of which are better served by other servers, the redirection model becomes much more complicated. Second, multiple response formats are supported by this protocol. At present the IETF WEIRDS working group is defining only a JSON [RFC4627] response format, but server operators may use other data formats when those formats are requested. 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. 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. Newton, et al. Expires June 8, 2013 [Page 5] =0C Internet-Draft RDAP over HTTP December 2012 4. Queries 4.1. Accept Header 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". 4.2. Query Parameters Servers SHOULD ignore unknown query parameters. Use of unknown query parameters for cache-busting is described in Appendix A. Newton, et al. Expires June 8, 2013 [Page 6] =0C Internet-Draft RDAP over HTTP December 2012 5. Types of HTTP Response This section describes the various types of responses a server may send to a client. While no standard HTTP response code is forbidden in usage, at a minimum clients SHOULD understand the response codes described in this section. It is expected that usage of response codes and types for this application not defined here will be described in subsequent documents. 5.1. Positive Answers 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. 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. In other words, the server is to hand back a complete URL and the client should not have to transform the URL to follow it. I think here it would be appropriate to provide an example, so that = the=20 "complete URL" meaning is clear. Here is suggested text: ADD: 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. For example, if the client sends = http://serv1.example.com/weirds/domain/example.com, the server = redirecting to https://serv2.example.net/weirds2/ would set the = Location: field to the value: = https://serv2.example.net/weirds2/domain/example.com. A server SHOULD use a 301 response to inform the client of a permanent move and a 307 response otherwise. For this application, such an example of a permanent move might be a top level domain (TLD) operator informing a client the information being sought can be found with another TLD operator (i.e. a query for the domain bar in foo.example is found at http://foo.example/domain/bar). 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. 5.4. Malformed Queries If a server receives a query which it cannot understand, it SHOULD return a 400 response code. Optionally, it MAY include additional information regarding this negative answer in the HTTP entity body. Newton, et al. Expires June 8, 2013 [Page 7] =0C Internet-Draft RDAP over HTTP December 2012 6. Extensibility For extensibility purposes, this document defines an IANA registry for prefixes used in JSON [RFC4627] data serialization and URI path segments (see Section 7). Prefixes and identifiers SHOULD only consist of the alphabetic ASCII characters A through Z in both uppercase and lowercase, the numerical digits 0 through 9, underscore characters, and SHOULD NOT begin with an underscore character, numerical digit or the characters "xml". The following describes the production of JSON names in ABNF [RFC5234]. ABNF for JSON names name =3D ALPHA *( ALPHA / DIGIT / "_" ) Figure 1 This restriction is a union of the Ruby programming language identifier syntax and the XML element name syntax and has two purposes. 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. Second, a clean mapping between JSON and XML is easy to accomplish using these rules. I think the registry should be set by the rdap-query draft. = Moreover, the registry should also contain the initial defined query = segments defined in rdap-query, so that the registry will be complete. = Reasoning: for developers, operators, etc..., a single registry is = easier for finding all possibilities. A single registry (with the all = the defined segments) would make sure that there is no conflict of = names. It is possible that another RFC defines another standard query, = which would not be listed into the rdap-query RFC, so no easy way to = track. For all these reasons, the registry should contain the standard = defined query patterns defined in rdap-query. Suggested text: ADD: The registry should include the query path definitions defined in = draft-ietf-weirds-rdap-query: ip autnum domain nameserver entity custom_ =20 and have the reference of these entries pointing to = draft-ietf-weirds-rdap-query. Newton, et al. Expires June 8, 2013 [Page 8] =0C Internet-Draft RDAP over HTTP December 2012 7. IANA Considerations This specification proposes an IANA registry for RDAP extensions. The purpose of this registry is to ensure uniqueness of extension identifiers. The extension identifier is used as prefix in JSON names and as a prefix of path segments in RDAP URLs. The production rule for these identifiers is specified in Section 6. 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. The following is a preliminary template for an RDAP extension registration: Extension identifier: the identifier of the extension Registry operator: the name of the registry operator Published specification: RFC number, bibliographical reference or URL to a permanent and readily available specification Person & email address to contact for further information: The names and email addresses of individuals for contact regarding this registry entry Intended usage: brief reasons for this registry entry The following is an example of a registration in the RDAP extension registry: Extension identifier: lunarNic Registry operator: The Registry of the Moon, LLC Published specification: http://www.example/moon_apis/rdap Person & email address to contact for further information: Professor Bernardo de la Paz Intended usage: COMMON Newton, et al. Expires June 8, 2013 [Page 9] =0C Internet-Draft RDAP over HTTP December 2012 8. Internationalization Considerations 8.1. URIs and IRIs 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. 8.2. Language Identifiers in Queries and Responses 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). Under most scenarios, clients requesting data will not signal that the data be returned in a particular language or script. On the other hand, when servers return data and have knowledge that the data is in a language or script, the data should be annotated with language identifiers thus allowing clients to process and display the data accordingly. A language identifier in the response is specified in section 5.3 of [draft-ietf-weirds-json-response]. It is used to indicate the language/script of the response data. It is possible that registration data is stored in several different languages and returned in a single response. Data portion of different language types SHOULD be tagged with its corresponding identifier if known. 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. However, servers MAY return language identifiers in the Content- Language header so as to inform clients of the intended language of HTTP layer messages. Newton, et al. Expires June 8, 2013 [Page 10] =0C Internet-Draft RDAP over HTTP December 2012 9. Normative References [draft-kucherawy-weirds-requirements] Kucherawy, M., "Requirements For Internet Registry Services", Work in progress: Internet Drafts draft-kucherawy-weirds-requirements-04.txt, April 2011. [draft-ietf-weirds-json-response] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", Work in progress: Internet Drafts draft-ietf-weirds-json-response-01.txt, December 2012. [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS Terminology and Structure", September 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Newton, et al. Expires June 8, 2013 [Page 11] =0C Internet-Draft RDAP over HTTP December 2012 Appendix A. Cache Busting To overcome issues with misbehaving HTTP [RFC2616] cache infrastructure, clients MAY use an adhoc and improbably used query parameter with a random value of their choosing. As Section 4.2 instructs servers to ignore unknown parameters, this is unlikely to have any known side effects. An example of using an unknown query parameter to bust caches: http://example.com/ip/192.0.2.0?__fuhgetaboutit=3Dxyz123 Use of an unknown parameter to overcome misbehaving caches is not part of any specification and is offered here for informational purposes. Newton, et al. Expires June 8, 2013 [Page 12] =0C Internet-Draft RDAP over HTTP December 2012 Appendix B. Changelog Initial WG -00: Updated to working group document 2012-September-20 -01 * Updated for the sections moved to the JSON responses draft. * Simplified media type, removed "level" parameter. * Updated 2119 language and added boilerplate. * In section 1, noted that redirects can go to redirect servers as well. * Added Section 8.2 and Section 8.3. Newton, et al. Expires June 8, 2013 [Page 13] =0C Internet-Draft RDAP over HTTP December 2012 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 Byron J. Ellacott Asia Pacific Network Information Center 6 Cordelia Street South Brisbane QLD 4101 Australia Email: bje@apnic.net URI: http://www.apnic.net Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Newton, et al. Expires June 8, 2013 [Page 14] =0C --Apple-Mail=_83A6D8EB-B9CE-4814-B2C5-1C68AB84A52C-- From aservin@lacnic.net Sat Feb 23 00:15: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 6271E21F8F4B for ; Sat, 23 Feb 2013 00:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 h1C9Zh1Wrku7 for ; Sat, 23 Feb 2013 00:15:12 -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 A554721F8DCB for ; Sat, 23 Feb 2013 00:15:09 -0800 (PST) Received: from MiniR2D2.local (unknown [203.126.139.254]) by mail.lacnic.net.uy (Postfix) with ESMTP id 9E438308454 for ; Sat, 23 Feb 2013 06:14:55 -0200 (UYST) Message-ID: <51287A80.3060406@lacnic.net> Date: Sat, 23 Feb 2013 16:14:56 +0800 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: <23C97473-FFB0-4686-B3EA-BDC043AB9B6A@viagenie.ca> In-Reply-To: <23C97473-FFB0-4686-B3EA-BDC043AB9B6A@viagenie.ca> 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] 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: Sat, 23 Feb 2013 08:15:19 -0000 Just a short comment. " The resource type path segments are: o 'ip': IP networks and associated data referenced using either an IPv4 or IPv6 address. o 'autnum': Autonomous system registrations and associated data referenced using an AS Plain autonomous system number. o 'domain': Reverse DNS (RIR) or domain name (DNR) information and associated data referenced using a fully-qualified domain name. o 'nameserver': Used to identify a name server information query. Since this document talks about multiple kinds of registries and that RIR may have names, I suggest to state "DNS name server" here to be more precise, since that is the intent. " For the sake of keeping things clear I prefer the way it is, it is very clear that in the case of RIRs is the reverse zone under .arpa. /as On 23/02/2013 04:41, Marc Blanchet wrote: > hello, > please find my comments embedded in the copy of the draft and tagged with . credit: Few of the comments are also from my colleague Jean-Philippe Dionne. > > Regards, Marc. > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From internet-drafts@ietf.org Sun Feb 24 19:42: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 D490D21F91B3; Sun, 24 Feb 2013 19:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 tjlH55VBvzI3; Sun, 24 Feb 2013 19:42:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231A321F91AF; Sun, 24 Feb 2013 19:42:04 -0800 (PST) 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.40 Message-ID: <20130225034204.13204.64180.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 19:42:04 -0800 Cc: weirds@ietf.org Subject: [weirds] 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: Mon, 25 Feb 2013 03:42:05 -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 : Redirection Service for Registration Data Access Protocol Author(s) : Carlos M. Martinez Arturo L. Servin Linlin Zhou Dario Gomez Gerardo Rada Filename : draft-ietf-weirds-redirects-01.txt Pages : 11 Date : 2013-02-24 Abstract: The traditional WHOIS protocol has several important shortcomings, and over the past few years several approaches to a better Registration Data Access Protocol (RDAP) have been discussed and proposed. Among these shortcomings, different registries operate different WHOIS services. For users this implies that several WHOIS queries to different registries may be necessary in order to obtain data for a given resource. This document describes a redirection service for RESTful WHOIS queries. This service allows users to query a single WHOIS service and be redirected to the authoritative registry. The solution implemented proposed here applies to Regional Internet Registries(RIRs) and Domain Name Registries(DNRs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-redirects There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-redirects-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-redirects-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aservin@lacnic.net Sun Feb 24 19:53: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 272AE21F91A9 for ; Sun, 24 Feb 2013 19:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 9lmjcmniEJ3D for ; Sun, 24 Feb 2013 19:53:34 -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 0F6E121F919B for ; Sun, 24 Feb 2013 19:53:34 -0800 (PST) Received: from MiniR2D2.local (unknown [203.126.139.254]) by mail.lacnic.net.uy (Postfix) with ESMTP id E7C49308464 for ; Mon, 25 Feb 2013 01:53:19 -0200 (UYST) Message-ID: <512AE032.3080302@lacnic.net> Date: Mon, 25 Feb 2013 11:53:22 +0800 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: <20130225034204.13204.64180.idtracker@ietfa.amsl.com> In-Reply-To: <20130225034204.13204.64180.idtracker@ietfa.amsl.com> 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] 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: Mon, 25 Feb 2013 03:53:35 -0000 Changes from lastest version: The original version was a description of the LACNIC's prototype redirection service. For the version 00 of the draft we didn't changed anything. For this version we added a new author and we changed the document to describe a redirection service for WEIRDS (or we have tried to). We also we would like to hear some feedback about how you want a redirection service: 1) Just doing a staless http redirection 2) Doing statefull http redirection to avoid loops (considering that the user agent may be bad implemented and incapable of break a loop) 3) Something in between as we are proposing with the trade-offs that we describe. @to the chairs Do you consider that we should discuss this at the Orlando session? Thanks! as On 25/02/2013 11:42, 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 : Redirection Service for Registration Data Access Protocol > Author(s) : Carlos M. Martinez > Arturo L. Servin > Linlin Zhou > Dario Gomez > Gerardo Rada > Filename : draft-ietf-weirds-redirects-01.txt > Pages : 11 > Date : 2013-02-24 > > Abstract: > The traditional WHOIS protocol has several important shortcomings, > and over the past few years several approaches to a better > Registration Data Access Protocol (RDAP) have been discussed and > proposed. > > Among these shortcomings, different registries operate different > WHOIS services. For users this implies that several WHOIS queries to > different registries may be necessary in order to obtain data for a > given resource. > > This document describes a redirection service for RESTful WHOIS > queries. This service allows users to query a single WHOIS service > and be redirected to the authoritative registry. > > The solution implemented proposed here applies to Regional Internet > Registries(RIRs) and Domain Name Registries(DNRs). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-weirds-redirects > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-weirds-redirects-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-redirects-01 > > > 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 johnl@iecc.com Mon Feb 25 12:12: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 2034721F84BE for ; Mon, 25 Feb 2013 12:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.021 X-Spam-Level: X-Spam-Status: No, score=-111.021 tagged_above=-999 required=5 tests=[AWL=0.178, 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 vgAwL65bns+y for ; Mon, 25 Feb 2013 12:12:42 -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 D3FCF21E80BD for ; Mon, 25 Feb 2013 12:12:23 -0800 (PST) Received: (qmail 49072 invoked from network); 25 Feb 2013 20:12:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Feb 2013 20:12:22 -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=512bc5a6.xn--30v786c.k1302; i=johnl@user.iecc.com; bh=wXRR2UOK4fEBkqHCw8uIoou7fn15wMUyDbzasu//k+c=; b=A24xgBOqS+cBeXm8b2CsLJSnV4i1OdRZ9heCc1lFzYHRmK7TfVcO+jQLbk9NYoVJOHWwbSG3ozu8cQs+Nn1XTv6cwXunGAdixfoBI9CprI5JQO49MtvryD+iLg31+dZ+WQHOvuB6qCbOyXUhLxSjYrKxbEzPvwgeRDdVX4ONzj0= 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=512bc5a6.xn--30v786c.k1302; olt=johnl@user.iecc.com; bh=wXRR2UOK4fEBkqHCw8uIoou7fn15wMUyDbzasu//k+c=; b=O+Qos0bbR2Uip51Tpscea+85CcZMuqLcx3uiLfGQtFr4L/Rr9yhCNrCMsrslLgTfumAH5LAHD0yOCmxobVEf0HC8uCuBuPMF5TunyBfw2R0jnKidclz8hbuJd4Dm5hntXPeEMsAQ/+p6xgG0N3+ourg0EtF+2qanE5ZW8wyBebo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Feb 2013 20:11:58 -0000 Message-ID: <20130225201158.26041.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <512AE032.3080302@lacnic.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-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: Mon, 25 Feb 2013 20:12:45 -0000 > 2) Doing statefull http redirection to avoid loops (considering that >the user agent may be bad implemented and incapable of break a loop) Has this been a problem in practice? HTTP has had redirects for 20 years. I'd think that redirect loops would be a solved problem at that level. -- 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 andy@arin.net Mon Feb 25 22:23: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 DD61C21F9666 for ; Mon, 25 Feb 2013 22:23:54 -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 1Sf1FF-nzkMG for ; Mon, 25 Feb 2013 22:23:53 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAB321F95FF for ; Mon, 25 Feb 2013 22:23:52 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id F26C9213689; Tue, 26 Feb 2013 01:23:43 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 598E0213600; Tue, 26 Feb 2013 01:23:43 -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; Tue, 26 Feb 2013 01: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; Tue, 26 Feb 2013 01:23:41 -0500 From: Andy Newton To: Marc Blanchet , "draft-ietf-weirds-rdap-query@tools.ietf.org" Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: AQHOET0fX2h/HTzfjU6Bs6Hy4KToBJiMiw8A Date: Tue, 26 Feb 2013 06:23:40 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF388@CHAXCH01.corp.arin.net> In-Reply-To: <23C97473-FFB0-4686-B3EA-BDC043AB9B6A@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.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <769F4B6CE2DC424680585335ACEA28AD@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@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: Tue, 26 Feb 2013 06:23:55 -0000 From: Marc Blanchet >hello, > please find my comments embedded in the copy of the draft and tagged >with . credit: Few of the comments are also from my colleague >Jean-Philippe Dionne. Marc, Thanks for the review. I owe you a beer in Orlando. (see how that works, people!) I'm responding here for the issues on which I have comments. Ones in which I am agreement are not listed. > 1.1.=20 > Add "RESTful" into this set and a reference for definition There was quite a bit of discussion on the list as regards to REST vs RESTful. I could provide my interpretation of RESTful, but I wonder if there is an external reference handy (one that doesn't confuse REST with RESTful). > 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. While registering the IETF specified queries is doable, do we conversely register the IETF specified JSON names? That would be a big registration. Again, thanks for the review Marc. Much appreciated. -andy From andy@arin.net Mon Feb 25 22:26: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 6C77A21F9666 for ; Mon, 25 Feb 2013 22:26:58 -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 iZgSCoTNgGQ6 for ; Mon, 25 Feb 2013 22:26:57 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id B68AC21F917D for ; Mon, 25 Feb 2013 22:26:57 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 6851D16510C; Tue, 26 Feb 2013 01:26:57 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id E16111650FE; Tue, 26 Feb 2013 01:26:56 -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, 26 Feb 2013 01:26: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; Tue, 26 Feb 2013 01:26:43 -0500 From: Andy Newton To: Marc Blanchet , "draft-ietf-weirds-rdap-using-http@tools.ietf.org" Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-using-http Thread-Index: AQHOET1XkcCFwjMW20mVmLUTGFyFMpiMi+IA Date: Tue, 26 Feb 2013 06:26:43 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF3A1@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: <15C1ED5AE4B77643A2CC681C2A557745@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] review comments on draft-ietf-weirds-rdap-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: Tue, 26 Feb 2013 06:26:58 -0000 From: Marc Blanchet >hello, >please find my comments embedded in the copy of the draft and tagged with >. credit: Few of the comments are also from my colleague >Jean-Philippe Dionne. > >Regards, Marc. Marc, Thanks for the review. I guess you get two beers in Orlando! I agree with the need for adding the redirect example. As to the comment about the registry, please see my email regarding your rdap-query review. Thanks again. -andy From jean-philippe.dionne@viagenie.ca Tue Feb 26 07: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 D987D21F88E8 for ; Tue, 26 Feb 2013 07:20:44 -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 yHhH0yaFO-RZ for ; Tue, 26 Feb 2013 07:20:43 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 084ED21F88DB for ; Tue, 26 Feb 2013 07:20:43 -0800 (PST) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 63DA240419 for ; Tue, 26 Feb 2013 10:20:42 -0500 (EST) Message-ID: <512CD2C9.5000209@viagenie.ca> Date: Tue, 26 Feb 2013 10:20:41 -0500 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: weirds@ietf.org Content-Type: multipart/mixed; boundary="------------030400060109010806020307" Subject: [weirds] Comments on draft-hollenbeck-weirds-rdap-search X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Feb 2013 15:20:45 -0000 This is a multi-part message in MIME format. --------------030400060109010806020307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, Here are my comments on the rdap search draft. Regards Jean-Philippe --------------030400060109010806020307 Content-Type: text/plain; charset=UTF-8; name="draft-hollenbeck-weirds-rdap-search-JPD.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-hollenbeck-weirds-rdap-search-JPD.txt" Network Working Group S. Hollenbeck Internet-Draft Verisign Labs Intended status: Standards Track A. Newton Expires: August 18, 2013 ARIN February 14, 2013 Registration Data Access Protocol Search Processing draft-hollenbeck-weirds-rdap-search-01 Abstract This document describes path segments and query parameters needed to construct HTTP URLs that may be used to search for and retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. It also describes a method of encoding responses using Javascript Object Notation (JSON). 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 August 18, 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 Hollenbeck & Newton Expires August 18, 2013 [Page 1] Internet-Draft RDAP Search February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . . 3 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Query and Search Parameters . . . . . . . . . . . . . . . . . . 3 3.1. Domain Search . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Entity Search . . . . . . . . . . . . . . . . . . . . . . . 4 4. Search Processing . . . . . . . . . . . . . . . . . . . . . . . 4 5. Search Results . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Internationalization Considerations . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Hollenbeck & Newton Expires August 18, 2013 [Page 2] Internet-Draft RDAP Search February 2013 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.1. Acronyms and Abbreviations DNR: Domain Name Registry RDAP: Registration Data Access Protocol RIR: Regional Internet Registry 2. Introduction This document describes a specification for registration data search functions using a RESTful web service. The search functions are implemented using the Hypertext Transfer Protocol (HTTP) [RFC2616]. Lookup processing as specified in [I-D.ietf-weirds-rdap-query] is used when a client wishes to retrieve information associated with a data object represented by a character string that exactly matches a particular key. There is no provision for partial string pattern matching to represent unknown characters or multiple result possibilities. By "unkown character", I understand "character that cannot be displayed". I propose the following: "There is no provision for partial string pattern matching or multiple result possiblities." Experience with WHOIS [RFC3912] implementation and operation has shown that people are often unsure of exact spellings and they often want to receive multiple results that match a particular pattern. This specification is intended to meet that need for the Registration Data Access Protocol (RDAP). With Internationalized domain names, the situation of being unsure of the exact spelling will be exacerbated. In section 4, we can read: "This document does not specify partial matching processing rules for Unicode or DNS u-label matching." This document is the right place to cover the problem of searching IDN records and internationalized string in general. 3. Query and Search Parameters RDAP search path segments are formed using a concatenation of the plural form of the object being searched for, a forward slash character ('/', ASCII value 0x002F), and an HTTP query string. The HTTP query string is formed using a concatenation of the question mark character ('?', ASCII value 0x003F), the JSON object value associated with the object being searched for, the equal sign character ('=', ASCII value 0x003D), and the search pattern. For the domain and entity objects described in this document the plural objects forms are "domains" and "entities". The JSON object value is "name". One could construct a query string for an entity email address using the "email" object name, but that is beyond the scope of this specification. "ASCII value" is not 16 bits. 0x002F should be 0x2F or U+002F. Hollenbeck & Newton Expires August 18, 2013 [Page 3] Internet-Draft RDAP Search February 2013 3.1. Domain Search Syntax: domains/?name= Searches for domain information are of the form /domains/?name=XXXX, where XXXX is a search pattern representing a fully-qualified domain name [RFC4343] in a zone administered by the server operator of a DNR. (Open question: how do we do IDNs?) The following path would be used to find DNR information for domain names matching the "example*.com" pattern: /domains/?name=example*.com Note that this search is relevant to DNRs, not RIRs. 3.2. Entity Search Syntax: entities/?name= Searches for entity information are of the form /entities/?name=XXXX, where XXXX is a search pattern representing an entity name as specified in Section 7.1 of [I-D.ietf-weirds-json-response]. The following path would be used to find DNR information for DNR entity names matching the "Bobby Joe*" pattern. /entities/?name=Bobby%20Joe* URLs MUST be properly encoded according to the rules of [RFC3986]. In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*". Is there a mendatory one-to-one mapping between the parameter name in the search url and the property name in the json response? e.g.: - /entities/?name= matches the "name" property in the json response. - /entities/?handle= matches the "handle" property in the json response. I also propose an alternative way of searching by using a json template in a POST request. e.g: POST /entities { "rdapConformance" : [ "rdap_level_0" ], "name": "NET-RTR-*", } This has the advantage of reusing the json response format as a template. 3.3 Search based on date. Are there use cases for search based on dates? Such as the Whowas service provided by ARIN? I guess this could be described in a separate document. 4. Search Processing Searching occurs either on whole strings or on partial strings. Partial string searching uses the asterisk ('*', ASCII value 0x002A) character to match zero or more characters. The location or number of occurances of the asterisk character is not dictated by this specification. Some servers might support the asterisk in a trailing location only (e.g. "/domains/example*.com") while others may allow it a leading location (e.g. "/domains/*example.com"), or within strings, or even in multiple locations. If a server receives a search request but cannot process the request because it does not support a particular style of partial match searching, it SHOULD return an HTTP 422 [RFC4918] error. When returning a 422 error, the server MAY also return an error response body as specified in Section 12 of [I-D.ietf-weirds-json-response] if the requested media type is one that is specified in For clarity, add the 422 error name: "Unprocessable Entity". Hollenbeck & Newton Expires August 18, 2013 [Page 4] Internet-Draft RDAP Search February 2013 [I-D.ietf-weirds-using-http]. The search patterns described in this document MAY include non-ASCII Unicode characters. This document does not specify partial matching processing rules for Unicode or DNS u-label matching. Partial string matching criteria for Unicode and DNS u-label characters is a matter of local server policy. See Section 6 for guidelines that may be used to develop local policies. The should be specified here for IDN and not only in section 6 as local policy. I suggest to remove the last 3 sentences above and replace it by: The search pattern can be composed of a-label and u-label separated by dots. Wildcard '*' characters can be inserted into any of the u-labels. The u-label must be appropriately percent encoded. e.g.: For a search of "démo*.com" : /domains/?name=d%C3%A9mo*.com The mapping of unicode characters to domain names is performed by the RDAP server according to "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 [RFC5895]". Clients SHOULD NOT submit search requests with partial matching for DNS a-labels. A-labels represent an encoding that can only be reconstructed properly when the label is complete. 5. Search Results The method to return search results described here is not limited to the /domains or /entities searches defined in this document. It can also be used by future specifications to define search results for other types of registration data. Search results are returned in a JSON object. This object contains data structures as outlined in Section 5 of [I-D.ietf-weirds-json-response] (e.g. "rdapConformance", "notices", etc...) and an array called "results" containing the objects that are a result of the search. For the /domains (Section 3.1) and /entities (Section 3.2) searches, the entity object class and the domain object class are defined in [I-D.ietf-weirds-json-response]. To identify the type of object returned in the "results" array, each object SHOULD contain a JSON string named "objectClass" (see Section 4.2 of [I-D.ietf-weirds-json-response] regarding the inclusion of new JSON data in object classes). For domains, the string MUST be "domain" and for entities the string MUST be "entity". Servers SHOULD signify their compliance with this specification by including the string "domain_entity_search_level_0" in the "rdapConformance" array. Hollenbeck & Newton Expires August 18, 2013 [Page 5] Internet-Draft RDAP Search February 2013 { "rdapConformance" : [ "rdap_level_0", "domain_entity_search_level_0" ], ... "results" : [ { "handle" : "1-XXXX", "name" : "1.example.com", "objectClass" : "domain", ... }, { "handle" : "2-XXXX", "name" : "2.example.com", "objectClass" : "domain", ... } ] } Figure 1 Server policies will require the servers to limit the number of search results returned. How will the client be notified about this? Does the server returns an error or a partial result list? The client can be notified by a 20x status code and/or with a notice in the json response. 6. Internationalization Considerations TBD. Give guidelines for how a local policy could work for searching. 7. IANA Considerations This document does not specify any IANA actions. 8. Security Considerations Security services for the operations specified in this document are described in "Security Services for the Registration Data Access Protocol" [I-D.ietf-weirds-rdap-sec]. As we identify specific use cases for which security services are needed they will be described here. Hollenbeck & Newton Expires August 18, 2013 [Page 6] Internet-Draft RDAP Search February 2013 9. Acknowledgements The authors would like to acknowledge the following individuals for their contributions to this document: TBD. 10. References 10.1. Normative References [I-D.ietf-weirds-json-response] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", draft-ietf-weirds-json-response-02 (work in progress), January 2013. [I-D.ietf-weirds-rdap-query] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol Query Format", draft-ietf-weirds-rdap-query-02 (work in progress), December 2012. [I-D.ietf-weirds-rdap-sec] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol", draft-ietf-weirds-rdap-sec-01 (work in progress), November 2012. [I-D.ietf-weirds-using-http] Newton, A., Ellacott, B., and N. Kong, "Using the Registration Data Access Protocol (RDAP) with HTTP", draft-ietf-weirds-using-http-01 (work in progress), December 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006. [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Hollenbeck & Newton Expires August 18, 2013 [Page 7] Internet-Draft RDAP Search February 2013 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 10.2. Informative References [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. Appendix A. Change Log Initial -00: First draft individual submission. -01: Changed HTTP error code from 500 to 422 in Section 4. Added a normative reference to RFC 4918. Authors' Addresses Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 US Email: andy@arin.net URI: http://www.arin.net Hollenbeck & Newton Expires August 18, 2013 [Page 8] --------------030400060109010806020307-- From jean-philippe.dionne@viagenie.ca Tue Feb 26 07:24: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 78C0521F8704 for ; Tue, 26 Feb 2013 07:24:05 -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 tpv2-YRplnlv for ; Tue, 26 Feb 2013 07:23:58 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C66F21F86DD for ; Tue, 26 Feb 2013 07:23:46 -0800 (PST) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0625D40419 for ; Tue, 26 Feb 2013 10:23:12 -0500 (EST) Message-ID: <512CD35F.7070102@viagenie.ca> Date: Tue, 26 Feb 2013 10:23:11 -0500 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: weirds@ietf.org Content-Type: multipart/mixed; boundary="------------010507010101020900030909" Subject: [weirds] Comments on draft-ietf-weirds-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, 26 Feb 2013 15:24:05 -0000 This is a multi-part message in MIME format. --------------010507010101020900030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, A few comments on the IANA considerations for the JSON reponse draft. Regards Jean-Philippe --------------010507010101020900030909 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-weirds-json-response-02-JPD.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-weirds-json-response-02-JPD.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]. 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. 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" ] An IANA registry needs to be created to protect the namespace. 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" } 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 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" } 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" } ] } 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" } ] } 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" } ] } 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" } ] } 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 IANA shall create a new registry for the "rdapConformance" namespace. Two registration procedures are defined according to string prefixes: - "rdap_": Standard Action - "local_": First Come, First Served This specification adds one entry to the registry: Name Description Reference ------------ ----------- --------------- rdap_level_0 [This document] The json response schema could also be maintained by an IANA registry. A registry can protect the first level property names defined in this document. 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. 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 ] } 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" } ] } ] } 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. Add note: The "names" and "variants" field must be in a-label form only. This appendix should only describe the format of the response in relation with IDN. The discussion about the client behavior should be moved into draft-ietf-weirds-rdap-query and draft-hollenbeck-weirds-rdap-search. 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. 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] --------------010507010101020900030909-- From marc.blanchet@viagenie.ca Tue Feb 26 18:12: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 2A68021F85D7 for ; Tue, 26 Feb 2013 18:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 0qTiUB+yqREc for ; Tue, 26 Feb 2013 18:12:35 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2E21F85C2 for ; Tue, 26 Feb 2013 18:12:35 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 59AC6403C5; Tue, 26 Feb 2013 21:12:34 -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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF388@CHAXCH01.corp.arin.net> Date: Tue, 26 Feb 2013 21:12:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5AC80493-D576-4766-B2C1-0DC31B0EA298@viagenie.ca> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF388@CHAXCH01.corp.arin.net> To: Andy Newton 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: Wed, 27 Feb 2013 02:12:36 -0000 Le 2013-02-26 =E0 01:23, Andy Newton a =E9crit : > From: Marc Blanchet >> hello, >> please find my comments embedded in the copy of the draft and tagged >> with . credit: Few of the comments are also from my colleague >> Jean-Philippe Dionne. >=20 > Marc, >=20 > Thanks for the review. I owe you a beer in Orlando. (see how that = works, > people!) >=20 > I'm responding here for the issues on which I have comments. Ones in = which > I am agreement are not listed. >=20 >> 1.1.=20 >> Add "RESTful" into this set and a reference for definition >=20 >=20 > There was quite a bit of discussion on the list as regards to REST vs > RESTful. I could provide my interpretation of RESTful, but I wonder if > there is an external reference handy (one that doesn't confuse REST = with > RESTful). minor comment. you may ignore it. one ref could be wikipedia: = http://en.wikipedia.org/wiki/Representational_state_transfer >=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. 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, I think we should. > do we conversely > register the IETF specified JSON names? That would be a big = registration. good question. Let me think about it. Marc. >=20 > Again, thanks for the review Marc. Much appreciated. >=20 > -andy From marc.blanchet@viagenie.ca Tue Feb 26 18:13: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 A22CA21F85ED for ; Tue, 26 Feb 2013 18:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 ch6ATUA+IgZH for ; Tue, 26 Feb 2013 18:13:50 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 152BB21F85EB for ; Tue, 26 Feb 2013 18:13:50 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 633E5403C5; Tue, 26 Feb 2013 21:13:19 -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: <51287A80.3060406@lacnic.net> Date: Tue, 26 Feb 2013 21:13:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA07AD6-6FEC-4360-A38A-91F259DB6E42@viagenie.ca> References: <23C97473-FFB0-4686-B3EA-BDC043AB9B6A@viagenie.ca> <51287A80.3060406@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1499) Cc: weirds@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: Wed, 27 Feb 2013 02:13:50 -0000 Le 2013-02-23 =E0 03:14, Arturo Servin a =E9crit : >=20 > Just a short comment. >=20 > " > The resource type path segments are: > o 'ip': IP networks and associated data referenced using either an > IPv4 or IPv6 address. > o 'autnum': Autonomous system registrations and associated data > referenced using an AS Plain autonomous system number. > o 'domain': Reverse DNS (RIR) or domain name (DNR) information and > associated data referenced using a fully-qualified domain name. > o 'nameserver': Used to identify a name server information query. >=20 > Since this document talks about multiple kinds of registries and > that RIR may have names, I suggest to state "DNS name server" here to = be > more precise, since that is the intent. > " >=20 > For the sake of keeping things clear I prefer the way it is, it = is > very clear that in the case of RIRs is the reverse zone under .arpa. >=20 fine. was a minor comment anyway. Marc. >=20 > /as >=20 >=20 >=20 > On 23/02/2013 04:41, Marc Blanchet wrote: >> hello, >> please find my comments embedded in the copy of the draft and tagged = with . credit: Few of the comments are also from my colleague = Jean-Philippe Dionne. >>=20 >> Regards, Marc. >>=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 andy@arin.net Tue Feb 26 19:25: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 90AEC21F86D8 for ; Tue, 26 Feb 2013 19:25:53 -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 Q49hY4HKtDQI for ; Tue, 26 Feb 2013 19:25:53 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F221F856F for ; Tue, 26 Feb 2013 19:25:52 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 89979213648; Tue, 26 Feb 2013 22:25:52 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 9B20D213615; Tue, 26 Feb 2013 22:25:51 -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, 26 Feb 2013 22:25:16 -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, 26 Feb 2013 22:25:50 -0500 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-hollenbeck-weirds-rdap-search Thread-Index: AQHOFDTeBje9lRnYNU+TFfHsmHfHpJiN5ciA Date: Wed, 27 Feb 2013 03:25:50 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF7E6@CHAXCH01.corp.arin.net> In-Reply-To: <512CD2C9.5000209@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.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <55BCA63A792A32429D7C0D6AA782616C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-hollenbeck-weirds-rdap-search X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Feb 2013 03:25:53 -0000 On 2/26/13 11:20 PM, "Jean-Philippe Dionne" wrote: >Hi All, > >Here are my comments on the rdap search draft. > >Regards >Jean-Philippe > Jean-Philippe, Thanks for the review. Below are my comments: Section 2: > > With Internationalized domain names, the situation of being unsure of >the exact > spelling will be exacerbated. In section 4, we can read: > "This document does not specify partial matching processing rules for >Unicode or > DNS u-label matching." > > This document is the right place to cover the problem of searching IDN >records and internationalized string in > general. > The point of this is that such rules are locally defined. Scott and I are looking at issues with Unicode and not finding good references for doing substring searches and partial matching. If you know of existing practices or standards in this space, we would be very interested in re-using them if possible. Section 3.2: > > Is there a mendatory one-to-one mapping between the parameter name in the > search url and the property name in the json response? e.g.: > - /entities/?name=3D matches the "name" property in the json >response. > - /entities/?handle=3D matches the "handle" property in the json >response. > > I also propose an alternative way of searching by using a json template >in a > POST request. e.g: > > POST /entities > { > "rdapConformance" : > [ > "rdap_level_0" > ], > "name": "NET-RTR-*", > } > > This has the advantage of reusing the json response format as a template. That's a very interesting approach. At the moment I don't think it offers any capabilities over query parameters but I see the potential if complexity is added where JSON would be a better serialization than query parameters. Section 3.3: > > 3.3 Search based on date. > Are there use cases for search based on dates? Such as the Whowas >service > provided by ARIN? I guess this could be described in a separate >document. > I think WhoWas services should be separate from the WEIRDS effort. ARIN's implementation isn't a real-time service specifically because of the amount of data involved and the special acceptable use policy around the service. Section 5: > > Server policies will require the servers to limit the number of search >results > returned. How will the client be notified about this? Does the server >returns > an error or a partial result list? >=20 > The client can be notified by a 20x status code and/or with a notice in >the json > response. > My first inclination is to use JSON but I haven't thought about this very much. A 20x code might be the right thing to do. Do you have specific recommendation? Thanks for the review. -andy From andy@arin.net Tue Feb 26 19:36: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 AF5A521F8721 for ; Tue, 26 Feb 2013 19:36:48 -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 ctOJSg2UGjzn for ; Tue, 26 Feb 2013 19:36:48 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id E59B221F8650 for ; Tue, 26 Feb 2013 19:36:47 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 97D25213671; Tue, 26 Feb 2013 22:36:47 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id B8EBB213665; Tue, 26 Feb 2013 22:36:46 -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; Tue, 26 Feb 2013 22:36: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; Tue, 26 Feb 2013 22:36:46 -0500 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-02 Thread-Index: AQHOFDVZZlq0ct1sn0u8j+ig45wFkJiN6NCA Date: Wed, 27 Feb 2013 03:36:45 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF7FC@CHAXCH01.corp.arin.net> In-Reply-To: <512CD35F.7070102@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.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <31B62EEAE0BF094489A18C5BCB6F5AED@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-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, 27 Feb 2013 03:36:48 -0000 On 2/26/13 11:23 PM, "Jean-Philippe Dionne" wrote: >Hi, > >A few comments on the IANA considerations for the JSON reponse draft. > >Regards >Jean-Philippe > Jean-Philippe, Thanks for the review. Here are my comments: Section 5.1: > > An IANA registry needs to be created to protect the namespace. > That registry is defined in draft-ietf-weirds-using-http. Section 11: > > IANA shall create a new registry for the "rdapConformance" namespace. > Two registration procedures are defined according to string prefixes: > - "rdap_": Standard Action > - "local_": First Come, First Served > > This specification adds one entry to the registry: > > Name Description Reference > ------------ ----------- --------------- > rdap_level_0 [This document] > > I do not understand the necessity to register the rdap_ strings since they are defined by standard action in the RFC. The intent of the registry is to offer a place where non-standard extensions can be found. Am I missing something? > > The json response schema could also be maintained by an IANA registry. > A registry can protect the first level property names defined in this >document. > That seems to be very redundant with the draft/RFC. Why would we want to do this? Can you explain further? Thanks for the review. -andy From andy@arin.net Tue Feb 26 19:38: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 91D4B21F84E9 for ; Tue, 26 Feb 2013 19:38: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXEXRKBDlrpk for ; Tue, 26 Feb 2013 19:38: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 A597121F84D1 for ; Tue, 26 Feb 2013 19:38:23 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 58ACB165508; Tue, 26 Feb 2013 22:38:23 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id DE404165502; Tue, 26 Feb 2013 22:38:22 -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; Tue, 26 Feb 2013 22:37:41 -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; Tue, 26 Feb 2013 22:38:16 -0500 From: Andy Newton To: Marc Blanchet Thread-Topic: [weirds] review comments on draft-ietf-weirds-rdap-query Thread-Index: AQHOET0fX2h/HTzfjU6Bs6Hy4KToBJiMiw8AgADGFoCAAJ4IAA== Date: Wed, 27 Feb 2013 03:38:15 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF80F@CHAXCH01.corp.arin.net> 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: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <26A0FF2D1B5D45408C9700892D36A09D@corp.arin.net> 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: Wed, 27 Feb 2013 03:38:24 -0000 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. Thanks. -andy From simon.perreault@viagenie.ca Wed Feb 27 02:55: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 2F06021F850E for ; Wed, 27 Feb 2013 02:55:18 -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 y3dwi87Elxs8 for ; Wed, 27 Feb 2013 02:55:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 263F021F8506 for ; Wed, 27 Feb 2013 02:55:16 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:bcea:a860:12fb:6e6e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3464F40418 for ; Wed, 27 Feb 2013 05:55:16 -0500 (EST) Message-ID: <512DE647.70107@viagenie.ca> Date: Wed, 27 Feb 2013 11:56:07 +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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF7FC@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEF7FC@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] Comments on draft-ietf-weirds-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, 27 Feb 2013 10:55:18 -0000 Le 2013-02-27 04:36, Andy Newton a écrit : > Section 11: >> >> IANA shall create a new registry for the "rdapConformance" namespace. >> Two registration procedures are defined according to string prefixes: >> - "rdap_": Standard Action >> - "local_": First Come, First Served >> >> This specification adds one entry to the registry: >> >> Name Description Reference >> ------------ ----------- --------------- >> rdap_level_0 [This document] >> >> > > I do not understand the necessity to register the rdap_ strings since they > are defined by standard action in the RFC. The intent of the registry is > to offer a place where non-standard extensions can be found. Am I missing > something? Yes, you're misunderstanding the purpose of IANA registries. ;) They are useful no matter whether the thing being registered is standard or non-standard. See RFC 5526. There are already plenty of IANA registries with separate registration rules for different string prefixes. And... guess what... vCard is one such registry. ;) We have e.g. vCard properties starting with "VND-" that are non-standard (first come first served), and everything else is "Expert Review and RFC Required". http://www.iana.org/assignments/vcard-elements/vcard-elements.xml Simon From superuser@gmail.com Wed Feb 27 13: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 4D49721F8503 for ; Wed, 27 Feb 2013 13:49:27 -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 U0OQ6HJZxmOe for ; Wed, 27 Feb 2013 13:49:26 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1E21F848B for ; Wed, 27 Feb 2013 13:49:25 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so904696wey.21 for ; Wed, 27 Feb 2013 13:49:25 -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=lgkwhNS7l+BrT0Xvs2BK8RXgGwuDfAezN0ZpAuSLgK4=; b=dIye6VZGgD7iMJBEKVQyL7B22KUM/nEy1UFP24y3UKBZaI7FG5eiRU2NleI81ClFq9 9grWXTJIe9REUhsGnnp71PKiUmaTnYnpcSD8QMfmsVbuzbxNh73m21b4px4Q+1a+7r5c Ja4Usj+BRsaehXF+gbmHSpvNQXxdb8G9u9UZ0oakuU6gU0hoZwd0WSt3ftGLfeKsfF97 G6sNi65W9Z1KXbcrGsKffmXSIvad+xwDNOdPb3KBBCegz8kg8ovUipDGr++AwWYZbcUL eU5Og+8iqIZ4xALr5b05361EYJ/tOEy/+MKUGiSTywCJTWXzHV8fkQDta/DSCIzLUpGJ t39Q== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr6872959wjc.35.1362001764955; Wed, 27 Feb 2013 13:49:24 -0800 (PST) Received: by 10.180.163.70 with HTTP; Wed, 27 Feb 2013 13:49:24 -0800 (PST) Date: Wed, 27 Feb 2013 13:49:24 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/mixed; boundary=089e013d1da86242b304d6bbbf39 Subject: [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: Wed, 27 Feb 2013 21:49:27 -0000 --089e013d1da86242b304d6bbbf39 Content-Type: multipart/alternative; boundary=089e013d1da86242af04d6bbbf37 --089e013d1da86242af04d6bbbf37 Content-Type: text/plain; charset=ISO-8859-1 Attached is the preliminary agenda for our session in Orlando. I've posted it to the meeting materials tool but it doesn't appear to have updated the agenda page with a link yet. A few of them are TBD in terms of presenters. Can we get some volunteers to lead those parts of the discussion? Suggestions for changes to the agenda are welcome, but keep in mind we only have an hour allocated. If there's something urgent that requires more time, we can ask our AD for help, but there are no guarantees. -MSK, WEIRDS co-chair --089e013d1da86242af04d6bbbf37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Attached is the preliminary agenda for our session in= Orlando.=A0 I've posted it to the meeting materials tool but it doesn&= #39;t appear to have updated the agenda page with a link yet.

A few = of them are TBD in terms of presenters.=A0 Can we get some volunteers to le= ad those parts of the discussion?

Suggestions for changes to the agenda are welcome, but keep = in mind we only have an hour allocated.=A0 If there's something urgent = that requires more time, we can ask our AD for help, but there are no guara= ntees.

-MSK, WEIRDS co-chair

--089e013d1da86242af04d6bbbf37-- --089e013d1da86242b304d6bbbf39 Content-Type: text/plain; charset=US-ASCII; name="agenda-weirds.txt" Content-Disposition: attachment; filename="agenda-weirds.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdp0mzi50 V2ViIEV4dGVuc2libGUgSW50ZXJuZXQgUmVnaXN0cmF0aW9uIERhdGEgU2VydmljZSAoV0VJUkRT KQpBZ2VuZGEgLS0gTWFyY2ggMTIsIDIwMTMgYXQgMTA6MzAgaW4gQm9jYSAxCgoxLiBBZG1pbmlz dHJpdmlhICg1IG1pbnM7IGNoYWlycykKMi4gSkNBUkQgKDUgbWluczsgVEJEKQogICAtIG5ldyBq Y2FyZCBXRwozLiBTZWFyY2ggKDE1IG1pbnM7IFRCRCkKICAgLSBhZG9wdCBkcmFmdC1ob2xsZW5i ZWNrLXdlaXJkcy1yZGFwLXNlYXJjaD8KNC4gSW50ZXJuYXRpb25hbGl6YXRpb24gKDIwIG1pbnM7 IFRCRCkKNS4gU2VjdXJpdHkgYW5kIEZlZGVyYXRlZCBBdXRoZW50aWNhdGlvbiAoMTAgbWluczsg TmluZyBLb25nKQo2LiBBbnkgb3RoZXIgYnVzaW5lc3MgKDUgbWluczsgVEJEKQo= --089e013d1da86242b304d6bbbf39-- From shollenbeck@verisign.com Wed Feb 27 13:59: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 A9B3021F8751 for ; Wed, 27 Feb 2013 13:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.327, 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 cAMa-yf2BPll for ; Wed, 27 Feb 2013 13:59:24 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA2121F87FF for ; Wed, 27 Feb 2013 13:59:22 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUS6Btdp9e7EbWp3F0X14Hf9NBxHXyr6n@postini.com; Wed, 27 Feb 2013 13:59:23 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 r1RLxEYJ024782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 16:59:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 27 Feb 2013 16:59:14 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Preliminary agenda Thread-Index: AQHOFTRSoBOwdNKvF0u/jxWJ5PfDo5iOQKWA Date: Wed, 27 Feb 2013 21:59:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243252ED@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_831693C2CDA2E849A7D7A712B24E257F243252EDBRN1WNEXMBX01vc_" MIME-Version: 1.0 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: Wed, 27 Feb 2013 21:59:24 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243252EDBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will volunteer for item #3 (search). Andy and/or I should probably take r= esponsibility for item #4. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Wednesday, February 27, 2013 4:49 PM To: weirds@ietf.org Subject: [weirds] Preliminary agenda Attached is the preliminary agenda for our session in Orlando. I've posted= it to the meeting materials tool but it doesn't appear to have updated the= agenda page with a link yet. A few of them are TBD in terms of presenters. Can we get some volunteers t= o lead those parts of the discussion? Suggestions for changes to the agenda are welcome, but keep in mind we only= have an hour allocated. If there's something urgent that requires more ti= me, we can ask our AD for help, but there are no guarantees. -MSK, WEIRDS co-chair --_000_831693C2CDA2E849A7D7A712B24E257F243252EDBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will volunteer for item= #3 (search). Andy and/or I should probably take responsibility for item #4= .

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, February 27, 2013 4:49 PM
To: weirds@ietf.org
Subject: [weirds] Preliminary agenda

 

Attached is the preli= minary agenda for our session in Orlando.  I've posted it to the meeti= ng materials tool but it doesn't appear to have updated the agenda page wit= h a link yet.

A few of them are TBD in terms of presenters.  Can we get some volunte= ers to lead those parts of the discussion?

Suggestions for changes to the agenda are welcome, b= ut keep in mind we only have an hour allocated.  If there's something = urgent that requires more time, we can ask our AD for help, but there are n= o guarantees.

 

-MSK, WEIRDS co-chair=

--_000_831693C2CDA2E849A7D7A712B24E257F243252EDBRN1WNEXMBX01vc_-- From steve.sheng@icann.org Wed Feb 27 14:04: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 E919021F8519 for ; Wed, 27 Feb 2013 14:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 WwsJmbhIQ7Yi for ; Wed, 27 Feb 2013 14:04:26 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 60BCD21F84FF for ; Wed, 27 Feb 2013 14:04:26 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 27 Feb 2013 14:04:25 -0800 From: Steve Sheng To: "Hollenbeck, Scott" , "Murray S. Kucherawy" , "weirds@ietf.org" Date: Wed, 27 Feb 2013 14:04:22 -0800 Thread-Topic: [weirds] Preliminary agenda Thread-Index: Ac4VNmdI2UVlrfTOSlSRVvP9Futlhg== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243252ED@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_3444818662_9187081" MIME-Version: 1.0 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: Wed, 27 Feb 2013 22:04:27 -0000 --B_3444818662_9187081 Content-type: multipart/alternative; boundary="B_3444818662_9160899" --B_3444818662_9160899 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit For #4 on internationalization, I volunteer to present ICANN's work in this area and potential implications for the protocol development. Kind regards, Steve From: , Scott Date: Wednesday, February 27, 2013 1:59 PM To: "Murray S. Kucherawy" , "weirds@ietf.org" Subject: Re: [weirds] Preliminary agenda > I will volunteer for item #3 (search). Andy and/or I should probably take > responsibility for item #4. > > Scott > > > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Wednesday, February 27, 2013 4:49 PM > To: weirds@ietf.org > Subject: [weirds] Preliminary agenda > > > Attached is the preliminary agenda for our session in Orlando. I've posted it > to the meeting materials tool but it doesn't appear to have updated the agenda > page with a link yet. > > A few of them are TBD in terms of presenters. Can we get some volunteers to > lead those parts of the discussion? > > Suggestions for changes to the agenda are welcome, but keep in mind we only > have an hour allocated. If there's something urgent that requires more time, > we can ask our AD for help, but there are no guarantees. > > > -MSK, WEIRDS co-chair --B_3444818662_9160899 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
For #4 on internationalizati= on, I volunteer to present ICANN's work in this area and potential implicati= ons for the protocol development. 

Kind regard= s, 
Steve

Fro= m: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Da= te: Wednesday, February 27, 2013 1:59 PM
To: "Murray S. Kucherawy" <superuser@gmail.com>, "weirds@= ietf.org" <weirds@ietf.org>Subject: Re: [weirds] Preliminary a= genda

<= style>

I will vol= unteer for item #3 (search). Andy and/or I should probably take responsibili= ty for item #4.

 

Scott

 

=

From: w= eirds-bounces@ietf.org [mailto:= weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, February= 27, 2013 4:49 PM
To: weirds@ietf= .org
Subject: [weirds] Preliminary agenda

 

Attached is the preliminary agenda fo= r our session in Orlando.  I've posted it to the meeting materials tool= but it doesn't appear to have updated the agenda page with a link yet.
<= br> A few of them are TBD in terms of presenters.  Can we get some volunte= ers to lead those parts of the discussion?

Suggestions for changes to the agenda are welcome, but keep in = mind we only have an hour allocated.  If there's something urgent that = requires more time, we can ask our AD for help, but there are no guarantees.=

 

-MSK, WEIRDS co-chair

 --B_3444818662_9160899-- --B_3444818662_9187081 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 BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFI4FaSxNHCjlH6dZtPdH2A8oFxI/MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIyNzIyMDQyMlowDQYJ KoZIhvcNAQEBBQAEggEAKQLs6EUXzqWCPiSO0KQBKhHOcj7jzJWAffYswanPrJCdVUhjjRsM j7ias1+yt9FzDXXBLIMzi8XHJSjabM9mC+dECqAJ96SAwwI1pFwNqSgf6FF7UF3jZ0XpqcQC Ia5zluJfWsJFrLFOt7RW7xsyl1M3BXPLadeJwBdpnBf2T3cTteKQBjsrHJA1Ywv8PDYC8L44 ym44WEQRqyZt1LMgjOVSrkCnHXkIjkR6qDRj+gvGLcnUgtr9uuDWdfTl5uaBeGHL+cgA080w zFKo/z5CMkDR+9SMp5dnddNtrkSIcKmyK5+g/bTDHCUlw8VLnQVUdhAnopxTaLwE1hOTvxrb pg== --B_3444818662_9187081-- From andy@arin.net Wed Feb 27 15:12: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 5A96221F88A0 for ; Wed, 27 Feb 2013 15:12:13 -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, HTML_MESSAGE=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 Giss8NkVKndq for ; Wed, 27 Feb 2013 15:12:13 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B3E7521F8896 for ; Wed, 27 Feb 2013 15:12:12 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 63C9821367C; Wed, 27 Feb 2013 18:12:12 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id C6C8D213633; Wed, 27 Feb 2013 18:12:11 -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, 27 Feb 2013 18:11:33 -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, 27 Feb 2013 18:12:11 -0500 From: Andy Newton To: "Hollenbeck, Scott" , "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Preliminary agenda Thread-Index: AQHOFTRfK0H8xxUjk0qSUGIui9nT25iOlMSAgACadwA= Date: Wed, 27 Feb 2013 23:12:10 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFD98@CHAXCH01.corp.arin.net> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243252ED@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBEFD98CHAXCH01corpari_" MIME-Version: 1.0 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: Wed, 27 Feb 2013 23:12:13 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBEFD98CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: , Scott Hollenbeck > Date: Wednesday, February 27, 2013 4:59 PM To: "Murray S. Kucherawy" >= , "weirds@ietf.org" > Subject: Re: [weirds] Preliminary agenda I will volunteer for item #3 (search). Andy and/or I should probably take r= esponsibility for item #4. I can do #4, or at least attempt it. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBEFD98CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <482976E69C1B8F41B5F7C03C32F85A86@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: <Hollenbeck>, Scott Hol= lenbeck <shollenbeck@verisig= n.com>
Date: Wednesday, February 27, 2013 = 4:59 PM
To: "Murray S. Kucherawy"= <superuser@gmail.com>, &q= uot;weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Preliminary a= genda

I will volunteer for item #3 (search). Andy and/or I shou= ld probably take responsibility for item #4.

I can do #4, or at least attempt it.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBEFD98CHAXCH01corpari_-- From zhoulinlin@cnnic.cn Wed Feb 27 18:49: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 B96A121F8A0C for ; Wed, 27 Feb 2013 18:49:10 -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=[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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6m2+tpr+YbT for ; Wed, 27 Feb 2013 18:49:10 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 8700321F89E2 for ; Wed, 27 Feb 2013 18:49:04 -0800 (PST) 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, 28 Feb 2013 10:48:57 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" , References: In-Reply-To: Date: Thu, 28 Feb 2013 10:48:56 +0800 Message-ID: <024501ce155e$27054910$750fdb30$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0246_01CE15A1.35288910" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4VNFNHdoZmnvpgQUWEOZOro97NBgAJybrQ Content-Language: zh-cn 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: Thu, 28 Feb 2013 02:49:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0246_01CE15A1.35288910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I suggest 5 min for item #4 to discuss the document draft-zhou-weirds-rdap-restful-search-00. I think there are some differences between the two search drafts we should notice. Regards, Linlin From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, February 28, 2013 5:49 AM To: weirds@ietf.org Subject: [weirds] Preliminary agenda Attached is the preliminary agenda for our session in Orlando. I've posted it to the meeting materials tool but it doesn't appear to have updated the agenda page with a link yet. A few of them are TBD in terms of presenters. Can we get some volunteers to lead those parts of the discussion? Suggestions for changes to the agenda are welcome, but keep in mind we only have an hour allocated. If there's something urgent that requires more time, we can ask our AD for help, but there are no guarantees. -MSK, WEIRDS co-chair ------=_NextPart_000_0246_01CE15A1.35288910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suggest = 5 min for item #4 to discuss the document = draft-zhou-weirds-rdap-restful-search-00. I think there are some = differences between the two search drafts we should = notice.

 =

Regards,

Linlin=

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Thursday, February 28, 2013 5:49 = AM
To: weirds@ietf.org
Subject: [weirds] Preliminary = agenda

 

Attached is the = preliminary agenda for our session in Orlando.  I've posted it to = the meeting materials tool but it doesn't appear to have updated the = agenda page with a link yet.

A few of them are TBD in terms of = presenters.  Can we get some volunteers to lead those parts of the = discussion?

Suggestions for changes to the agenda are welcome, but keep = in mind we only have an hour allocated.  If there's something = urgent that requires more time, we can ask our AD for help, but there = are no guarantees.

 

-MSK, WEIRDS = co-chair

------=_NextPart_000_0246_01CE15A1.35288910-- From johnl@iecc.com Wed Feb 27 18:57: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 4C5A821F86D3 for ; Wed, 27 Feb 2013 18:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.065 X-Spam-Level: X-Spam-Status: No, score=-111.065 tagged_above=-999 required=5 tests=[AWL=0.134, 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 2n+E75E0tUwS for ; Wed, 27 Feb 2013 18:57:30 -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 543AA21F88A0 for ; Wed, 27 Feb 2013 18:57:22 -0800 (PST) Received: (qmail 20987 invoked from network); 28 Feb 2013 02:57:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Feb 2013 02:57:22 -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=512ec792.xn--i8sz2z.k1302; i=johnl@user.iecc.com; bh=tnrUZdN2j1LTBeMHgTCFvjnPsDW3DuzRVISfXtO5sAA=; b=GyeNzyGauecgfZMzQ3o5BrA91MQlhfoUCiMSB0hyxxluRt0Icwqp5nfvu3w9ER9cSPKtzn3Kz44DkqgFxflpeINYZrd7JHv7S0MCH/ZZSUpWp3mppFXHXtIToJfceHF9LdYRWi+gDh2DczSQOqKPxyBDwgtzzlAC69lbje2ZpuQ= 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=512ec792.xn--i8sz2z.k1302; olt=johnl@user.iecc.com; bh=tnrUZdN2j1LTBeMHgTCFvjnPsDW3DuzRVISfXtO5sAA=; b=j0Kepfa7v5CWRKOrt4vB/KyBfsltUiJNIqbx3tpf+2m736L8C/CFI5GnJUButB5KVCl4ihvUFbJXof/J5HnOMpa6+ysQ4Glooi/8RnPEMytaAPHSpWh7BZUCz+ADhzce+Vzni84fHHYFRVpI9++/pFocqOO+5155ud8qn+47N1Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Feb 2013 02:57:00 -0000 Message-ID: <20130228025700.33171.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: Thu, 28 Feb 2013 02:57:31 -0000 >For #4 on internationalization, I volunteer to present ICANN's work in this >area and potential implications for the protocol development. Not to intrude on the chairs' prerogatives or anything, but this really does not sound like something that is appropriate for a WG meeting session. Only a fraction of the people active on the list are likely to be there, and WG meeting time is for working out issues, not for watching pitches. 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. R's, John From shollenbeck@verisign.com Wed Feb 27 19:14: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 0CC1E21F8A42 for ; Wed, 27 Feb 2013 19:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVLBSqL-feCL for ; Wed, 27 Feb 2013 19:14:08 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAD21F8A45 for ; Wed, 27 Feb 2013 19:13:28 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUS7LWKHdbj7vacZkzIEDWTtihMAre80w@postini.com; Wed, 27 Feb 2013 19:14:08 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 r1S3DPST022614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 22:13:25 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 27 Feb 2013 22:13:25 -0500 From: "Hollenbeck, Scott" To: Linlin Zhou , "'Murray S. Kucherawy'" , "weirds@ietf.org" Thread-Topic: [weirds] Preliminary agenda Thread-Index: AQHOFTRSoBOwdNKvF0u/jxWJ5PfDo5iO5bYA//+yx9A= Date: Thu, 28 Feb 2013 03:13:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243255A8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <024501ce155e$27054910$750fdb30$@cn> In-Reply-To: <024501ce155e$27054910$750fdb30$@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: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F243255A8BRN1WNEXMBX01vc_" MIME-Version: 1.0 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: Thu, 28 Feb 2013 03:14:10 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243255A8BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's more appropriately included as part of #3, and yes, I was planning to = include it if I have the opportunity to lead the discussion. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Linlin Zhou Sent: Wednesday, February 27, 2013 9:49 PM To: 'Murray S. Kucherawy'; weirds@ietf.org Subject: Re: [weirds] Preliminary agenda I suggest 5 min for item #4 to discuss the document draft-zhou-weirds-rdap-= restful-search-00. I think there are some differences between the two searc= h drafts we should notice. Regards, Linlin From: weirds-bounces@ietf.org [mailto:weird= s-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, February 28, 2013 5:49 AM To: weirds@ietf.org Subject: [weirds] Preliminary agenda Attached is the preliminary agenda for our session in Orlando. I've posted= it to the meeting materials tool but it doesn't appear to have updated the= agenda page with a link yet. A few of them are TBD in terms of presenters. Can we get some volunteers t= o lead those parts of the discussion? Suggestions for changes to the agenda are welcome, but keep in mind we only= have an hour allocated. If there's something urgent that requires more ti= me, we can ask our AD for help, but there are no guarantees. -MSK, WEIRDS co-chair --_000_831693C2CDA2E849A7D7A712B24E257F243255A8BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s more appropria= tely included as part of #3, and yes, I was planning to include it if I hav= e the opportunity to lead the discussion.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Linlin Zhou
Sent: Wednesday, February 27, 2013 9:49 PM
To: 'Murray S. Kucherawy'; weirds@ietf.org
Subject: Re: [weirds] Preliminary agenda

 

I suggest 5 min for item #4 to discuss = the document draft-zhou-weirds-rdap-restful-search-00. I think there are so= me differences between the two search drafts we should notice.

 

Regards,

Linlin

 

From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, February 28, 2013 5:49 AM
To: weirds@ietf.org
Subject: [weirds] Preliminary agenda

 

Attached is the preli= minary agenda for our session in Orlando.  I've posted it to the meeti= ng materials tool but it doesn't appear to have updated the agenda page wit= h a link yet.

A few of them are TBD in terms of presenters.  Can we get some volunte= ers to lead those parts of the discussion?

Suggestions for changes to the agenda are welcome, b= ut keep in mind we only have an hour allocated.  If there's something = urgent that requires more time, we can ask our AD for help, but there are n= o guarantees.

 

-MSK, WEIRDS co-chair=

--_000_831693C2CDA2E849A7D7A712B24E257F243255A8BRN1WNEXMBX01vc_-- From aservin@lacnic.net Wed Feb 27 19:14: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 1A94F21F8A45 for ; Wed, 27 Feb 2013 19:14: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUS3vC42uunH for ; Wed, 27 Feb 2013 19:14:27 -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 417C821F8A42 for ; Wed, 27 Feb 2013 19:14:27 -0800 (PST) Received: from MiniR2D2.local (unknown [IPv6:2001:df9:0:4022:7d74:eee0:89ce:e4a8]) by mail.lacnic.net.uy (Postfix) with ESMTP id 4907630843E for ; Thu, 28 Feb 2013 01:14:09 -0200 (UYST) Message-ID: <512ECB84.4030002@lacnic.net> Date: Thu, 28 Feb 2013 11:14:12 +0800 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] 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: Thu, 28 Feb 2013 03:14:28 -0000 What about redirects? Regards, as On 28/02/2013 05:49, Murray S. Kucherawy wrote: > Attached is the preliminary agenda for our session in Orlando. I've > posted it to the meeting materials tool but it doesn't appear to have > updated the agenda page with a link yet. > > A few of them are TBD in terms of presenters. Can we get some > volunteers to lead those parts of the discussion? > > Suggestions for changes to the agenda are welcome, but keep in mind we > only have an hour allocated. If there's something urgent that requires > more time, we can ask our AD for help, but there are no guarantees. > > -MSK, WEIRDS co-chair > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Feb 27 19:15: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 139B121F8984 for ; Wed, 27 Feb 2013 19:15:13 -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 nMZSVVk6dOBn for ; Wed, 27 Feb 2013 19:15:12 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2021F897F for ; Wed, 27 Feb 2013 19:15:12 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id E4DC1165446; Wed, 27 Feb 2013 22:15:11 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 628C2165409; Wed, 27 Feb 2013 22:15:11 -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, 27 Feb 2013 22:14: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, 27 Feb 2013 22:14:58 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Preliminary agenda Thread-Index: AQHOFTRfK0H8xxUjk0qSUGIui9nT25iOlMSAgAABcACAAFHDAIAAix2A Date: Thu, 28 Feb 2013 03:14:57 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> In-Reply-To: <20130228025700.33171.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: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DC25CF2857C7C47B028B2E2402BE313@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 28 Feb 2013 03:15:13 -0000 On 2/28/13 10:57 AM, "John Levine" wrote: >>For #4 on internationalization, I volunteer to present ICANN's work in >>this >>area and potential implications for the protocol development. > >Not to intrude on the chairs' prerogatives or anything, but this >really does not sound like something that is appropriate for a WG >meeting session. Only a fraction of the people active on the list are >likely to be there, and WG meeting time is for working out issues, not >for watching pitches. > >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 do agree that having a written document for reference would also be helpful. -andy From zhoulinlin@cnnic.cn Wed Feb 27 19:19: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 E204421F8A64 for ; Wed, 27 Feb 2013 19:19:37 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, 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 l-oZWtWfb+Me for ; Wed, 27 Feb 2013 19:19:37 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id D283B21F8A5F for ; Wed, 27 Feb 2013 19:19:35 -0800 (PST) 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, 28 Feb 2013 11:19:28 +0800 From: "Linlin Zhou" To: "'Linlin Zhou'" , "'Murray S. Kucherawy'" , References: <024501ce155e$27054910$750fdb30$@cn> In-Reply-To: <024501ce155e$27054910$750fdb30$@cn> Date: Thu, 28 Feb 2013 11:19:28 +0800 Message-ID: <025301ce1562$6ae00e50$40a02af0$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0254_01CE15A5.79034E50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4VNFNHdoZmnvpgQUWEOZOro97NBgAJybrQAAG5N8A= Content-Language: zh-cn 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: Thu, 28 Feb 2013 03:19:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0254_01CE15A5.79034E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry, it is item #3. From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Linlin Zhou Sent: Thursday, February 28, 2013 10:49 AM To: 'Murray S. Kucherawy'; weirds@ietf.org Subject: Re: [weirds] Preliminary agenda I suggest 5 min for item #4 to discuss the document draft-zhou-weirds-rdap-restful-search-00. I think there are some differences between the two search drafts we should notice. Regards, Linlin From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, February 28, 2013 5:49 AM To: weirds@ietf.org Subject: [weirds] Preliminary agenda Attached is the preliminary agenda for our session in Orlando. I've posted it to the meeting materials tool but it doesn't appear to have updated the agenda page with a link yet. A few of them are TBD in terms of presenters. Can we get some volunteers to lead those parts of the discussion? Suggestions for changes to the agenda are welcome, but keep in mind we only have an hour allocated. If there's something urgent that requires more time, we can ask our AD for help, but there are no guarantees. -MSK, WEIRDS co-chair ------=_NextPart_000_0254_01CE15A5.79034E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, it = is item #3.

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Linlin Zhou
Sent: Thursday, February 28, 2013 10:49 = AM
To: 'Murray S. Kucherawy'; = weirds@ietf.org
Subject: Re: [weirds] Preliminary = agenda

 

I suggest = 5 min for item #4 to discuss the document = draft-zhou-weirds-rdap-restful-search-00. I think there are some = differences between the two search drafts we should = notice.

 =

Regards,

Linlin=

 =

 

Attached is the = preliminary agenda for our session in Orlando.  I've posted it to = the meeting materials tool but it doesn't appear to have updated the = agenda page with a link yet.

A few of them are TBD in terms of = presenters.  Can we get some volunteers to lead those parts of the = discussion?

Suggestions for changes to the agenda are welcome, but keep = in mind we only have an hour allocated.  If there's something = urgent that requires more time, we can ask our AD for help, but there = are no guarantees.

 

-MSK, WEIRDS = co-chair

------=_NextPart_000_0254_01CE15A5.79034E50-- From ed.lewis@neustar.biz Wed Feb 27 19:23: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 BD74021F8A6B for ; Wed, 27 Feb 2013 19:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.841 X-Spam-Level: X-Spam-Status: No, score=-101.841 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tT6Jh1E77FKK for ; Wed, 27 Feb 2013 19:23:33 -0800 (PST) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id BC82B21F8A64 for ; Wed, 27 Feb 2013 19:23:24 -0800 (PST) Received: from eastrmimpo305 ([68.230.241.237]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130228032324.RHGB23841.eastrmfepo103.cox.net@eastrmimpo305> for ; Wed, 27 Feb 2013 22:23:24 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo305 with cox id 5fPM1l00q3cuADQ01fPNpC; Wed, 27 Feb 2013 22:23:24 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.512ECDAC.0018,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=IelZrxWa c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=C_KFqnMj-7oA:10 a=hGBaWAWWAAAA:8 a=ZoOIZJZALqYA:10 a=2zj1MnH_AAAA:8 a=iTfQMBlZIDBPs3Jvhl8A:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=EFlsPNwo0xgA:10 a=I-_wS540UDb2Sqo0mjcA:9 a=_W_S_7VecoQA:10 a=T7AkLQsOoKpRUre-:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7332BE28-F148-4A4A-A352-1DB2857D69FF" From: Edward Lewis In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> Date: Thu, 28 Feb 2013 11:23:24 +0800 Message-Id: <1CCE8CEF-FABC-43E6-99C0-C8B3964F6C00@neustar.biz> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis 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: Thu, 28 Feb 2013 03:23:33 -0000 --Apple-Mail=_7332BE28-F148-4A4A-A352-1DB2857D69FF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Feb 28, 2013, at 11:14, Andy Newton wrote: > Actually, I'd like to hear it. Me too, aka +1, etc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_7332BE28-F148-4A4A-A352-1DB2857D69FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Actually, I'd = like to hear it.

Me too, aka +1, = etc.

Edward = Lewis             
NeuStar       = ;          =    You can leave a voice message at = +1-571-434-5468

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_7332BE28-F148-4A4A-A352-1DB2857D69FF-- From ajs@anvilwalrusden.com Wed Feb 27 20:39: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 4CD3421F85A1 for ; Wed, 27 Feb 2013 20:39:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9rp-Wbl-8eZ for ; Wed, 27 Feb 2013 20:39:55 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E308A21F858A for ; Wed, 27 Feb 2013 20:39:54 -0800 (PST) Received: from mx1.yitter.info (dhcp107-16-78-99.hil-boslhhh.bos.wayport.net [107.16.78.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6957C8A036 for ; Thu, 28 Feb 2013 04:39:54 +0000 (UTC) Date: Wed, 27 Feb 2013 23:39:54 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130228043953.GH9197@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 28 Feb 2013 04:39:55 -0000 On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: > Attached is the preliminary agenda for our session in Orlando. I'm slightly surprised that we're not doing any interop demo. Some while ago, I suggested that Dyn would be ready to show off an implementation, and suggested a bake-off. People said at the time that such work should be in the WG session and not on the side. Has my wandering attention failed to notice a change in the views of others? (It wouldn't surprise me.) A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@taugh.com Wed Feb 27 20: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 0A5DB21F8B16 for ; Wed, 27 Feb 2013 20:52: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxHLWtndZmht for ; Wed, 27 Feb 2013 20:52:23 -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 1028721F8B0B for ; Wed, 27 Feb 2013 20:52:22 -0800 (PST) Received: (qmail 52172 invoked from network); 28 Feb 2013 04:52:22 -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=cbcb.512ee286.k1302; bh=aJNQq7cGPLZ+PXw0/S6J/hT7ENyUWqaUXFiVVT4qU2Y=; b=dk5vQY0zvgqbVWayHroEuoTge8HnUigbm9p76FozOuKUncJ5rels9oagNPeILSIO1QVwSthEK2FDwIGP14UKsusv+xzGanB1v6SjtPiBitZdm+z7tfyWiTRaoPxiHc1uS3A29FG030SQGwRZPMtejJmTDbx/zZfntEBt8u96Fck= 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=cbcb.512ee286.k1302; bh=aJNQq7cGPLZ+PXw0/S6J/hT7ENyUWqaUXFiVVT4qU2Y=; b=YNeQX2knQOjeOGcKDhkPbdXNqDOdNbQwv+QEa5DZg0WIf1yZtVIrbRPhm3i40qClxcC1LattS+9ncmMZmb0U5y5eQ7A5tkQNxAoRVU82tmmcXULhxcLXM5JbmCvBmSuH3eFvlUQFIZcbPsf/d2Fan9IjFsBa07VNeiG4tXC6sZg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 28 Feb 2013 04:52:00 -0000 Date: 27 Feb 2013 23:52:21 -0500 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@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] 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: Thu, 28 Feb 2013 04:52:24 -0000 >> 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 From superuser@gmail.com Wed Feb 27 21:08: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 A471D21F8B3B for ; Wed, 27 Feb 2013 21:08:00 -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 rGz9smrbD99E for ; Wed, 27 Feb 2013 21:08:00 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D2BAB21F8B3A for ; Wed, 27 Feb 2013 21:07:59 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so1144748wer.11 for ; Wed, 27 Feb 2013 21:07:58 -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=LmaJ6oJCnvw6vTt3/hAJwjis2YApi3J5ot8XBOiocJs=; b=eKYToT3wGWAjaSTnW3AoTgEtER78STtzV+cibo5qXOCpyU8otMWmb3s1dPiTW/YVlY rbrks13iCVGs38R4hbWrU4O08ihNgmXZJ0CnYrZ5WeEuDQgh6N2ZaOTTOqHsR6rC8kbF JnVDwmM7SNcmbOpIZxJF/69K1AmAkmGgNjU56/TpxS9vGwwLQe0Cxh/zja0wbS0jBhF2 ZSrHEFzMcBIRPDz/sWpsz/TPhwKZJJEPeYN2SVhIzQ0sf4EFEbkhk/4ynawU/J/qLTPL sfBVQ8sBpfKj+yGT87feQKpBNNU/RZaZ/pAQTH9T5tflc76xg0GQUKiXluzXdRrghmHz rg9w== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr8250334wjq.51.1362028078701; Wed, 27 Feb 2013 21:07:58 -0800 (PST) Received: by 10.180.163.70 with HTTP; Wed, 27 Feb 2013 21:07:58 -0800 (PST) In-Reply-To: <20130228043953.GH9197@mx1.yitter.info> References: <20130228043953.GH9197@mx1.yitter.info> Date: Wed, 27 Feb 2013 21:07:58 -0800 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b86cea4ce263204d6c1df9e 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: Thu, 28 Feb 2013 05:08:00 -0000 --047d7b86cea4ce263204d6c1df9e Content-Type: text/plain; charset=ISO-8859-1 As I recall there was AD resistance to the idea of doing this in a scheduled working group session. (Pete, feel free to correct me if I misinterpreted your remarks.) That said, there was also agreement that a bake-off is a fine thing to do since we do like demonstrations of interoperability, so there was support for arranging some "lab" time outside of the meeting if we're so moved. Should we make such a request? If so, can we get some idea of how many would attend and how many participants there would be? -MSK On Wed, Feb 27, 2013 at 8:39 PM, Andrew Sullivan wrote: > On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: > > Attached is the preliminary agenda for our session in Orlando. > > I'm slightly surprised that we're not doing any interop demo. Some > while ago, I suggested that Dyn would be ready to show off an > implementation, and suggested a bake-off. People said at the time > that such work should be in the WG session and not on the side. Has > my wandering attention failed to notice a change in the views of > others? (It wouldn't surprise me.) > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b86cea4ce263204d6c1df9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I recall there was AD resistance to the idea of do= ing this in a scheduled working group session.=A0 (Pete, feel free to corre= ct me if I misinterpreted your remarks.)=A0 That said, there was also agree= ment that a bake-off is a fine thing to do since we do like demonstrations = of interoperability, so there was support for arranging some "lab"= ; time outside of the meeting if we're so moved.

Should we make such a request?=A0 If so, can we get some idea of = how many would attend and how many participants there would be?

-MSK=


On = Wed, Feb 27, 2013 at 8:39 PM, Andrew Sullivan <ajs@anvilwalrusden.com= > wrote:
On Wed, Feb 27, 2013 at 01= :49:24PM -0800, Murray S. Kucherawy wrote:
> Attached is the preliminary agenda for our session in Orlando.

I'm slightly surprised that we're not doing any interop demo.= =A0Some
while ago, I suggested that Dyn would be ready to show off an
implementation, and suggested a bake-off. =A0People said at the time
that such work should be in the WG session and not on the side. =A0Has
my wandering attention failed to notice a change in the views of
others? =A0(It wouldn't surprise me.)

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--047d7b86cea4ce263204d6c1df9e-- From aservin@lacnic.net Wed Feb 27 22:12: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 77F0B21F8B49 for ; Wed, 27 Feb 2013 22:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_220=2.118] 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 aprZqvQXXnBZ for ; Wed, 27 Feb 2013 22:12:57 -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 D275021F8B47 for ; Wed, 27 Feb 2013 22:12:56 -0800 (PST) Received: from MiniR2D2.local (unknown [220.247.156.154]) by mail.lacnic.net.uy (Postfix) with ESMTP id D254D308427 for ; Thu, 28 Feb 2013 04:12:35 -0200 (UYST) Message-ID: <512EF555.4050507@lacnic.net> Date: Thu, 28 Feb 2013 14:12:37 +0800 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: <20130228043953.GH9197@mx1.yitter.info> 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] 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: Thu, 28 Feb 2013 06:12:57 -0000 I do not mind doing in or outside the wg but I would prefer just set up a date and do some testing in the term room. But anyhow, if somebody has some client libraries to try, our weirds server should be complaint with the latest drafts and we would like to try interoperability. Regards, as On 28/02/2013 13:07, Murray S. Kucherawy wrote: > As I recall there was AD resistance to the idea of doing this in a > scheduled working group session. (Pete, feel free to correct me if I > misinterpreted your remarks.) That said, there was also agreement that > a bake-off is a fine thing to do since we do like demonstrations of > interoperability, so there was support for arranging some "lab" time > outside of the meeting if we're so moved. > > Should we make such a request? If so, can we get some idea of how many > would attend and how many participants there would be? > > -MSK > > > On Wed, Feb 27, 2013 at 8:39 PM, Andrew Sullivan > wrote: > > On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: > > Attached is the preliminary agenda for our session in Orlando. > > I'm slightly surprised that we're not doing any interop demo. Some > while ago, I suggested that Dyn would be ready to show off an > implementation, and suggested a bake-off. People said at the time > that such work should be in the WG session and not on the side. Has > my wandering attention failed to notice a change in the views of > others? (It wouldn't surprise me.) > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 sm@resistor.net Wed Feb 27 22:31: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 885E121F8AF2 for ; Wed, 27 Feb 2013 22:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 nqmMZsOkgTst for ; Wed, 27 Feb 2013 22:31:50 -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 837E221F8AC3 for ; Wed, 27 Feb 2013 22:31:50 -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 r1S6Virj004315; Wed, 27 Feb 2013 22:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362033109; bh=hU02Kf6xKPq2/jhQW9UBzN9uX19yVwWeZ9zUJU10xFk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xlk0I8M0Xaqd6fdYUNqQ+ZA4Rg4Zp1mIUNU6waww3Qv7OlU2Modxma4kpgBoderHj PJjYTrs094YwLYlCJj43pbYmjURzg0JZWJBvi7fTpgElijL4c6/g37UwnRJG3Qx8zM GtFqlQbWLcSOT/FNPUn1ZzrfPaRFlPOgPOd69av0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362033109; i=@resistor.net; bh=hU02Kf6xKPq2/jhQW9UBzN9uX19yVwWeZ9zUJU10xFk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aWXQx3/W+awK3+bhySmVy4cvqwkIGjuVAJY/A9Sh3o16ixJ4UZrBJsNqOa20DcfXZ LQouZ/IcICaLh7I/m7keuvZev5s6xb4+QrQUa3CmiNSl82aCO5haXbDPlrxQOrFRfX Z5SYbIQID22aZRtsDHYI1GVB8dZyeqE3M2l5AySo= Message-Id: <6.2.5.6.2.20130227222207.0a3f1360@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Feb 2013 22:31:48 -0800 To: "John Levine" From: SM In-Reply-To: <20130228025700.33171.qmail@joyce.lan> References: <20130228025700.33171.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Thu, 28 Feb 2013 06:31:52 -0000 At 18:57 27-02-2013, John Levine wrote: >Not to intrude on the chairs' prerogatives or anything, but this >really does not sound like something that is appropriate for a WG >meeting session. Only a fraction of the people active on the list are >likely to be there, and WG meeting time is for working out issues, not >for watching pitches. Yes. There is a message about the meeting at http://www.ietf.org/mail-archive/web/weirds/current/msg02047.html Regards, -sm From aservin@lacnic.net Wed Feb 27 22:59: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 9F70D21F8B88 for ; Wed, 27 Feb 2013 22:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, RELAY_IS_220=2.118] 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 DptyQjoDwFXj for ; Wed, 27 Feb 2013 22:59:01 -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 A8D3121F8B85 for ; Wed, 27 Feb 2013 22:58:58 -0800 (PST) Received: from MiniR2D2.local (unknown [220.247.156.154]) by mail.lacnic.net.uy (Postfix) with ESMTP id 42964308437; Thu, 28 Feb 2013 04:58:45 -0200 (UYST) Message-ID: <512F0024.7080507@lacnic.net> Date: Thu, 28 Feb 2013 14:58:44 +0800 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: John Levine References: <20130225201158.26041.qmail@joyce.lan> In-Reply-To: <20130225201158.26041.qmail@joyce.lan> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 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] 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: Thu, 28 Feb 2013 06:59:03 -0000 No and yes. It has not been a problem but some people commented that it would be good to inspect some mechanisms to protect weirds servers against bad programed clients. We are happy to follow the WG desires, we could forget about any mechanism, we could look for another one, etc. Regards, as On 26/02/2013 04:11, John Levine wrote: >> 2) Doing statefull http redirection to avoid loops (considering that >> the user agent may be bad implemented and incapable of break a loop) > > Has this been a problem in practice? HTTP has had redirects for 20 > years. I'd think that redirect loops would be a solved problem at > that level. > From peter@denic.de Wed Feb 27 23:33: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 5660C21F8B33 for ; Wed, 27 Feb 2013 23:33:18 -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 EBitKTbFNzwx for ; Wed, 27 Feb 2013 23:33:17 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id B172721F8B2F for ; Wed, 27 Feb 2013 23:33:17 -0800 (PST) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1UAxzQ-0004UR-Ih; Thu, 28 Feb 2013 08:33:16 +0100 Received: from localhost by x27.adm.denic.de with local id 1UAxzQ-0004ei-F4; Thu, 28 Feb 2013 08:33:16 +0100 Date: Thu, 28 Feb 2013 08:33:16 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20130228073316.GA15921@x28.adm.denic.de> References: <20130228025700.33171.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130228025700.33171.qmail@joyce.lan> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch 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: Thu, 28 Feb 2013 07:33:18 -0000 On Thu, Feb 28, 2013 at 02:57:00AM +0000, John Levine wrote: > really does not sound like something that is appropriate for a WG > meeting session. Only a fraction of the people active on the list are > likely to be there, and WG meeting time is for working out issues, not > for watching pitches. > > 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. I agree with John, just am too shy to use the same words. Steve may want to try IEPG instead (only a suggestion, I am not involved in agenda building). -Peter From james.mitchell@ausregistry.com.au Thu Feb 28 03:17: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 EE06F21F8ADC for ; Thu, 28 Feb 2013 03:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=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 4VvGVMjYeL2I for ; Thu, 28 Feb 2013 03:17:25 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98721F8AC3 for ; Thu, 28 Feb 2013 03:17:24 -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; 28 Feb 2013 22:17:22 +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, 28 Feb 2013 22:17:17 +1100 From: James Mitchell To: "weirds@ietf.org" Date: Thu, 28 Feb 2013 22:17:19 +1100 Thread-Topic: Entity "Objects" Thread-Index: Ac4VpSpYsI/bTeI7RJeUXSF9/NAbNQ== 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.0.121105 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD3C8A564DF47jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [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: Thu, 28 Feb 2013 11:17:26 -0000 --_000_CD3C8A564DF47jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_CD3C8A564DF47jamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

I am concerned regarding the use of the entity object as described in= the rdap query draft. It appears to me as though two separate objects, con= tacts and registrars, have been pulled together because they share data.&nb= sp;This is problematic for me because
 - Contact objects and= Registrar objects do not share the same identifier space.
 = - Contact objects and Registrar objects share very little data; one may thi= nk of registrar objects as being composed of contact-like (not contact obje= ct) data, perhaps even several contact-like objects (registrar-contact obje= cts do not share the same identifier space as domain-contact objects)
=

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

Thanks,
James
= --_000_CD3C8A564DF47jamesmitchellausregistrycomau_-- From shollenbeck@verisign.com Thu Feb 28 05:17: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 9E6F921F849A for ; Thu, 28 Feb 2013 05:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 nM-cMz8rUgaf for ; Thu, 28 Feb 2013 05:17:46 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 1870821F842B for ; Thu, 28 Feb 2013 05:17:41 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUS9Y9eda207xOVHwwBqR5sFhu44QNhjl@postini.com; Thu, 28 Feb 2013 05:17:45 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 r1SDHbIK024134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 08:17:38 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 28 Feb 2013 08:17:37 -0500 From: "Hollenbeck, Scott" To: "james.mitchell@ausregistry.com.au" , "weirds@ietf.org" Thread-Topic: Entity "Objects" Thread-Index: Ac4VpSpYsI/bTeI7RJeUXSF9/NAbNQAECmOA Date: Thu, 28 Feb 2013 13:17:36 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24325839@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_831693C2CDA2E849A7D7A712B24E257F24325839BRN1WNEXMBX01vc_" 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: Thu, 28 Feb 2013 13:17:46 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24325839BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_831693C2CDA2E849A7D7A712B24E257F24325839BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@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 same identifier space.

 - 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_831693C2CDA2E849A7D7A712B24E257F24325839BRN1WNEXMBX01vc_-- From carlosm3011@gmail.com Thu Feb 28 06:04: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 30A6021F8814 for ; Thu, 28 Feb 2013 06:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-1.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, 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 v81Jxh5Dawze for ; Thu, 28 Feb 2013 06:04:00 -0800 (PST) Received: from mail-gg0-x236.google.com (mail-gg0-x236.google.com [IPv6:2607:f8b0:4002:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1C21F86A5 for ; Thu, 28 Feb 2013 06:04:00 -0800 (PST) Received: by mail-gg0-f182.google.com with SMTP id d1so259314ggn.27 for ; Thu, 28 Feb 2013 06:04:00 -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=/7SF1zC6xqFiZ4b2MGNlDTdSBjhHtXbUaTHamotPgiA=; b=spJjMlZ9zLwgVEEDYOkCSV6TZuVlYMsWfM5eHjxaWgp9NDmfAny4uZJ1HpubdsawAr 3IEVj04YW5WkDD4GngRjmIORKdiZfStkPTT9G2wxlsKE8ctm3iJV3MhiRRjk31Ovkxo2 izds4YpeOOA+DqePC6IpwpuUeH4XnAbbsT34BJiBtidVtqRSo5RjCDdGdBCWY5vyiOwN FzGcV3fkCtrJnTz+f7NZ/Bh5IXv92rthsdr02pHFjdH5Jkc6qcmO+w5q/CXB6ZE9cJJV DnEOZX8mxddY/ObEcBrS6i2Y7PSHDizpsH04X6pbFCXEM6ALkDHkmmr9ANwT1T/DrKSs iZiA== X-Received: by 10.236.77.230 with SMTP id d66mr4618730yhe.182.1362060240095; Thu, 28 Feb 2013 06:04:00 -0800 (PST) Received: from [200.7.85.156] ([200.7.85.156]) by mx.google.com with ESMTPS id u2sm13366448yhl.8.2013.02.28.06.03.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 06:03:59 -0800 (PST) Message-ID: <512F63CB.6020101@gmail.com> Date: Thu, 28 Feb 2013 12:03:55 -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: Arturo Servin References: <20130228043953.GH9197@mx1.yitter.info> <512EF555.4050507@lacnic.net> In-Reply-To: <512EF555.4050507@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] Preliminary agenda 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, 28 Feb 2013 14:04:01 -0000 I like the idea of an interop demo, but also believe that it should be scheduled outside the 'normal' (for lack of a better word) WG slot. I support asking for room space and support setting a date today. Let us know, ~Carlos (already setting up some VMs :D ) On 2/28/13 4:12 AM, Arturo Servin wrote: > > I do not mind doing in or outside the wg but I would prefer just set up > a date and do some testing in the term room. > > But anyhow, if somebody has some client libraries to try, our weirds > server should be complaint with the latest drafts and we would like to > try interoperability. > > Regards, > as > > On 28/02/2013 13:07, Murray S. Kucherawy wrote: >> As I recall there was AD resistance to the idea of doing this in a >> scheduled working group session. (Pete, feel free to correct me if I >> misinterpreted your remarks.) That said, there was also agreement that >> a bake-off is a fine thing to do since we do like demonstrations of >> interoperability, so there was support for arranging some "lab" time >> outside of the meeting if we're so moved. >> >> Should we make such a request? If so, can we get some idea of how many >> would attend and how many participants there would be? >> >> -MSK >> >> >> On Wed, Feb 27, 2013 at 8:39 PM, Andrew Sullivan > > wrote: >> >> On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: >> > Attached is the preliminary agenda for our session in Orlando. >> >> I'm slightly surprised that we're not doing any interop demo. Some >> while ago, I suggested that Dyn would be ready to show off an >> implementation, and suggested a bake-off. People said at the time >> that such work should be in the WG session and not on the side. Has >> my wandering attention failed to notice a change in the views of >> others? (It wouldn't surprise me.) >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> 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 jyee@afilias.info Thu Feb 28 06:18: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 18D8A21F88EE for ; Thu, 28 Feb 2013 06:18:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWbbRgSGu5zq for ; Thu, 28 Feb 2013 06:18:16 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 827D721F88EA for ; Thu, 28 Feb 2013 06:18:16 -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 1UB4JL-0005TK-5A for weirds@ietf.org; Thu, 28 Feb 2013 14:18:15 +0000 Received: from mail-wg0-f70.google.com ([74.125.82.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UB4JL-0004L4-4f for weirds@ietf.org; Thu, 28 Feb 2013 14:18:15 +0000 Received: by mail-wg0-f70.google.com with SMTP id dr1so2136435wgb.9 for ; Thu, 28 Feb 2013 06:18:09 -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=VmTn1OJY21/XNoFc/wt6oEWbbk5D1ewyk6mEkFH92B0=; b=OitArEe2TWES+A8Kwkg8VpHOaa8jf1A77Y2BbLgMWv2nSnEP7sgL+qmNK/GqKZKvL0 6+OKJ2RU2veQB3YnjvNdniJw7ibsoanJGj6pGWxdz3L5eCL2ebeEzMAEDya1nA2+aD8i YFoeYLDJcEi/lMqa437c6S3fxESJWHyT5MrsLryBvVn+ot4EW1nkUONl7HTzrj7MRc+Z 385f/ZxmMNGVz25jrFyHosmqyJr0xNlObdbLiHsOjbAklrnOWx2BQotwWfQIyQj7dGvf m5/9GZ+m4m3b+ZQQD1+zDUvwn/6pl6eoMmkE/+NARE3WzcqEVf3V6mIBLXEM9wDG0M56 yGmw== X-Received: by 10.194.88.138 with SMTP id bg10mr11346082wjb.13.1362061089481; Thu, 28 Feb 2013 06:18:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.88.138 with SMTP id bg10mr11346058wjb.13.1362061089296; Thu, 28 Feb 2013 06:18:09 -0800 (PST) Received: by 10.216.148.196 with HTTP; Thu, 28 Feb 2013 06:18:08 -0800 (PST) In-Reply-To: References: <20130228043953.GH9197@mx1.yitter.info> Date: Thu, 28 Feb 2013 09:18:08 -0500 Message-ID: From: Joseph Yee To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkz1Om4TyG+15HDwtXifjxBSNdgEpWOuY9lkUi/5B5OIOSScmPC1p0/06DEyCvGVufpzqPCv2ccJoBpBxJPrV5MG8uN+0MW9nUB7qRIZkK84nzucwgnMQY2WbErdJVSukA+b18y 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: Thu, 28 Feb 2013 14:18:17 -0000 On Thu, Feb 28, 2013 at 12:07 AM, Murray S. Kucherawy wrote: > As I recall there was AD resistance to the idea of doing this in a scheduled > working group session. (Pete, feel free to correct me if I misinterpreted > your remarks.) That said, there was also agreement that a bake-off is a > fine thing to do since we do like demonstrations of interoperability, so > there was support for arranging some "lab" time outside of the meeting if > we're so moved. > > Should we make such a request? If so, can we get some idea of how many > would attend and how many participants there would be? > > -MSK > That's what I recalled as well, is to schedule demo outside the working group session. And it makes sense, 1 hour is not enough for both discussion and demo. +1 for both request and attendance Best Joseph > > On Wed, Feb 27, 2013 at 8:39 PM, Andrew Sullivan > wrote: >> >> On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: >> > Attached is the preliminary agenda for our session in Orlando. >> >> I'm slightly surprised that we're not doing any interop demo. Some >> while ago, I suggested that Dyn would be ready to show off an >> implementation, and suggested a bake-off. People said at the time >> that such work should be in the WG session and not on the side. Has >> my wandering attention failed to notice a change in the views of >> others? (It wouldn't surprise me.) >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> 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 carlosm3011@gmail.com Thu Feb 28 06:18: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 57A8821F8922 for ; Thu, 28 Feb 2013 06:18:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US+GqLrZv6SP for ; Thu, 28 Feb 2013 06:18:58 -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 B390921F88DD for ; Thu, 28 Feb 2013 06:18:58 -0800 (PST) Received: by mail-ye0-f170.google.com with SMTP id m15so260361yen.29 for ; Thu, 28 Feb 2013 06:18:58 -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=RYeepMRxqluWlZeyDoHxn1fz5GZtNQwTWHdT9bb24Y4=; b=B20S43sidBEi6YvP+ALd17zkUyxuUPYYdKdR/UdL5n5/MPVe3I8qr7sN8DypSy+ZnK RAFZ5bmMk4h8zmivK6s158bswAxpV/3Zd3eW9E70GoQbuFjvEr06zeJghqodWOmhzN8q rHuhjA2AaIKokP/4SqV1W5b8zX76h5DRERgCdFpO1j6jZPUXdF8zPWuauKd45sKqrAqP 4f3QrNu4lZ8EodnBwwc3gmtiN4cpH94ZKSzl5sRlW0bxqwzc8bbx61Ft/sB8ji+XRo7w rR1+6q6rxn9A3w7DaOU73qnGhB/H3LFms8yUdDr3EAIY9vDTA1R7Xmno0vkTapT5HYAR WcXQ== X-Received: by 10.236.149.146 with SMTP id x18mr4594974yhj.29.1362061138330; Thu, 28 Feb 2013 06:18:58 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:5128:b076:d30d:f384:3992? ([2001:13c7:7001:5128:b076:d30d:f384:3992]) by mx.google.com with ESMTPS id x8sm13435529yhn.12.2013.02.28.06.18.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 06:18:56 -0800 (PST) Message-ID: <512F674B.1080102@gmail.com> Date: Thu, 28 Feb 2013 12:18:51 -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: Arturo Servin References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> In-Reply-To: <512F0024.7080507@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Levine , weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-redirects-01.txt 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, 28 Feb 2013 14:18:59 -0000 IMO, some 'lightweight' redirect warning embedded in the protocol would be a good addition. I'm specifically thinking about scenarios where very simplistic clients are used (curl/wget scripted with bash or some quick n'dirty javascript concoctions) This would not be a protection against a determined attacker, but would rather serve as a useful warning/protection for/against the fat-finger crowd. But, again as Arturo mentions, we are willing to submit to the WG's desires :D Cheers ~CArlos On 2/28/13 4:58 AM, Arturo Servin wrote: > > No and yes. It has not been a problem but some people commented that it > would be good to inspect some mechanisms to protect weirds servers > against bad programed clients. > > We are happy to follow the WG desires, we could forget about any > mechanism, we could look for another one, etc. > > Regards, > as > > On 26/02/2013 04:11, John Levine wrote: >>> 2) Doing statefull http redirection to avoid loops (considering that >>> the user agent may be bad implemented and incapable of break a loop) >> >> Has this been a problem in practice? HTTP has had redirects for 20 >> years. I'd think that redirect loops would be a solved problem at >> that level. >> > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From marc.blanchet@viagenie.ca Thu Feb 28 06:32: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 4D06021F8BA2 for ; Thu, 28 Feb 2013 06:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 nPiMigR4G8w0 for ; Thu, 28 Feb 2013 06:32:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3E21F8976 for ; Thu, 28 Feb 2013 06:32:36 -0800 (PST) Received: from [172.16.59.115] (modemcable186.124-70-69.static.videotron.ca [69.70.124.186]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 14DB540417; Thu, 28 Feb 2013 09:32:06 -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: <20130228043953.GH9197@mx1.yitter.info> Date: Thu, 28 Feb 2013 09:32:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130228043953.GH9197@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) 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: Thu, 28 Feb 2013 14:32:42 -0000 Le 2013-02-27 =E0 23:39, Andrew Sullivan a = =E9crit : > On Wed, Feb 27, 2013 at 01:49:24PM -0800, Murray S. Kucherawy wrote: >> Attached is the preliminary agenda for our session in Orlando. =20 >=20 > I'm slightly surprised that we're not doing any interop demo. Some > while ago, I suggested that Dyn would be ready to show off an > implementation, and suggested a bake-off. People said at the time > that such work should be in the WG session and not on the side. Has > my wandering attention failed to notice a change in the views of > others? (It wouldn't surprise me.) >=20 I would suggest: - do interop bakeoff outside and before the weirds meeting - provide a two-three slides summary during the weirds meeting, with the = focus on what was tested, what was found unclear in the specs, etc... Marc. > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Thu Feb 28 07:39: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 AE93621F8BBA for ; Thu, 28 Feb 2013 07:39:34 -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 5nVEf1s2hrO5 for ; Thu, 28 Feb 2013 07:39:33 -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 A379721F8BB0 for ; Thu, 28 Feb 2013 07:39:33 -0800 (PST) Received: (qmail 27926 invoked from network); 28 Feb 2013 15:39: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=6d15.512f7a34.k1302; bh=2lsAV1dhj1+JKEXwX52kMyXGUmrjNSigLqlVwekPr00=; b=B0AOu/8327pv3IM4YpeWG1PyXn1ciz7bQeUI6z88A1+4dNRgwqRCFdy9OfpEvN75GkYQ8rR01Yr7dbcAwXrpODkd9++K2StnbhHr/WJXnpNmjJ5yPY+nZw1EyWstCiNHCw9XHYM1rZv/sTo/ZZVjUEXmbr0v7WKJ+xaiGdkMyRM= 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=6d15.512f7a34.k1302; bh=2lsAV1dhj1+JKEXwX52kMyXGUmrjNSigLqlVwekPr00=; b=XMN7zIjQlDEoA0WL9Cmca2ieS+TiC7faSXPgsXT3KPQKO1W1QV4l1SoiJzh74yCiasb4sqeH58y6OyjkrOIFRCm9kXR+ce0t79ncUGtXEHbRU+j1zL5uJGbDChmlmRGNInD7nL6UdDvXE3mRVM/MwKstKPjAJIVnXSBfRL5I8pE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 28 Feb 2013 15:39:10 -0000 Date: 28 Feb 2013 10:39:32 -0500 Message-ID: From: "John R Levine" To: carlos@lacnic.net In-Reply-To: <512F674B.1080102@gmail.com> References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: weirds@ietf.org 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: Thu, 28 Feb 2013 15:39:34 -0000 > IMO, some 'lightweight' redirect warning embedded in the protocol would > be a good addition. I'm specifically thinking about scenarios where very > simplistic clients are used (curl/wget scripted with bash or some quick > n'dirty javascript concoctions) 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. Really, this sounds like a solution in search of a problem. It's hard for me to imagine a plausible scenario in which someone would be doing WEIRDS lookups, and the underlying HTTP fetch tool wouldn't already deal with redirect loops. Also, I can tell you from long experience dealing with similar indirection loops that server side loop breaking doesn't work. No matter how clever you are, someone will do something that resets the loop count, or that the server doesn't recognize as a loop, and you end up breaking it in the client anyway. Just take it out, please. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From superuser@gmail.com Thu Feb 28 13:11: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 77D9321F891C for ; Thu, 28 Feb 2013 13:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 vhiLdsw4yLzA for ; Thu, 28 Feb 2013 13:11:21 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id BA09B21F88ED for ; Thu, 28 Feb 2013 13:11:20 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hq4so2691323wib.5 for ; Thu, 28 Feb 2013 13:11:20 -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=MhK3yaiDtT0SyEg6in4LUc8XM0iefHK01613sDMJ/P8=; b=Y+D6EO2BR9QHB3XhU8RsJ6WaKkOmGthN2t9ikGYmhbhipzl7curG3LW3VvFSfT/ZC5 t+j8oSQH93ext5JbEs5m5j6mi2nw15j34/S5i+57M5ecaWW/XkxK93Q5Eba1bDB41Nu1 m7odCp4jh0Vyu2gvGdX6FBw9AM34mfFnwmeRn3Z98d/dpGt+cFYkmZA1mXZXmPSNjbQX Ek2zXHs1R6BNXa4e3OD4sW7tyXblVha6JSyc4wfOpBLTQr6u2Q5m7RdwbqUWyNZNaWWr wBijOeC/Zn6VM3ZphXo0ePNStfQKdeatqBc2gHSTZ0OgIdKjGR8UPBobWz5OtAHpRtfQ seIQ== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr35620045wiy.5.1362085879949; Thu, 28 Feb 2013 13:11:19 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 13:11:19 -0800 (PST) Date: Thu, 28 Feb 2013 13:11:19 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428eb607325f04d6cf5592 Subject: [weirds] Interop time requested X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Feb 2013 21:11:21 -0000 --f46d04428eb607325f04d6cf5592 Content-Type: text/plain; charset=ISO-8859-1 I've requested a second meeting slot so we have some space allocated to do demos and interoperability testing as some of you have expressed interest in doing. I've no idea what's actually available, so I can't give any predictions as to what time slot we might get. Will keep you all posted. -MSK, WEIRDS co-chair --f46d04428eb607325f04d6cf5592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've requested a second meeting slot so we have some s= pace allocated to do demos and interoperability testing as some of you have= expressed interest in doing.=A0 I've no idea what's actually avail= able, so I can't give any predictions as to what time slot we might get= .=A0 Will keep you all posted.

-MSK, WEIRDS co-chair
--f46d04428eb607325f04d6cf5592-- From james.mitchell@ausregistry.com.au Thu Feb 28 13:26: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 79A4621F87A4 for ; Thu, 28 Feb 2013 13:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=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 UxSpl6p--cHs for ; Thu, 28 Feb 2013 13:26:46 -0800 (PST) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id D6A2A21F892C for ; Thu, 28 Feb 2013 13:26:45 -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; 01 Mar 2013 08:26: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; Fri, 1 Mar 2013 08:26:37 +1100 From: James Mitchell To: "Hollenbeck, Scott" , "weirds@ietf.org" Date: Fri, 1 Mar 2013 08:26:35 +1100 Thread-Topic: Entity "Objects" Thread-Index: Ac4V+kmNQNSbs+CDTbmTTuUvhpGo5g== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24325839@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.0.121105 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD5613F5558FAjamesmitchellausregistrycomau_" 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: Thu, 28 Feb 2013 21:26:47 -0000 --_000_CD5613F5558FAjamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_CD5613F5558FAjamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Scott,

Perhaps contact objects and registrar objects share the same identi= fier space in Verisign's system, however in ours they do not. Wha= t 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 differ= ent names, email addresses etc.

If I do not care a= bout direct queries for contact/registrar objects (URLs constructed by clie= nts), and instead assume that links will always be obtained in domain respo= nse,  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 registr= ars should be their own path segments at /registrar/id. Does anyone else ha= ve this problem?

Regards,
James

From: <Hollenb= eck>, Scott <shollenbeck@= verisign.com>
Date: Frid= ay, 1 March 2013 12:17 AM
To: J= ames Mitchell <jame= s.mitchell@ausregistry.com.au>, "= weirds@ietf.org" <weirds@ietf.org= >
Subject: RE: Entity "O= bjects"

Entity objects can be identified by role. A registrar entity and a c= ontact entity (such as a registrant) would have distinct roles in the conte= xt of a domain object.

 

Scott=

 =

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

 

All,

=  

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

 - Contact objects an= d Registrar objects do not share the same identifier space.

 - Contact objects and Registrar= objects share very little data; one may think of registrar objects as bein= g 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)

 <= /p>

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

 

Thanks,=

James

<= /div>
--_000_CD5613F5558FAjamesmitchellausregistrycomau_-- From superuser@gmail.com Thu Feb 28 14:01: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 1ED6421F88C1 for ; Thu, 28 Feb 2013 14:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 3mnD+Kk00hQm for ; Thu, 28 Feb 2013 14:01:51 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCA521F87EE for ; Thu, 28 Feb 2013 14:01:51 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so8346883wid.17 for ; Thu, 28 Feb 2013 14:01:50 -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=vjOW62+c6Jc5s9hAdgTBDN9uMfy8TRAyglANdtsE7U4=; b=qaFztj0TnbK2SPGUTMwpI83PN0pet91W6b8Q53P6inEx3gBDeaO0g+XRYseIlf7ged 4hxTm0Hm4MQZUVsxHN7iOqX63lHdspfIiv/cj6ITXGaelXKILAohwsrOxyZvM5c7pu7R P012GPt0csuHLNwK8hXokO1jDsjS7Q0y8kjhMik9szbV+f17m83RStob0YY5V99wMzK/ +ZmUYkOKF9ZmpV39n15zrzFQAO97MVHGqHd2Tm+VweKrKo8rPB6mGl2L9Sf/3sBfW8EK 5t9c2xVlF4807GKtHsSh5jWzeNoTJBktOKD0vqe0RqLhODQzk/A51PGslyyR2oJQ5YOM aawQ== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr35822681wiy.5.1362088910392; Thu, 28 Feb 2013 14:01:50 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 14:01:50 -0800 (PST) In-Reply-To: References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> Date: Thu, 28 Feb 2013 14:01:50 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d04428eb6a816d304d6d00926 Cc: Carlos Martinez , "weirds@ietf.org" 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: Thu, 28 Feb 2013 22:01:52 -0000 --f46d04428eb6a816d304d6d00926 Content-Type: text/plain; charset=ISO-8859-1 For what it's worth, this is also how sendmail does email loop detection. Specifically, beyond a fixed (but configurable) number of Received fields, the mail is assumed to be looping, so it bounces. -MSK, participatin' On Thu, Feb 28, 2013 at 7:39 AM, John R Levine wrote: > IMO, some 'lightweight' redirect warning embedded in the protocol would >> be a good addition. I'm specifically thinking about scenarios where very >> simplistic clients are used (curl/wget scripted with bash or some quick >> n'dirty javascript concoctions) >> > > 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. > > Really, this sounds like a solution in search of a problem. It's hard for > me to imagine a plausible scenario in which someone would be doing WEIRDS > lookups, and the underlying HTTP fetch tool wouldn't already deal with > redirect loops. > > Also, I can tell you from long experience dealing with similar indirection > loops that server side loop breaking doesn't work. No matter how clever > you are, someone will do something that resets the loop count, or that the > server doesn't recognize as a loop, and you end up breaking it in the > client anyway. Just take it out, please. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > ______________________________**_________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/**listinfo/weirds > --f46d04428eb6a816d304d6d00926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For what it's worth, this is also how sendmail does em= ail loop detection.=A0 Specifically, beyond a fixed (but configurable) numb= er of Received fields, the mail is assumed to be looping, so it bounces.
-MSK, participatin'


On Thu, Feb 28, 2013 at 7:39 AM, John R Levine <john= l@taugh.com> wrote:
IMO, some 'lightweight' redirect warning embedded in the protocol w= ould
be a good addition. I'm specifically thinking about scenarios where ver= y
simplistic clients are used (curl/wget scripted with bash or some quick
n'dirty javascript concoctions)

curl and wget recognize and break redirect loops. =A0Javascript depends on = the browser in which it's running, but they all break redirect loops, t= oo. It's very simple: after some large fixed number of redirects, like = 20, they declare failure and stop.

Really, this sounds like a solution in search of a problem. =A0It's har= d for me to imagine a plausible scenario in which someone would be doing WE= IRDS lookups, and the underlying HTTP fetch tool wouldn't already deal = with redirect loops.

Also, I can tell you from long experience dealing with similar indirection = loops that server side loop breaking doesn't work. =A0No matter how cle= ver you are, someone will do something that resets the loop count, or that = the server doesn't recognize as a loop, and you end up breaking it in t= he client anyway. =A0Just take it out, please.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds

--f46d04428eb6a816d304d6d00926-- From johnl@taugh.com Thu Feb 28 14:18: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 BAEF921F8BB6 for ; Thu, 28 Feb 2013 14:18:47 -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 SjpPmQn39V3z for ; Thu, 28 Feb 2013 14:18:47 -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 A11BA21F8BAF for ; Thu, 28 Feb 2013 14:18:46 -0800 (PST) Received: (qmail 41642 invoked from network); 28 Feb 2013 22:18:46 -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=a2a8.512fd7c6.k1302; bh=37m5XFGCzb0rblwSQWf5BFg8ilmoUbImoWVhMS8Gsv0=; b=SuHD6ZgqLg/JYA0xWolrwVVxzliu0b3DHmJhQpg9qStE2yPT9Uw2xAzkKZ1xTLX8dvruZ7mkJroOVTsQULoK8okwUNVS5C3msGHVUF5rtwYsGW+XUVQjKQ5KxoTnDm5g3FRYtU+5YC297dX+isUg6xTIFpht6KRO/hljxHvFRgQ= 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=a2a8.512fd7c6.k1302; bh=37m5XFGCzb0rblwSQWf5BFg8ilmoUbImoWVhMS8Gsv0=; b=mSK0qR0caahKSkDHAFA8gt+opbbC2p4hhaC/gKd2WdP7Cpo7hNKu7ePMim7l7Z4XMlvEsxKoWtdPiat2WQmWr6APF96HxSh2eZmApPJbXXLnfz1idz4wdyEm089WmYyxHk6i0K5LEf/5G5NzdgdM5AFyfI036PZ8ptzN0+YqNxY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 28 Feb 2013 22:18:24 -0000 Date: 28 Feb 2013 17:18:45 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> 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-1218864827-1362089925=:64845" Cc: "weirds@ietf.org" 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: Thu, 28 Feb 2013 22:18:47 -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-1218864827-1362089925=:64845 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 28 Feb 2013, Murray S. Kucherawy wrote: > For what it's worth, this is also how sendmail does email loop detection. > Specifically, beyond a fixed (but configurable) number of Received > fields, the mail is assumed to be looping, so it bounces. I should hope so. See RFC 5321 section 6.3 which is the same as RFC 2821 sec 6.2. Again, this is a solved problem. R's, John > On Thu, Feb 28, 2013 at 7:39 AM, John R Levine wrote: > >> IMO, some 'lightweight' redirect warning embedded in the protocol would >>> be a good addition. I'm specifically thinking about scenarios where very >>> simplistic clients are used (curl/wget scripted with bash or some quick >>> n'dirty javascript concoctions) >>> >> >> 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. >> >> Really, this sounds like a solution in search of a problem. It's hard for >> me to imagine a plausible scenario in which someone would be doing WEIRDS >> lookups, and the underlying HTTP fetch tool wouldn't already deal with >> redirect loops. >> >> Also, I can tell you from long experience dealing with similar indirection >> loops that server side loop breaking doesn't work. No matter how clever >> you are, someone will do something that resets the loop count, or that the >> server doesn't recognize as a loop, and you end up breaking it in the >> client anyway. Just take it out, please. --3825401791-1218864827-1362089925=:64845 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMjgyMjE4 NDVaMCMGCSqGSIb3DQEJBDEWBBQ1n2gZnuVrOjBt8/82FW9xyjCn/zB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQCSuWaF3m9w3O2NMVepflkDu7iBOYGgDrfFnY4oWl6VLcRqlVE27MnVpzjl dsTV5TPi3Mh+kp4rx/0kkxSzyQUZhOX4PgFOP5BDNjdfgiLrtmXC/Dg/Pirg INtB6MBw13XWA2CyEkrfh9oUKaemWPCo/bu5N5xF5CbAV7BS0Y8w/OKsJ7gt LEMr3VDTZf3x+nbqgx+j0R8YKPNfyNbj+KU8BMDoyqrqW11b3AbbfZZOXPlY HVVaAZVjeseF2JxUDhJUNTZUMW5qJ1NykcvojMpYpLhHXSoR4YnIDaz/rRZG 9wL60BtJ593WnRctvBXSzhHP/Ct3KVd/v46e8zJ7WOmy --3825401791-1218864827-1362089925=:64845-- From superuser@gmail.com Thu Feb 28 14:34: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 1514021F8749 for ; Thu, 28 Feb 2013 14:34:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzCjzNHYh7HP for ; Thu, 28 Feb 2013 14:34:09 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BE61D21F86B8 for ; Thu, 28 Feb 2013 14:34:08 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so2019757wey.3 for ; Thu, 28 Feb 2013 14:34:07 -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=VEUYBua073yQVrnuBuyE1/zy9eh58QEa9u1E/Ioid4U=; b=Xr88pxeyF8x0qGuDUwuBLbdDaQyPO/ACDjvFKbefah+O2rLjvKVphPtJ9NuUo6Z+w8 s244hKrqNSCFN2ZutaZaOww+ey4y2G+4pGz1PwYp39iIKl71Y3BPEAGQFEXsQ0PWozI2 Vs8NxbpulXIjr6nU5YwFBHdxo8Lx5koPZhg7qz3L5peWUwXqJ6aBlM5GIpv3gAg0+Car BsXpohCphWbssuOmyTqj4yZrcAaDthNf8rzoEEDbBELfAfuwWwKu9pT5Q1qwtlUw8OBY 3qqulspkEM10uBOgHTddCtIkVFzuF+ep3XsXZ2oHgaps3QEXstMbP/bpS065yvVw8zcP PGew== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr14007910wjb.39.1362090847205; Thu, 28 Feb 2013 14:34:07 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 14:34:06 -0800 (PST) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> Date: Thu, 28 Feb 2013 14:34:06 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7b5d456c197e6204d6d07dde 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: Thu, 28 Feb 2013 22:34:10 -0000 --047d7b5d456c197e6204d6d07dde Content-Type: text/plain; charset=ISO-8859-1 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 > --047d7b5d456c197e6204d6d07dde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 <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<= br> 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. =A0But background prese= ntations are not what in-person WG meetings are for. =A0I've played jun= ior chair enough already, if Olaf and Murray see it as an issue, I'm su= re they can handle it.

R's,
John

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

--047d7b5d456c197e6204d6d07dde-- From superuser@gmail.com Thu Feb 28 14:35: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 DBE1621F8700 for ; Thu, 28 Feb 2013 14:35:47 -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, 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 dU3SyLyb7M2A for ; Thu, 28 Feb 2013 14:35:47 -0800 (PST) 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 D593521F8630 for ; Thu, 28 Feb 2013 14:35:46 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so9723396wib.1 for ; Thu, 28 Feb 2013 14:35:46 -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=1vfOG0GpcZvH1ONMpOSiBTGJCMC6zTEhG7Wr3FwUCTs=; b=CZZ1m/lLHC3v5vjyntCAAqqksDCvc7gkld9qD640R/FCHbOLGyokAlp53iG8peajQP kU3PZv6KylKMsbvX16qkUkHaKfMI4A/6cEl91CVXRJTaj9CekCZqK73wAQW6L/IHhFnC 8JxOXL/+bAYIMM/YOOhCmHVWcDvh6cvJz7lc6q2ZDX3tJtw0D6MtAkeScwq5uNwAzYbg BeLlD1ijdRBtFyay/JDxkapiU4+anXTXgx369rBOsoXn3ThTmwBnZga44hfEgqNvMTtA LoYZN50iyx7WKqInFTlDzS6HTDuKLFnUrbLwaZqg+GzHYy//ZVrVYP5w5ELDnfsMvuqC r2ew== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr13931311wjq.51.1362090946060; Thu, 28 Feb 2013 14:35:46 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 14:35:45 -0800 (PST) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243255A8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <024501ce155e$27054910$750fdb30$@cn> <831693C2CDA2E849A7D7A712B24E257F243255A8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 28 Feb 2013 14:35:45 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=047d7b86cea4fde94804d6d08293 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: Thu, 28 Feb 2013 22:35:48 -0000 --047d7b86cea4fde94804d6d08293 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I propose to add Scott's and Linlin's documents in "Call For Adoption" state, and we can figure out how to proceed in Orlando. Any objections? -MSK On Wed, Feb 27, 2013 at 7:13 PM, Hollenbeck, Scott wrote: > It=92s more appropriately included as part of #3, and yes, I was plannin= g > to include it if I have the opportunity to lead the discussion.**** > > ** ** > > Scott**** > > ** ** > > *From:* weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > Behalf Of *Linlin Zhou > *Sent:* Wednesday, February 27, 2013 9:49 PM > *To:* 'Murray S. Kucherawy'; weirds@ietf.org > > *Subject:* Re: [weirds] Preliminary agenda**** > > ** ** > > I suggest 5 min for item #4 to discuss the document > draft-zhou-weirds-rdap-restful-search-00. I think there are some > differences between the two search drafts we should notice.**** > > ** ** > > Regards,**** > > Linlin**** > > ** ** > > *From:* weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] > *On Behalf Of *Murray S. Kucherawy > *Sent:* Thursday, February 28, 2013 5:49 AM > *To:* weirds@ietf.org > *Subject:* [weirds] Preliminary agenda**** > > ** ** > > Attached is the preliminary agenda for our session in Orlando. I've > posted it to the meeting materials tool but it doesn't appear to have > updated the agenda page with a link yet. > > A few of them are TBD in terms of presenters. Can we get some volunteers > to lead those parts of the discussion?**** > > Suggestions for changes to the agenda are welcome, but keep in mind we > only have an hour allocated. If there's something urgent that requires > more time, we can ask our AD for help, but there are no guarantees.**** > > ** ** > > -MSK, WEIRDS co-chair**** > --047d7b86cea4fde94804d6d08293 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I propose to add Scott's and Linlin's documen= ts in "Call For Adoption" state, and we can figure out how to pro= ceed in Orlando.=A0 Any objections?

-MSK


On Wed, Feb 27, 2013 at 7:13 PM, Hollenb= eck, Scott <shollenbeck@verisign.com> wrote:

It=92s more appropriately= included as part of #3, and yes, I was planning to include it if I have th= e opportunity to lead the discussion.

=A0<= /p>

Scott

=A0<= /p>

From: weirds-bounces@ietf.o= rg [mailto:weirds-bounces@ietf.org] On Behalf Of Linlin Zhou
Sent: Wednesday, February 27, 2013 9:49 PM
To: 'Murray S. Kucherawy'; weirds@ietf.org


Subject: Re: [weirds] Preliminary agenda

=A0

I suggest 5 min for item #4 to discuss = the document draft-zhou-weirds-rdap-restful-search-00. I think there are so= me differences between the two search drafts we should notice.

=A0

Regards,

Linlin

=A0

From: weirds-bounces= @ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, February 28, 2013 5:49 AM
To: weirds@ietf= .org
Subject: [weirds] Preliminary agenda

=A0

Attached is the preli= minary agenda for our session in Orlando.=A0 I've posted it to the meet= ing materials tool but it doesn't appear to have updated the agenda pag= e with a link yet.

A few of them are TBD in terms of presenters.=A0 Can we get some volunteers= to lead those parts of the discussion?

Suggestions for changes to the agenda are welcome, b= ut keep in mind we only have an hour allocated.=A0 If there's something= urgent that requires more time, we can ask our AD for help, but there are = no guarantees.

=A0

-MSK, WEIRDS co-chair=


--047d7b86cea4fde94804d6d08293-- From superuser@gmail.com Thu Feb 28 14:37: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 71C4121F8704 for ; Thu, 28 Feb 2013 14:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.618, 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 7E55gPhGnhpE for ; Thu, 28 Feb 2013 14:37:32 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90621F8630 for ; Thu, 28 Feb 2013 14:37:26 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so1862721wgb.21 for ; Thu, 28 Feb 2013 14:37:25 -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=CSguIMTB3mytGQKQQ5gFL/9fJbDvM/AVfXHELqWUUCE=; b=OpYrUxGYccsDPECjT2HRxbxUoA18mdLZIFtiCukIUQN0LYmSWfkJ5QlTxaXfXywEmX H5PgS0LT3aIgjNogBfJyhajmUiEao86pF/oAn2youNPsSO8Io3kTgZ+8iA3xh/lkHRIA SgRmmZFiAHvDnhjNfkr+Hdu1TMNxqtjYxhkkfFrQjOQe69cGRVUHr/WSmkbXI1385Vvr UZBeCe6vuhWgokGDjphGG8ZazS2qNMOHG/NKQmWluagYtpSmQYjQAPYzo+0o7w4SXK6X L/IJjDc1kA9e+Ede6eKCZZRRq2aLXGpfpatuzvxUDKY+5M0P1uJYLJoCSqQYzFgu5zXE Vz0g== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr13936839wjq.51.1362091045504; Thu, 28 Feb 2013 14:37:25 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 14:37:25 -0800 (PST) In-Reply-To: <512ECB84.4030002@lacnic.net> References: <512ECB84.4030002@lacnic.net> Date: Thu, 28 Feb 2013 14:37:25 -0800 Message-ID: From: "Murray S. Kucherawy" To: Arturo Servin Content-Type: multipart/alternative; boundary=047d7b86cea4eb4d2004d6d08876 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: Thu, 28 Feb 2013 22:37:35 -0000 --047d7b86cea4eb4d2004d6d08876 Content-Type: text/plain; charset=ISO-8859-1 Is this a topic for which we need face time? Perhaps a good way to answer this question is to consider the following: Has it had much list discussion so far? Are we stuck on it? I'm not suggesting it's not a valid or important topic, but we only have a one-hour session so we need to make good use of the time. -MSK On Wed, Feb 27, 2013 at 7:14 PM, Arturo Servin wrote: > > What about redirects? > > Regards, > as > > On 28/02/2013 05:49, Murray S. Kucherawy wrote: > > Attached is the preliminary agenda for our session in Orlando. I've > > posted it to the meeting materials tool but it doesn't appear to have > > updated the agenda page with a link yet. > > > > A few of them are TBD in terms of presenters. Can we get some > > volunteers to lead those parts of the discussion? > > > > Suggestions for changes to the agenda are welcome, but keep in mind we > > only have an hour allocated. If there's something urgent that requires > > more time, we can ask our AD for help, but there are no guarantees. > > > > -MSK, WEIRDS co-chair > > > > > > > > _______________________________________________ > > 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 > --047d7b86cea4eb4d2004d6d08876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this a topic for which we need face time?
=
Perhaps a good way to answer this question is to consider the fol= lowing: Has it had much list discussion so far?=A0 Are we stuck on it?
<= br>
I'm not suggesting it's not a valid or important topic, = but we only have a one-hour session so we need to make good use of the time= .

-MSK


On Wed, Feb 27, 2013 at 7:14 PM, Arturo Servin <aservin@lacnic.net>= ; wrote:

=A0 =A0 =A0 =A0 What about redirects?

Regards,
as

On 28/02/2013 05:49, Murray S. Kucherawy wrote:
> Attached is the preliminary agenda for our session in Orlando. =A0I= 9;ve
> posted it to the meeting materials tool but it doesn't appear to h= ave
> updated the agenda page with a link yet.
>
> A few of them are TBD in terms of presenters. =A0Can we get some
> volunteers to lead those parts of the discussion?
>
> Suggestions for changes to the agenda are welcome, but keep in mind we=
> only have an hour allocated. =A0If there's something urgent that r= equires
> more time, we can ask our AD for help, but there are no guarantees. >
> -MSK, WEIRDS co-chair
>
>
>
> __________________= _____________________________
> 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

--047d7b86cea4eb4d2004d6d08876-- From sm@resistor.net Thu Feb 28 14:44: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 D0B3921F87EE for ; Thu, 28 Feb 2013 14:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 afTBO3MTFfMr for ; Thu, 28 Feb 2013 14:44:02 -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 2DA5E21F87CE for ; Thu, 28 Feb 2013 14:44:01 -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 r1SMhu4J007050; Thu, 28 Feb 2013 14:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362091441; bh=lET8I6w+0NGdn3JIISJRRLXdz611yjak2nuP1xwv9t4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cDjzI90/wbWKXqNZjKy4wLhcXm7az7PrUTSuk+3Cv91KfZsuEJfx6pZcs/vUHJKcI +Kfj8tXyr/YkTi1qeAG+Xle/2V6sih+Z1LpqfnM1ZHhGdae+Q9tQAta3+Ski8t6Gtu VF4ivy0pquZF408n4sZQW1/cVe2Q/MHsgHZC9rEs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362091441; i=@resistor.net; bh=lET8I6w+0NGdn3JIISJRRLXdz611yjak2nuP1xwv9t4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C/SKQYykRtXNtIxwsBfrXA1v3s3Z7rFYj34AyowQAob/35f1E3wQeXLNJtUvkqGvk IlQV9JRuWuZwzkR65JJcRUD5q2Eb+l3ffepKdKe690a0eNNzyi4jipgd4H0kQSGwfU MT1vguSMIIzhzfTUQSMOQg2kKjQJtvo63HYwjZJw= Message-Id: <6.2.5.6.2.20130228143447.0a0c76f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 14:41:55 -0800 To: "John R Levine" From: SM In-Reply-To: References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: carlos@lacnic.net, weirds@ietf.org 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: Thu, 28 Feb 2013 22:44:07 -0000 At 07:39 28-02-2013, John R Levine wrote: >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. Regards, -sm From superuser@gmail.com Thu Feb 28 14:46: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 8633221F8793 for ; Thu, 28 Feb 2013 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 e6ahvTyblaJW for ; Thu, 28 Feb 2013 14:46:34 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D521F8621 for ; Thu, 28 Feb 2013 14:46:33 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so2779617wib.3 for ; Thu, 28 Feb 2013 14:46:32 -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=TUWV3vnTmCfbB77ih2+KGZoDDJLJWgmB4DLDOy0dH6s=; b=GKj0kYE3o5kJNHBTtu3NzVEpsrLuqISMHe3DQrGwiJQeSyabxYCYyRBYMxDouVnO4j x8FqITZgR1jWz3NE1gBj3ZyTZIY9UypelNwtmUalF4RDdjGIk7z6y8K1UWiSkgDnwNxr t1qM0wkgkLIG3+JhYrfw4a2WCatkkfhvdoH21QTKk7K39mltM1XAyiWNB2AAFgp7X4EC ITt1vir4m7PqgU+bsqQvgSflrCYFrJSJTIUk8RaI3UxQbdIW1O7Y+2qnDO1RW9hXjWy6 FkyoyAbXLx/qzPpIq040FzUMiEGw9usnOz6+6s11585wxQ2au4zFvSFpf761R577P210 cLBA== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr14049742wjb.39.1362091592710; Thu, 28 Feb 2013 14:46:32 -0800 (PST) Received: by 10.180.163.70 with HTTP; Thu, 28 Feb 2013 14:46:32 -0800 (PST) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBEFF4F@CHAXCH01.corp.arin.net> Date: Thu, 28 Feb 2013 14:46:32 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7b5d456c89006c04d6d0a97c 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: Thu, 28 Feb 2013 22:46:34 -0000 --047d7b5d456c89006c04d6d0a97c Content-Type: text/plain; charset=ISO-8859-1 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 >> > > --047d7b5d456c89006c04d6d0a97c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Also, having a document that the WG can review ahead of ti= me would be really helpful.=A0 Steve, could you produce such a thing?=A0 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 <superuser@gmail.com> 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 <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<= br> 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. =A0But background prese= ntations are not what in-person WG meetings are for. =A0I've played jun= ior chair enough already, if Olaf and Murray see it as an issue, I'm su= re they can handle it.

R's,
John

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


--047d7b5d456c89006c04d6d0a97c-- From johnl@taugh.com Thu Feb 28 14:48: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 87E5421F8922 for ; Thu, 28 Feb 2013 14:48:39 -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 tY2YpjbotpK0 for ; Thu, 28 Feb 2013 14:48:39 -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 910F121F8858 for ; Thu, 28 Feb 2013 14:48:38 -0800 (PST) Received: (qmail 48951 invoked from network); 28 Feb 2013 22:48: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:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=bf34.512fdec6.k1302; bh=DG2pJp5IhSql1NfsA2y1nkkOlDG5jIQ24s203HiJBSc=; b=X+ClnVd2JJ+wgQrrQq4xforrjsKmz8YhjYlXT2QwwddvEb/lF5HUVQbWVM3UkeaiiM2UYjhA7OWuMBTbEqa3PVB3U2NHTHtp7h7XTov2fYE0NQfbd1ddlisxndVN79khazsGpj/mDkqi+EcteJ8gFA2l3NUuPewtzCTzYkYtCbA= 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=bf34.512fdec6.k1302; bh=DG2pJp5IhSql1NfsA2y1nkkOlDG5jIQ24s203HiJBSc=; b=WRvdF29sG/mIe6xrK4Wm+oBbBkqv10S2If8AbLPl8vb32so51DENANNWs48j3IOGpNyQZUQRl1XYdwWVT1dVRqDkm8btvq6aqU5nFxzBkA/7zNP9/0uoLGT1P0mk3GLUmUKg5aLsY2brwGgwOZFvFrQdAB5Wg+CbOGQeHRy4GQ8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 28 Feb 2013 22:48:16 -0000 Date: 28 Feb 2013 17:48:37 -0500 Message-ID: From: "John R Levine" To: "SM" In-Reply-To: <6.2.5.6.2.20130228143447.0a0c76f0@resistor.net> References: <20130225201158.26041.qmail@joyce.lan> <512F0024.7080507@lacnic.net> <512F674B.1080102@gmail.com> <6.2.5.6.2.20130228143447.0a0c76f0@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-1664486073-1362091717=:64845" Cc: weirds@ietf.org 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: Thu, 28 Feb 2013 22:48:39 -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-1664486073-1362091717=:64845 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> 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. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1664486073-1362091717=:64845 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMjgyMjQ4 MzdaMCMGCSqGSIb3DQEJBDEWBBR5bwNdhdfApJn38TeAjrdvcyw3VzB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQA9qKS8lGA2ji+IggFgBip/BBpd0SBi5a8Pm85PtY/mIAEhabyWLdZy/8To y91lMK5yQjgvKISsPx9s4SEQj0yMGDBbxNr3EoQz1PbKSmIuM0xzz6OsFVH9 DQ02UXL/kTrwyws+enCr7F1tkERC4jHG4jJYhlJ+nu7/4HNvDYfOnaPBAbHG AIkPpmcLo8XApcBb0F1XPdmgl5eOWZBocVYqesQ+Ltrx3I8zqnc8nxL9jWk7 pqPQTOSr1BX1spr2FJqoBewqowQJJsjV0wyWHa7c53SQb/Nzqm6Qhubqxtmu 9s7jHUfSD8OsWxMgWThM2bN0Eggnnv7P2zKTbtswfq/G --3825401791-1664486073-1362091717=:64845-- From andy@arin.net Thu Feb 28 15:11: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 2781721F85D7 for ; Thu, 28 Feb 2013 15:11:49 -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 BrUv4R3rLBFz for ; Thu, 28 Feb 2013 15:11:48 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 84A5A21F8511 for ; Thu, 28 Feb 2013 15:11:48 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 1E25B1656C6; Thu, 28 Feb 2013 18:11:48 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 11A7A1656C2; Thu, 28 Feb 2013 18:11:45 -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; Thu, 28 Feb 2013 18:11:03 -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; Thu, 28 Feb 2013 18:11:44 -0500 From: Andy Newton To: James Mitchell , "Hollenbeck, Scott" , "weirds@ietf.org" Thread-Topic: [weirds] Entity "Objects" Thread-Index: Ac4VpSpYsI/bTeI7RJeUXSF9/NAbNQAECmOAABu3eIAAFG7BAA== Date: Thu, 28 Feb 2013 23:11:43 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF03E0@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: <9047B84A63D49945A5ADDB41AC23B967@corp.arin.net> Content-Transfer-Encoding: quoted-printable 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: Thu, 28 Feb 2013 23:11:49 -0000 From: James Mitchell >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? James, We have to support multiple registry models, some with no registrars and some more than 2 tiers. Some registry models have different concepts for types of customers. Should we have to specify a new path segment for each differentiation? What about registries that don't want to differentiate? Imagine the complexity your putting on clients to know the distinctions. If you need to separate the namespace for your registrars from your contacts, do that with your identifiers. There's nothing stopping you from prefixing "contact_" or "registrar_" or whatever prefix you see fit to your registry unique identifiers if this is a necessity for you. -andy From nkong@cnnic.cn Thu Feb 28 19:43: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 1372C21F886D for ; Thu, 28 Feb 2013 19:43:40 -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 HxKserWpaMdx for ; Thu, 28 Feb 2013 19:43:39 -0800 (PST) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id CA21D21F886B for ; Thu, 28 Feb 2013 19:43:38 -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 11:43:27 +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: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> Date: Fri, 1 Mar 2013 11:43:27 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> To: Marc Blanchet 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 03:43:40 -0000 Hi Marc and Jean-Philippe, Thanks for your review. Below are my feedbacks. 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. > I agree that we should follow the relative outputs of this proposed WG. > but federated authentication is optional. So small change to = clarify: >=20 > NEW: > REQUIREMENT: Federated authentication mechanisms used by RDAP are = optional. However, if used, they MUST be fully supported by HTTP. > Good suggestion. Thanks. > One thing related to availability, especially from the client = point of view, is query throttling, commonly used. I think it should be = mentionned here. Moreover, it could be appropriate to define a standard = way to signal the client about that fact, so all clients may respond = correctly, instead of throwing the error message to the user. >=20 > Suggested text: > An RDAP service may use a throttling mechanism to limit the number of = queries a single client may be sending in a given period of time. In = this case, the server should send a 503 Service Unavailable message: >=20 > http://tools.ietf.org/html/rfc2616#section-10.5.4 >=20 > The Retry-After response-header field can be used to give an hint to = the client > http://tools.ietf.org/html/rfc2616#section-14.37 >=20 > The throttling mechanism is related with the rate limiting which was = discussed by the mailing list. IMO, the approach of rate limiting is = worth to be covered by this draft. I think Scott may give more feedbacks = on this point. Thanks again. Cheers, Ning= From sm@resistor.net Thu Feb 28 22:23: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 8941821F8771 for ; Thu, 28 Feb 2013 22:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 JbgMis-rrPS8 for ; Thu, 28 Feb 2013 22:23:26 -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 126BB21F871D for ; Thu, 28 Feb 2013 22:23:26 -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 r216MZQc014864; Thu, 28 Feb 2013 22:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362118965; bh=Aq23KB/TgH5yy6IROuyB+rIC0Ez0jPpSDLtqx4EzpXI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xku5QGNHBbFjuXQVB3BQvjkX+nDOb74zeqTNvVMXg41qn3zXGbl8pVFUk7wypa4O2 1/SqixBaQzFxonHAm6vQjgeybT+rmLAozYX1zOGmZHZ9BaSf+E7y1zdhdlIRvY15CE mdSXFBDorLIJp/TXUI7qfKXX7j0SgLMrnijZ8Sg0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362118965; i=@resistor.net; bh=Aq23KB/TgH5yy6IROuyB+rIC0Ez0jPpSDLtqx4EzpXI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ktzNKjwhR+apq8fNZdDLc/cCHVM6ECbDlckUOPnx1QuhxwX/UXDy5iCJw9xSUN+Ym 1TcY7lN+Pfugy5lk0egp1cjj4wL2Neqwzgi5PZdFkH8u5L1Bdns58uStWO0uzIsPyP +XQ+Zc2R/hRJ3tboIcTezw46Xr1s+BXucTL7DU0I= Message-Id: <6.2.5.6.2.20130228221324.0ad437f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 22:18:30 -0800 To: Ning Kong From: SM In-Reply-To: <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> References: <86AD0CF5-C1F1-4F09-87E8-F12D43BB8E53@viagenie.ca> <5EFE73A6-9A23-4BA2-8871-A18CC143705A@cnnic.cn> 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 06:23:26 -0000 Hi Ning, I took a quick look at draft-ietf-weirds-rdap-sec-01. Is it a protocol specification or a requirements document? What is the meaning of "security services"? Regards, -sm From sm@resistor.net Thu Feb 28 22:46: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 18D1D21F89CB for ; Thu, 28 Feb 2013 22:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 d3mdH5JWQ5tr for ; Thu, 28 Feb 2013 22:46:54 -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 7381F21F89B2 for ; Thu, 28 Feb 2013 22:46:54 -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 r216keV4003945; Thu, 28 Feb 2013 22:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362120408; bh=KOPt5u1mbRzhz3+I2dpjYmKt1snEqPtk8HRK32y3ekM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kO0C+rQ7iMWwB9e0CZoNsnKLxnc978dINA2HRbg/CoJAOwUlDyYMlAIzTdKsUJ8A9 u1N/ovrQsJu6gioTeYyV0eQ80msTP7wqwci0O0GtsnUIL57XuEC29nAxz2atzViCtf m+JZglK620+7r+22KpcIPuoNH5M1EE/YwOIW8Qn0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1362120408; i=@resistor.net; bh=KOPt5u1mbRzhz3+I2dpjYmKt1snEqPtk8HRK32y3ekM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wiVUn6w/xvrkC7nnn+sVZGtAj2T4K4E8AysOuJ9mqxWx2og1gqYOTAxUweeV2WQdq MaLk/vLMCO6KGyf1c8wgrOIzflMiWIpPeDKL3M+ruM+Li88cLypF6Bp6Ok4Z9gxMlm Jp0/WNW2e8/el1zzOJySBQPtK6Yky1vNtJU+D3P0= Message-Id: <6.2.5.6.2.20130228223223.0ad6c7f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 22:45:38 -0800 To: Andy Newton From: SM In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF03E0@CHAXCH01.corp.ari n.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF03E0@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 06:46:55 -0000 Hi Andy, At 15:11 28-02-2013, Andy Newton wrote: >If you need to separate the namespace for your registrars from your >contacts, do that with your identifiers. There's nothing stopping you from >prefixing "contact_" or "registrar_" or whatever prefix you see fit to >your registry unique identifiers if this is a necessity for you. The discussion is about identifiers. The above will be different conventions for identifiers. It will create a mess. It might cause internationalization issues. Regards, -sm From andy@arin.net Thu Feb 28 23:29: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 3D01421F8530 for ; Thu, 28 Feb 2013 23:29:59 -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 0oPIFVt3UKTl for ; Thu, 28 Feb 2013 23:29:58 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id B1E1621F8442 for ; Thu, 28 Feb 2013 23:29:58 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 619371656EB; Fri, 1 Mar 2013 02:29:58 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id E01D91656DD; Fri, 1 Mar 2013 02:29:57 -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 02:29:02 -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 02:29:44 -0500 From: Andy Newton To: SM Thread-Topic: [weirds] Entity "Objects" Thread-Index: Ac4VpSpYsI/bTeI7RJeUXSF9/NAbNQAECmOAABu3eIAAFG7BAP//qRdngADiEoA= Date: Fri, 1 Mar 2013 07:29:44 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF04A8@CHAXCH01.corp.arin.net> In-Reply-To: <6.2.5.6.2.20130228223223.0ad6c7f0@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 07:29:59 -0000 On 3/1/13 2:45 PM, "SM" wrote: >The discussion is about identifiers. The above will be different >conventions for identifiers. It will create a mess. It might cause >internationalization issues. Care to explain? -andy