From maarten.wullink@sidn.nl Wed May 1 06:43:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA321F9F2C for ; Wed, 1 May 2013 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MCewyV2AzIg for ; Wed, 1 May 2013 06:43:52 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id D6B0721F9F28 for ; Wed, 1 May 2013 06:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=Ebv/uqEhB0833li8Qn/8ay4QvclSmd5XL54cZg3TP+M=; b=rTI+zSVi+/TzWXgIfqVrsfnDjAjTQXi4oAs/Jib9FDnazJA4eiBROAxztJezwM7BNP7C9qknNXGSaTeOSVZPgbsziIuxsKbYKUIczpeLB2dGlorN8IKi/MU47ViTK2Rkd30yYb7S5dBQzMc/7u2REhboq7/Odc5IyNi5UMDfBBo= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r41DhoUA026865-r41DhoUC026865 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 1 May 2013 15:43:50 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 1 May 2013 15:43:50 +0200 Received: from [94.198.152.215] (94.198.152.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 1 May 2013 15:43:50 +0200 Message-ID: <51811C15.5080402@sidn.nl> Date: Wed, 1 May 2013 15:43:49 +0200 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "weirds@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.215] Subject: [weirds] vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 13:43:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When implementing http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 i noticed that in the example used in section 6.1 the "label" property is used together with a vcard version identifier value "4.0". The "label" property is no longer supported in version 4.0 of the vcard spec http://tools.ietf.org/html/rfc6350 It should be replaced by the "adr" property. "vCard" : [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Joe Bob, Inc." ], [ "fn", {}, "text", "Bobby Joe Shopping" ], [ "label", {}, "text", "123 Maple Ave\n", "Suite 90001\n", "Vancouver\n", "BC\n", "1239\n" ], [ "email", {}, "text", "joe at bob.com" ], [ "email", {}, "text", "bob at joe.com" ], [ "tel", { "type": "work" }, "uri", "tel:+1-958-555-4321" ], [ "tel", { "type": "work" }, "uri", "tel:+1-958-555-4322" ], [ "tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323" ], [ "tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324" ], ], The jcard draft http://tools.ietf.org/html/draft-kewisch-vcard-in-json-01#appendix-B.1.2 shows an example with the "adr" property. ["adr", { "type": "work" }, "text", ";Suite D2-630;2875 Laurier;Quebec;QC;G1V 2M2;Canada" ] Cheers, Maarten - -- Maarten Wullink MSc|Technical advisor / R&D engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05 maarten.wullink@sidn.nl | www.sidn.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRgRwVAAoJEHZPQ3qFDFN1YFAIAOCifj3x9bi1o1naJBnqlz90 xWULFvUqP4BBmI+n2fDEezXRvtl3a4CYnRTESo/ygTjcCDwD9jy9jtApILTyCNbT KCqGUXn/G9tRPJg5x4HE7F6QS6bePcI6fUEj/TZIYT8/uJfgf32q2uQfPZq1KxgC O3sPtppBIr72XyqbbdXwOiyRKjx9EMts3uw8IU2Zqj/2fzBv6fCo7lSKMwFgFziv pwaWJl5/vv7J2mG2UvrKu/+Cbl1X21czpNfSObAUUmR+qidYK/t+nWtB9SPUIL1r cmAUVPqnz3kLo7r9gGYtsEFcorgbjK/NLMM8nbSdWTNxVcxwkAZDYSnc98Nn5Pc= =Uibd -----END PGP SIGNATURE----- From simon.perreault@viagenie.ca Wed May 1 07:02: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 723D721F9D82 for ; Wed, 1 May 2013 07:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7dUkm++DAmU for ; Wed, 1 May 2013 07:02:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BE84C21F9D1D for ; Wed, 1 May 2013 07:02:39 -0700 (PDT) Received: from [192.168.0.14] (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E01C541594 for ; Wed, 1 May 2013 10:02:38 -0400 (EDT) Message-ID: <5181207D.3090502@viagenie.ca> Date: Wed, 01 May 2013 16:02:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: weirds@ietf.org References: <51811C15.5080402@sidn.nl> In-Reply-To: <51811C15.5080402@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 14:02:40 -0000 Le 2013-05-01 15:43, Maarten Wullink a écrit : > The "label" property is no longer supported in version 4.0 of the > vcard spec http://tools.ietf.org/html/rfc6350 It should be replaced by > the "adr" property. You're absolutely right. Sorry about that. Removing the LABEL property happened lated in the vCard 4 drafting process and I had totally forgot about it. The LABEL property was replaced by the LABEL parameter, which applies to the ADR property. The LABEL parameter has exactly the same functionality. What's important to WEIRDS is: - Structured addresses can be expressed using the ADR property. - Unstructured addresses can be expressed using the LABEL parameter on an ADR property. The ADR property value can be empty if there is no structured equivalent. - Addresses that have both structured and unstructured representations are expressed with an ADR property having a LABEL parameter. This will be important when the examples get updated to use structured and/or unstructured addresses. Simon From presnick@qti.qualcomm.com Wed May 1 09:04: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 2B8D221F988F; Wed, 1 May 2013 09:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssDb3ZkFPD0l; Wed, 1 May 2013 09:04:44 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 461D321F9801; Wed, 1 May 2013 09:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1367424284; x=1398960284; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=l/lZjz2W++dYE9wV+uZouU1v4GqwnPEUFKbYykNQfJk=; b=m7I5n5Peq/SV8zG6eaxDR4SsX8xZm/I7h7uqCutLA8Xt8SHNyCyhgHvQ VTHLWa9lLYaTYb4IHtFZRlIFkNUpwJfv7mC0pyE/+gPXzt/NVzenBUZ5h 3Vixview1Khh6v1bm9aDfcyKy2LCEyWVzLkjm63C7O7oIb6E1YYTe5/7r Y=; X-IronPort-AV: E=Sophos;i="4.87,589,1363158000"; d="scan'208";a="37658440" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 01 May 2013 09:04:43 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 May 2013 09:04:43 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 1 May 2013 09:04:43 -0700 Message-ID: <51813D18.3040604@qti.qualcomm.com> Date: Wed, 1 May 2013 11:04:40 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> In-Reply-To: <5181207D.3090502@viagenie.ca> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: weirds@ietf.org Subject: [weirds] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 16:04:48 -0000 JACARDCAL folks: Let's please make sure that the ADR example in the jcard document shows the use of the LABEL parameter, given that this is a requirement for the WEIRDS folks. WEIRDS folks: The jcard document is very close to done: https://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcard You folks giving it a sniff would be exceedingly useful. If there are open issues (other than the above, making sure that there is an example of the use of an unstructured address), please let us know. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From andy@arin.net Wed May 1 10:54:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE5621F9A65 for ; Wed, 1 May 2013 10:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AGMrIUe5ptU for ; Wed, 1 May 2013 10:54:06 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0B21F9977 for ; Wed, 1 May 2013 10:54:02 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 6BC232136B6; Wed, 1 May 2013 13:54:02 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id EB76C2136AF; Wed, 1 May 2013 13:53:59 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 1 May 2013 13:53:38 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 1 May 2013 13:53:52 -0400 From: Andy Newton To: "media-types@iana.org" Thread-Topic: registration of application/rdap+json Thread-Index: AQHORpTVrYPOwkBnGEmIpSQ1CMmXUA== Date: Wed, 1 May 2013 17:53:52 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0160B@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B9343CCEC9E7A428253CB20D2623140@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: [weirds] registration of application/rdap+json X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 17:54:11 -0000 All, The WEIRDS working has recently completed WGLC on a draft that registers the media type application/rdap+json. (Section 8.2 of http://tools.ietf.org/html/draft-ietf-weirds-using-http-04) It has been suggested that we need to add more information to our registration, specifically in the security considerations section. We are looking for guidance on this matter. The registration in the draft is as follows: This specification registers the "application/rdap+json" media type. Type name: application Subtype name: rdap+json 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 Intended usage: COMMON Restrictions on usage: none Author: Andy Newton Change controller: IETF Provisional Registration: Yes I have proposed the following changes to better meet the criteria needed for registration: Encoding considerations: The media described by this media-type is JSON. JSON supports Unicode. At a minimum, all servers offering this media must support be capable of serving it using UTF-8 encoding. Security considerations: See the Security Considerations specified in Section 6 of RFC 4627. Interoperability considerations: See draft-ietf-weirds-json-response. Additional information: This media type is a product of the IETF WEIRDS working group. The WEIRDS charter, information on the WEIRDS mailing list, and other documents produced by the WEIRDS working group can be found at https://datatracker.ietf.org/wg/weirds/ Guidance and help are appreciated. Does this registration meet the needs for an IANA media type registration? -andy From superuser@gmail.com Wed May 1 14:31:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A41B21F9B34 for ; Wed, 1 May 2013 14:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UnNOe597Onk for ; Wed, 1 May 2013 14:31:23 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6F21F9B2F for ; Wed, 1 May 2013 14:30:54 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1901514wiv.15 for ; Wed, 01 May 2013 14:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=k42AAt26O+Fqklardact07AO9/UfH2Act1J0nbUcxvg=; b=mE3Z5kmQQI3xDSzlxFqHqC8Z9MqQvfLCj2RfYuDFsk2ZVk4qoWGMBjGmDrRgGSX+f8 jgqtp+yb3+aTBCkdqzP5L2i6l1qcaxUQHaWNoGT5Gwixr64qTzBiFwBdpKStWM7LOiBe X3bbt/Fps6Eq42rhtFeMR7NjF+t0VKCmOBZEvuzfW0kPRGJ4XY6HBvAE28fZgEJEkKEb QPW/rPnl52J73679LnyMJd3wFvVLZPEML2y65eZZ90Z6jLc+6q+itQr65AipcFiVfm9I tZ3X7DkOglsFr4ujFfo/n09xXsfbm63r9BqD6+A7p4c8F/Lpm1+YVZzS1NawdKJc77r8 UG3g== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr6062270wic.32.1367443853396; Wed, 01 May 2013 14:30:53 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Wed, 1 May 2013 14:30:53 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0160B@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0160B@CHAXCH01.corp.arin.net> Date: Wed, 1 May 2013 14:30:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=f46d040fa04c21d11d04dbaed534 Cc: "media-types@iana.org" , "weirds@ietf.org Group" Subject: Re: [weirds] registration of application/rdap+json X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 21:31:23 -0000 --f46d040fa04c21d11d04dbaed534 Content-Type: text/plain; charset=ISO-8859-1 Looks good to me. You might also reference the Encoding Considerations in RFC4627 if they're applicable. On Wed, May 1, 2013 at 10:53 AM, Andy Newton wrote: > All, > > The WEIRDS working has recently completed WGLC on a draft that registers > the media type application/rdap+json. > (Section 8.2 of http://tools.ietf.org/html/draft-ietf-weirds-using-http-04 > ) > > It has been suggested that we need to add more information to our > registration, specifically in the security considerations section. We are > looking for guidance on this matter. > > The registration in the draft is as follows: > > This specification registers the "application/rdap+json" media type. > > Type name: application > > Subtype name: rdap+json > > 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 > > > Intended usage: COMMON > > Restrictions on usage: none > > Author: Andy Newton > > Change controller: IETF > > Provisional Registration: Yes > > > I have proposed the following changes to better meet the criteria needed > for registration: > > Encoding considerations: The media described by this media-type is > JSON. JSON supports Unicode. At a minimum, all servers offering this media > must support be capable of serving it using UTF-8 encoding. > > Security considerations: See the Security Considerations specified in > Section 6 of RFC 4627. > > Interoperability considerations: See draft-ietf-weirds-json-response. > > Additional information: This media type is a product of the IETF > WEIRDS working group. The WEIRDS charter, information on the WEIRDS > mailing list, and other documents produced by the WEIRDS working group can > be found at https://datatracker.ietf.org/wg/weirds/ > > > Guidance and help are appreciated. Does this registration meet the needs > for an IANA media type registration? > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --f46d040fa04c21d11d04dbaed534 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Looks good to me.=A0 You might also re= ference the Encoding Considerations in RFC4627 if they're applicable.


On Wed, May 1, 2013 at 10:53 AM, Andy Newton <andy@arin.net> wr= ote:
All,

The WEIRDS working has recently completed WGLC on a draft that registers the media type application/rdap+json.
(Section 8.2 of http://tools.ietf.org/html/draft-ietf-weirds-= using-http-04)

It has been suggested that we need to add more information to our
registration, specifically in the security considerations section. We are looking for guidance on this matter.

The registration in the draft is as follows:

This specification registers the "application/rdap+json" media ty= pe.

=A0 =A0Type name: application

=A0 =A0Subtype name: rdap+json

=A0 =A0Required parameters: n/a

=A0 =A0Encoding considerations: n/a

=A0 =A0Security considerations: n/a

=A0 =A0Interoperability considerations: n/a

=A0 =A0Published specification: [[ this document ]]

=A0 =A0Applications that use this media type: RDAP

=A0 =A0Additional information: n/a

=A0 =A0Person & email address to contact for further information: Andy = Newton
<andy@hxr.us>

=A0 =A0Intended usage: COMMON

=A0 =A0Restrictions on usage: none

=A0 =A0Author: Andy Newton

=A0 =A0Change controller: IETF

=A0 =A0Provisional Registration: Yes


I have proposed the following changes to better meet the criteria needed for registration:

=A0 =A0Encoding considerations: The media described by this media-type is JSON. JSON supports Unicode. At a minimum, all servers offering this media<= br> must support be capable of serving it using UTF-8 encoding.

=A0 =A0 Security considerations: See the Security Considerations specified = in
Section 6 of RFC 4627.

=A0 =A0 Interoperability considerations: See draft-ietf-weirds-json-respons= e.

=A0 =A0 Additional information: This media type is a product of the IETF WEIRDS working group. The WEIRDS charter, information on the WEIRDS
mailing list, and other documents produced by the WEIRDS working group can<= br> be found at https://datatracker.ietf.org/wg/weirds/


Guidance and help are appreciated. Does this registration meet the needs for an IANA media type registration?
-andy

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

--f46d040fa04c21d11d04dbaed534-- From derhoermi@gmx.net Wed May 1 13:25: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 C499721F9B48 for ; Wed, 1 May 2013 13:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QneBEOXAvaIA for ; Wed, 1 May 2013 13:25:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2121F9B37 for ; Wed, 1 May 2013 13:25:27 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lo3TK-1U59Sg2niy-00fxg3 for ; Wed, 01 May 2013 22:25:26 +0200 Received: (qmail invoked by alias); 01 May 2013 20:25:26 -0000 Received: from p5B231A2B.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.26.43] by mail.gmx.net (mp001) with SMTP; 01 May 2013 22:25:26 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+tnR4yDTitCYOkSqOG4YjJ+xJ6rRcGuLYxFXuL5T A4/+OyI1M4usKr From: Bjoern Hoehrmann To: Andy Newton Date: Wed, 01 May 2013 22:25:27 +0200 Message-ID: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0160B@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0160B@CHAXCH01.corp.arin.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 01 May 2013 14:34:54 -0700 Cc: "media-types@iana.org" , "weirds@ietf.org Group" Subject: Re: [weirds] [media-types] registration of application/rdap+json X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 20:25:42 -0000 * Andy Newton wrote: >The WEIRDS working has recently completed WGLC on a draft that registers >the media type application/rdap+json. >(Section 8.2 of http://tools.ietf.org/html/draft-ietf-weirds-using-http-04) > Applications that use this media type: RDAP This should give you some idea of the kind of application that would use the format (2D drawing application, music playback). At least say some- thing like "Implementations of the Registration Data Access Protocol [RDAP]" if that is accurate. > Provisional Registration: Yes If the draft is approved for publication as an RFC, I don't think it'd be quite right for the registration to be provisional, but I'd have to check RFC 6838. >I have proposed the following changes to better meet the criteria needed >for registration: > > Encoding considerations: The media described by this media-type is >JSON. JSON supports Unicode. At a minimum, all servers offering this media >must support be capable of serving it using UTF-8 encoding. This should simply reference RFC 6839, section 3.1. > Security considerations: See the Security Considerations specified in >Section 6 of RFC 4627. It's a good idea to point out that since the format is based on JSON that the Security Considerations for JSON also apply to this format, but this would at least need some assertion that the specific format does not have security considerations beyond that, or something else along those lines. > Interoperability considerations: See draft-ietf-weirds-json-response. Does that draft list known interoperability problems? If there are no known interoperability problems, it would be fine to say that. (I also note the lack of discussion of fragment identifiers.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From presnick@qti.qualcomm.com Wed May 1 15:28:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA221F9A8B; Wed, 1 May 2013 15:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYZH9iB4X1MR; Wed, 1 May 2013 15:27:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0190321F8B15; Wed, 1 May 2013 15:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1367447039; x=1398983039; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PikoQWQ+9cJ4JLFrTZzRqsJJkhbBMIhaAUa7v7smunM=; b=REUpKlpQTu2r5BcDx1ylaawm5Y0pGvNLGiVCU0hZ/sfgKOrBss6YW6Di T/IZRkDlWznGQMOEyMvr36UaEHJsblkKEIw68S+s+GKc7rWJhDkbQFZuL +q3uCOIZ4CRfpimcIXIs/p4oYRVnNeIAdBDg4tABa+A85Vvl/SsLliAwK E=; X-IronPort-AV: E=Sophos;i="4.87,591,1363158000"; d="scan'208";a="43426369" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 01 May 2013 15:23:58 -0700 X-IronPort-AV: E=Sophos;i="4.87,591,1363158000"; d="scan'208";a="477217733" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 May 2013 15:23:58 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 1 May 2013 15:23:58 -0700 Message-ID: <518195FB.8090204@qti.qualcomm.com> Date: Wed, 1 May 2013 17:23:55 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Philipp Kewisch References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> In-Reply-To: <518193E7.2090008@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: jcardcal@ietf.org, weirds@ietf.org Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 22:28:02 -0000 On 5/1/13 5:15 PM, Philipp Kewisch wrote: > If this is a requirement I'm happy to comply, but since those examples > are not about the ADR property but rather about the structured value > it uses, I think the "label" parameter is just additional clutter. Or > is label becoming mandatory? Oh, no, if I gave that impression, I apologize. The *ability* to have an unstructured (i.e., label) form of the address is a requirement for WEIRDS, and since we are writing a document at this break-neck speed for their benefit, I think it would be a good thing to show them an example of how one does that in the document. But this is not some sort of protocol requirement. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From zhoulinlin@cnnic.cn Wed May 1 22:56:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF43021F8A4E for ; Wed, 1 May 2013 22:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba4sVRy0R-lj for ; Wed, 1 May 2013 22:56:06 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id DC30121F89D5 for ; Wed, 1 May 2013 22:56:02 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 02 May 2013 13:55:54 +0800 From: "Linlin Zhou" To: "'Murray S. Kucherawy'" , References: In-Reply-To: Date: Thu, 2 May 2013 13:55:52 +0800 Message-ID: <00d801ce46f9$b5158310$1f408930$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01CE473C.C338C310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5FUCYl3H6BXppSQJ6Y3dNfKzJ7qwBp7IMQ Content-Language: zh-cn Cc: 'shenshuo' Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 May 2013 05:56:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01CE473C.C338C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since the response draft has a reference of the inventory draft, I suggest to complete it before the response draft. Maybe July or August is appropriate. Regards, Linlin From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, April 30, 2013 11:09 AM To: weirds@ietf.org Subject: [weirds] Milestone for draft-ietf-weirds-object-inventory Hi there, Now that we have adopted the above draft as a WG document, we need to add it to our charter with a projected milestone. Could someone suggest a month by which we could reasonably commit to being done with it? -MSK ------=_NextPart_000_00D9_01CE473C.C338C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since the = response draft has a reference of the inventory draft, I suggest to = complete it before the response draft. Maybe July or August is = appropriate.

 =

Regards,

Linlin=

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Tuesday, April 30, 2013 11:09 = AM
To: weirds@ietf.org
Subject: [weirds] Milestone = for = draft-ietf-weirds-object-inventory

 

Hi there,

Now = that we have adopted the above draft as a WG document, we need to add it = to our charter with a projected milestone.  Could someone suggest a = month by which we could reasonably commit to being done with = it?

-MSK

------=_NextPart_000_00D9_01CE473C.C338C310-- From simon.perreault@viagenie.ca Thu May 2 01:25: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 9688921F85ED; Thu, 2 May 2013 01:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8-sjUoG01Ly; Thu, 2 May 2013 01:25:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B521F8526; Thu, 2 May 2013 01:25:33 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 716FE4135B; Thu, 2 May 2013 04:25:31 -0400 (EDT) Message-ID: <518222FC.1090909@viagenie.ca> Date: Thu, 02 May 2013 10:25:32 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: jcardcal@ietf.org, "weirds@ietf.org" References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 May 2013 08:25:33 -0000 (Re-sending to include WEIRDS.) Le 2013-05-02 02:38, Michael Angstadt a écrit : > @Philipp: The first two components of the ADR property are for storing > a post office box and an "extended" address (such as a suite or > apartment number). In the second example, it might be good to > populate these fields with values that will make this more obvious. Sorry, no. RFC 6350 section 6.3.1 says: Experience with vCard 3 has shown that the first two components (post office box and extended address) are plagued with many interoperability issues. To ensure maximal interoperability, their values SHOULD be empty. Why not just translate the example from vCard into jCard? ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. ["adr", { "geo": "geo:12.3457,78.910", "label": "Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\nU.S.A." }, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] } > @Pete: The syntax of the jCards in your examples aren't *quite* > correct. The first element of the jCard array is the string "vcard". > The second element is an array which contains all of the property > arrays. The "vcard" string is redundant in this context, since the > object field already uses this name, but I am just thinking that > parsers might have trouble parsing the jCard without it. The examples > should look like this: > > { > "handle" : "XXXX", > "vCard" : > [ > "vcard", > [ > [ "version", {}, "text", "4.0" ], > [ "fn", {}, "text", "Joe Bob, Inc." ], > ... > ] > ] Right. Mea culpa again. Simon _______________________________________________ jcardcal mailing list jcardcal@ietf.org https://www.ietf.org/mailman/listinfo/jcardcal From kewisch@gmail.com Wed May 1 15:15:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6E121F9B0E; Wed, 1 May 2013 15:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYgnTDgN0d0a; Wed, 1 May 2013 15:15:09 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D290321F9AAD; Wed, 1 May 2013 15:15:05 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id y7so817177bkt.10 for ; Wed, 01 May 2013 15:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=5TZSXoXCOKZQoamAww4bd7JR2gVccECjHylvVfwyMQI=; b=IlN3lcHoT8YbdcLKbkPIH3vZYhf8RYnssj8oG7ZlxTLJ42pmg5lz3r0vaJgBNHXU8G nu5hscrX/AY6/XCP4G22LJQBVOcRp1/LJnUsB34msmooespD7cAfzFPXw7c5/qX0b7r2 m6FTe8m9YMIQD54bWk1S7fcCYWKC2opPETp3PdK/0WHx2EB1RZgQdSEp+JSfymHxT5EG QNRePlu3mivjmUzpbqiG4nk+U6U68vli+VGWPlF5LGPnwoPs5iJutBPFn528f9+aT7e9 1Y/kz7Y+52bTmkpfDe4AMp0WFCxStU9NTDOVQKYsJYNw9EWL6apEjJGOvfV4WETAwag7 oT3Q== X-Received: by 10.205.36.138 with SMTP id ta10mr413654bkb.4.1367446504902; Wed, 01 May 2013 15:15:04 -0700 (PDT) Received: from oskar.fritz.box (e177103240.adsl.alicedsl.de. [85.177.103.240]) by mx.google.com with ESMTPSA id 2sm755093bki.19.2013.05.01.15.15.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 15:15:04 -0700 (PDT) Message-ID: <518193E7.2090008@gmail.com> Date: Thu, 02 May 2013 00:15:03 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Pete Resnick , jcardcal@ietf.org References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> In-Reply-To: <51813D18.3040604@qti.qualcomm.com> Content-Type: multipart/alternative; boundary="------------080203050600030100020404" X-Mailman-Approved-At: Thu, 02 May 2013 09:49:40 -0700 Cc: weirds@ietf.org Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 May 2013 22:15:10 -0000 This is a multi-part message in MIME format. --------------080203050600030100020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, I see you already noticed the issue with LABEL property vs parameter. I've changed the example for structured values to: ["adr", { "label": "123 Main Street\n Any Town\n CA\n 91921-1234\n U.S.A" }, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] and: ["adr", { "label": "My Street, Left Side, Second Shack\nHometown\nPA\n18252\nU.S.A" }, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] If this is a requirement I'm happy to comply, but since those examples are not about the ADR property but rather about the structured value it uses, I think the "label" parameter is just additional clutter. Or is label becoming mandatory? Philipp On 5/1/13 6:04 PM, Pete Resnick wrote: > JACARDCAL folks: > > Let's please make sure that the ADR example in the jcard document > shows the use of the LABEL parameter, given that this is a requirement > for the WEIRDS folks. > > WEIRDS folks: > > The jcard document is very close to done: > > https://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcard > > > You folks giving it a sniff would be exceedingly useful. If there are > open issues (other than the above, making sure that there is an > example of the use of an unstructured address), please let us know. > > pr > --------------080203050600030100020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ok, I see you already noticed the issue with LABEL property vs parameter. I've changed the example for structured values to:

["adr",
 { "label": "123 Main Street\n Any Town\n CA\n 91921-1234\n U.S.A" },
 "text",
 [
  "", "", "123 Main Street",
  "Any Town", "CA", "91921-1234", "U.S.A."
 ]
]

and:

["adr",
 { "label": "My Street, Left Side, Second Shack\nHometown\nPA\n18252\nU.S.A" },
 "text",
 [
  "", "",
  ["My Street", "Left Side", "Second Shack"],
  "Hometown", "PA", "18252", "U.S.A."
 ]
]

If this is a requirement I'm happy to comply, but since those examples are not about the ADR property but rather about the structured value it uses, I think the "label" parameter is just additional clutter. Or is label becoming mandatory?

Philipp


On 5/1/13 6:04 PM, Pete Resnick wrote:
JACARDCAL folks:

Let's please make sure that the ADR example in the jcard document shows the use of the LABEL parameter, given that this is a requirement for the WEIRDS folks.

WEIRDS folks:

The jcard document is very close to done:

https://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcard


You folks giving it a sniff would be exceedingly useful. If there are open issues (other than the above, making sure that there is an example of the use of an unstructured address), please let us know.

pr


--------------080203050600030100020404-- From mike.angstadt@gmail.com Wed May 1 17:38: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 DDE6421F9ADD; Wed, 1 May 2013 17:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3mEowkFwx27; Wed, 1 May 2013 17:38:21 -0700 (PDT) Received: from mail-da0-x22b.google.com (mail-da0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5E621F9AD9; Wed, 1 May 2013 17:38:21 -0700 (PDT) Received: by mail-da0-f43.google.com with SMTP id u7so38735dae.2 for ; Wed, 01 May 2013 17:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gJ8/XX8a8fv9WctUG57uwGmE3FEGN/ppQrq0i2zQdbo=; b=oetLaB0LWzPuS2ooNLxmku5Zc/lyFXDhF2Ky0zYUJsL9F8vVw1DBAb8f/4zVMI8SZW J6GZyIvQB6qivpuG96WbPKeE/o0xdr/YQYIsteeyuioRkhV4w/fih5AUCGH/ec4beKKU PEYeezGZSUC7MCgQv9F+Z25L1hEp/YK+4AoTuhUqSRKRX/cBYBrsSO51MX/bxIc0E6pX +CH3Q/OTGVndjG5/fGKMqV4n6WgIjPax24Ns+2WGfaDMHidBRNlOq5KydlYXrEuDa03r YEtgu+HSdGZaS4CW11xbvtDG+VmJPo4iNLaCYkAmGZ63xtD/C68rpIjXluwEPQzbFE4O l0jg== MIME-Version: 1.0 X-Received: by 10.69.3.4 with SMTP id bs4mr6527930pbd.5.1367455100905; Wed, 01 May 2013 17:38:20 -0700 (PDT) Received: by 10.68.125.201 with HTTP; Wed, 1 May 2013 17:38:20 -0700 (PDT) In-Reply-To: <518195FB.8090204@qti.qualcomm.com> References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> Date: Wed, 1 May 2013 20:38:20 -0400 Message-ID: From: Michael Angstadt To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 02 May 2013 09:49:50 -0700 Cc: Philipp Kewisch , "jcardcal@ietf.org" , weirds@ietf.org Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 May 2013 00:38:22 -0000 @Philipp: The first two components of the ADR property are for storing a post office box and an "extended" address (such as a suite or apartment number). In the second example, it might be good to populate these fields with values that will make this more obvious. Also, in the label, maybe remove the newlines between the town/state and state/zip-code so that it more closely resembles a mailing label. For example: ["adr", { "label": "P.O. Box 123\nSuite 456\nSecond Shack\nHometown, PA 18252\nU.S.A" }, "text", [ "P.O. Box 123", "Suite 456", "Second Shack", "Hometown", "PA", "18252", "U.S.A." ] ] @Pete: The syntax of the jCards in your examples aren't *quite* correct. The first element of the jCard array is the string "vcard". The second element is an array which contains all of the property arrays. The "vcard" string is redundant in this context, since the object field already uses this name, but I am just thinking that parsers might have trouble parsing the jCard without it. The examples should look like this: { "handle" : "XXXX", "vCard" : [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Joe Bob, Inc." ], ... ] ] Thanks, Mike On Wed, May 1, 2013 at 6:23 PM, Pete Resnick wrote: > On 5/1/13 5:15 PM, Philipp Kewisch wrote: > >> If this is a requirement I'm happy to comply, but since those examples are >> not about the ADR property but rather about the structured value it uses, I >> think the "label" parameter is just additional clutter. Or is label becoming >> mandatory? > > > Oh, no, if I gave that impression, I apologize. The *ability* to have an > unstructured (i.e., label) form of the address is a requirement for WEIRDS, > and since we are writing a document at this break-neck speed for their > benefit, I think it would be a good thing to show them an example of how one > does that in the document. But this is not some sort of protocol > requirement. > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > jcardcal mailing list > jcardcal@ietf.org > https://www.ietf.org/mailman/listinfo/jcardcal From mike.angstadt@gmail.com Thu May 2 05:22: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 9087821F84B7; Thu, 2 May 2013 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjxjxANMUFsX; Thu, 2 May 2013 05:22:21 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F221F99B9; Thu, 2 May 2013 05:22:20 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p11so326391pdj.26 for ; Thu, 02 May 2013 05:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wZKRAc1AOhQhBtX26xyjS8IBxpamlTiS/lX8aykhFzQ=; b=PWsSj/dK5m26dOO87T1/0DSHXqO/JVo3ARj/mO+2S5soim3iTrlk8+XdCy1MF7tpaC 6z7xYPp8bNwD1xrK4l2PgOgR5tMpLBhWvuw/+MJQu8I126KetW1UwwQiz0jdjGoPCw/f JX7PlxjrI9GFg77KncHR/FG7kuz3gL5koBAPCDZ/46UpyCUxCeXzjirN0SkC1rvne4/q hLhOJ/wE7KaJZPVxJHYQNZD4aOP2xqxDFLoVnnxRvBPogpSZgbcljX5HV9FRCyKLvcX3 mt0FHgDL07Tl6lp9YiPMRoqMjhholsWnMJkpUfMiFhvDUN5oZA3L5ghxp0gGkglX3hUc A8iA== MIME-Version: 1.0 X-Received: by 10.66.181.208 with SMTP id dy16mr9554137pac.5.1367497340657; Thu, 02 May 2013 05:22:20 -0700 (PDT) Received: by 10.68.125.201 with HTTP; Thu, 2 May 2013 05:22:20 -0700 (PDT) In-Reply-To: <518222FC.1090909@viagenie.ca> References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> <518222FC.1090909@viagenie.ca> Date: Thu, 2 May 2013 08:22:20 -0400 Message-ID: From: Michael Angstadt To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 02 May 2013 09:49:58 -0700 Cc: "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 May 2013 12:22:25 -0000 On Thu, May 2, 2013 at 4:25 AM, Simon Perreault wrote: > Sorry, no. RFC 6350 section 6.3.1 says: > > Experience with vCard 3 has shown that the first two components > (post office box and extended address) are plagued with many > interoperability issues. To ensure maximal interoperability, > their values SHOULD be empty. Ahem, I do believe that the wording here is "SHOULD" not "MUST". Also, if I may refer you to the paragraph above (asterisks added for emphasis): Quoting RFC 6350, section 6.3.1, page 33: Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position. The structured type value corresponds, in sequence, to ** the post office box; ** ** the extended address (e.g., apartment or suite number); ** the street address; the locality (e.g., city); the region (e.g., state or province); the postal code; the country name (full name in the language specified in Section 5.1). From johnl@taugh.com Thu May 2 18:06: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 86A1E21F8EBB for ; Thu, 2 May 2013 18:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ4U-Jba12Ta for ; Thu, 2 May 2013 18:06:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9D721F8EAF for ; Thu, 2 May 2013 18:06:22 -0700 (PDT) Received: (qmail 73603 invoked from network); 3 May 2013 01:06:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=11f82.51830d8c.k1305; bh=j0ergwMJaJxOOvZcjWhsvQTU5Gm9UatwrdOqDErcQf0=; b=l4TKFG0nigxv4dW1GkztXP/9zj999kH5800Do/RbMdz/yd79Co2HG7+8PiMy+ZoHQe7TG7Bu9R4LLNcNZwfG5F33Y02fnYYuK+8BHCVb6VV2dLNq1TS93PVoh2rqSLlKVMak4yxENT0uNPNUornTZMT5ByCGqcBEhSNuItx7fYc= 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:user-agent:cleverness; s=11f82.51830d8c.k1305; bh=j0ergwMJaJxOOvZcjWhsvQTU5Gm9UatwrdOqDErcQf0=; b=WYep7gP1HIwExFWdLdmtAXvBXHuObKEP0UxkLiav3Vc6vCrQW8+vtci66X4hasJcZCz0Hr1N7H5CG4w3DDzEpOxefk1M0SgwkPVLtvFfJL2/L3jQyxNGGhO07w0Iood8mdnJQrH91IjvOoQqBIlm1iveIo8tbtGabSF6IvC+Dto= Received: (ofmipd 127.0.0.1); 3 May 2013 01:05:58 -0000 Date: 2 May 2013 21:06:20 -0400 Message-ID: From: "John R Levine" To: weirds@ietf.org In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-984506013-1367543180=:66619" Subject: [weirds] Inventory of existing WHOIS 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: Fri, 03 May 2013 01:06:24 -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-984506013-1367543180=:66619 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Steve Sheng and I took a look at existing WHOIS search features. We didn't find much. The three large gTLD registry operators, Verisign, Afilias, and Neustar offer simple minded searches described in the attached PDF. I looked at a bunch of ccTLDs, and other than a few operated by those three registries, found no search features at all. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-984506013-1367543180=:66619 Content-Type: APPLICATION/PDF; name=1MaySearchTLDs.pdf Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=1MaySearchTLDs.pdf JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0Zp bHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nNVZW4vbRhR+968Q9C1gWzMj aSQwAvkWUhJoEkMfSh+WbLLZNrvbOFv693suc9WMZJf0ocVgdJk51+/cRuVK FH8t1sP5+f7TzYfnYvtmt/halPBrhCx0J4vzx8XPL4rHxQHerN8/3zze3pxv N5v1m92rfVH2/XZvd5TF+W6xPS2Ealaq0KVetcXptlgfRQG0Tp9+2ZSiV5tS 9kv4V3hZlTXdNP2y2sB1vSl1v5Sbsu3hr8MlQy825Xa8akcP9j3cH2jDEZaJ EtfSKiFwFV9KfKrxnskgbaFwl6jov7bMBGxocRtesiSw0AlF8tBu7dYxeyIh WlpFu3WyGx6xOJ3fMPRLYSiyJFsW4tfTj4vDafE2b3SRM7pU9aoumk6xyaU3 Odi7QXOjbBVqWpMZG5IMmAtUDJ/QS21eD3y7JQlrVHRHl3u8NNvs2p1noHnb 4YIKMqtC3QAaG93C/0gJ9C7iBn3MTAVCiVyLrhRmCb9iRXptFIMtpAbY3CqD jkYvXRBTZcXUEsVs1GpsawCAIv9WhstAXLYMTSfOzohJq9Ge4oB/xwvCVDlh uhJlEe1Kj0OtQoZ7AjxDdNebqBP0FJgKZIom4RCqOCb3F+SoJ+Wo225sEQr4 AHV7FqK2trAuwXdbhBE5WZZSwB5JNxZTuFUqCjwybgRXLatykIT0CMwBfg3r pd8F3Bu8GSBGSvMKl8LNQF4DkkzeOK5vLXkixpc6wJVsApQqq54NF4F0d4E0 vBY5ScgRDULDrTXrWAG2CptjCDRkBrKFtfNOa6adVncpkFUY0cbCiKchsBNa hNY1+EB2BCpvimtcAoaHZQMTA9K4mLWUyrA1m9j55hkug52EWnqoQhbWB+aN 8yBcbi0J2YI26OYxqmRr+AtnXZDQg9ESbdmB6Kt4NyDJrbH49Q/KWLQ2YBM7 MXZULTpI7qmnkOvpt9wOdm1Vwbb5VErZfIjgbxIqFgj2qrWaDzl4RhWY5Edg y30/E2eCkyHQO9A95cUginm1h0qUFnykhBGhTSUC1gnE+mW3CVGx72NkDix2 IKi1RxDcQxjjYbmzItdWqlhkH/VAj/cB1iD/xwH6+v7xdxucOhecdSlWDbiw g3/jQo0uh7xtXZ6N9DZPrAbopHhg185BSAb8LYQiD5vkPoOI2Mc5i8ljCL8Z SCSmBT4cipAvfWJR2Ahy30fJSQlH3cOpjLxFeUC4lgekX+o5ELnUTsUDC0OQ F+MConzhj4qHcrXDpaWm7yIoQ7kQu0AWk8wGW7m2kxlD5r13KWOIyjbt3t3s M+fnTICzMmHypbDkahWE0YiS6YzM46ATtSHuPcqKT2eZIGtxMap81tpapDjZ MPlLn2K4OUNX7lwqD8R2bUiCcgrsTBsQ5yxb26zugZedmXI6TbiWHFV13Spp tr6vnSHjQmFkC8y3E91kO1HpciXHvSgNeRAldk7bcb9rOhtlJikeBXd9FfWt 0WRHlhduYlvaGY9qgKGoTEVXWHeWkt8xRRaB2+HgHTcSFRK2T5fUGzuazKTu aW6KTXO8v/vz/NHNZmYiflt8LbqyqEQJnbmu4cIN0l/xHq0Gz9ySDw+L9asH qYr9UzE19glPOjegj4bwpkZvEPFRPNds7Fk1pOcFgyvUDqYkJNAMWeID0kVG 64w6ek4d9U/UIWypWqStKmZ5Jc00DalfKTv6S1MCaHClLvPCXD09YSkpkjJ4 oXWZrWqjIgg1LOgU3BvX1hzc8A5zgp3XRGk3c/0JZwQKc1XlHP36/tvzD7L8 6eZ8c3e++eOz0356rpOdSJPNgRrYqSQlyja7caOm6o8QEpqTHKtwMExHoOlE KWo1IbxsuPGG4jq5uemmxLEZnbiTU3xjT/+quYy17EAmJJ6AgHQ2hTqmSmNb o93RgoGE6YInynKg5tSQdFWdNro16ZyedYeaNQ6V5cDoItBf0YST0z8J89Yc r7lgC9Wg8ncl7LPNN8NeyWR8okObi7BPNl6EfYbVd8I+Q/F62OfEycD+GqBn 5xED9FIm3eb/BuhJu8cSIXkruwxOTg7mBDmKEy4KwVAQzxDe0jMxU4kOCm7W lFgITbh0ZAMKFz+Nc5E07JL4Wc7zpRARrU7zI4ktw9PiYEgwbnRztGlFjeOC YSw4HHNH0sHmzh6eTnSsk/E+3bqKuk3zzvGKeE83Xor3HCsz8dlpw3TzwaQ7 gXUPRlOTVXNVDy/zH28oMoVskwRwOTLD/OLmqFwo+vkrG43LJglHlTHP+CQA m6fk4MhHpYWONIdeB3cKHcdzDM04LlNzp8YehafU1Ddn7EmzBgViLjzNBy85 Vd6uCk+h0vb/PxGex6en58enZzdwyOxHLVJCdz6zjU/ARssVrNTVSOWZI48G nJKsz35uoiRuDrSt3nRaHx0J/iujgPtQZL/BDTAeWGEOjgp3QGqAmVSpxL7R B13W+d3LhVMe5s4Wy8bDQnQtX34p8LLD6f0LzqX+yrz+vNi+IOI4sa0PL983 ZXH3rVifznXHc97fK2OjLgplbmRzdHJlYW0KZW5kb2JqCgozIDAgb2JqCjE4 ODAKZW5kb2JqCgoyNyAwIG9iago8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9J bWFnZS9XaWR0aCAxMjEvSGVpZ2h0IDQyL0JpdHNQZXJDb21wb25lbnQgOC9M ZW5ndGggNjEgMCBSCi9GaWx0ZXIvRmxhdGVEZWNvZGUvQ29sb3JTcGFjZS9E ZXZpY2VSR0IKPj4Kc3RyZWFtCnic7VpdKLtfHN/Ffsm8szUxTSPJBbLEmtTK DU1KSZEk8hKRl4gkLry0XAl3iwtEXm6sFEXiQrtAeWuTQumvlkJDQ/b/5uT0 /M6zPf9nz55t9udzsT7ne87zfD/n+5z3Hbv9Fz8UIyMj9fX1vlbxI6BSqRYX F32t4kdAIBD4WoLHERUVxZAr+MTS0hJOms1mICKRSKvVIsvLy8vJyQmQzc1N 4sGamhqcjImJQSQkJAQXgzcLvsAsg2P1vg1YVhCRoaEhxDMyMpD96Ohoe3vb YDA4LI/JwsIC4qurq9Tcvr6+yspKNkrm5+f1er1rdftOMJlMqampznKp4Xp7 e6PaPz4+cDI6Orq/v5/6CDVoDjmd7O7uajQaZrV+3bC59VnCTg8mtsCiIjk5 GXG5XH5+fg7k8PBQrVYTz7IJ408INdGki4qKjEYjvRidNDU1wS/qAkQu1fjw 8PDDQ63T6dBsBQMyJN/f36nhwv0dcaFQiIoBYPoDY2tra3t7OxCLxUL1pVAo gL++vtq/pk4qYVY7MzPDubK+hfvtpLGx0WuzFahta2vzji/e4X6ovdmpwVdL S4vX3PELEG+1Wt15wz+f4EsPM0DtxsaGd3zxDhBfVlbmaxVs4e/Toh/p9yOp dFRXV/uRfodSY2NjvSZAJBKNj4+z0eCwpPuhhi1zXV0dQ4GBgYGtrS375/a8 q6uLmxfYThJSYdxm9ushUGUwa2DY63H2m5OTw1IbZ3fwQflVzvkN7KvDo2D4 ppmZmTxqY4DNZnNVuVKp5OaLGd4PtVqtJg4/xWIx5tDOJyYmCBcmkyklJYWb O7rU7u7u6elpogDWk5SURE3Cb1xcHCLohA0IGmMnJydRmdzcXMLF8vIyUUdC Bl2DM8G8jB4OLZjAul0ikSAeEBDAoztnSTqZnZ1Fyb29PVweZi58tgNZCoUC SH5+/uDgIDJ2dnbCXpjui0OrxocbnMEm1JGRkc/Pz2yEueqReBt8UIZv8fHx wZBLl03l6+vr1ANebgMIv60aGnB8fDyR5Tl3DQ0NxH+RBwcHuEx2dvbOzg7O kslk6AjX4duY1TJ8I7oGBsGcqw91GRsbo1oSEhKgskASExPT0tIYxHMDg3Jw TRj/s5osQ22xWNh0B0Bvby97wS6B/uDp6SkYw8LCUC76J4s6pwDB47arYF6B AI+IiNBqtVKpFFkKCgrAGBwc7EwtWGBwAwKDA24zhFo8pTL4dcgdWngMtUdB X1dfXl6yWWpyA9VXUFCQs6yrqysGDbyE+uzsTKVScXiQM+i7RYTa2lrefT09 PdH/kgMUFhbe39+z0UAvWVVVxSHUZrMZxLj6lPvwcj/S6XR3d3d8vY1YnH9z +JFUOkB8eXm5r1Wwhb+H2idDATeAWthN+FoFR/hXOwG1zc3NvlbBEX4X6vb2 dl+r4Agi1Hq9Hk2UsB1AuSKRiCiJxpz9/X0g+CaeXC7HufgOJNo+EDMvvgwp FArxIy8vL7B6RMXy8vLomwicnJub4zsGXoKzNbZSqcRhpGYdHR1BkFdWVrAR HSWhXPzIxcUFIunp6dSX0C9DwgbTaDSic8iOjg6U9efPH3TZ1Wq1FhcXO1Pr XxB83TLCyZKSEpx8fHykNldEoMGPjo4Cub6+ZnlKQyewycrKykI8NDR0eHiY qur4+Bj55Wtj+x0AOxqZTEa1pKSk4Brh42WNRlNaWoo4zsVjS09PD7oMbKfc gbTZbGKxmHiE+dNQgYy4CzCU9COwaYSoFzu85YgJkSuRSG5vb4FAF8DLBpQL nYVNqAl7d3f34eGhGxX9FsDnVzAlSaXStbU1ZA8MDASjwWCAVi34umJNDzUM rQyfCeIDfGpqyv73WZnDFk5IwoDvGB4ezlN1f/EXKioqfC3hf46bmxtY3uBZ 4BeeA0ymvpbgEfwL5fUUOAplbmRzdHJlYW0KZW5kb2JqCgo2MSAwIG9iagox NDM3CmVuZG9iagoKMjMgMCBvYmoKPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUv SW1hZ2UvV2lkdGggNzUvSGVpZ2h0IDQxL0JpdHNQZXJDb21wb25lbnQgOC9M ZW5ndGggNjIgMCBSCi9GaWx0ZXIvRmxhdGVEZWNvZGUvQ29sb3JTcGFjZS9E ZXZpY2VSR0IKPj4Kc3RyZWFtCnic5VlLKHVRFL4DUogrj4FISVJyQyF5xFAZ KSVCIqVEXgN3YMRloDzymBADiRIDZcDAxMgARSQZkIEyQS6R7P/r7v7Vts85 +557Xf/l/Gugb6+99trr287Z1ucw9iWbm5vr6+v7Wo6fbjab7Ycn/KL9tHqM LDY21qd4m8fy8/O7u7vJGRISAmdRURHFuN3ug4MDgNXVVe5JSUmh+LW1NZ4H CzE8OTmh45qZmeG4tLTU1zPUxvudQVwoOY+Pj0FtfX2dnM/Pz2LYwMBAY2Oj OmFqaipARUXF0NCQ+fJWVlbm5+dpeH5+7nA4zC+fmJiorKyU6pmdnY2Pj5ec MTExo6OjANfX11oKBK6urgoKCnQJap0mTTfPV9YCfHx8GBUWHh7OgdPpdLlc RmGK5D5VqMjp01q73U6VqwuTAD8Kjh8fH2m2oaFhampKkcePIv1Yzp83fi0A FBcXU56amho109DQUNHJMYGdnR2Azc1N4PLy8snJSSnSJ4JLS0v+EfwVBlJ0 vVuVYGdnJ+Gnp6fg1hNwAyk88IRra2uDW0/ATboKrPeUioyam5utTVA7/O22 t7dnbYLoRY0IKnp4/qq2tLTQMDExkYPIyEimeZfv7+8lj+2vkQcSBsPo6Gjg 6elpPoU/8RyIvwiA9PR0jltbW8U8AC8vL2dnZ+R5fX1V/AZ1e3ipJyHtc3l5 yUF2drYYhm4kKyuLl93W1gYQERHBp8Qj0oKEhASAvLw8cerw8JAwfr6/v9Pw 9PR0f39/cXERuLe314iRLlk/mmEJvL29kefm5kZcOz4+zns8HKbY7LHPRh70 h6JneXmZpqKiooaHh40WAkC4mSQ4MjKSkZHBMXTrxcUF8zwPcXFxijNRJ9ed NYqHUispKfG6Sr2XgmB7ezv7rAVgkIG3t7cAkH4dHR3SkurqajH57u5ufX29 tOnDw4OaIPk3Njbw4nCcmZmpIGhESreHx2UC0NXV1dPTA3B3d6dL/+joCHhh YYF5BKB4D+DYgXE+2juHv6rS1mIMly3SKsUrpiZoDVPfohYwxd9Ba5jUyTQ1 NVmMIPvP1ARwXV1dEIv5DpMIut3uIBbzHQZS29vbhL9vI5fLlZub+335jQyk tF3HvzcSCAE3kEJbQlgdDDVELRMFa9UQLC0tDR4ugpjnX/fa28wmaCIa6m4h fZphespIQRANuUmCTBB9ZWVlTE8NiXkgnXjDKToVckl3C+2nGSNlZFSwiKFr zMfTUFRDYoyuU5JLRjm1Q/HTjK4y8lowHrakpCTz8doh83xdysnJkWbhwZkb LTRJ0Gtf7V/Bojkcjq2tLd14UkODg4OFhYUAycnJUm301YkJcmlsbKyqqop5 +kbFFuKnGfME+/v7IW0kp2KtdkpSQxRGF4XkUcgloy3EbIowreE87Xa71zCf DM8hvRoQpHjmA5s/6BYWFkbYem0tN1ySTqcz2FXo2B8u2xwOCmVuZHN0cmVh bQplbmRvYmoKCjYyIDAgb2JqCjEwOTcKZW5kb2JqCgo1OSAwIG9iago8PC9U eXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTU4IDM5NSA2NzEg Mzk1LjEgXQovTGVuZ3RoIDgKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9iagoKNjAgMCBvYmoKPDwvQ0Eg MS4wL2NhIDEuMAo+PgplbmRvYmoKCjY0IDAgb2JqCjw8L0xlbmd0aCA2NSAw IFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczVnbihtHEH3XVwzk LTBSd/VcQQzotsEhhhgL8hDysHjtzQbsZOUN+f1UVXfP9FUzcmwIC2LVM11d derUrSXWsvhntdldXp4+3L97KfavD6vnQuBfI6Foeygu71e/fF98Wp3wyean p88v34H4+f5y/3i5/+v37Xbz+vDqWIhh2B/tTlFcHlf786oXKLwV7borzg/F 5g4KFHn+8OtW7Qe1hW747fzj6nRevQn2SdElN25VPZz/SO6QsK6TR0kxtFvR itNQwlb0eK6sh1JuxZH+FWKHL5T9VtSkUQNygK08yAN+L6slm6FTzVB2JGC0 hpF6+3L/6eH+8mARkimEJDRoadOSvQFELR6BH6gF62Z0aPnoUFujgCIdaUOF 69AIIF3ZBuB/xU7v1i/ppWooG7OXF3BbrY0js2vzcmS2WeB9LFOxenSA1RgY QtEShBZAq5yzXdJ388iRtBT/GP3nQjoIV1UGX4nGyd1QIso946T4U5LkHRne GD0ygpncTaPWKpDsYQ1C2wNKY8XGwmgD2qZRcuwPQDFs9Ew3nt1PvnOBlwzU UYfYEmpCNngb2a1bbZ+09pHGZBhpeDegGgc67o6VA3qEyCnzljgMbFY5Eph3 CPzgt5DBkgzTxmrQK4ugIrkHZvoktiP27LWVpRRGjOVyaw6DdjACCAL/NVCj /vwwJcLH6+7p8e/Le4uW0mi9KZ6LXhR11awBGVbU9Zgpn+k7IYlr4yvvPq42 rz62fXH8s8j4oZokpxJwkDrqFh2kZfsE1IwIne4bUU9HyQaQw1qQrKFQlXMi LdCZuOi+p43p1BVjmluMYbLVQq6bMH0DOlIBOV3HquLA1cHJD5Fi5NTdLMvb LMurVq778GCOQJ2LYGj8PMjp7W7MVCp4m15xXocOCdvbJawYTmI2UcFJQFUp v+Uqbpc3p4KIE5wT5ipuvHGu4qaOEnuCS4eaTYVT5vcTqk9olVHerXS5zU2f U6ceU6ucsq/2DPqF/OCqRzXPus36STtJNbMU6/M1vmK8bq3xbkU0pcJvUjIl /1q9h6jc09M5p6lbICwhwnDkOlfCTE1VPWAgpqCK8kDHh6gpHKOquyyMZL5z VR3EnethQRzFG+fiKHXUf4ujlETjE6IPeHKHjjhzzElEONMafkVaLIgueaWF Vmz0VwgvH6NmhIjxKdt0m90sCblxwbTY6F/TMnmO8H18W+pyACZgvfR1Le4q UETCBIbfLu7yTadCbarQl8clcRdtnI27xFGzcZdKwjf5SJ3YmJvLi1T5AIBe 2U79/zJDzhF83HQ7eMqULbfvau20qJupkxlCKm9w1MPSGMhutIcz1jSS8XMz r5nLAuaAiXxzyk5DdhzkleTMBAecR8N+E+eRbpyiabTFWNInYmpRzomaMmxH CxW+BxNaB1xSX4ApSsk1pTc1TnrkzxV9vg0weQLfyXcBXYdzQAok7P1L0ON5 amjXQ6LtyecyUxRd1ZXoqvqosQyjC07Mux1OvEYtyp08mCQmfJ+UI4rO1YAm OAE9It/YHf14v0I+dzxlBITh92VxZi1z/70jlLN3NtEhYpSgtpXgwbtLz6fZ QlFnCwXIPmoUK7mgUMQb5wpF6qhvWSgqWFAfspA1V5gsqmjIXtAo7aZL0eiW lNl4+wDiZbM4gd4wlCQuH91ETun0aNfEzK3jUhc5N2/86t6JZEU3FDvRkSG2 rTwGnE/5RnZ93GO7NcagYJbsQHilcrgJBkzNmGBvk00we8bcVbgwRjllylKY FSjtewF+czr0r1fS6VCvtmhh66bDoDv3EqFmFjPJ8RFHV5NtjhO+aau4Zi+o x05bZJTX6AgmjmWRsaNlSxx/anTr5VlDNXNVLn8NJpWImmHgbotLa+jFOIK1 5o6tOvyYj6WEq6aOHUI/ejDRvPlpRB5ssgjF2nBA8V6Z5AtkezsnLBdNANTT HYvIWVG5dB0JZUKGY+6gV317whHQiznskiyCro8Fk9Z0qCoImwxXa6Ar1NiR dHi6vGnPyzqubgsaFBX0J+Nn3KC4YSkWkD6VlYK6k/WS88OH7QunAhzj7/2a ZQJz/AWKskzAKufHrUjY9GyiZuKWQbNiok9QCX1CXhslcEs09nm/kVELHrX7 Ppfk+HscshdR9lpzSiJ0h785/fBWgioePxeb80UC6Kv/fwF+M5wYCmVuZHN0 cmVhbQplbmRvYmoKCjY1IDAgb2JqCjE2MjgKZW5kb2JqCgo4MyAwIG9iago8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNTIvSGVpZ2h0 IDM0L0JpdHNQZXJDb21wb25lbnQgOC9MZW5ndGggMTI0IDAgUgovRmlsdGVy L0ZsYXRlRGVjb2RlL0NvbG9yU3BhY2UvRGV2aWNlUkdCCj4+CnN0cmVhbQp4 nO1ZWyj8TxT/vWwiySXkEoUoSnIpQhEPCg948IRILlGSWy6rbC37IGrDs9pk pXhweUGKF3lAuWw8SewLCrnkku//tNN/muZ72fl+v+u3X/vbz8O3M2fmnDkz Z2bOme9wnBcaxR8huNsoL5hgsViMRqPTZl6HahmyvLO1tZWfn+9yG6xWa3Nz s0SDkZGR7e1tIBYWFvr6+lxuwG+HXq83mUyyRAT9fnt7q9gGpDAvL4+xU2XH Qnt7uwKp3wIFc2K324ODg1UqwdjY2MjKynLaTL0f1QhqH8qGRkpNTU3V19cr 6z03N5dKpYDw8/Pj94Lp8/Pz5ORkZd1xnutK9X5UOTOkOMQ+koOJ5+fn0NBQ RPv4+LiqO0+CpvwIeHp6io2NpargGH99ff2J7jwGWvMj3m6FhYXV1dU/0d3L y4saDdqEe/2YnZ1tNpsFNVdWVsL3+/vbhd2JiUdFRbHIQuCGZECxuHqIGcDx xoWK0vP2+flJNejq6lJmGF+5r68vMFdXV2E/AgF9cf//YsIiOFaq7xGyZel7 KwBWGnlnITWwiLscgktR0I9oL3COBIN/7RoYGCClIFn9RRcBwfFKczjxhe2W YM3iR51OB1+j0cg/0DBSUlJycnLU22Oz2Sg9fwFO/ciHXq+fmJgQFHEqnpiY KNNA52Dfj/Hx8fBNT09HzJaWFrJNaWkpdWFU4MeLiwu35BuUqf39/bOzs4g+ OTnhzwb/mYAskuJUexQXcNHf3x/HLEzgwIqyr9PTUyCWl5f5NpSXl4sNQZDZ 29sLST54ClfFxMTwm4FVmIbg+/HxwdesTUjvR8G9xtJGsD1fEM1bQUEB55g3 FP2Pj48PDg5WVlYYbRD0Y1xcHJ+JG0McPzo6khgLEEtLS4IaNAuJOWGZN7Eq yL7YFwlVDAoKMhgMQMBs42cIxqAMm07sPLTb7cPDw0Ds7OyAK/myJAdW19ra mqAeDYIaSGtr6+LiIr8WE2NjY9RvQFIDJX54eMi4ADg5+w4SSxTpBPUgREdH 85lky8DAQFkmaRwSltfW1uLbGeZDuv7tgKAIpvE8Y87k5CRK+61WK3xTU1PX 19fFupb2Y0ZGBplLsMRHzrGoyCLEvu7ubqoNGR9hjJ7hRzh5oIjiVGRkJNCd nZ1wNQbi7u5OUIScfzgby8rKwsPDyVqxWIk4+NmIbIZpdFD39PSw7BoFLigp KWloaMBFlJjJVeIuUKZeXl6yvJqJaVAgrqCXH/JjWlpaZmYmqWFmZgYX0UoG QGRBtXBPpPpCaTYkaUDgNw7y97hELSAhIQE4AQEBSOH09PQfItUHori4WHCF i423qamJZeCQ/D88PCgWlwVsZ0hIyNvbm7QBnCI/goMkZoZ81oeMem9vr6io iGyJ0myc5QITvWWw1JJEVVUVnAyYGRYWBgTeHTqdDq6onOOXFP49pWy87oLF YoE8k7GxgnF9fX1J7/r7+3tcxO8XcGVua2tDNISS8fFxIK6urvgOkq5lvFLB pR5tYb55j4+Pcob7O6BsfUrPIXDQVZdzNu346R9S69HRUae1c3NzSUlJLDZg Zl1dnZjlngTX+nFzc5NiImJ/f186zUYE9VOXX2s2myE6c47fFyx+FFxjcgb6 a6Dejzc3N2SK0tjYSM0wKgom4ZiAcMZeSymE9IZ6xJQYmtePElIRERGQn7jI IpehpqaG4niqEzkX+VFTgPMB0l0cW/8RKPDI9fU13N1+whiX4P393d0muAEG g6Gjo0OWiJY3478MWX4ZGhqqqKj4OWO8UIOzszOTybS7uwtuwkyKttlskM+4 wzov5GFwcFDsUgb0/Py8O4zy4m/gP9Zy/NwKZW5kc3RyZWFtCmVuZG9iagoK MTI0IDAgb2JqCjEzNzcKZW5kb2JqCgo3OSAwIG9iago8PC9UeXBlL1hPYmpl Y3QvU3VidHlwZS9JbWFnZS9XaWR0aCA2Ny9IZWlnaHQgNTUvQml0c1BlckNv bXBvbmVudCA4L0xlbmd0aCAxMjUgMCBSCi9GaWx0ZXIvRmxhdGVEZWNvZGUv Q29sb3JTcGFjZS9EZXZpY2VSR0IKPj4Kc3RyZWFtCnic3VpNKHxRFJ8FyZiQ r0I+EiLRSIjxNVZIFkrJ58ZGSfnaTJkVUSPyNdMgZklR8pWiLOxmZSGzQCKL qaEmhQyZ/+l//26ve+978+a98R/Pb6HzzjvnnvObd+99557H6/UbKysrIyMj /vv9RKhUqh8+oE6na2ho+P9x/YLP6AMDA2azWXgEQElJyeDgIFaGhISAEn4B bJOUlIQEjUaDvbD95uYm0oAjdklOTgYBoiPLqqoq4WwDcpdrRig3NjaQfH19 jQStVss1MxqN3d3dhK9arX5/f8fKjIwMEOrr68fHx/mS8Xg84eHhzFvw+9jt dj7H2dnZxsZGIgGLxRIfH++THVO4vb0tLS0V48sHPgPxD4sb6/Pzk1CmpaVd Xl6C8Pb2FhcX55ORZCJRUVEdHR2SiURHR8NMEJMAPCyn0wnC1NRUf38/9+7T 05N8Ii6Xi7YxGAzCjnd3d3h5glBRUYHDtba2CmdydnYG8trampez8Lk7AAgx MTEg6PX6ubk5rJQwu8LCwoK7o0oDnTNoYG4HIxdZYBLJz88PSjJywCSC3mLK ApPI71gjoaGhcoiYTKbe3l55SUkBnTOxhfoLq9Xa1tYmLykpoHOGgkEOEcm+ coLabDamu3wi8Be/9AG7u7vE0oP9BGkmJiagtlF9we12SwialZX1HUT29/e5 g8CJoLq6mhgZ1wMIUIk9Pz/LCfpNT4QpEMrHx8eARETuTU1NAsn4i/Ly8pOT ExAeHh5yc3OJ0W5ubghSNTU1MiNi9+3tbaZe8oBIQAsEFfb0ozk+PiY0SJie npYc9/X1VSAfCQMioaioCOSXlxfv3xq+srISLh0OBzbr6ekhno7M+czcJRT3 ZocJAEdUWq84Ih8fH3D6IJRmsxmfaBQEZtEYlExkAtYjnNyRbDQaFcoCYWtr i+/4ryBApXp4eMjVeDweKF2ClY9kBLxE8Yns7OyAu8CzYP74YohAHUi8xdAl 6sgxO7d6vR5XuYQXvB+xBrWMABcXF0wXZsJQYEsgIlAZcgW6c0uMTHstLi62 t7eDMDk5KTIZZIOqCMlE8CW8kgQYMR35qmJ/k0E2LpfLZ54E5ufnYcLw2Usg Aj9+Tk4OX2iRRJaXl5l6Aa/19fW6ujqmPUxp/LmEJjIzM9Pc3IxG4Or7+vq8 VKlsMploFwEiZWVl/hLxfq3QiIgIdLm3twelDqwIOI9gRszOLVdGp104Pw4N DeG5wbcbiMlHApGfBp1OR+cMRzzFEWHmXFtbqzgi3l/dMv1NRNLT04OSjBww ieTl5QUlGTlgEklMTPzWEN8BOkpsbOx/WyMBDEQPtbq6Sig1Go2K+vzqdrvp bSEzMxM0+Kc4Pz/nGgg0rqHoRZaobuemp+IU+aq/jTiHwyGyJGOaoX8mQU1O KP7Rd0ZIAH/WwV5arbazs5MeSrhxDZYJCQkgFBcXE75IgOOJ3W632WwgDw8P c4c6PT0VT4S+hEOxz1KckAUa1wKXWI6MjISnyUzYarXSeiiqR0dHRUZBsFgs hYWFwkS8go1rvkvhIl9YT9wqKCg4ODhg3m1paUHC2NgYKqRTUlLw3a6uroWF BST7bFzzEWEW+Vzs7OzAyuIj4nQ6U1NT+fiq1Wp6pWMN1h8dHam+TtMqwcY1 t+xH4Cvy6VR9bn1XV1cit0dYg3jqwgld2uczCVhaWgrsm4LbQFZincbF/f29 wWAIdhb/8AfZw5grCmVuZHN0cmVhbQplbmRvYmoKCjEyNSAwIG9iagoxMjg2 CmVuZG9iagoKMTIyIDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlwZS9G b3JtCi9CQm94WyAtNTggMzk1IDY3MSAzOTUuMSBdCi9MZW5ndGggOAovRmls dGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nAMAAAAAAQplbmRzdHJlYW0K ZW5kb2JqCgoxMjMgMCBvYmoKPDwvQ0EgMS4wL2NhIDEuMAo+PgplbmRvYmoK CjEyNyAwIG9iago8PC9MZW5ndGggMTI4IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxtUl2L2zAQfNevEPStkHh3pVgyiAV/tbT0oOEMfTju wVx66fXhPnyB/v2uJNs0aTAIW7MznhkJtqj/qKKeTk+P48NJNzetetMgT4mk XUV6+ql+fNTPqhekuD2Nz4dxOoRQ3LRfOg3MTbcwQE9H1QyqAhEtnZd1OOji E2mRGh7vgql5YwJ0jBTA8EZWhwA73thAPZt5AAXCgMQIAdr4TrUM3Q9fVT+o fXby7en99IHg+ziNx2l8/bU4wmuOEKKZ0vqtPbMUyPHwO6teMKi8yrgL5CWA ic5bm4ySZxcohYAqRWkyIJ6NoNbmEOkzT+COy5Bzg2dMNVDH84ygcbyKbJpf I6mFOrWVKpQlYrD8xXiRzP0ZQ2YuNWHIFBnxZ2fyccMKRgDuH3NZ/Mzs6r6e TacRw7slMdhdOs6kH+X6FZvpXUJSSGkwqSCuUfJ3I6Cwc2bP1WKoSRtuNbLe hKtnZsy2vDyzRdTmKmIS2fuvExcbJmA/X8/F6eXt2+s3XfSfb9F4fXzXxTCh cbp70Xv1Fz7Uu64KZW5kc3RyZWFtCmVuZG9iagoKMTI4IDAgb2JqCjQwNApl bmRvYmoKCjEzNyAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9y bQovQkJveFsgLTU4IDM5NSA2NzEgMzk1LjEgXQovTGVuZ3RoIDgKL0ZpbHRl ci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwDAAAAAAEKZW5kc3RyZWFtCmVu ZG9iagoKMTM4IDAgb2JqCjw8L0NBIDEuMC9jYSAxLjAKPj4KZW5kb2JqCgox NDEgMCBvYmoKPDwvTGVuZ3RoIDE0MiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aDEgMzQwNDQ+PgpzdHJlYW0KeJztvQl8G9WdOP5m3ui+79PySLIt 2ZItyfJ9Tmw5ceKcjpNYOcCyrcROfGE7V4HENIQEByihhHBtm3IkW+ih0JYG SktaIGV3gba7LUu77fZY2rK7ZUsPtqVJ5P/3zYxkO6TdlrL/3+f3+RF5Zt68 8/u+93vvK2V6cncaqdEMwogbGE1N3D7c24YQegkhyjiwZ5o9s+6X7ZD+EUL0 qe0TO0a1Bv/nEGJmEFKv2jGyf7vq6evXIaT/JkKds0Pp1OB1X3+nAKHkVuij Zggy3s4+KYP3u+G9aGh0et8eTecleD8HfbIj4wMpwxNrziK0+TUov2s0tW/C o7mORmjLCLyzY6nR9CbHiRvg/TaEim+fGJ+anqauzyJ0k5uUT0ymJ1IFs/fC exNC+MuQR8GH/FNDUkreacxIpDK5QqlSa7Q6vcFoMlusNrvD6XIXeApZr89f VFwSCJaWhcLlFZForDJeVV1TW1ff0NjU3NLKLWnrWLoM/V/8T3I7UqKQZAPS w30rUgDtbCQtlOJnhPTcW3N/Q+5CGqFsN0lL7kESSF3M9SW9Eelx89xb9I+Q fu7U3G+Rgc9uIrfsjYvHze7OpeTixZCXNnQaHUek7jY0gdbAcwNc4f9xGl97 T5P/MnoKZfjUWfQ4ehR9jE9/Gnr7/IJaSfG5BvWgfWgzOgUwbUd9kHMdWp6v 1Qf1YvBBcCnzuV9Bb6BPApv9B/Xjq4x/hB/5a+jjaCVKoxbJryW/RncDJB9H XegQ4GH+3yv8/TU6hXbwqQNX9LQDrYJ7J0BE8HUzQJlBd0KfR9BudA+8H0GT gNUfoPNoBH0UPQDwP4seQjehu9AD0id5qv1GchZp6AagphyosAe1ZV/Lfo3Q +j3+iyIvKkEcYC2JtgLenkZTkt8jhawEqQhXMRZkJlwHPKSU3oAMzLq5dyQn 594h/EW4C7fN/Sezdu4PXDJ97TXbtm7ZnOzd0NO9amXXiuWdy5Ym2tuWcK0t zU2NDfV1tTXVVfHKWDRSUR4OlZUGAyXFRX6fly30FLhdTofdZrWYTUaDXqfV qFVKhVwmlTCYplCYsmfs7b0dOzOO9r6M2p/w69mMevVbqyIZZHR5/QY2HkmW i7UyklAGmboy5rW9ZxFXl8xIQ1dWWZ3Bxfpfe6HxKhfbkWGK4c+/IjWYCXb3 ev36V1358iS0yTjbe71eV4Yuhr/lUAR/K1LsYEa/FvK9LiFneQat7SXXubmf 1EEmqvMm4d7dm/HkXpPJqwH5FCDy/BVgrqZm9WfVjvZEBpnPIvVPMshCqr1V B8zSlAmGABA9pPjeUCRDmX+doUwZyrIKQF48BGn2o7qr4KBjcKe/Y3AYMDrY N4/TtwSMetlZdra71xCHJA90V+bFdb1nVcp2f3taCRmIz0BnlSrIUZEM6GLi LKVuofgEre5oOEsjuQbQZyTgdpBrZ4Y71gcJfwLwBiWm+ZJzc+dvW1iEoFku ZRJSAhAZaXtGJgDBDme4VAYdY8+Gz8/edk6P+vtC6kH/YGprbwanoMJZhIs7 hnoy7q61myELhoKrb4gl5E7wN0I8tmOInYV3UrcP7v4EIfqi/MGhdB9hE6rP n4AyRXvvEe95V8YIz46MIZTRQDXNh1534dkO+zBLXmdnj7CZUwDuglIvuQMT 2AH02Q4/jAaddexsIySJ5MnGc+PyQZ443LEUm5np3ynwXuq2HP97Z/UZ9X97 gTpAH2jJNxRROdi3k4C8M0Wm2bGTnT2W5qd6Gz814Fe2Y2eCXKQhcD/aAK03 93YM+TvmB4SJQwIXX9nW6804QqTh7GwHATE1CNALIEPBPPxEJlwhCuBpz3A9 /AP18DSAEblUIilmiRU2k2akpC+RTHoFukPVjKz4iKTCz86SHmXFGXNI730e ys6Xh7u6ezsSLn72Gbq9t/lNu+tNSHetzWdTdqgzG3nTJeCoa72/a53ABUO5 W1+PIMB0nvJQVazP9/qy3fWykN7au9S/tG92dqmfXTrbN5s6NzfT72f1/tmz avXsREcfy4s/BflPH3Nllt6WzOj7hqgGnkKkO5bw3tLuroxp3RZCqqXsUEpQ HK1+b53La8jXWfvHikWZA+4HGSAyN6v/BcCmBu3kYpcSVXMONIQro68jIgsA begFmRjg+Ze/gaysh85dRGpwsrhjeL2ILOBMkXmIDlwn5kInXi+Rp2PnONQP L5mZdb3CO4v6XU8gLhICOvaRkvO5EssGUjKTK8k37/MD3exd6/8H/l7I27MG v5Gtj/D451XvYOZ8D8zx93UZeZ1IelN7L3bRYop2YZJShkCVNWVsIb4hwQlo zFm9n/2mP6MPZSTtveddTUlWbwBVR0GdzhCRINCo3/T/HUX0KDLrM1RThrKS fAR6lVfv2FYHhXlGYjtm+0ROWzgt0RgMDl19blBH74fpuYT6BqOfzPAlXr2J Wrt4KZErl1eosSKZ0RLdnNH+gr8BvK72XhY0EUjuOj7BdrBDhNgZti/Bq4Sk a2H2ubkf9SWICgSQSRWXyOJwF1C7mNfKw38uo88Ao990W3KoAXrhymAGbDUM y0tLT6+IpTqXKFFkrOVkKovL81jM1QHig+B5M1Hn39mBUZ32N5NXQ3lXz6K3 BYPxZXV5zdDTm1kaynUuvC8LuRa+dl5RvDxXDOrjRteHiBmhUdtZP3V03VmO Orp+c+9TeliyHO3pfYKm6Pa+tuTZIijrfYpFiONzaZJLMskLS15QFwW9PUHL +fqupziEZvhShs/g3wfOUYjPk+fyKDRwjhby9Lk8GvIYIY/j8wSvosM+BCjo 9QPRBzPc2t4bkkOzfUmCbGQVGBA429+CMrS/5SxFS9UZpT/dllH520h+K8lv FfKlJF/mbwP2B+FgiajP9vlB/EEB9yIXlSQsTNiFLmbPzc2BBn0ZNK83Iy3e ChcoWEUoyQIXr4B6y8jVB9nLMjMDKQIHYVNMdPnygWRGnu8QqizPKKAHhdgD 1FjKtyFWABoNALOm/HwSskE4ZpKZZIgM2jtMOmBZ8Ic6/Q0ZaYnQp6SEDBRJ zhr9lbw5kRZnlMVHyEMBsBFFyOe44BUGSwpIkqkB8gE/FA30sYBtBg2sB2Zk Ssif0iXkpMGqMyVp/lK6xEIkSJBKo8woKoitkvFpVQV0CH+yZFIAnn87IlaA sfUZFUBUsgCVYgPADhQtJ7DA3xEAlVT9Kulm3TnU7d8HMkiA5nuSQXFGU7w8 BQpHaK+CHH9drjH0JeezSB/PC7kyMnM179D2nJs749/vXfCvPOwH69xLGBO5 wIfkUHL2yozMFlCc8itzNXz27Kxcc/UGAr7kmvyTZCIWrAkgUFqyPHWszlhV TtYlDKzJEHOLpAcFYV0ZRVUoxZnMZq1PKtWicCgU1drt0SouAjLCuaIoro/T 8QJVEKGykMlcaQ6pcLy8vCYaj7xsrI8YbfUvR+BTT24osu1l5w+cJP9lQ33k B68Y6g1xeIlFqeqqFrq2BVdXlfh9Wlrmr66piVd6aIsZXrTYYrFZ/NWUwWsg F10rtZYV2UpcuiUtbLTIoehrurV96UCLW1fUFGZLLDLjndSly1KculRH/dxq LS6rDjgi8Xp/V7e5qNLzYU9FQXxpaUlL89JybzgQdEvHPvGJ7OvM/Re3M7/7 w6dg2oia82RvpB+H1ZcHbQHxbN/Qy9llMqT3YJ3DarOeTtgwo8Kq45yWqUL2 1rjzzRA8QgYUj4JLaYvHIzEXZ/ifqiaLtbTfVxKotVrjlTU1taYaWKfBqxdm LKPKfTs/eb2rSu/UBywNGzqc/6FURytV1J2qEq/LZQk9+FRSIumT4JrD04wn vMkTKcaxmNwc3NCHQFmtn/slfhq/hMzIh5LiDBy6Q253keUQh5Ed209wyKoq xIUnOJUeABLAgjuZgPNNIMqbMAX9n6yZlPhKqqtqa2pb6HilFdaQMi1Nmclc jDwdpTR13wOP60z+8tu/ODz10TZH0ew3sz/csrX/3t6e5NADScNnHm5aN7wu /dFVvScHkum7X9lFlYwNZ6jmfSOjn8k+Q/aiYM2On4IVcBjdLs6iXBL0YYqq 0LnUGq1Tq9U7sQ6FzyR0yKJ2yQvlWH6SK9TbbWcSduSkANJWEVzAeBzwHxIo pD9y/vx5g5GqhzRM1PmXdQG+skAsnlmxn2qhecrVxrGNMC7BBZZKLWar1YYf zV44oLVE60sHxpaYtnyaolQKJt6mvtzwKfU1j/WmBs09SrklFKEu1V5X0dmc OHawN7uG2VtZXqIr89FVistdzI2Tu4a5zdkHQ1WmQp9BAnjZBHh5DugbRsdF vFQEJYvwYgK8UGRSlMX5mJ2fjG7B7BZOCGan/+kfw4zrL+3kStwIL4uRIwXs CMj5bPaFg2pbrKostXO5ecun75UYDKUx9b/Vt6v7n9ySGtTIewzmsih1KbYn sqxlyU2Hr82uoR+3bfa4C3W4WpG9xMwe3jVctMGbfbCzzOMzEtyUAW5+wMvu URE3AdcjnNvNSs0WLNGpNerTCQ1GbkqD3R6PBVuOezgPOp3wGIlgIqddTzhc //y112xbINIgEU4iEu730EESNNti6cbxStB3ceytLilxWq2PLZLtV/+7fVVH my+VvvRETOqKdgxgumLDAgG/FHN27OnN7gU5J/tAH8YvIzfM+hvibFvcCFkN h4uKwtabOYW5ABfcw+nMhWa6AIMWZ7QBHDjBafWIY4s7EYvcb7lpFXYzjAM7 TnKMNSfi+m8D/E7HyyGByEZUb4+QnIUqApQ44ZHY/8YggnasoIll4JmG8RKe Ae1SW9wiERSMFFesOHq0e81kV9GqB793/f792a9mL6i7t229pztbtvXYYFtA V1+39MiOr6+7JhhPXt+56+3ndvUPPfZY09Lha9euv0SZvBW1zd7mjvTjwDed gMuv4meQHaVFTBbCXJxKud6gV+gNWGnT6rQgASozxeh0BoWczCIeb7XF57kE hIcXHYIVw5+un6RsWonMjyto4AkTrzIDtfi0qzjQvn7nkS03blNYgiEVRa38 1OlgVImfqUxuvOmOh762j/7N8tYCHLv00zepRDriwzGi70Ef0FFJAoFqR3eL 0EftFIMYLQ2sihmsoQe4CUzp8A8xrcPXYlqBsf0x0NpnEladWnUmobbw3CtK MqHCdUCHKAWzAo1AtALMyfcee0lSMn9tTiPKvAt0Ah2tOFuxVCUFKVdk//6k RmkIxlS/bZQkvva1i0/GI3oi1DH6oYYOWwGrp6sVZLY9c7/C/wpc70Jx9KA4 20ihRo1Ubhq7sUpVXXqIM9GUHvkcPuw7wTn0GnVYH8bhk5zeqlScSShzYOb1 l5AAAsGMeebmp81P2vNee0pStTZh0jDn2oBU6icGswWE34pzKpIReLqmFv5w 21buPq2yYoki+5NWTd+n+sb2h5M3PNzXMuFWSNtWla1cvayBrW8vbO+uitQa 8bE2/eVk0xJLabEkdpG57cOn7+n76qdvXl2QPVva5F+9zNW6/a4za4Z2uLuW tx9KinhjOsGaFqFG9KSIt4bG4iKL2YSQUoVNpubYIQ78eDV2KSm57ExCjorK vGW47ATn1VvMVfYqXHWSs1uNhjMJ4x+dOMkELPJyPI9Igkn/X9trkprnHOrq mLXhq2F2u1xtLa1WX2zMXr4Kgpt31HTq3oVg5gbvWo+nUIurFBdnWluuxLOj MPtSJ/duPFMIz73FGCVp8J1/J2LZbX/EZrNagzMyWaUOPRKNRiLsDKdTFRVh t/Xc3FtcpdbSaUU2vY21zdgYLbaZZkxu7D7OmZiIHsoiumhhlNbiaHgmjDE+ zoVNog4Fc/MSoLo+tPjNYATfmufleCQOmpqo60qSirm+8L8+bNIkoJ4nFVHh vN23YX8FTbQ2rwWIc8/TLWD6+MTerTcnQpu6V/Q3TH7z6Na/ubaujwl3J9Yf aCtas7J/R2z3d45u+9amJqp2/97EjRubt22orUztW7Hn8/0OT3ZuQ6ossbuz qntNVWLXvjX7v7zDbadMQIUDoM+1zOfAD3gmZxklLouLfttFgYE0meQWo9Vg 1csVCoMVy3UG4HqDkVOAElNY/osz6hDnI7bLg7ELu05yeIHREi3W5ef5mb8M MxfUJNGSBioeAWSjbdfFosDxf2W/YAZF5q41+YkbEZd5ZV6cs4T0w92nNu8c Mt5wQtXYEQl6ZmupZmv2a33B6nhFuuncQHpkR+tqWhaXFTf3X/O7dPaGh9Y2 ty7rRPTcR7JL8E9Ah0ZQG/qpiJ9lBUWeIrdGrar2FFWDGk2YmMPhMAe6tIRV 6DtLPGWIjUT0ZZ4CvbveUY/rBX0Y1UdxlOjDMhmWneDK3AtXCVfoRMKHMEt4 iG6EyJuCkgD8gZao+F8ZLWnT0jzWwPFarDCIkpbJpPABj4MFZq0trswtRYkS 2W5yqkZGB27e2lGkTZ3uG93fMHTorjWtE/VbuSGV2hlx+ypCex4Yzt6S6KJ2 xNNTXHlOlTRttJWXFXR1LD3+nSfw4Q89cu/4a5+ZqvMUtemzocrWQ79I7uho 3VDx/bqt8UNL7519ZeW8MhH8WOZJ8GOjVINIn/Gy0tLAI8GgnXY+wjkcdrsO +aLYSxu9WKcrLSyNlH689LOlz5ZKS6MoqA+ywVPBTFCiwEEfVIse55CPsmCf Tek7rogih97BOmYcdzokWuwA6SdLVS/2HudsWK5Sqk4nlEZxocojNC/jgGnR RRN9XP3z23gvwQB/RNc4BWUT552gnv+zcCUpnui8leB9cMEFB0XE+L2Ytw5x 7K8CteSn9snkUjM4H9m0SnDKrRVVKnxLRx+jtTgDRdmX9n4p3FBZvCXVKzH5 K56n/J6yZluhX8/Ecl76YEOsBMeyLy9bFzTJL//I3royu7llqVuFxBXbAVix udETufW48lFOoZDLzUbaRMHHhs3oMbceazTn5t7g3GZbJ1LoFbQZK6QzUg3W cFK923Um4daZLfk16ct5RREyxOP6n/KEyGmhOL9iefKv7zRJxWX80s0m85fM r+sEQ0zd0bRUfe0X+pbHojvkvqLA9p3VWljIWYzBqAq/8N/MoQOqH1XVrL1t TydZul0T41duSOBv+jzwdwFaL2LEgnQFWGu3WC2nE1YsVcgVpxPyeWrPu9lk a+JPV0vOewdXrr2ofRp5ebUqO6G6ytqL8jd2uMuL52m6aOUlSuWLAHWMCuV2 JIwGg+4RvR45/d5HfPQjHOUDA1PqUDoV8AnjUp0R2BssgLrT6NCdmzvPVUFS p1TCWug4p4wVKY9Ho1RsJhY9nYgpsOI4F8M6L6XF3qKi4tOJIid2HueKjEhk d3FhmWd9wvcC018IwR+xGYuYgHABSOMCmdT8/w5QknqXxGG/H3sriUHDC0WT ebGjD+vNRN6ennw23FhZuGXzBrnGzBa/OEMFw82VFbGyVO+lW3MiCqSTbMi+ 3LkuABL3W3tjc3amtsqhlV5+VsPG13ZnT+dls5mQkfDd0whJHEBBL7orT8FH DAa93q7TPMJptXK53YmlBq1drpNjnRZW+Vr5cU4HepaiTyeoBdrnMq93SFr/ vKACCbJ5LagnewXOv7iTpFdABvGSZH6TV9RNWNRi9IvZLapASYHH/OrBlhUr qvu6GPPqPqW7tOru7ypkEtBeMYmlLLkV/1NR/xS1LnsqlYqbLoELFjcTRUVm v3LuLcmPYZUbzM++BtZwZa6AxWDRByHbEMQWS5nL4fV5nV4fdkkLAzK3FfQF yxaeSbA6hw/pDRIn8VpscTIJMu3Fq18+BX8U2TUhHGf/8zpJFovLYK+wNAb1 EpDS+TUyGG7gln968GFYD1O0y1+WWLljZtPeUomKVtU8festK6XGsqiKkjbd fmOTXnXn6X+luobIArky2Xfklk98eQ/1UOxjIepw9ul/pH/V0FnExC7958/e +uy1MUTNzYGvaOT30/5exMoS26OwrLUUo0fD4VBIe0tBQYXslmKvSuXEKNwX ngCHmFHjcClXCn7xCa5Ur7MWWmkjthqNIB8nOOO8W5cTj5xWzbnmb+Z9ct5u Eo4Jv48DJKmSkry3TbZnBW+7Ns5vNy9yzW0y+m7Vug2RlWHPMi61evOD/b33 dUZWy7ZsSg56uMbW1aHuk+lHD1TQ/7R5nb+9vLi5LbTkQ2uvOcQ5za9t3ZJc Hkq0BEMrt9Su/xAXeoVw2fm538h+THwXdEbEZ2sETEcljvpYT4GvgHEXYOxD qFImcTntRpdRanRhmbY0jFVupkxuKKmQqdVg69UYOV1en0RqWsgptnl+IzqO qLb4C7bKha+E69x/QX9JiaGq1k+JrAaOoMVitpmAAWRx6NEsg0fehoBoUoxL obz8738TYVwVZSrqE6ryuJlSUJSSLj2JpUrqhC0eqVZR96kqepZePqOhv//E Vy+eZXrX9walsRiOrFvhM5qy+0PJdd9iJi+n9068hXXhvaFgXAF2J3nTxc8S HN4490vm07CKbERviTgsKgXnLxAINBsaKUqjw42NzfEDnEMil8lPJ5CMUshk NQGyrCuGpVuAuFozQazFwaKZonJcDjqb0RkNNZYaXHOc01sICi7kXOXFqzjA IHGo9PbnF+6GENEW+VT7vzomrPJz5poBJz/AH5MIRw014mlDfi1J5516HLUK htxXAAyv71hT1bl2Y/T6T2+yOsqCw0vqj96z/tqPXdPcJyvfkOi549Cu+l3j pRu7GjQUd027YOK1jvD6ruwF6xqfWz/01Zt3TRwc23lmSd3qoM2T/c2mdEXy U9k/ZN8ae+gBU8XqRtAab4NP92ugUAh9IrcL5cg6nSal9FGZzDfLmUzlIWWp RoOsTs+Mx4qt93MemUw+o0RyhNF9nNyeX7UQyc2LcE5BCJvO9eLqHdBe8J47 SxbnbC3ZEKnlzysAfTJ/Lb805/fkhQ/dUVzqdNuM21ZcekvZ8KVTt8S39AWv 7e0+FLwpdN1X+/o/spz1lW1a/bk/pE7JdZ5gIPv96NDr9x6s3nrLdFPPlv7N 58tDS6Y6luyq5pJrTv3oEOHkxNxbzArJSVSM3sitNF3wggqKsdtt0fge9ful sxZLQKPLajmthrZjF3Jj+wMcTRt0vkIfKHEN9hVA9eL7uAKpVjmjNGDD/ZzS sWAzQtSFF4CZeLTZKvkVZtypz21+iAtNUBMkALAro+ne3Hu22F13FrnrkoDd 0Ps3MHCwiNWczhW3QwjOAyYv7wbJvNTDW0bSd6/e+/PTG19YXTElfXHkjs6R HdHVtRuOUb/xFVrV67jLv8eUd/XxvkO/21/i/faFifOpiT1KPUdPqZwFb8A6 /mHwR9cBD3oAoQ/lLDorL5LYHUVYIglYCxWqYpXKVowhhQthsaWg1FihsBcV YxtD6Qo8jMFoMJ5OGASfxIhs9UQ11i/Y7Bc1rWDahY1g9r11lvTyrBcIEC0K Gpa453QtFTd5aJuM8oLFr/bTp0GbWrAs21kbKEqrsjtUhbUtdfRNJzslzvKQ 6nIXdcSAGVWMCa/mAhU39XcMlPToYzGmdH0f03Px0TXJkDRGu6m2tgthwM/v s934dbDsPlSX3/Oscx7iotEGhbm2yIfI1qcJK/h9SZePLWVLcekJjrXWmuO2 OI6f5Gx602PgHp5JGHS5fe3FWw3k1KJ14emZgCr+uKj4r+83aVuwbz5/lGbk D0W02O8LmKTCflALkzt2e1UpMZdF5dl/uGzKnac99cXR/Y3DN31kzeHeFUpJ e3d846qWmKORiw/saTOdjVYZ+J12prenKX+2RulOnxz5Xua6ugaqsrrOtXpZ cOXIR062De/ouPfuPuF0lq6S3IMsaIWIWRNFq7GKoizmMwkLWrQ/Lu4K84s3 7R+vAWtNKj9f4VyVLDLfacxe4g8J5NkXKVopZ8huruSei4PRmAj4DeFwUMfv 1iIaXQ8axwFSYUUV8+ff+ltZNmq7lWNUfuy/n1PJkAu77udQTpivcv79J2uS 82+wSkayi0R2M2miP7GZd6+MwhG4LKdVpdSj225eHl0/fexjPeuvW1Z4sH/j aOoX7oZ41+03bm/tCJfFo43xcLHT6NYvPXVoN2X49YUjy6q23bTq1WzHnQdb 6qiydVtK76Cc1LlTO1NWV0vX9SO3b++/k2jXcbBCG2GuhWhcnKnH4XQaXW5k dGOd1eWMOhxyl4ysk7Hi4wvthL2VKKy/M9YLaxfihZI9S9Of1SZG1tj5vRWm 1jSv36g4sSMpY1lqu+5yi65nc63PqT6lUHgszp3DAepiR4HeSHm7/cGAAS9f zmjtvro6+jtllXqPI96yllLs5jbAvExAQxrmVYm+Jc6rTaMoKQlXZhEKO3zH DAbFbDhc5XBlnZzToYG1QgkuuZ8LMNbA/dEoYmaYCI7czzEyh9M6Y/Vgz/2c dYHefrk+r8HFFSsRuEUmI2d5SRxLPbBD4P0aJEnV5uJbwJmUEUMhhoIIzjmP SX8uHgbcTXnpxDPbl0xvind+4hh1w82dh74ys/Uf28FijO0cvGPNsWODpv1P T8f6N/TdEGZWnY+UelpS7Vs/sq9GVXDv2Pq/3dNc6vn29r7ex3aNjPTKO8du aO3ees01/K7U3C/xftCOLLqQW/cYDIVy9Cis0wrlN3PIBvrdxrpn3AxmTnBu vYFsXhtYnX5cf1D/ET2jg9ucHptgzW7WYM1Jzrz4bPe6/OEuj47csVD+TIJs 976P3Scp3isEvHposj9uEzd6jcIBhIz+IW2JhNKf2K4rbo5sObyi+Zpnx47f s/b+V3av3VsRo19amfB9Ivvdo2Urago7VjQP9X3qkV0U+lqfUf0Tgq3DsEr8 Faydy9DunEfu0Ni1Wp0J2+1hSlKEWS1CZWcSSOd0yOUFsOw6k7Dl1BvIFyw4 RKeaDyjIGVPzn9cqafLinKana03xdx8t5mOI7qMaD2otsarQ4MQS45ZP3yvV RzhV9iecJvWFralBlbJHKYu24GeyuG68YllL++0HNlFPXN7g6nWX+ZnYRT6o wrMuTA2Eq4zlRRJx/1LyQ+CUtvxpSiuLvQg+JdjniyrUdmw2J6JNkcZIpKoR R3FTM3ZJSzlYvpae5Dh9w2P19XVnEvW6qM9kMp5JmCziFkh8oe0D4ai3VV65 m5Bz2/gT6L+q4yTYHdl8hM6i4+hF8Sp/NHgFP0tt+tTWawfMfGCKgo/tqawJ pHa2m7d8esqii9cEUyM8zoVQltfr2tRbn9zWN0j/XiuTX79HiOQRglViYswP d/NN27Jd1KVtSbazecnRQ5sXB7lcZm49PEqi0u7M/juF0RtIi1hOI0dnOa2c lZ3XZnQzyKnPOr8PwiCYrwuxYjMsnQKglimsLShp3r6uIlrtc7HyN4oGty5d samqJVjXsOrOFaTXfwb78QRwdQg9m/POaS+jcioNyODzMg6n0haw0ZDyqiDt ZJRWuNtQIFBusNEqh4+xoNIyXCju7MgVNmwx89bdssAHFJ5Gm6BgyQrdWF9P TI5eDC7QH5Gfl4t3/sz9L+8Z7JHM5sE2mR/z5zZA2UBNbaACg1o1EV1Kdv6f +Nq3txWHi4oCqneO2des8CgK/Krsv5n+5dvXFhR5Q0HVO4djvUVaTkUV4GPf +Pt/6V1fbAA63WXp2lBVYnZ6YPn+nxd+mFgWsOBY9kh5X13YXiuPgcexCnTD a+ALuVAMfUnEY4n5EFdaGqfdWg35PiVWY1pN8S4P0mrCBj6KwKBH5+Z+xBkU mk7kc/IxBk4rZaX57XjR5oYWx1m15jd4Fzia5ven52QtmG9xp2NBwBZxM/G7 vMx/38pRWGrgg9kymtRjG3Iepk4p6VhbtXFVa9TRuCS6bbLTEVuiZ/Y6rikQ QtoSzIenRdeSGilvda9ZGlw1dvvJJUNDzbffPYWo7G+yS/DfSh5EQfRNEZfe kpJit8ullUq1wWJUhHRaK7IWYa3OcCahC/5Xsc59bu7858B6kCfncrg73WSD 281yDhazJzgHxYArcy/HLDovFCxzKNR6+XnRgZ8/xAV36AUDH8mpfB8HIceQ 4LLXikqcP9NdcLRC3IG4zJ/17X1sf9hvs1dUt9fHbf+wXx0LOsym6h883r8s 0KstD9evrbc7fmr9meHUM93KXrm7df8APhyXGAqql3z+C/rH6itbbhweTYPe 3k59lW6ityKM3JwWUzSFqT/8kKZO0RSNItu2vRmCWZMAXG+tl3Zlu7zUF6iv PgDtyJdN3wZdg5HhSaiamaGMqJWPB4rHamX+2rfjX4m/8QasQPkTkd9INgDn l+X3lEslB7ji4rDZXYZNZUFXEAePuziX83TChd0eDbhJxzWcRns6oVkQMidG eeTSi8PuPO+1lyQlhBEz/kUnQaZ5RpbRj5985uHulumH7n3mxuzWhadC7oLu 9KPHJpcFnzsfjks2VOz7+tEj//2N+7pLrzgduijD4dRDZ87v+tY/YcDIElCr F/AtgDsZinFuhpIgiYyWYoQlWEpn+vAEzmCMZRkp4PTNyLbFUVYkVMoEF3UB UFwGF77ljTcu9wOuKfLtT/wo6GoHeiXnr1GOR5FO86hWi7BUb6AMBiNGWgpp J7Qz2re0jApEhDPIdTo5lp/Q6XSIgnKKw5SZMmPzCY6yoPxqU9w+bl30dh0h eTyyjShscoL0JlnAVbzPQyQp7AW9UxsQor9NXhtlEzb1Cpovh020f7pG+h9V 0WitL9lIf910uVL6kyYuGi+hHNmfx+g9h+tkWn8HR8kqL70i0xQtX02inTbA yv+HYpTYvbmTHrfLWWgwFmKnk8SISQ16vc6n5nWjWu9CoDeJ5sRWh/1MwuH6 82LECHe+137y0R25SIT8kspkulqEGH3/5seT+aiwpq3cHDKYQ+CGvPip9quE iL1xcF8uKKy4TX/xIytLCr0knO5O6mC4teBdoUvUHJNdzsdABvJ7zutNAb24 y1Ma8DzKFRS4pTJ3gEFeu8HaSXuNXtrGmGQBq1oiYc4kNDpKwUh0uoLCgkjB ZwueLfhGgVSNCxycw0vOEEuwl3PwypE/Xs4dWIgxkSQ8kmTz4pCPJIAc8BMA y43/m0MmTcIhExIPoKQ0LQSE5FdloD2eUhqD5SQmk+oWzqCqH/3lXRMrGwe2 VbkS9tBqylPAVsSXb62nf7KysZAEaVKvvMgfQR3Lvpr92LMf7apvdKgUX/IF NZ620VXErw6CX303aM8adFrEeH1ALS+rKA9FQlJZKMKUldUV6LRqvQo+hbhA pS4LMXaqugYXg0U8nSjBVrndYXecTthze271V/pbi4O6c8ck/BHJX9xdkuLj l/1UScAvpWX4qsfslNUWrzHm3yV3C4fr/3k0+/3qoEZa4+lVqMkR/EOLjuBb KXl9oUpeb18q0/HnusKh+8Xv4M333xfP/vjW7HVlq4sWHs6HVgeJ+r309t9O N1PunVSjd3MJf8xLoY3US/hZei3o4AJOx9s9ROtp+i2wexSKvLztOt7eR2LE 8OGHLn2+AK+kXrpZjEuQHAOKLMnvFzbFdNpKVLkEa7XtbFRviBgM3giGFNYf 56JBZ/R4NGpXSLHL6TqdkDuNZXWNOFAfDAZOJ4JYXI0YbPxXB8h5k7gT8Ed2 Vkv+2m6vCH3wCofHV4uEwN4Fr4yMaV8UGNF9+efr5Qom2DAfKqHQLAiVSNCO RC7D57ZZ7PorgieoqewtxZFyV6hEkqdY6TbXfDhF9hUqns/Q2ss3LUOiP3E7 4N+PovlYmSrwJ0pLK91RlTqiVhdEsFulUBThouOcQuG3Rsr95KzJz/l9pxN+ bLZZbacT1gURIXl3APSJsAuD4legn/cy/H99r6K/QdR6AF8t+IiqFDY1wfHA 9L/vvW8gdsdvHtue4ITz+8XRRxS1/8S1VU1jG1oSRyUbilftWX3P94eY7PdK w8KB/hWRR5eXVQ7fuXFDfym+/BBZ2ZHvcb0JmGxH/yDicZUjbJc1yqVOaShs b2qUN5c1OyAVlkG6scwpbXY2N8rt4UY7fDoSMkeoiammDEYz09be3nY60Y59 RcVxprqmuuZ0otp41VUYwSagI0IWd396jce+p/5BAfFHBzYT778Jp7UyymS1 CR8ZOeKCtR6eDzcn2KcwWQfSM6pQ3Lv+VV2BTSVhAypqt8pTvXwg++pdXrNV r9FqvcrsiLIiZh96PV6hKXSpsrcpzYXFrUHqlrutPm+Ri2glWXmIS/2a0plK A26r0gWIjymCa/dkH8zu3BqptBmUCmUsJosFGjupWPbfuHUFdrcB6sgMhUsj 1DepB5q7o3ZJTND90iNAn2b0PZE+q1lvobfJW+hpbrZUymUKqcJhsyKLU6pw YoultZL8bkeJFz5VuLLZU8gpjJ2FheU01dDY2HA64fA2Yq3eEGLKK8orTifK FyIwHhd0OWHVUDw+v4RcoH0EKglfYBDIRmTirxsnSQmqZrGdqPWTQ3Q/xn7p HzEhJslKqlFQNI8vUkuHnUFtQX1dtn60z2UuKekzKN9tSdKTOeNx6feLVBK9 Ze/RmoFtlw30f1Gai5/Jrly5gr2aQakhu33oVvxTRoFUKMVVKrVymmljaAWi 5JQU0zKZnKNoDB8t5qSyNpmUU4ADLgW3/iuF0multBRWV+K+E/E4RGUhbC+/ XCkKBKW/AOsv/c9iFAafFyYdx14ZPdFzT0/2cQ/Vs/6e9VSvh5ZmD1E3HqFu yN58hOjHn+IX8XWSTwJcNlTEGaSqFxFyqI22F9UGNfq8pAKWFPVg9iOXLxDv 6fKFGEW+W2nTYos3l6ArC5uH1oQrGsLGrDOfxC8OXr99R3VD6caDxzwLkjDm 0/hJvFRykh/Tx+nVLxptNgd6UaqyGSSfVyHU+jo/5AXiFF94M0aRr20GWnC1 N5eg3mFbhlaFw00hE/WzfFJyMn39ju1VDYHeA8cKFyQB+1HA/uuMHElRGWcC P49CNFhwWImSH6RiJIDeeNwBbGuHlQmM/HJlZT0YcxlVS1G1+HXPpZ1++p3L t3noj9yWveUUVUYFbxdiKt5iTknSYGNeFCVOaTK5EFId4FyIRDFEtZZOqKin ZigMy+XgTFCCJce5IGO2Q4lZZyo0AcVNthlAo/Y4Z/sfwuHFAHx+o5v/JZn3 fQASWifEZNK5dQLZGJ4PmBA+ZBuHOdXUJ9+S7rn75v6qXZNdE/3RvubtXxm8 4TO9SrXTW1nTsWTl0oe2bHlAUpn91fWjA1+6mL04/PB95bv6sq+77Tueu7Uz 0TNwfXpX98p4pMqas9QPgv5qQCvQayI+E3qs0zAMtqtU1Qc5jltZssJmtS+3 24PLcUmDdcUKK15xnLNavcuXVSzDy45XcBXlpxMVWKUuxF6fF0ytzEv0STyv +fNmNmdlxWOaxVtg5IgGjI3g1gbfv4GSFJgQm0cC+qkkEODDFq8aUlzpwfyX lQO8ea9giHnHpdFGo01msLkKAx5l9j9ZR1hVGKovnVx6VWP/5Z23XMuxjduP dP1k9M6+Fr0z2LQmUd04Q+8qGkxOF7XU+6waSSx5/bdru0o12edyUX1XOAGO yjUDdcnZoU4bF+q9syfUHvY5VMzlLwO9bpj7JfPPwP1GFJo/FWUOmEzl3gOc RvR8TIh8o5F84/6Pnor+yZrgAJHzLJpm/OLxKE3pF56E8mwqcCXuuOELqZ1/ l83eftsXNy4/+NnXqNU/rInWxetjDaFyl/O6ic3rBtdujLgl6b7n73wge2P2 p7eOfPXQQaox+8TW7B6q0mgNxVZuntp37PDIg/fVtt/1Nz85TPgyDnzpkWxF bvAhXxDn6fTL5RL9o5zBoDKpzEqzRyGVeJVmL5YYyF6eT6HpNMhm5CoTlhXI CnDBg5xM5vYppE7oBaNPcm7xCJScxLQK21IC4/Cbe7kNnPzmoZOP6SNCb3gf ek8WA6fVemupuBhBK/PLclaThPTU+inqnkCx22lyX/6FiX7t9Fd81VGfZXP9 b1mFrKxOlZ16lNpXE6rWZnFMYi1bt2nmGtx36WFDafyVO0MJS0WAiVFz7zz/ /OXbAXvHQUd6gEtYVIsezu2bsF637FgwWO+9zBkLiwpQGYbPAxzGRe4Clwtm 9ADnkmmAL+7nNItOyYkQzbvHYJHyrAT2iciq96/sjnwlTIi1IZvUJKKRj28q qrXJpEiGc19E4rdW50/jD6y+e3XPrev8K/d8fHDz4d6w2sCWnnyVYo4XK9/K fjLZNj665sPLX/Atafeweq1SKZXKZfQ3o5Hl94ws++hNqbolU/dvXrtmbNN1 3zozaqqNGbL/djH70ePHdzy9+5cat9mi1xpNNgcXB4tzYe4d5jbQkRp0MPet UuUjnEqFGQRLUoRVUiRVS7H0Pk4tpfEnE7R90W6RXf88FYnzzvR80NJTiJn7 RV2SjzYmB/bG/7kTclpP+WupWq8YWczcdOl7J9T0azibijVXFG5dhxOS4j98 u44Z01lr11IJsn4Yn9PR2+cOAYdqPoeJ+YyQA9xITFbttRynf/er6WmSuS+7 Cj8keQB5UQVn83p1uoJOjtHBInY1p/Mg4M/VyAU+ySJNEo8Qay3aKCOJAaqJ y3zSRUrCGqcld2TWGO1bwvE9tyX7bzX2TpZXRWrj4XCR1VO/a1N21fbnPjp0 4CHqjkMnvjzm8nQHgxXrB07Nfv3hDz+5b/cttTCDVHYVfYyHLcrZvV49AY3R 80BxyKM3YMNq/RXA8bIL0JmEnzQQvhYkk/prK3mVZSQ3fv2W5YGrjIRiU7cn +48ae68Lg+4aCPvNroZdGyUPAHDbr//Md1648fanxpwAXCCyMU01fuPUDZ+c 2HNLDZAeLQVJWwKSVoJq0FL0WC56y4z8gVtttlpdK/jHx6LRztpjnM6M2sLh Ntx2PxcuVIXvj0YLQRfczxXKVA244X5OtUhKFsQazMsbmMi4GM5Aghm8773H JGURUJMLzASVVFuy+LcgpNJi4Qy+JvdVbeHcWjw7wuwppaaw+MATo3s+u63x yE5q6RK5yu3b//jg4cdXthzJug3lXU29t6wf6B+cbf+b0Z3r9y0v6d/efWBt Kf2CZuUTgarljZ1DjSuOXbP2EzNhTeXB1SWh1nhLX93qmXVr77n+6yUd1YUb HxtIXZv6zGX94FDH5D2J1EBi6jiam0NPz90pHQKsB1D73LPZ1+CZwOQrOjLU Tv/7pQGk/yKFlDIGh8tRa3U1/IFOvIjL8UHp7cgEtSOcXf2Sx1NqfonDyIZt P+NQqRI46mfKwJVszhtMit/fZeKVBGXATtKAYAAFPiKWkSik706MueNrUqMN /6owbGiJH3i4Ih4pa0oWGMujleUNWwr0uPzGG9acPLpvQ/idzrqdzyXqWl5I 1PuiX797y+qWpqLIS/f0ICqrnjuFbaBtMDJ/EYOzTCNMowg5MAQVUhkDFUBh 28XbTjJ7JRv+0CX5ApHy/dlupgt8e4xMX8TgXiMPBSJB2sRfFpowXRdfOcXE JSd//yVZB0j8M3O/lAzCKHE0mjudM/v82GSqlisqcBg7XQWg3Sh0OkHhgA7r jnMBU56ZBLuWP93h48Esf1aTJFW7YC357p9MwTw7zkdBUIyKuktYQt6o0e0a 2X60231MWCDeoCr2u5yWDwfu+M79nz5nswypVRWSInFb6vI363fUjk70fOwA vbt8o/j1H0tw4zWXP/m5b19z5lTd8S3UP1avd5QHhBg4pkhyD3hU/5TzgB0G o93OSkC7KBTlrAcVhgoLvSHMYoMTtKgHe5ZxSGNDyyqjKq1Geyah0OhCVGnw TKIUkdAPk83C8me08VxQHEmBY5CTQWS7cvOKx6Tg+obfz1GSFI9lPmST7InL ZHygphfzX0pZ8LMn1ARb2NndUVVpTKiohGn9tsv3mMtqQ6rs23dpzc6CFUML fvaELrfHa8saw+aYNBbr6nwhezhe68Qx6oGAW521LvjlE4T43yKW/Gz7j39+ vP9aXdPbSCXnfzr1qZ/d25z7GdWsOrtE9mMp8VwUcAn/oJ20MVtPpfK/tjqN HIt+fbVTkkBfodNzHkaL1jMtaBXTiTZRzwE1I+CN/C3qxp9BnXQIbWKqUQ8T Qz34eyBLz6EDTMXcR5haqNOGNtF3ojLmNrhOoqcl/4hWYu3cnCyMzjOfQTcy DXNvMw0owXxh7mGmdu73tA/GaEDXwzUOlwnvhb470WHpIIx779yd+N65f2ZC aBW9Kfsb+na0nboXMZIwKqONaAm+D7yIMNqAPzPHSK5BQQahjZLNMO51cG2d +4p0I+Q1oMP0L9FP4Xoa0lFmHcDwFJS/g26A9zhcx+G6QP9ubpx+B+2j35lL wftS6Q9gdR9EF9EPsmr89Nx+iQ49g//A/1ruTejHVAf1Lfpa+HwHX4+/y6xl fiE5JR2Q/lr2nPwxRVxxh3Jc+V+q/Wqv+jnN3dqg9lXddr1Zn9L/s6Hd8Lbx NpPS9JLpd+b7LUssP7PSVpv1lPVl24Dtsv1JR7/joLPV+brr8+5D7m8UKAra CkY9Zs8vCvsK59jTXsZr86a9n/eN+271/cD3O7/ef09Rh8gPnagLlhw9SALU 1qMI2g4u/6PqVZBHSiN0g0hhDX1vntpaNMK/Yf5tEDNimkJaPCSmaaTGe8Q0 Ri34w2KaQW58XkxLkB1/X0xLIf+3YlqG/gBuhZCWozKJUkwr0FJJlZhWypSS D4lpFdqovllMq1FQ/T0xDTBraDENMOvuF3+NG6FKvVRMU0imrxPTNJLqW8U0 RoX6DjHNIK1+UExLkFo/KaalkH9ATMvQjfrbxLQcWQwKMa1AfoNHTCvxYcMS Ma1CIfOF/K+Dm82/EtMaaqVFIqa1CFnXASQUQ6R3MJ8GPFu/IKYBz9bnxDTg 2foNMQ14tmnENODZViqmAc+2JWIa8GzbJqYBz/ZNYhrwbL9JTAOe7V8X04Dn wm+JacAzGxDTgGd2jZgGPPt+jpJoHO2GNc8oSqH98NyNphBZA02jITQMaRb4 bByNwTsLNcj7BJRPQv1hyJuG9CDk9fNtSRvStgNtQCvRErHt5IKSCXgbhxa7 0QDf4zD0zKK9/FgDcL/6uMI7qTuARqDtoDjqNNRgIUXKJ6BEmEEK6g2KYw2L PQyIfaX5ewXkXDlvUj7Cp4LQqhSeaSjrz490NajG3tXzn4+j+d4H+Z52QN4k vE9BjUkeG9NwJ31ffe7C6O+Gq3EBBshMhLlM8+NN8NRI8f0Lcx2EnL38zMch /4/NVMBzahFO0zxdx8W7MCshvRveJvg7y0O7h59NOt8PqTkCNf40hYZ4zE2g BtB0EYCRfCp4jA7wPDQF13a+Jmk5CnWmYUZkhjv4OU5AD/t5LSn0OwVpAs12 KNsN45OWKZ5v9qFPwviVKAqfekitetcYLGrnZ5rDX44yhI+WQF8j8OyGvB08 1FP8W5qXo0mYPaFXBfSQ4ilOZpxCy6FeCtqRkd49XgM/4sL67KIWDXl4q/9k vY08BFMitCzUroAZRq9oU76ozZX9CbyQ5jk5R+OUyKs7+FKBF3JyMsnzUZqX q0m0K88jqT9auv0vwvlCzic8tQHehvMytp6fyTSP/ZwcRK7CpQM8n46JskZq V/wFMKzi7+Mix6V5rJMZ7chLck4CeyBnkuf6HrHuXr6vXTDGlZgeEnUH0Qpp fo6DPGSEr8bE+W3Pz2UM6DbFw5urTVKpBdokB4MgdUTCx3mM7+BTg6LeFdou lOtBvi2Z/RQ/K4G/CRwfEjElcNk8xHt4rO7n+WSP2CORrBTAdyU0ggUQMDqv 4UifCR4PO/icFD9mro3Q/zRPH6GEjEwwO8L3v5DarCh3w4ArIXeSp9Akr3UE Gu7h0/v5utM8PATGcN4SjfAthngYyawFDZIS8XC13hdiKgdHDp8LqSBoYQFv Aj7nYdgl2oWxPA2neLhTC/h2mm87JrbKjTQualuh3igP4wg/SwGzPXmdnqMz ocuEOE+hZJTne9KLwNmCzk4BN+ZqLZS64QUaYyrPSZN5zyEtctxePneAn2+a l7shHmcp3r4J2mkhFnfDeMQ7WGjjpng5G1lgQfr5dGrBnId57PSL9jNnhdN8 q1HRpkzltY0gg4MgQcOi3OYwtSkvEVfXg4J3tFASB3hbs9BW52QnJy9k1D0i /YjWZnnuF7gjvABf8xwzCZC9G1PvlqkpnkeJNRvMY2WKp4pgiQQeF3Tzbp6e CyGfx5bgdwhWcZ5j0ldoIAEHYyjAt9nJ42IaLebzK0fYzbcWJHQKCf7GAOTO 06RhwWiCTdnNy+kkT6d0fi5X049psN2LR94r2inB3gj97BDxkuZ7EThgVJSq hVpjgLcEY6KvMgW4I/Qfh14W42SZqHN3LWjdDrUFr0qQiT9Pm+8WIRf4aISX wJwcTIjew/AC+y3AnspbQYEvxhZYJkFHTfOSO5pvQfA0IerQqbyeE3y6YZ4W 8xoqhyfBIgn2fVz0SIXex3grtlADpXhpysnrqMhJw3kLNcxLCLvAXi7Exfvn 6xFJmff3rt7rfHmutw9WQB+sgP4fXwF9kq2MRuvZVcMDk+NT49un2fbxyYnx ydT08PhYBbtkZITtHt4xND3Fdqen0pN70oMV7anR/snh1PLp1MjwQL5dAyvm s0JBA+m3enHexvTkFHTLVlfUR8WScqEkV294ik0PTw+lJ9kUO5neMTw1nZ5M D7LTk6nB9Ghqchc7TkoWvG6/OuTs8BgL3bAbxoanof366dR0eopNjQ1GoINx foCB8d1j05PD6amKq/awanxsfHr/RJpdPpraMTy2gzRme4Ynx9keyN07Prlr Kgf0UGqK7U+nx9jB9NTwjjEYbzsZZax8amCSZE+mU4O5HqbH2ZHx8V3sjvHx QXbvEJROTA6PERhT0+zUaArwPTX8IQAKUMZ3vCc9uZ9N74GKUxOpgVw3E5Pj ACiBE2omhlM7xsdSI3wJ1J8eHoCXodTw5MjwmDBtFmg3vB2Sk2kAZwRmuCc9 sp+dmp4cH9sRBkCGR9Ls0Pjk8IfGx4AgC6sLQJE+CJzCFNKjEwAbwMn3sCvN Qj6ANsUC7ghup4dSAO80aTS+e5pQYnQqPbKHTKtnCGhM5jwwPAFjwsvo+NQ0 C8geHkin+kmWQLphnjGmCJIACpIzMr43PTmQmkqzA0OpydQA8IYI4u7+wd1p AiAMuh+6ABD70wSj0Gx4EtIwAuAyPZIeTY8BLwPbAAUHy4eBtgSoTYQQC3hw 95RIxIHUBI9knjqELuw4IBhYm50YB3SEebh4xEyW54HKU2pqaHz3yCABZWqE CBFgHLh594DYOQ/WZHpq98g0j5i0yEAAwVhgmt25G4oFnOca7J4iBJ1iB8cH dvMzaeCbgaTsHklNsnvTZJR5fkzvExvvBZkCuYE6OwCW9DRBwGiK5BHWGBhO jw1A/v7R/vEREZJlwLm7+OL2/ZPDI0CJq7D5bugccDQyPkVoMAHqYZiXb+g9 NSZgZYwXJuCo6XRqlBSk90G96SnCc+Nsang0zTMUgQkECeQdeJBw71h6r8BA qUmerqOApGEiUMMTQFUilwIUFUPT0xMNkcjevXsrRnNyXDEwPhqBSuM7JlMT Q/sjA9Pbga2nFlTl30m15PhuwMR+QnGgJZCelBBeAShHh6eJYPbv56ncsWHl Ep4K5AXkD+hIyENkZ2BoQVt4AnOP7B4UZjY4PDUxAgMIUgs4AcVDaDpdwebG Hh8DxggOl4JY9ZNG812N5SpfFSK+Oq9ZgIlAlQ0IrJofnRcksa9GHoDgMIwy DdILSg6ouh8Yae/YyHhq4aAAc0pUSpNsXluCGE+AJA+m94CYkjpD6ZGJKyb0 wWYa+mAz7YPNtA820z7YTPtgM+2DzbQPNtM+2Ez7YDPtg820DzbT/p/ZTBNi ktDcb+E6BAVX+cet++GPrDb3t78Dt+tvsLquv8HxrX+E9J69cBudgNvIONx2 jVldu8YOTjqnd5st7h074bZ9GG7pIbMrPXT4Oqdjyvqhdod3P1zn5t763AMe bz35Mpf1QdZfz76q1ta/9hWKzag09dwL4Vg9+Q2Xz5lMfBXfW66C+ovH6VDi 90ePH/3Vvcfv/ZXk3K8oxYB94OsDmB3Q6Ei1zy0rLOarl97rK66v/Rh1zwk6 ZD9ZWlZvO0npT7Ry9d89Qb35H3SI+w+zrZ570Wwmg3D+szDKrYcloZmDdOim g1TowEFJ6NIhOnTLYRx67SB18HBx4RIntYpaCTa8kOqgEvyzlqrhn+1UG/9s ppr4ZyvVwj+rqDjXSIWOHqZCR+C6GQY4BJf8sKIWtXMxhb7eVWux11gs1RZj lUUXt6grLYqYRRq14IgFVViWhCgZJUc6SkJJkZbCFANpiqKRFrVSFFwYLgni 4ElKJHxstB4uFtIsPKNQEoV0FNIcXD+EVkpKw420t3hLAtpgQKcriwbpspA2 HNL5/NoiP/lhRrZQhyR6Ca3TG9QKpUotlcnVmJGoEUWrpXiw0IOChSpdl45W gbQl8DR+HP2LTqpCKqzSNaJGRRJvUezBD6AHFPfpvovUT1FaSscZdS6qQGOX OTUWvU1jZMwatERBaVGEIpPRoo/AxQC+SprCTWVNwaaSpqImXxPb5GlyNdmb LE3GJl2ToknahJtQ09p4D5UxdqGunraMiYLn+rZMPNR1DrPdmcpQV0axdkvv WYq6Iwm5GfroOQr1ZJij52h4GNs3b+k9RzlI8WHXUySSOdPVd/j2ZChUkBkk /0/xTEEyU0kSdxYkUVemcl3G5W8LvevflHCf3r3oPTSVKevIhDtSmWBHX6bE n+DrXNGUWvS2oBRNkzeSMS02EnrN2DOtMMcrQTirIJNd291G/vvtrsxgd1fG s3ZLX8bpb+vKvAhvNWu3ZNT+NpDf/w/CKAwqCmVuZHN0cmVhbQplbmRvYmoK CjE0MiAwIG9iagoxNzA1OAplbmRvYmoKCjE0MyAwIG9iago8PC9UeXBlL0Zv bnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStDYW1icmlhLUl0YWxpYwov RmxhZ3MgNjgKL0ZvbnRCQm94Wy0xMTA0IC0yNzggMTIyMSAxMDQ3XS9JdGFs aWNBbmdsZSAtMzAKL0FzY2VudCAxMDEzCi9EZXNjZW50IC0yMjIKL0NhcEhl aWdodCAxMDQ3Ci9TdGVtViA4MAovRm9udEZpbGUyIDE0MSAwIFIKPj4KZW5k b2JqCgoxNDQgMCBvYmoKPDwvTGVuZ3RoIDUyOS9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxdlE1vm0AQhu/8Co7pIYKdWSCWLEuOHUs+9EN1+gMw rF2kGhAmB//77jsvbaUeYj0sM7PPzmbIdsf9se/m7Ns0NKcwp5eub6dwHz6m JqTncO36xEnads28PNlvc6vHJIu5p8d9DrdjfxnW6yT7Ht/d5+mRPm3b4Rw+ JdnXqQ1T11/Tpx+7U3w+fYzjr3AL/ZzmyWaTtuES63yuxy/1LWSW9Xxs4+tu fjzHlH8B748xpGLPjirN0Ib7WDdhqvtrSNZ5vknXh8MmCX3737tyxZTzpflZ TzHUxdA899tNZDEuD2Alv4A9+Q1cGEsOLpm7A1eMKcAvxlUJXnF9Bd6SHfiV 7ME740LBe+ba+htjKvCBe6Gmyxkj4MUf9R39PRwc/QvUcfSvUMfRv8Jejv6F rdPfG9NfrT791WrS38Pf0b9CHxz9S/TB0V9tnf5q8fRX7Cv0L43pX6G+LP3f g+kvqCmLP+5C6F/CTehfoidCf7Fc+gvuS+jv0Qehv+KuZfE3pn8FT1n6j34K /b3Vgb/kDs5Kfw8fpX+B8yr9C1unv4eP0j9uGblgHZxLS7LF0F+xl9Lf2170 L3BeXfqP/0+lv+JcSn9FH3TpP+5R6V9YPPsvcPP0F5zR019tnf6Cu/BL/5Hr 6V/Y+tL/VxuuZYowZvgO/BnftPmYpji69rGwmcW0dn34+z0ZhxFZ9vcbDMwM /QplbmRzdHJlYW0KZW5kb2JqCgoxNDUgMCBvYmoKPDwvVHlwZS9Gb250L1N1 YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQ0FBQUFBK0NhbWJyaWEtSXRhbGlj Ci9GaXJzdENoYXIgMAovTGFzdENoYXIgNjkKL1dpZHRoc1s2NTggMjk5IDUw NiA1MzAgNTM1IDIyMCA1MjIgNDU3IDQ1OSAyNzAgNTI1IDUyMyA0ODEgMzQ1 IDUyMiA1MjYKNDA3IDMyMCA1NjggNTczIDcyNyAzODEgODk2IDU4NCA1Mjgg NTI4IDU4OCA1MjYgMjY2IDUyOCA1MjggNTI4CjQzMyA1MzUgNzk4IDE5OSA0 NDkgNTIwIDI5MiAzMTggMTk5IDY0NiAyNTggNDQ5IDUyMSA0NTkgNjcwIDUw MAo2NjggNTU1IDU0NCA3OTEgNTI4IDM2NiAzNjYgNTI4IDUzOSA1OTAgNjIx IDUyOCA1MjggNTI4IDM3MCAzNzEKMzcxIDUyOCA4NTcgNDY1IDYzMiA0OTcg XQovRm9udERlc2NyaXB0b3IgMTQzIDAgUgovVG9Vbmljb2RlIDE0NCAwIFIK Pj4KZW5kb2JqCgoxNDYgMCBvYmoKPDwvTGVuZ3RoIDE0NyAwIFIvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aDEgMjY1NDQ+PgpzdHJlYW0KeJztfXl8W8W9 78w5Wixr32XLy5GPLS+yJdvybsdWZDmx4wQSxyFWTBLLlmIrsS1jyQmBJgQI SwwtEBqarpQuyS1tQaFAw30PGvpooC18LhRKSxcKlO7lNnThUkLk95s5R7Ls GEr77l/34XhGvzPrb76/ZX4zR4bE7FwEqdAhxCLf2FRo5rmfP/8UQuhphLBh bG+C+9HWVV6gX0GIuWTXzPjUml1tf0FIUouQanB8cv+uA28tMAjpDiNUZZqI hMJ3PPnNIoTajsMYTRNQMJb6rByen4Xn0ompxJV/M174Ajz/FZ6/NBkbC1X8 uhXmayftB6dCV868ot7PwvMf4ZmbDk1FHvQbhhHqUCFUFpmJxRMJdOMCQqEE qZ+Zjcx8lu2ZgOePIyQrgDIM/8gPtMcy8sywEqlMnqPIVarUGq1ObzCazBar LS/fXlBYVMw5SvjSMmd5Bfqf+iOdRxrItyAdctEcSepJLvywrwj0wrmFz5Jc oBFKDQj00h/ZAaRjVy2cY6DXwuehhf6DcJAjJgl5OIBeRk/R4o+DzoHk0HF0 C1qFRtAV7zvI3z7ITEt/cCduwjW4FH0RHcG12IFt6FaxvB5XoPsyDQ+iOfQs +hz6DLoDxdEEKNCf0SvoOqgZRdOZVoQ/P/xDaBtdjjCHBrsR6DIzsAIDLwhW BPXPoh3oSnQJugvm+hl6DepG0O9hjkVeqzP5PPDxefj8KKSHaeUoPN9Iy5Io DLMjdC+aReuWTiZ7DOUwCZDPtSCXV9CLUDSHtqDOzAxtuAoXoX8D3F8Hzu5i JOhn+B10BuY4hzVQ8jCs+BX8MtrGyoDLu9A5tBf4/lnqx6mfL5yT9Mmw9KS8 HyHftkh4547tlw9vCw5tGRzYsL5/XV/v2jWBbv9qX1fnqo72ttaW5qbGBm99 Xa3HXVPtqqqsKHeWlfIlDq64qLDAnp9ns1rMJqNBr9Nq1CplriJHLpNKWAaj amxL2rqHenYn87pHkio+wOu4pOqScxs8SWSwO3g95/UEa8RWSakriYz9SdPG oVPI1xJMylzLm1ySZMt0f3ZA5w12ricpKYNffl0onKwYGHLwuhftmfog9Enm dw85HPYkUwa/fVAFv+tCXDip2wjlDrtQ0pdEG4dIOr3wWgsUohZHEPKBoWRR +jEYXInJR8Cyzixj8xI8rzulyusOJJHpFFK9lkRm0uxcC0i6I1nhAkZ0QNHR kCeJTX9OYmMSmzcAy0unIN1eaVkBg57wbr4nHAVEwyOLmJ4TEHVw89z8wJDe CyRluj/51KahU8rcbr47kgsFiBagU7lKKFGSAhhi5hRWdWJKMKqetlMMylED fAbCbg9Ju5O+W0aA4AOAG9QYF2tOL5y5NbsKQbc0ZRQogYmkrDspF5jgoklf KIlu4U5Vn5m/9bQOjY64VGE+HLp8KMmGoMEpxJb1TAwmC/o3boMimArSyARH xB2gGREe1zPBzcMzaTsCOR8gQl9SHp6IjBA1wSN8AOoU3UM3Oc7Ykwb47Enq XUk1NFNf9bqdne+xRTnyOD9/E5f8PLCbVesgOSiBDVif7+FhNhisZ7efiMST ERvVxr4wFY7vlhCXPDS6W9C90K1p/XfM65KqtxwgHZAP9KQdRSjDI7sJy7tD ZJk9u7n5WyJ0qbfSpYG+cj27AySRjqD9aAv03jbUM8H3LE4ICweCLVve1+FI 5rlIx/n5HsJiKAzcCyxDxSL/xCbsLgz8dCd9g/QDDVIZwIy+UCAoFokNtpFu pGYkEAw6BLlD06S87Capm+fmyYjysqTJpXM8AXVnaqr7B4Z6Ana6+iTTPbTq DZv9DaD7N2aKsQ3azHvesAsY9W/m+zcJWjCRzkYGBQNmMpKHpmJ7OuozNvsz An350Bp+zcj8/BqeWzM/Mh86vXBolOd0/PwplWp+pmeEo+aPofzfb7En19wa TOpGJnAblRAZjiO6t2agP2ncNExEtYabCAmOo4t3tNgd+kybje9VLdocaD/Y ALG5ed0fgTcVeCc7t4a4mtPgIexJXQsxWWBoyxDYxBjVX5qBrWyGwe3Eathg WU90swgWaKaoPMQHbhJLYRCHg9jTLad9aBQekoc2DQnPHBq1P4B8HhfIcYTU nEnXmLeQmkPpmkz3ER7kZuvf/A/0O1u35/W8gWv1UPyp6w0nzwzCGt9uSea0 iKI3dg+xdkakGDtLqFwXuLKOpNVFOxJMwGPO63juWT6pcyWl3UNn7B1BTqcH V4ehTa+LWBB41Gf572LiR5FJl8QdSWwh5Qj8KnXvrLUFKjOKxPXMj4ialr0s cTMIT6y8Nmij42F5dqG93sCTFT5N3ZvotcvWELuyO4QW64JJDfHNSc0faQb8 2ruHOPBEYLmbKMH1cBNE2EluJEBdQtCeXXx64ZWRAHGBwDJpYhdVHHIB2qW6 VlP9QRX9ECj6tbcGJ9pgFF8VrIBrhGmptQwOiSi12EWLInP1kaUsrc+gmG4D wgfDcyRr879rA0XNt70RXAny/sElT1mT0bqWjGcYHEqucaUHF57XuuzZj73L qvvS1eA+DtivItsIg/yneHzzplM+fPPmbUOPQGjM3Tw49ACDme4Rf/BUKdQN PcJBEERLGVJKCskDRx5QP4bRHmByaHv7Iz6EDtFaCS2gz2OnMaJlOekyjMZO M0KZLl3GQJlEKPPRMiGq6LFNAARDPAg9nPRtHPpIcGJ+JEjARhZBAUGz+U6U ZPjOU5iRqZK5fMSfVPJ+Ut5FyruEchkpl/N+UH8wDo6Y+vwID+YPDngI2XGQ qDBRF6aMO72wAB70GfC8jqSs7HJI4GAVriAHWrwO2q0laQSK1yYPjYUIH0RN WeLL+8aCyZzMgNCkL6mAERTiCNBiDe1DdgHoNAbKGuIpCcVgHIeCyaCLTDoU JQNwHMRDvXxbUuYUxpQ6yUSe4LyBr6fbiawsmVt2E/lQAG/EEdISOzzCZEEB JLkKOB/joWpshAO0JWhsMyijxEl+c+1CSQR2dYkzQlOuXaxEggUp1blJhZvs VXJKK90wIPzKg0GBefp0k9gA5tYllcCRMwtKsQOgA1V9hBf4vQlYJU0fJ8Ns Oo0G+CvBBgnTdCQ5VCfVZX0hcDhCfyWU8C3pzjBWDi0iYzwhlMrJylU0oB08 vXCS3+/I+qmp5mF3HiKKiewQQ/pQcH55QXIYHGfO8lI1LZ6fz1Gv3EHAK0ed +SSFXE8UdBVxsKcAjDJnX+iWFkNDDaD9GJwPb5QOogpUjWpRA6rwmdFhbd6N Nvsxs+4TJarjUrNFWlCiRV1dXbpf617XvY49b3her6vFjQ2dTHMn29jg5Es0 jJxvbGry1hcxZhM8aFiz2WrmG7HeoSeJaZZZqkqtTrt2dSdXW5qnGOk40r1m rLNAW9pRzTnNcsPt+N0LMjb0bgv+jcVSVtVYnufxtvL9A6bS+qLrityF3jWV zs5Va2oc1eUVBbLpe+5JvS751Pldkv9652vAPUb2hb/LH4RzNo+uBjvr3jLk q5Ap8lmr3KFjbTbriYCN1XI8a9Bq4ECkM+g5HTxZWUVZoRWCQ6/ubL3e2qr3 eoVf5LF6u1x6ZPXqrd66WrvPvOJgyLa0XRA3wQnMWd7oMAMImGcxj90MeZTJ zCarEXuNsq0ak9eL7ymrryhKHfnP11J/fSf1vKWkimPyG+oLv46LX/s9m3Jv dzTUSfz+nMp1W8+fZr/67hbJyICPy/H7Ze6qxpkLfey770rIncsIQtIIrLoF 3SOuurZKzarv8FXxlqo7amtNcglrtQDDMouhrNbLltTxfMmJAM+igy6lsq1K c7AAVv9qvaHV430VkZWQhdi6vHRNLlhf/hsusn7nBxzW9p5jBMtMFovV7Gjs ZBpBI0xFLH1gG/UNAkQaxgzlDU4BPtYsOa+uaLzwVluJJtUhUVkrCi/8pcxl lknNLiejbizX4SfU5U1MbnWFXnp+Q6tT7fdri5q34DtSMb7DmW+U+/251squ WnaHx1eRlwu1pe0bUg/gS9a3l2n9fpW9qqEJvP3uhXNSpzSCNKgQbRUxtCED azjqQ0a5nbUf9ckluQes1mLtAZZgBVABUrAkWKsIjm55e6Eq3SAo5ZC+wVDq hQ8TI5NhncFbDyg0MGA5DPPN1E9SL92GLWewC1cHv/SrVPiOYxsmuwu7rhm7 46M6PIS3voq7TqS+krrv0dSb9w0w30v9IPXS5mNPX/UkVh9J/UHQAmYKtKAA DYorMFtNZtOJgJmVKXIUJwI56KBGU1SoN+BWWAHyEBkJkiLsa5c3ti1pAIK7 WFasmcEXCaWy3JRzfin4O2s7K20AvjKvtK2FaOzgwjn2ecC7Dr0k8Pqgsqys xgpRpK9DY+61oryNeSN5rILNM5kK2cKjPpOkVgcVtdo6rGHrampYlj1aY8yz 2Sodh3S62spDcrkX+WpBNPnPENmQpG/1PIO6iAR0T+zcsb3VJYhDfDCAncO6 Fyeu/sAT+2qMadm+98hBo8XiraeewFnuBgdJHKPFqufdDF9CHAHYAfGTMhlf 4izX/zxv7or2Ha3uXcOXHAzWXfWb48EvTBwxtg91t25rqNkdufqj3bM/uW3X z0N40765imB35/CAu3wwcmX/1V8LGm2ply/dXl1xaUvblk0NvqvvGLn6oZDV ghtAIdAwIP139hzKQxz6lqgXbZyR5Y77ZoxYayw2XmrcaZRYWKMxl82FJR/3 5epQHlayeSxrYS3HfKwlDxkO5+eXcMbDsrSfePNsPcpaNCH1BgR6BQ/bRYPw /JPTLMF0hRGDZRQrEUmLlfxzUJCbWScYkUzO/mLXU9f97g/7X75z+Mgo5zSa 8IUb8TXXrb9q7aOS3o0bhhUPT25bOP+FP+yv6m/s2rR570Nfbe3F/Z+86zN3 AlIdC+ckOkCqAnnRORGpDcpKtvJzPp9yo5KZUWKlUqI1F5uvMbO5rNlu17G6 4z67rsJ5MlCBsJf1II/Ow5gkEg/ruUtiQVhZIeEOe72NOSafufqGHALeC/nP 6IlyWr1UNWFxxE16XEsWDw22XyGiuOpfZ8EnSWP6j6YJlpVTbAHc0jKisURF YTPvZAnSZtFPs1RtqVIzX9YOfHrrZdesxg7srPK73d1N6kcvv2rfDs/+O3pl alNhRepW26ePBTrcA7XXSzf2ds303fkVy87tkUoueOnDldWFKt/t16Su8vfy ZnWuH/9YMjnRubpuwA2+oQ8h9hjIwYnOiFJo0WMlytHlMAo2R+JjlAZliZLV SyRKVnnMJ9E57y0t5U8GSrWWPFveyYAtxyeXVzhBZwupthJ1zX8m4+5g7b9K Y5Jv0z1DoPFSD+j+56ZZdJDvNWQQW4mqgs0TQMFb6rM2P+pDy7z4++q+T21b 1f2QvtltaawxyjRV9SljbZlaaiyvxYaD7Cb2svXq1B/bOu113oaG1OM717sU fr+6qncn/vQ6OGTlgqsG1IidfxZQK0KzImpFOuUhpZE1HvcpdUgiKWALjkks Op8WYczZrpeLu5j3xfyMk6RrgAU8TWOdi7sv6tPSxrDObMuEkI+ulyE+DrSF 3bhh9JuTL71+4Pef2HSP/6y2o6Ws21tUPbqxbRyj7SObF/7ypT9dbTW9ueOy suFPzs3ds7Ue1tMGEelN0uOoHc2nI7lyvYatqqw6GdBVmtuLYJNl7eA2dC3N JwMtqA3nHDabV7Vzh2vTPgo26C5R4UFOmViELK7wfcdCtpX7kcAu2x7ScqT+ HMoktExCylgiWz1+dvi2/ukrm1mV2WlP2T28Wl1cV+Hc3MzKlIaSgpSlqMSo kbC5JmcVNh9gL9/Uven4/tSd1RvchSbYPJVV63ZiaTi2qsizyZ36SMsqR77F AOVyY155j49VXbap2WHK8WsufIdogB4QexX2fw+6WUTMyel0SGHLL69irRVi xCrPVeSeCChKq3CBlcMHtdq6WjEgaD1bD/FvdlgALgN8lbBP+vLfe7AloUJW pyDODvAwbINCFAx6YTUaF4NkVs68I9NZK/kLP66ss8lTb/Imq6MgjzFvyCv4 yjft5soyfIedr2qD4CL1n43NJWa9FECwVK2uwwamo4+vLNWwEGr483s7Ujfj WHNfaWklA1GyuWZbL0FmO8THBYBMLfqoiEylUuUsl5gdHszVOhzciYCDzTEb LWYLBEDlOZUlKq382srKeu219nSwlz4R0CWmlwplBmsrQcf+PgOK8FzUK4hJ BKXnARjesugbSHxFw18MBV6nvpF6CmlBhcOqSqU6h12KXG15U+pGEnGpKxvx MTzq2F2pU+aa+UrpFr/aULSq6/wJNvdz2370p9Rj/R28BrCxVXZ62FB/q1Pj v/DJtrNDf8L2f1/dVmRS+QEfP2jOTwGfkoytOQ1IA/GORuvLl2vlrPyoT8s6 MMInAsigt6t9GvtBmayUFzUHXIjuxYyHFcxG9IP1VHXee7SM6izvFRSQEA6V cCLg3VKeF9QJX11VZ5Nt6vB5SpRHJJ88YrTYi0q8lb1Uhfxya9XqWvZXBR2R GrwzdU/AV1NkULxrF9UGMQtvgzaUSC8HT+lAJ8X1QlDusDuKsdQh1WkdDrvF wksVDoW2GLPFENJjbGcxVmhZudnG5loV2VpPTzmgIcT3CyELcUD1EHx6yUlS d9OZMyTV2X3F//KAQeyQ07Mj9TnNsOcWMYQWTKjMwbLlqS0OjWEitaWsxZ2P 78FKvM5SVOu68OOGeo0uNYInPo9P7qzorxoF9yGpXr9WsvX85/u7yhX0LFm8 vu1HDPmaATKDJrwMmuBH30jHigqbq13ib8Q6I7ta7/evPhHws8UlXrbJ0djY dCLQaFNwknZX2WqXzVjbrlA3qo1lHBeQrK5tJCfqJ+ih8ol66hKyElpcasZp CJbE/aMJs2Fa0hfsSYyrrc3ZJ3AWC56ZlIEplcvpzpTGkiW+mrncU67hnNv3 V9iry/FnCxsC/T/Ga/S8I8+mvvBCdZVcr8+/5YvG/FxXRWrU0by6FUvfrWyv KDaDwUkdJXpXh+/TD7R3lXLlEn93Dr9pT+rpC7+2N1aalOCYpByvKqgorv7V m4W1FXZ7BRzpcysvGcB78RcD2zwmiZ8g35YaYJ+TfgKxyOrLRZixs6CmmPF4 CX6wkdXVYsxj9rkL7u8wL0g/8fb/kvdAWzjzSX4G8uJQNWpF94kya6xuZVuP +qotiuqjtbUWiB+PWnwW84mAhVVAXHhU4aP6xqGaooNl7EGvt7265qA2s22+ ACcnIiCyu9Pzq0hlXwR8sBmIqN5zlCD4N3JNxGefKetJVA/F0jLx6MSXAPbi QQp2Wp599NY7u488ctuF45kT520za3f0dK5JnUt9Nzzb7ts7tMbfvmHn1YHS 3nD/Lcz3q0/OhT++s3rpPYBSW+a4avC1K1xte3ZsDlVJU6UX9rOeuV29412F IA3jwluSHvYV8BHj6WgKa/RsoTZfojRLi4oKTwaKtHLYBeXyQqWekxSmb49a 6Sax9NbItFJXQGHpnZF4ObRkWxQvjhiZpzr/9rtNptpqfEMhX1ztTD31aOpt e0llEfuKX1FaWrsh1Y+vqe3jq5rl/m5FftXmwQsbmL9f2l4sA49HImpmlTQG +mJHD4rraWUZlh3zaZlLGWaBwVrmW8wvgJAoEKNjGB3L6O/VajUnA1ptnsQu ORmww1ZrOJyTU1ggOv0ndE8siamJv9qx/YpZUUNq/9nxl4bTS0YDcByNbFbQ LMZa+LnUf+6uK1Mr8lwl2HhADKps0tjf/vbO8zRCfq6uo9QoD+RcaE0HT+KZ WOKFWFkL8l287aGxLrIoIBQ87lPoVNfbbJzuesl73vYsa7/8tocepjoZiBfJ GR+TcxO57aEnK6b9zh9eue7wN/f8+a2rXks9uHOkca3LsHN7YMCpG//l/Tc+ cWjVwlv3/WGW0b7wfNOu24I/+uFlXyM+YhPE+NuAbw96XuD6EcQv/PabCl1v Ls8b+dMLv/XVCQ+s1egzQsh+3KhDHjhke6p91SzLHq+22KzW8uIbtFp3+Q0y WR3yuVe+MhE34jRJrjRcRLnJ2i+e1fH+s4KfENF5n2HF+5Jl1yVm4bokc1sC 7qKkvPFHtomt/Rv4TaPNod6qicc/0ndr7LC12e/2X1LQO75jb2fH5CeGv/w9 rBkeDqyubGt02dr6tjVvO7xGZfqdb429o8nZ5HWVb4mt2zS3vszzJ+G0wdTC acOKNqbvzsymkxC6WbFELpOfDMjQYbU6z7bs7qyLqoJ2eVNbVnUQp+O6xXMB flpV5k0H/wozDf6xY2evS31xbE/0tSM1IBkHufOoDj0k8tdAJmPlJ30yu/le o9HAGk76jNpaa01+DVtzzJevc5Sz5cd9Dkvh9VVVXrOllEWHlUSXrfXLtFk4 4winul+JBWRZFR90hmzNX3mwoHTJwZeCIKdnY4twAVauN4nCp2cp/LSusiGl 8ZTpWKWp3InNV2tVlx279IEHos8eHx/bErw8tPXymi1N3+jvLFX5/ZqSVevZ PWs7quymnEDOHezmvvPvfP13c/m48+q5x7/x5Bn3lkaC4ghY/TzImAP7SUc3 jdQdIw6bStnS4z6TTpbD5twrk0lBjDJFrod1qV2s65hPbclRWAFBj6eu4npd 2iWQOxy6RHK14qFLzlywiLpR+YEnSOP3XmOBIpGgT8o3ly85bDemLxJE7MQL GkmB1FDhSZ3br9D23t338EPTL32yekubzOisB2VL/WJgS2ew5rJh15Y2XLp+ TZU9t1txO+679J3z9/7uSqVueE/Qk5/brbmArtob/Lf4d77tCrYJNzOyV0AP g+gHIn6+nFIlLOwYuSPAAdYn8bE+clcSvHfr1stOBrZqrfl1DX3S9d68/v71 JwP9+sNFOdWHW4paWoqGg6jn8Mb0DU2rx6N7tV4nWpYY3C3qkDVzQqAXi//k rKJBvu+o4l0NqKn4AuuiM75GQsqYxTKJeO6/+E7ne6rho+vXjQbMkWObNkYD xcL5v6imRK0q8Tjzq2s4o1yq48tSpW5eJVWZ7WUFZZualaU1KUfWzc8Qu2WN s699x/qqocOXL7sVUG27wlegc5RUNbSn/j3QW11Ibter+kawyj/cUpWvcQ94 Ugd29LuUy6+KqBQl5H6tFR0TpeiyMq1sfl7+yQDOM5ffW1ZWejJQpq3Qa2rg 0HbMV6PzHpbJ2osqyo2Hi4jA9F59xocIBi+Auni/wv2jEbO9xdLOQcc/xFdu JftqWkaSYym7u1QtU1sLSgucAy2qMk+qcBFGrapzx3jrwGR3IZWCX+nq24mV a4fbyvNUns2e1DU7112E0u1sc1eZZ9t1l6WOCqhT/wEB+SUQa9ehVeg7InLN 9vxqr7ea9cKZrhrOdNXVcNCtZ+uPanwa9YmAhq0rYUoxZk4EsD2/pvWgpZTv 8tYcpJdv9bof1r/w6uJZSICCxsiZi2/xAEgPRlUffK7MjcP7DkmRXoy8068j 5GZygqKgO8vLScxNRcDqMwEMM5X1vmft3i93NvSW98yNrguVd1Vtbk1d09Z3 CV/f2NymqWiaHNs4scp66OBlS8NvR0nBliv6R2/dXpnL7Rm4eXg417/xc19d 77ORC4tSjeQzF15wbZjovPlmEfcO+l6rBu0XcXcUwB50tMBXYD8RKGC15E2N 1qfVnQhoZQfKyz2FB82ZsO3iEwgBM+89B1jpzELcQ30RC+jAMVwuyz6xYHC3 zU3kn3haYSZOvnLfnoa+vtWPXr37nlRbGih8j6Fvur+lfLWjdNcj13bapVsa Zj79zLWfeXvo0l1mw1J4zpeynK2qZ/rKrz92fh8DNrt+4Zy0mN5gTYoIWCRy B1skLS4uOgH+xVjNVh/1GY3q01jxUG1tfflB2/K4VTwq06vdFftmdptMyyBe fA+rN2lYvsTNZL/8I+6Qbjbsc2pnMz5dWmWRVQwe+EzoY09c3b74MtDUuGPd rnClZFt/e6lWfCV44baPnJxdU9S+794bmZvEV7P07eCFyUuv214/cOdRWPU4 7NirpRGI0v93Ot5FC+d8jRpzLxjkRmaEYRUsU1AgZaVHfQUSPXlRp9dqsYbV muDkrTxqMsLJw6fTcTkH0njkP/PC+7wUpNEtEl8GfrA5fKb3fRlIb0HpfTij J298m5qavXqygZeCLRlKYceRrL7ZNjH4uS98/La+y5tNR6YfHn029fcDd+Ki JyNfkjalXr5iT+q51IupP6R+WTcaTD2Xb7sLe377El59n0V89y9ZB5rhxqo0 RuqFM771ClWvOkfngw+dzpxjZs1HfTluRw6c1hGDYUVuN7mIc/vcNScCbrbI 4bCwlqMOn6PkRMCh1mm1FgYX+YqLa3MsB8vTNwP5z7xITgrP1GcZle6Jriwa liye7+HprMelOytASljq+H9hKdsqP8CUBHPquUTA0w+dkmYvm2W9Et8Rh9u3 4SeHq+sd2iuu0JR4PIdf4mudvL3IcMT4bmXaeKVbUt/e2V2e4vLaVqV2t63K v/B7hcVZ3duVunOp5YJEOhFindLPoDJ0QrTVeiNZtFF7SAsrOu7T4iI4JkiL 1vrsWh6awdZYWFhs9BmK7cUyVfFhiaTcKR40vGf1Xt2L9Hy2eL1a78o6TVFv 5viHE2Tdsy7vHmwmWyt519dM31YJb29g5zV7zby4+w5CKH6Vp8ymYXV/+NFl 3TfrKx0ut/7xx2mYTgNwZqJHri90lz74iObp5obW6M71By4cp/E50dJxyBLY jVikeYhNMvh+hnjmN+pq6VeDEqm/YHfqB9gt3NXLwvS7LF9Nn3Sa7D6Fqddu b6hA3uYiM9vQ4D0RaGAVKidbqayoqDwRqLDnNzWVNJul1+j1bY3FJde6M2/+ XvV6Da2LN/fipaHVS2MYAIU6RP4DTLHs2nHJCEFMvraSfYHf1MzDToHf+24f O2ThRqdWVdZ6YaG6xKiQsWaVvSz112Tq13lGQ66mqoHc8FukamcLfhObcTX+ odSo5dv737171Vr61RVDYXsA/37Tz9wVG8YuuFlXT+DLr6Ya1rWR78Dk2io6 a9nQ+pZSnf/d77ON9G534e9S2HXAmw6LyObJ4FBjkpuF730UabWaoiITq+Dy TStcZ6U3D+2yTumLrJW/+5T1xSeL1cg+qNV7G/H9zkZXYWr7b1IPkztqprKh XmU8K1FXrausa5D4/bKynkvOf0kykrmfdnT1XKgH3TkOy/gy+wpQcpSDSh9g kuxpcCwajb6XzdHKkzLMSO+XgcjBQb3R9aIrrV+QjPjLoGTq1F/uYr9MNO3C EZIzD4i7zJ9hl6nOfD8iN99K32/ZeES+GOJauhe4XDJWdtTnknA8D9HsUd7I +HARaJ4794BT3GXefGHZW9XF74Z40qeYZbM43n8WH29c9u71oiFFp1cigzDO QI/TjVlfqpKXy3j6DSRi5JL9R6zt2/vGjg+17w8ODeaaS1wMqi9V3x7Y96nU z1Kv7nrol9f9VFqben1wuGZ/6r++f39q4WPRuHP9as5EvmHl7GpN3VTU24e3 4G0PY9PXL03vROWgXy4sE3EcQLyO5/gkL+GLtM5ip8f5LadEwTqdriIXWwSL cxXmINtG24htxgblNrOZxGFm35LvIfHOMvBePqu1pggd1CxuRemNSLwzzN4P yOkkvR/Ao+7sdoJ34L+Dm6xbyn804wrfmFphU2Kw8Obz1+mthn2SbkmPH/J4 HcorrlCV1LsPnU+/9FTYKn217HZhrxG2JLYw0Jla39VTQGRgS/0cHwQ/qkEm n0L+DU1Sm8OeUnlePYt0b5Fva1rofYu8nATy5XiPIrdp3+QGV51Zhd2V4YrN hw6s3+ocHF+/LU7/jlP6611V3+z9005tx9+QUviju0d+fXxV+m/aFt5ODcgf hJ0OIwXE6eIfuoH/bk+14tDiH9ct+7u8SmkAPSY/hezSs2hEejvazTyNRiR2 NIj/D2hQFxqW9KIO9hTqY88AfRa1SV5EemkMbZcWIr+0eeFtyV+QWaJEbdIm 6NeFjMxh1Cf5GBpmv4Y2Mfug/ZOoA9KIvBjKX0B90n6Y54uQomi95C40Lrkb jTCfQZ34p2hc9h0Y14jMzCp0XFoNdVE0AuU24DOMfoEP4deYFuYN5g32Oska yavSPulrsphsQb43R5LzeM7PFDcr/pS7L/d55SHlf6hm1Ub1W5qj2ku0z+r6 dT/XnzDUGnoMfzZuNh40lZheN+dSJCrRNuFPMQExHfKgXRAt/EA1CD6N1HqY NhElNXM8g5gGTdInlj6FWYlIY6RhJ0SaQTnsXpFmURt7UKQlyMaeFmkp0M+K tAzo34q0HL1DWSJ0DqqSvCPSCrRGWirSufJc6W6RVqLLVAmRVqEK1fdEGnhW /VmkgWftfEb29dq3RBojua5CpBkk0XlEmkWFOq9IS5BKt1GkpUBfLtIyoCdE Wo4O6BIinYPMujdFWoF4vUykc9kb9JUirUQu032Zv042mV4SaTVeb3pDpDUI WVqJJCQKgnOGBpwtnxVpwNnyVZEGnC3fEGnA2fKGSAPOVqlIA87WQpEGnK2N Ig042zwiDTjbgiINONvuFmnAufgrIg04Fy+INODMlYs04FzyLRREMTSHODSF Qmg/fM6hOIrAZwJNoCjQHOhZDE3DMwctyPMM1M9C+yiUJYAOQ9ko7Uv6kL49 aAtaj1aLfWezambgKQY95tAYHTEKI3NoH51rDPKV5xWeSdsxNAl9w+KsCWjB AUXqZ6BGWEEI2oXFuaLiCGPiWBGau6Fk+bpJ/SSlKqBXJXxGoG40M9NKXE1f NPIHx2hx9DAdaRzKZuE5Di1mKRoJyMnYK69dmP1ivtqzECArEdaSoPPNUGmE 6PjCWsNQso+uPAbl77VSAefQEkwjVK4xMRdWJdBz8DRDc45yu5euJpIZh7Sc hBbvL6EJitwMagNP5wEeyT83RXSM6lAc0i7akvScgjYJWBFZ4Thd4wyMsJ96 SWHcONCEm11QNwfzk54hqjdXoq/A/PWoFv61ArXhojk41E1XmsYvLRmiR6th rEn4HICyccp1nD5FqB3NwuqJvNwwQohKnKw4hPzQfxLKL56rjc6W3ZbLtG7L 8Nn0nm0uo7PGRQ451Ahzt0KPpe1rMu2XjyPIPkI1Ny3TkKib47RWkH3aLmap 3kSoHc2iPRmdCL1n7a5/CuNsTSc6tAWeohmb2gxUiD7FM3rvWUErx6heTou2 RVq7/wkeNtA8JmoY4aKPrmg8Y7lpixuEklmq5YNi2310rD0wx3KkJ0RfQbxA hK4xTDkjejQtrm9XZi3TILM45TfdmlChLO+R5kGwMmLRMYr4OKXCop8V+mbb cZj2JauP01UJ+kz4uEpEiqw3kcXxXorqfqone8URiSWFgL/l3AgeX0B00aOR MQMUh3FaEqJzpvsI4yeofIQaMjNBdpKOny1tTrSzKGAllM5SCc1SLyPIcC+l 99O2CcoP4bE6s/NM0h4TlEeyasFjhEQcVho9G6k0H2k8s6UgeF0BNwHPRR72 iPvAdEaGccp3KEtvE7TvtNgrPVNM9K5CuynK4yRdpYDsYMaHp+VM5DIjrlOo maJ6T0YRNFvw0SHQxnSrbKuLiniQVvGMJs1mIoWIqHH7aOkYXW+E2t0ExSxE 9zPBM2WjOAfzkWgge0+LUzubzNoxRikdylpzlKIzKu6X6V03QntNiXtIPONt BBsMgwVFRbtNI7U1YxEr+0EhGsq2xDG6t2TvzWnbSdsLmXWvKD/irTmq/YJ2 VGfhtagxs8DZxUhdbFNxqqNz1G+nUYlTqQg7j6Djgm+eo/LM5nwRLSHOEHbB RY2JLPNAAgbTqJz22U2xSKCler58hjnaW7DQOBLiizEoXZRJW9Zswp4yR+10 lsopklnLSv4xAnv10pn3ifuUsN8I44yLuEToKIIGTIlWle01xuhOMC3GJnHA jsif7IpLMVkr+tw9Wb27obUQRQk28cG8+ZzIuaBHk9QC03YwI0YL0ay9W+A9 lNkFBb2YztqZBB+VoJY7lelBcJoRfWg84+eEGC5KZbHoodI4CTuSsL/HxAhU GH2a7mLZHihErSltr1OiJkUzO1SUWgiXtV9mY/HfF9sRS1mM71YedbE+PdqH J54PTzz/n594vsLV19a2chuiY7OxeGxXguuOzc7EZkOJaGzaza2enOQGouMT iTg3EIlHZvdGwu7u0NTobDTkj02GM73aOLGUI8VtZMym7JLLIrNxGJBrdLfW iuU1pDzdJhrnItHERGSWC3GzkfFoPBGZjYS5xGwoHJkKze7hYqQm63HXyhxz 0WkOhuG2TEcT0H9zIpSIxLnQdNgDA8ToBGOxuenEbDQSd684wobYdCyxfybC 9U2FxqPT46QzNxidjXGDULovNrsnnmZ6IhTnRiORaS4ciUfHp2G+XWSW6Zr4 2Cwpno2EwukREjFuMhbbw43HYmFu3wTUzsxGpwmPoQQXnwoBzvHoVcAU15eg A++NzO7nInuhYXwmNJYeZmY2BowSPqFlIBoaj02HJmkNtE9Ex+BhIhSdnYxO C8vmQGbRXUDORoCdSVjh3sjkfi6emI1Nj1cDI9HJCDcRm41eFZtOQOes5gJT ZAzCp7CEyNQM8AZ80hH2RDgoB9biHGBHsE1MhIDfBOkUm0sQSUzFI5N7ybIG J0DGZM1j0RmYEx6mYvEEB2BHxyKhUVIkiC4KfETH4gQk4IKUTMb2RWbHQvEI NzYRmg2NgW6ILM6NhucihEGYdD8MASyORgii0C06CzTMAFhGJiNTkWnQYVAb kGC4JgqyJUxtJYLI0sG5uCjEsdAMBZlKh8iFiwHAoNbcTAzgqKZ8UWBmazJM ZSQVn4jNTYYJK/FJYjyAOGjz3Jg4OGVrNhKfm0xQYCKiAgEH0+UJbvccVAuY pzvMxYlA41w4NjZHV9JGu4GlzE2GZrl9ETLLoj5GrhQ77wObAruBNuPASyRB AJgKkTKiGmPRyPQYlO+fGo1NipysBc3dQ6u7989GJ0ESK6j5HAwOGE3G4kQG M+AWotS6YfTQtIDKNDUm0KhEJDRFKiJXQrtEnOhcjAtFpyJUoQhPYEhg76CD RHunI/sEBQrNUrlOAUhRYlDRGZAqsUuBC/dEIjHT5vHs27fPPZW2Y/dYbMoD jWLjs6GZif2escQuUOt4VlP6TJoFY3OAxH4icZAliJ7UEF0BLqeiCWKYo/up lHu2rF9NpUAewP5AjkQ8xHbGJrL6wico9+RcWFhZOBqfmYQJBKsFTMDxEJkm 3Fx67tg0KEZFtBLMapR0WhxqOt14RY5oc+pZQInAlY0JqpqZnRqSOFY7ZaAi CrMkwHrByYFU94Mi7ZuejIWyJwWeQ6JTmuUy3hLMeAYsORzZC2ZK2kxEJmeW LejDS7MPL80+vDRDH16afXhp9uGl2YeXZh9emn14afbhpdmHl2YfXpr9j700 S3/PCX4WrkcJtMLPI4jDRQ8qbHgddxoXpomCNGFNE5Y0YUgT+jShTRPqNJGb JhRpIidNyNKENE1IfL+j1Hmav0Pz39P8dZr/kuav0vxlmv+Y5s/T/BmaP03z 79L8KZqfpfkTNP82zc/Q/FGan6L5/TS/lea30Hye5kdofiPNb6D5YZpfT/Pr aH4tzQ/R/BqaH6T5AZpvovlGmvfRvJfkntUe7ERdkC6FtBNSDNI1kG6DdDek +yF9C9J/QFKiYlyKPJC6IF0KaSekGKRrIN0G6W5I90P6FiQlCJL3XYl/8YrF WvDCDyG7+iMW+9UfyXvuB0Dv3QfZ1AxkkzHI9kxb7Humr5nNT8yZzAXjuyHb FYUsMmGyRyZuuCI/L265qjvPsR+S/Enrk8xvfotdiW9g62O4/MWRx2YeO/SY 5JOfYly+T+Gdd+I7jjIu8q1e3R/sha2KMdvYk2MsN6bWttL/0tza4rJW3b2R g62fO84X2z7hrGr9xHHs6j2O7zrGuHTHunytLx3DyqQ9eTjJrlZjOZaCWrqw TPyUiJ9SX988ct0C6Qik+Rtkrmuvwa4DB6Wug4dLim++AbtugnT4Bqnrekj2 ZrOtyWxuNBsazFqvWVVvVtSZZbVm1mNGbvNpzPkOdXc6nOWainKttgpXvL3g evvv2rf+S/PXv2lq36p9mzn3Nq5yaapd2hJeU8pri4o1XLFWq9OryP/dQybP UbESqQphRiVjw8VKbb+WUYKHCrC7FAn2JsVX0QnFT7UKJVKySm07alcE2WHF Xjah/TT6tOKT2kcUP0GaR7ADl/gMWjsuVNvk+Wqzzqo2SEzq4tUa7CBf0oNc B8kDqQvS3ZC+hR0+p6y6o6qjosPZUdpR0sF1FHXYO2wd5g5Dh7ZD0SHrYDtQ x0bvIE4a+lH/oD9pxPC52Z/0uvpPs9xAst7Vn1RsHB46hfHHglCaZG4+jdFg UnLzaQY+DN3bhodO4zxSfYP9EYQxSvaP3PDRoMtVmAyT/yz1ocJgsp4QtxcG UX+yflPSzvtdy3/iCfFjbklp8q89ybd7oqHk23wg+VZPFB5Gkm/xgbhQW9WT rO4JJSug0MkHlgyIl42PYAJhDvIRj8NUcUIlbckuWO9yfk4pyMI3DvjJf3m9 Pxke6E/aNw6PJPN5f3/yKXhq2jicVPH+eDx+CjHdg6cYkskgGx4eWl2Ii1AY F0IqgGSFZIFkgKSHpIWkhpQLSQEpB5IMkhSSxLchfD78Tvj34dfDvwy/Gn45 /OPw8+Fnwk+Hvxt+Knw2/ET42+Ez4UfDp8L3h28N3xKeDx8J3xi+IXw4fH34 uvC14UPha8IHwwfCm8Ibw33h3vBFQH+Qn+C/1Ov/An3+lXkKZW5kc3RyZWFt CmVuZG9iagoKMTQ3IDAgb2JqCjEyNTU0CmVuZG9iagoKMTQ4IDAgb2JqCjw8 L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkFBQUFBK0NhbWJyaWEt Qm9sZAovRmxhZ3MgNAovRm9udEJCb3hbLTExMDkgLTI5OCAxMzcxIDEwNDZd L0l0YWxpY0FuZ2xlIDAKL0FzY2VudCAxMDEzCi9EZXNjZW50IC0yMjIKL0Nh cEhlaWdodCAxMDQ2Ci9TdGVtViA4MAovRm9udEZpbGUyIDE0NiAwIFIKPj4K ZW5kb2JqCgoxNDkgMCBvYmoKPDwvTGVuZ3RoIDQwMC9GaWx0ZXIvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJxdkk1vgkAQhu/8ij3ag4FdETQxJBY18dCP1PYH IIyWpCxkwYP/vvvObNukB8mzs/PxCBOXx93RtlP86vr6RJO6tLZxNPY3V5M6 07W1kTaqaespnPhZd9UQxb72dB8n6o720m82Ufzm78bJ3dVs2/RneojiF9eQ a+1VzT7Kkz+fbsPwRR3ZSSVRUaiGLr7PUzU8Vx3FXDU/Nv66ne5zX/KX8H4f SBk+a1Gp+4bGoarJVfZK0SZJCrU5HIqIbPPvLk2k5HypPyvnU7VPTZJlXng2 zOkKvBA+gFPhNXgp+QtwxmwScM6cLcErYQ1eM+cGvJU41z4K86xSenL/ncza g/cST8EHiaOnTiSOWi3+Bp46+GOWFv88A4t/hv5a/DPOF/8cPjr4l2Dxz/G/ tPhncNDBfwcO/vDUwZ/nBn/OD/54Jzr4Y5YR/xRxI/4ZPI34G/Q04f1jlhH/ JeeI/2ILFv8U386If8o54m9KXoDwpbEK2NWfFVP1zTm/XrzQvFfYqNbS784P /YAq/n0DV67IygplbmRzdHJlYW0KZW5kb2JqCgoxNTAgMCBvYmoKPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0NhbWJy aWEtQm9sZAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDQwCi9XaWR0aHNbNjU4 IDk2MSA3MjEgNjk1IDM0OSA1MTMgMjIwIDUzMCA1MzUgNDYxIDQ2OCA1OTYg NjA0IDY3OSA2MzkgNjUxCjYxOCA1MDUgNjUxIDUzMCAzMTQgNTY5IDQ1OCAz MDggNTk3IDU5NyA4OTAgNjAzIDY2MSA3MDQgNjc2IDU3Mwo1NzcgMzI2IDIz MSA4NDYgNjM0IDI3OSA2NDYgNTUxIDIzMSBdCi9Gb250RGVzY3JpcHRvciAx NDggMCBSCi9Ub1VuaWNvZGUgMTQ5IDAgUgo+PgplbmRvYmoKCjE1MSAwIG9i ago8PC9GMSAxNTAgMCBSL0YyIDE0NSAwIFIKPj4KZW5kb2JqCgoxNTIgMCBv YmoKPDwvRm9udCAxNTEgMCBSCi9YT2JqZWN0PDwvSW0yMyAyMyAwIFIvSW0y NyAyNyAwIFIvSW03OSA3OSAwIFIvSW04MyA4MyAwIFIvVHIxMjIgMTIyIDAg Ui9UcjEzNyAxMzcgMCBSL1RyNTkgNTkgMCBSPj4KL0V4dEdTdGF0ZTw8L0VH UzEyMyAxMjMgMCBSL0VHUzEzOCAxMzggMCBSL0VHUzYwIDYwIDAgUj4+Ci9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJL0ltYWdlQl0KPj4KZW5k b2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTQwIDAgUi9SZXNv dXJjZXMgMTUyIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vQW5ub3RzWwox MzkgMCBSIF0KL1N0cnVjdFBhcmVudHMgMAovQ29udGVudHMgMiAwIFI+Pgpl bmRvYmoKCjYzIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTQwIDAgUi9S ZXNvdXJjZXMgMTUyIDAgUi9NZWRpYUJveFswIDAgNjEyIDc5Ml0vU3RydWN0 UGFyZW50cyAxCi9Db250ZW50cyA2NCAwIFI+PgplbmRvYmoKCjEyNiAwIG9i ago8PC9UeXBlL1BhZ2UvUGFyZW50IDE0MCAwIFIvUmVzb3VyY2VzIDE1MiAw IFIvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1N0cnVjdFBhcmVudHMgMgovQ29u dGVudHMgMTI3IDAgUj4+CmVuZG9iagoKMTUzIDAgb2JqCjw8L04gMy9MZW5n dGggMTU0IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylkLFL AlEcx7+eSVGGQQUNDTdIQ+iQLY1lgxAiYgZZLXenp8Gpx91JRGNDq4NLRUsW /Qe1Rf9AEATVUkvNDQURhFzf5wlC6NQ73vt9+L7f9917X0CqG1rZlsaAcsWx Mom4vJ7bkAefEYCESQxgTtFscymdTqLv+HqAT9T7qDirf1/PMZIv2BrgGyIv aKblkBfJqR3HFFwnT2glJU8+I0csXpB8J3TV4zfBRY+/BVvZzDIgBcly0eOI YNVj8RZZK1llskEOl42a1rmPeEmwUFlbZZ1uTxsZJBCHDBU1bMOAgyhrhZn1 9sXavhSq9GhcTezCoqOIEr0RqjWeWmDVqRf4GezgENn/zdTW52PeH4IrQODV dT9ngcFjoHXguj+nrttqAv4n4KbR9VcbjPOder2rhU+A0D5wed3V1HPgihlP vZiKpbQlP6ek68DHBTCaA8aZ9fDmf/e9vDv7aD4C2T0geQscHgEz7A9t/QKV 2XR+CmVuZHN0cmVhbQplbmRvYmoKCjE1NCAwIG9iagozNjkKZW5kb2JqCgox NTUgMCBvYmoKPDwvVHlwZS9PdXRwdXRJbnRlbnQvUy9HVFNfUERGQTEvT3V0 cHV0Q29uZGl0aW9uSWRlbnRpZmllcihzUkdCIElFQzYxOTY2LTIuMSkvRGVz dE91dHB1dFByb2ZpbGUgMTUzIDAgUj4+CmVuZG9iagoKMTU2IDAgb2JqCjw8 L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDMwNjM+PgpzdHJl YW0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRh LyI+CiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogIDxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSIiCiAgICAgIHhtbG5zOnBkZmFpZD0iaHR0cDovL3d3dy5h aWltLm9yZy9wZGZhL25zL2lkLyI+CiAgIDxwZGZhaWQ6cGFydD4xPC9wZGZh aWQ6cGFydD4KICAgPHBkZmFpZDpjb25mb3JtYW5jZT5BPC9wZGZhaWQ6Y29u Zm9ybWFuY2U+CiAgPC9yZGY6RGVzY3JpcHRpb24+CiAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgPGRjOmNyZWF0b3I+CiAgICA8 cmRmOlNlcT4KICAgICA8cmRmOmxpPlN0ZXZlIFNoZW5nPC9yZGY6bGk+CiAg ICA8L3JkZjpTZXE+CiAgIDwvZGM6Y3JlYXRvcj4KICA8L3JkZjpEZXNjcmlw dGlvbj4KICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgIHht bG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgIDxw ZGY6UHJvZHVjZXI+TGlicmVPZmZpY2UgNC4wPC9wZGY6UHJvZHVjZXI+CiAg PC9yZGY6RGVzY3JpcHRpb24+CiAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9IiIKICAgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLyI+CiAgIDx4bXA6Q3JlYXRvclRvb2w+V3JpdGVyPC94bXA6Q3JlYXRv clRvb2w+CiAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDEzLTA1LTAyVDE3OjA0OjQ4 LTA0OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICA8L3JkZjpEZXNjcmlwdGlvbj4K IDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9 InciPz4KCmVuZHN0cmVhbQplbmRvYmoKCjE1OCAwIG9iago8PC9PL0xheW91 dAovUGxhY2VtZW50L0Jsb2NrCi9UZXh0QWxpZ24vQ2VudGVyCj4+CmVuZG9i agoKNSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1Ag NCAwIFIKL1BnIDEgMCBSCi9BIDE1OCAwIFIKL0tbMCBdCj4+CmVuZG9iagoK MTU5IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKL1RleHRB bGlnbi9DZW50ZXIKPj4KZW5kb2JqCgo2IDAgb2JqCjw8L1R5cGUvU3RydWN0 RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0EgMTU5IDAg UgovS1sxIF0KPj4KZW5kb2JqCgoxNjAgMCBvYmoKPDwvTy9MYXlvdXQKL1Bs YWNlbWVudC9CbG9jawovVGV4dEFsaWduL0NlbnRlcgo+PgplbmRvYmoKCjcg MCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBS Ci9QZyAxIDAgUgovQSAxNjAgMCBSCi9LWzIgXQo+PgplbmRvYmoKCjE2MSAw IG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2NrCi9UZXh0QWxpZ24v Q2VudGVyCj4+CmVuZG9iagoKOCAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0K L1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDEgMCBSCi9BIDE2MSAwIFIKL0tb MyBdCj4+CmVuZG9iagoKMTYyIDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1l bnQvQmxvY2sKPj4KZW5kb2JqCgo5IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxl bQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0EgMTYyIDAgUgo+ PgplbmRvYmoKCjE2MyAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Js b2NrCj4+CmVuZG9iagoKMTAgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAxNjMgMCBSCj4+CmVu ZG9iagoKMTY0IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sK Pj4KZW5kb2JqCgoxMSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3Rh bmRhcmQKL1AgNCAwIFIKL1BnIDEgMCBSCi9BIDE2NCAwIFIKL0tbNCBdCj4+ CmVuZG9iagoKMTY1IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxv Y2sKPj4KZW5kb2JqCgoxMiAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1Mv U3RhbmRhcmQKL1AgNCAwIFIKL1BnIDEgMCBSCi9BIDE2NSAwIFIKPj4KZW5k b2JqCgoxNjYgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+ PgplbmRvYmoKCjEzIDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFu ZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0EgMTY2IDAgUgovS1s1IF0KPj4K ZW5kb2JqCgoxNjcgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9j awo+PgplbmRvYmoKCjE0IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9T dGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0EgMTY3IDAgUgo+PgplbmRv YmoKCjE2OCAwIG9iago8PC9UeXBlL09CSlIvT2JqIDEzOSAwIFI+PgplbmRv YmoKCjE2OSAwIG9iago8PC9PL0xheW91dAovQmFzZWxpbmVTaGlmdCA5LjgK Pj4KZW5kb2JqCgoxNiAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTGlu awovUCAxNSAwIFIKL1BnIDEgMCBSCi9BIDE2OSAwIFIKL0tbNyAxNjggMCBS IF0KPj4KZW5kb2JqCgoxNzAgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVu dC9CbG9jawo+PgplbmRvYmoKCjE1IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxl bQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0EgMTcwIDAgUgov S1s2IDE2IDAgUiA4IF0KPj4KZW5kb2JqCgoxNzEgMCBvYmoKPDwvTy9MYXlv dXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjE3IDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIK L0EgMTcxIDAgUgo+PgplbmRvYmoKCjE3MiAwIG9iago8PC9PL0xheW91dAov UGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMTggMCBvYmoKPDwvVHlwZS9T dHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAx NzIgMCBSCi9LWzkgXQo+PgplbmRvYmoKCjE3MyAwIG9iago8PC9PL0xheW91 dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMTkgMCBvYmoKPDwvVHlw ZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgov QSAxNzMgMCBSCj4+CmVuZG9iagoKMTc0IDAgb2JqCjw8L08vTGF5b3V0Ci9C YXNlbGluZVNoaWZ0IC0xOS42Cj4+CmVuZG9iagoKMjEgMCBvYmoKPDwvVHlw ZS9TdHJ1Y3RFbGVtCi9TL1NwYW4KL1AgMjAgMCBSCi9QZyAxIDAgUgovQSAx NzQgMCBSCj4+CmVuZG9iagoKMTc1IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFj ZW1lbnQvQmxvY2sKL1dpZHRoIDE1MAovSGVpZ2h0IDgyCi9CQm94WzkwIDQx MC43IDE2NSA0NTEuN10KPj4KZW5kb2JqCgoyMiAwIG9iago8PC9UeXBlL1N0 cnVjdEVsZW0KL1MvRmlndXJlCi9QIDIwIDAgUgovUGcgMSAwIFIKL0EgMTc1 IDAgUgovS1sxMCBdCj4+CmVuZG9iagoKMTc2IDAgb2JqCjw8L08vTGF5b3V0 Ci9CYXNlbGluZVNoaWZ0IC0xOS42Cj4+CmVuZG9iagoKMjQgMCBvYmoKPDwv VHlwZS9TdHJ1Y3RFbGVtCi9TL1NwYW4KL1AgMjAgMCBSCi9QZyAxIDAgUgov QSAxNzYgMCBSCj4+CmVuZG9iagoKMTc3IDAgb2JqCjw8L08vTGF5b3V0Ci9C YXNlbGluZVNoaWZ0IC0xOS42Cj4+CmVuZG9iagoKMjUgMCBvYmoKPDwvVHlw ZS9TdHJ1Y3RFbGVtCi9TL1NwYW4KL1AgMjAgMCBSCi9QZyAxIDAgUgovQSAx NzcgMCBSCj4+CmVuZG9iagoKMTc4IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFj ZW1lbnQvQmxvY2sKL1dpZHRoIDI0MgovSGVpZ2h0IDg0Ci9CQm94WzE3MC4z IDQxMC43IDI5MS4zIDQ1Mi43XQo+PgplbmRvYmoKCjI2IDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9GaWd1cmUKL1AgMjAgMCBSCi9QZyAxIDAgUgov QSAxNzggMCBSCi9LWzEyIF0KPj4KZW5kb2JqCgoxNzkgMCBvYmoKPDwvTy9M YXlvdXQKL0Jhc2VsaW5lU2hpZnQgLTE5LjYKPj4KZW5kb2JqCgoyOCAwIG9i ago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3BhbgovUCAyMCAwIFIKL1BnIDEg MCBSCi9BIDE3OSAwIFIKPj4KZW5kb2JqCgoxODAgMCBvYmoKPDwvTy9MYXlv dXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjIwIDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIK L0EgMTgwIDAgUgovS1syMSAwIFIgMjIgMCBSIDI0IDAgUiAxMSAyNSAwIFIg MjYgMCBSIDI4IDAgUiBdCj4+CmVuZG9iagoKMTgxIDAgb2JqCjw8L08vTGF5 b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgoyOSAwIG9iago8PC9U eXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDEgMCBS Ci9BIDE4MSAwIFIKPj4KZW5kb2JqCgoxODIgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjMwIDAgb2JqCjw8L1R5cGUv U3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0Eg MTgyIDAgUgo+PgplbmRvYmoKCjE4MyAwIG9iago8PC9PL0xheW91dAovUGxh Y2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMzEgMCBvYmoKPDwvVHlwZS9TdHJ1 Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAxODMg MCBSCi9LWzEzIF0KPj4KZW5kb2JqCgoxODQgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjMyIDAgb2JqCjw8L1R5cGUv U3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0Eg MTg0IDAgUgo+PgplbmRvYmoKCjE4NSAwIG9iago8PC9PL0xheW91dAovUGxh Y2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMzMgMCBvYmoKPDwvVHlwZS9TdHJ1 Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAxODUg MCBSCi9LWzE0IF0KPj4KZW5kb2JqCgoxODYgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjM0IDAgb2JqCjw8L1R5cGUv U3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIKL0Eg MTg2IDAgUgo+PgplbmRvYmoKCjE4NyAwIG9iago8PC9PL0xheW91dAovUGxh Y2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMzggMCBvYmoKPDwvVHlwZS9TdHJ1 Y3RFbGVtCi9TL0xpc3QjMjBQYXJhZ3JhcGgKL1AgMzcgMCBSCi9QZyAxIDAg UgovQSAxODcgMCBSCi9LWzE1IF0KPj4KZW5kb2JqCgozNyAwIG9iago8PC9U eXBlL1N0cnVjdEVsZW0KL1MvTEJvZHkKL1AgMzYgMCBSCi9QZyAxIDAgUgov S1szOCAwIFIgXQo+PgplbmRvYmoKCjM2IDAgb2JqCjw8L1R5cGUvU3RydWN0 RWxlbQovUy9MSQovUCAzNSAwIFIKL1BnIDEgMCBSCi9LWzM3IDAgUiBdCj4+ CmVuZG9iagoKMzUgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0wKL1Ag NCAwIFIKL1BnIDEgMCBSCi9LWzM2IDAgUiBdCj4+CmVuZG9iagoKMTg4IDAg b2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgoz OSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAw IFIKL1BnIDEgMCBSCi9BIDE4OCAwIFIKPj4KZW5kb2JqCgoxODkgMCBvYmoK PDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjQwIDAg b2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgov UGcgMSAwIFIKL0EgMTg5IDAgUgovS1sxNiBdCj4+CmVuZG9iagoKMTkwIDAg b2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo0 MSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAw IFIKL1BnIDEgMCBSCi9BIDE5MCAwIFIKPj4KZW5kb2JqCgoxOTEgMCBvYmoK PDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjQ1IDAg b2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9MaXN0IzIwUGFyYWdyYXBoCi9Q IDQ0IDAgUgovUGcgMSAwIFIKL0EgMTkxIDAgUgovS1sxNyBdCj4+CmVuZG9i agoKNDQgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xCb2R5Ci9QIDQz IDAgUgovUGcgMSAwIFIKL0tbNDUgMCBSIF0KPj4KZW5kb2JqCgo0MyAwIG9i ago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTEkKL1AgNDIgMCBSCi9QZyAxIDAg UgovS1s0NCAwIFIgXQo+PgplbmRvYmoKCjQyIDAgb2JqCjw8L1R5cGUvU3Ry dWN0RWxlbQovUy9MCi9QIDQgMCBSCi9QZyAxIDAgUgovS1s0MyAwIFIgXQo+ PgplbmRvYmoKCjE5MiAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Js b2NrCj4+CmVuZG9iagoKNDYgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAxOTIgMCBSCj4+CmVu ZG9iagoKMTkzIDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sK Pj4KZW5kb2JqCgo0NyAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3Rh bmRhcmQKL1AgNCAwIFIKL1BnIDEgMCBSCi9BIDE5MyAwIFIKL0tbMTggXQo+ PgplbmRvYmoKCjE5NCAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Js b2NrCj4+CmVuZG9iagoKNDggMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAxOTQgMCBSCj4+CmVu ZG9iagoKMTk1IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sK Pj4KZW5kb2JqCgo1MiAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTGlz dCMyMFBhcmFncmFwaAovUCA1MSAwIFIKL1BnIDEgMCBSCi9BIDE5NSAwIFIK L0tbMTkgXQo+PgplbmRvYmoKCjUxIDAgb2JqCjw8L1R5cGUvU3RydWN0RWxl bQovUy9MQm9keQovUCA1MCAwIFIKL1BnIDEgMCBSCi9LWzUyIDAgUiBdCj4+ CmVuZG9iagoKNTAgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xJCi9Q IDQ5IDAgUgovUGcgMSAwIFIKL0tbNTEgMCBSIF0KPj4KZW5kb2JqCgo0OSAw IG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTAovUCA0IDAgUgovUGcgMSAw IFIKL0tbNTAgMCBSIF0KPj4KZW5kb2JqCgoxOTYgMCBvYmoKPDwvTy9MYXlv dXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjUzIDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIK L0EgMTk2IDAgUgo+PgplbmRvYmoKCjE5NyAwIG9iago8PC9PL0xheW91dAov UGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKNTQgMCBvYmoKPDwvVHlwZS9T dHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxIDAgUgovQSAx OTcgMCBSCi9LWzIwIF0KPj4KZW5kb2JqCgoxOTggMCBvYmoKPDwvTy9MYXlv dXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjU1IDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgMSAwIFIK L0EgMTk4IDAgUgo+PgplbmRvYmoKCjE5OSAwIG9iago8PC9PL0xheW91dAov UGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKNTggMCBvYmoKPDwvVHlwZS9T dHJ1Y3RFbGVtCi9TL0Zvb3Rub3RlCi9QIDU3IDAgUgovUGcgMSAwIFIKL0Eg MTk5IDAgUgovS1syMSBdCj4+CmVuZG9iagoKNTcgMCBvYmoKPDwvVHlwZS9T dHJ1Y3RFbGVtCi9TL05vdGUKL1AgNTYgMCBSCi9QZyAxIDAgUgovS1s1OCAw IFIgXQo+PgplbmRvYmoKCjU2IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQov Uy9EaXYKL1AgNCAwIFIKL1BnIDEgMCBSCi9LWzU3IDAgUiBdCj4+CmVuZG9i agoKMjAwIDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4K ZW5kb2JqCgo2OSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTGlzdCMy MFBhcmFncmFwaAovUCA2OCAwIFIKL1BnIDYzIDAgUgovQSAyMDAgMCBSCi9L WzAgXQo+PgplbmRvYmoKCjY4IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQov Uy9MQm9keQovUCA2NyAwIFIKL1BnIDYzIDAgUgovS1s2OSAwIFIgXQo+Pgpl bmRvYmoKCjY3IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9MSQovUCA2 NiAwIFIKL1BnIDYzIDAgUgovS1s2OCAwIFIgXQo+PgplbmRvYmoKCjY2IDAg b2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9MCi9QIDQgMCBSCi9QZyA2MyAw IFIKL0tbNjcgMCBSIF0KPj4KZW5kb2JqCgoyMDEgMCBvYmoKPDwvTy9MYXlv dXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjcwIDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgNjMgMCBS Ci9BIDIwMSAwIFIKPj4KZW5kb2JqCgoyMDIgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjcxIDAgb2JqCjw8L1R5cGUv U3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgNjMgMCBSCi9B IDIwMiAwIFIKL0tbMSBdCj4+CmVuZG9iagoKMjAzIDAgb2JqCjw8L08vTGF5 b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo3MiAwIG9iago8PC9U eXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYzIDAg UgovQSAyMDMgMCBSCj4+CmVuZG9iagoKMjA0IDAgb2JqCjw8L08vTGF5b3V0 Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo3MyAwIG9iago8PC9UeXBl L1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYzIDAgUgov QSAyMDQgMCBSCj4+CmVuZG9iagoKMjA1IDAgb2JqCjw8L08vTGF5b3V0Ci9Q bGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo3NCAwIG9iago8PC9UeXBlL1N0 cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYzIDAgUgovQSAy MDUgMCBSCi9LWzIgXQo+PgplbmRvYmoKCjIwNiAwIG9iago8PC9PL0xheW91 dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKNzUgMCBvYmoKPDwvVHlw ZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyA2MyAwIFIK L0EgMjA2IDAgUgo+PgplbmRvYmoKCjIwNyAwIG9iago8PC9PL0xheW91dAov QmFzZWxpbmVTaGlmdCAtMTkuNgo+PgplbmRvYmoKCjc3IDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TcGFuCi9QIDc2IDAgUgovUGcgNjMgMCBSCi9B IDIwNyAwIFIKPj4KZW5kb2JqCgoyMDggMCBvYmoKPDwvTy9MYXlvdXQKL1Bs YWNlbWVudC9CbG9jawovV2lkdGggMTM0Ci9IZWlnaHQgMTEwCi9CQm94Wzkw IDU0Ni4yIDE1NyA2MDEuMl0KPj4KZW5kb2JqCgo3OCAwIG9iago8PC9UeXBl L1N0cnVjdEVsZW0KL1MvRmlndXJlCi9QIDc2IDAgUgovUGcgNjMgMCBSCi9B IDIwOCAwIFIKL0tbMyBdCj4+CmVuZG9iagoKMjA5IDAgb2JqCjw8L08vTGF5 b3V0Ci9CYXNlbGluZVNoaWZ0IC0xOS42Cj4+CmVuZG9iagoKODAgMCBvYmoK PDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1NwYW4KL1AgNzYgMCBSCi9QZyA2MyAw IFIKL0EgMjA5IDAgUgo+PgplbmRvYmoKCjIxMCAwIG9iago8PC9PL0xheW91 dAovQmFzZWxpbmVTaGlmdCAtMTkuNgo+PgplbmRvYmoKCjgxIDAgb2JqCjw8 L1R5cGUvU3RydWN0RWxlbQovUy9TcGFuCi9QIDc2IDAgUgovUGcgNjMgMCBS Ci9BIDIxMCAwIFIKPj4KZW5kb2JqCgoyMTEgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawovV2lkdGggMzA0Ci9IZWlnaHQgNjgKL0JCb3hb MTYyLjMgNTQ2LjIgMzE0LjMgNTgwLjJdCj4+CmVuZG9iagoKODIgMCBvYmoK PDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0ZpZ3VyZQovUCA3NiAwIFIKL1BnIDYz IDAgUgovQSAyMTEgMCBSCi9LWzUgXQo+PgplbmRvYmoKCjIxMiAwIG9iago8 PC9PL0xheW91dAovQmFzZWxpbmVTaGlmdCAtMTkuNgo+PgplbmRvYmoKCjg0 IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TcGFuCi9QIDc2IDAgUgov UGcgNjMgMCBSCi9BIDIxMiAwIFIKPj4KZW5kb2JqCgoyMTMgMCBvYmoKPDwv Ty9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjc2IDAgb2Jq Cjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcg NjMgMCBSCi9BIDIxMyAwIFIKL0tbNzcgMCBSIDc4IDAgUiA4MCAwIFIgNCA4 MSAwIFIgODIgMCBSIDg0IDAgUiBdCj4+CmVuZG9iagoKMjE0IDAgb2JqCjw8 L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo4NSAwIG9i ago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1Bn IDYzIDAgUgovQSAyMTQgMCBSCj4+CmVuZG9iagoKMjE1IDAgb2JqCjw8L08v TGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgo4NiAwIG9iago8 PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYz IDAgUgovQSAyMTUgMCBSCi9LWzYgXQo+PgplbmRvYmoKCjIxNiAwIG9iago8 PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKODcgMCBv YmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9Q ZyA2MyAwIFIKL0EgMjE2IDAgUgo+PgplbmRvYmoKCjIxNyAwIG9iago8PC9P L0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKODggMCBvYmoK PDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyA2 MyAwIFIKL0EgMjE3IDAgUgovS1s3IF0KPj4KZW5kb2JqCgoyMTggMCBvYmoK PDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjg5IDAg b2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgov UGcgNjMgMCBSCi9BIDIxOCAwIFIKPj4KZW5kb2JqCgoyMTkgMCBvYmoKPDwv Ty9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjkzIDAgb2Jq Cjw8L1R5cGUvU3RydWN0RWxlbQovUy9MaXN0IzIwUGFyYWdyYXBoCi9QIDky IDAgUgovUGcgNjMgMCBSCi9BIDIxOSAwIFIKL0tbOCBdCj4+CmVuZG9iagoK OTIgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xCb2R5Ci9QIDkxIDAg UgovUGcgNjMgMCBSCi9LWzkzIDAgUiBdCj4+CmVuZG9iagoKOTEgMCBvYmoK PDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xJCi9QIDkwIDAgUgovUGcgNjMgMCBS Ci9LWzkyIDAgUiBdCj4+CmVuZG9iagoKOTAgMCBvYmoKPDwvVHlwZS9TdHJ1 Y3RFbGVtCi9TL0wKL1AgNCAwIFIKL1BnIDYzIDAgUgovS1s5MSAwIFIgXQo+ PgplbmRvYmoKCjIyMCAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Js b2NrCj4+CmVuZG9iagoKOTQgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L1N0YW5kYXJkCi9QIDQgMCBSCi9QZyA2MyAwIFIKL0EgMjIwIDAgUgo+Pgpl bmRvYmoKCjIyMSAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2Nr Cj4+CmVuZG9iagoKOTUgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0 YW5kYXJkCi9QIDQgMCBSCi9QZyA2MyAwIFIKL0EgMjIxIDAgUgovS1s5IF0K Pj4KZW5kb2JqCgoyMjIgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9C bG9jawo+PgplbmRvYmoKCjk2IDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQov Uy9TdGFuZGFyZAovUCA0IDAgUgovUGcgNjMgMCBSCi9BIDIyMiAwIFIKPj4K ZW5kb2JqCgoyMjMgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9j awo+PgplbmRvYmoKCjEwMCAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1Mv TGlzdCMyMFBhcmFncmFwaAovUCA5OSAwIFIKL1BnIDYzIDAgUgovQSAyMjMg MCBSCi9LWzEwIF0KPj4KZW5kb2JqCgo5OSAwIG9iago8PC9UeXBlL1N0cnVj dEVsZW0KL1MvTEJvZHkKL1AgOTggMCBSCi9QZyA2MyAwIFIKL0tbMTAwIDAg UiBdCj4+CmVuZG9iagoKOTggMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L0xJCi9QIDk3IDAgUgovUGcgNjMgMCBSCi9LWzk5IDAgUiBdCj4+CmVuZG9i agoKOTcgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0wKL1AgNCAwIFIK L1BnIDYzIDAgUgovS1s5OCAwIFIgXQo+PgplbmRvYmoKCjIyNCAwIG9iago8 PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMTAxIDAg b2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgov UGcgNjMgMCBSCi9BIDIyNCAwIFIKPj4KZW5kb2JqCgoyMjUgMCBvYmoKPDwv Ty9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjEwMiAwIG9i ago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1Bn IDYzIDAgUgovQSAyMjUgMCBSCi9LWzExIF0KPj4KZW5kb2JqCgoyMjYgMCBv YmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjEw MyAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAw IFIKL1BnIDYzIDAgUgovQSAyMjYgMCBSCj4+CmVuZG9iagoKMjI3IDAgb2Jq Cjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgoxMDcg MCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xpc3QjMjBQYXJhZ3JhcGgK L1AgMTA2IDAgUgovUGcgNjMgMCBSCi9BIDIyNyAwIFIKL0tbMTIgXQo+Pgpl bmRvYmoKCjEwNiAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTEJvZHkK L1AgMTA1IDAgUgovUGcgNjMgMCBSCi9LWzEwNyAwIFIgXQo+PgplbmRvYmoK CjEwNSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTEkKL1AgMTA0IDAg UgovUGcgNjMgMCBSCi9LWzEwNiAwIFIgXQo+PgplbmRvYmoKCjEwNCAwIG9i ago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTAovUCA0IDAgUgovUGcgNjMgMCBS Ci9LWzEwNSAwIFIgXQo+PgplbmRvYmoKCjIyOCAwIG9iago8PC9PL0xheW91 dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMTA4IDAgb2JqCjw8L1R5 cGUvU3RydWN0RWxlbQovUy9TdGFuZGFyZAovUCA0IDAgUgovUGcgNjMgMCBS Ci9BIDIyOCAwIFIKPj4KZW5kb2JqCgoyMjkgMCBvYmoKPDwvTy9MYXlvdXQK L1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjEwOSAwIG9iago8PC9UeXBl L1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYzIDAgUgov QSAyMjkgMCBSCi9LWzEzIF0KPj4KZW5kb2JqCgoyMzAgMCBvYmoKPDwvTy9M YXlvdXQKL1BsYWNlbWVudC9CbG9jawo+PgplbmRvYmoKCjExMCAwIG9iago8 PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3RhbmRhcmQKL1AgNCAwIFIKL1BnIDYz IDAgUgovQSAyMzAgMCBSCj4+CmVuZG9iagoKMjMxIDAgb2JqCjw8L08vTGF5 b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgoxMTEgMCBvYmoKPDwv VHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9QZyA2MyAw IFIKL0EgMjMxIDAgUgovS1sxNCBdCj4+CmVuZG9iagoKMjMyIDAgb2JqCjw8 L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4KZW5kb2JqCgoxMTIgMCBv YmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5kYXJkCi9QIDQgMCBSCi9Q ZyA2MyAwIFIKL0EgMjMyIDAgUgo+PgplbmRvYmoKCjIzMyAwIG9iago8PC9P L0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVuZG9iagoKMTE2IDAgb2Jq Cjw8L1R5cGUvU3RydWN0RWxlbQovUy9MaXN0IzIwUGFyYWdyYXBoCi9QIDEx NSAwIFIKL1BnIDYzIDAgUgovQSAyMzMgMCBSCi9LWzE1IF0KPj4KZW5kb2Jq CgoxMTUgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xCb2R5Ci9QIDEx NCAwIFIKL1BnIDYzIDAgUgovS1sxMTYgMCBSIF0KPj4KZW5kb2JqCgoxMTQg MCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xJCi9QIDExMyAwIFIKL1Bn IDYzIDAgUgovS1sxMTUgMCBSIF0KPj4KZW5kb2JqCgoxMTMgMCBvYmoKPDwv VHlwZS9TdHJ1Y3RFbGVtCi9TL0wKL1AgNCAwIFIKL1BnIDYzIDAgUgovS1sx MTQgMCBSIF0KPj4KZW5kb2JqCgoyMzQgMCBvYmoKPDwvTy9MYXlvdXQKL1Bs YWNlbWVudC9CbG9jawovU3RhcnRJbmRlbnQgNzIKPj4KZW5kb2JqCgoxMTcg MCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xpc3QjMjBQYXJhZ3JhcGgK L1AgNCAwIFIKL1BnIDYzIDAgUgovQSAyMzQgMCBSCi9LWzE2IF0KPj4KZW5k b2JqCgoyMzUgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+ PgplbmRvYmoKCjExOCAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3Rh bmRhcmQKL1AgNCAwIFIKL1BnIDYzIDAgUgovQSAyMzUgMCBSCj4+CmVuZG9i agoKMjM2IDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4K ZW5kb2JqCgoxMTkgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5k YXJkCi9QIDQgMCBSCi9QZyA2MyAwIFIKL0EgMjM2IDAgUgo+PgplbmRvYmoK CjIzNyAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+CmVu ZG9iagoKMTIwIDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFuZGFy ZAovUCA0IDAgUgovUGcgNjMgMCBSCi9BIDIzNyAwIFIKL0tbMTcgXQo+Pgpl bmRvYmoKCjIzOCAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2Nr Cj4+CmVuZG9iagoKMTIxIDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9T dGFuZGFyZAovUCA0IDAgUgovUGcgNjMgMCBSCi9BIDIzOCAwIFIKPj4KZW5k b2JqCgoyMzkgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9jawo+ PgplbmRvYmoKCjEyOSAwIG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvU3Rh bmRhcmQKL1AgNCAwIFIKL1BnIDEyNiAwIFIKL0EgMjM5IDAgUgo+PgplbmRv YmoKCjI0MCAwIG9iago8PC9PL0xheW91dAovUGxhY2VtZW50L0Jsb2NrCj4+ CmVuZG9iagoKMTMwIDAgb2JqCjw8L1R5cGUvU3RydWN0RWxlbQovUy9TdGFu ZGFyZAovUCA0IDAgUgovUGcgMTI2IDAgUgovQSAyNDAgMCBSCj4+CmVuZG9i agoKMjQxIDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxvY2sKPj4K ZW5kb2JqCgoxMzEgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL1N0YW5k YXJkCi9QIDQgMCBSCi9QZyAxMjYgMCBSCi9BIDI0MSAwIFIKL0tbMCBdCj4+ CmVuZG9iagoKMjQyIDAgb2JqCjw8L08vTGF5b3V0Ci9QbGFjZW1lbnQvQmxv Y2sKPj4KZW5kb2JqCgoxMzIgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L1N0YW5kYXJkCi9QIDQgMCBSCi9QZyAxMjYgMCBSCi9BIDI0MiAwIFIKPj4K ZW5kb2JqCgoyNDMgMCBvYmoKPDwvTy9MYXlvdXQKL1BsYWNlbWVudC9CbG9j awovU3RhcnRJbmRlbnQgMzYKPj4KZW5kb2JqCgoxMzYgMCBvYmoKPDwvVHlw ZS9TdHJ1Y3RFbGVtCi9TL0xpc3QjMjBQYXJhZ3JhcGgKL1AgMTM1IDAgUgov UGcgMTI2IDAgUgovQSAyNDMgMCBSCi9LWzEgXQo+PgplbmRvYmoKCjEzNSAw IG9iago8PC9UeXBlL1N0cnVjdEVsZW0KL1MvTEJvZHkKL1AgMTM0IDAgUgov UGcgMTI2IDAgUgovS1sxMzYgMCBSIF0KPj4KZW5kb2JqCgoxMzQgMCBvYmoK PDwvVHlwZS9TdHJ1Y3RFbGVtCi9TL0xJCi9QIDEzMyAwIFIKL1BnIDEyNiAw IFIKL0tbMTM1IDAgUiBdCj4+CmVuZG9iagoKMTMzIDAgb2JqCjw8L1R5cGUv U3RydWN0RWxlbQovUy9MCi9QIDQgMCBSCi9QZyAxMjYgMCBSCi9LWzEzNCAw IFIgXQo+PgplbmRvYmoKCjQgMCBvYmoKPDwvVHlwZS9TdHJ1Y3RFbGVtCi9T L0RvY3VtZW50Ci9QIDE1NyAwIFIKL1BnIDEgMCBSCi9LWzUgMCBSIDYgMCBS IDcgMCBSIDggMCBSIDkgMCBSIDEwIDAgUiAxMSAwIFIgMTIgMCBSIDEzIDAg UiAxNCAwIFIgMTUgMCBSIDE3IDAgUiAxOCAwIFIgMTkgMCBSIDIwIDAgUiAy OSAwIFIKMzAgMCBSIDMxIDAgUiAzMiAwIFIgMzMgMCBSIDM0IDAgUiAzNSAw IFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgNDIgMCBSIDQ2IDAgUiA0NyAwIFIg NDggMCBSIDQ5IDAgUiA1MyAwIFIgNTQgMCBSCjU1IDAgUiA1NiAwIFIgNjYg MCBSIDcwIDAgUiA3MSAwIFIgNzIgMCBSIDczIDAgUiA3NCAwIFIgNzUgMCBS IDc2IDAgUiA4NSAwIFIgODYgMCBSIDg3IDAgUiA4OCAwIFIgODkgMCBSIDkw IDAgUgo5NCAwIFIgOTUgMCBSIDk2IDAgUiA5NyAwIFIgMTAxIDAgUiAxMDIg MCBSIDEwMyAwIFIgMTA0IDAgUiAxMDggMCBSIDEwOSAwIFIgMTEwIDAgUiAx MTEgMCBSIDExMiAwIFIgMTEzIDAgUiAxMTcgMCBSIDExOCAwIFIKMTE5IDAg UiAxMjAgMCBSIDEyMSAwIFIgMTI5IDAgUiAxMzAgMCBSIDEzMSAwIFIgMTMy IDAgUiAxMzMgMCBSIF0KPj4KZW5kb2JqCgoxNTcgMCBvYmoKPDwvVHlwZS9T dHJ1Y3RUcmVlUm9vdAovUGFyZW50VHJlZSAyNDQgMCBSCi9Sb2xlTWFwPDwv Rm9vdG5vdGUvUAovRGl2L0RpdgovTGlzdCMyMFBhcmFncmFwaC9QCi9MSS9M SQovTC9MCi9MQm9keS9MQm9keQovRmlndXJlL0ZpZ3VyZQovU3Bhbi9TcGFu Ci9MaW5rL0xpbmsKL1N0YW5kYXJkL1AKL05vdGUvTm90ZQovRG9jdW1lbnQv RG9jdW1lbnQKPj4KL0tbNCAwIFIgXQo+PgplbmRvYmoKCjI0NCAwIG9iago8 PC9OdW1zWwowIFsgNSAwIFIgNiAwIFIgNyAwIFIgOCAwIFIgMTEgMCBSIDEz IDAgUiAxNSAwIFIgMTYgMCBSIDE1IDAgUiAxOCAwIFIKMjIgMCBSIDIwIDAg UiAyNiAwIFIgMzEgMCBSIDMzIDAgUiAzOCAwIFIgNDAgMCBSIDQ1IDAgUiA0 NyAwIFIgNTIgMCBSCjU0IDAgUiA1OCAwIFIgXQoxIFsgNjkgMCBSIDcxIDAg UiA3NCAwIFIgNzggMCBSIDc2IDAgUiA4MiAwIFIgODYgMCBSIDg4IDAgUiA5 MyAwIFIgOTUgMCBSCjEwMCAwIFIgMTAyIDAgUiAxMDcgMCBSIDEwOSAwIFIg MTExIDAgUiAxMTYgMCBSIDExNyAwIFIgMTIwIDAgUiBdCjIgWyAxMzEgMCBS IDEzNiAwIFIgXQozIDE2IDAgUgpdPj4KZW5kb2JqCgoxNDAgMCBvYmoKPDwv VHlwZS9QYWdlcwovUmVzb3VyY2VzIDE1MiAwIFIKL01lZGlhQm94WyAwIDAg NjEyIDc5MiBdCi9LaWRzWyAxIDAgUiA2MyAwIFIgMTI2IDAgUiBdCi9Db3Vu dCAzPj4KZW5kb2JqCgoxMzkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9GIDQvU3Vi dHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs1MDAuOCA1NDEuOCA1MDYg NTU2LjddL0Rlc3RbMSAwIFIvWFlaIDkzLjcgODYuOSAwXS9TdHJ1Y3RQYXJl bnQgMz4+CmVuZG9iagoKMjQ1IDAgb2JqCjw8L1R5cGUvQ2F0YWxvZy9QYWdl cyAxNDAgMCBSCi9QYWdlTW9kZS9Vc2VUaHVtYnMKL09wZW5BY3Rpb25bMSAw IFIgL1hZWiBudWxsIG51bGwgMF0KL1N0cnVjdFRyZWVSb290IDE1NyAwIFIK L0xhbmcoZW4tVVMpCi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4KL091dHB1 dEludGVudHNbMTU1IDAgUl0vTWV0YWRhdGEgMTU2IDAgUj4+CmVuZG9iagoK MjQ2IDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA1MzAwNzQwMDY1MDA3NjAwNjUw MDIwMDA1MzAwNjgwMDY1MDA2RTAwNjc+Ci9DcmVhdG9yPEZFRkYwMDU3MDA3 MjAwNjkwMDc0MDA2NTAwNzI+Ci9Qcm9kdWNlcjxGRUZGMDA0QzAwNjkwMDYy MDA3MjAwNjUwMDRGMDA2NjAwNjYwMDY5MDA2MzAwNjUwMDIwMDAzNDAwMkUw MDMwPgovQ3JlYXRpb25EYXRlKEQ6MjAxMzA1MDIxNzA0NDgtMDQnMDAnKT4+ CmVuZG9iagoKeHJlZgowIDI0NwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAw NDMwMjUgMDAwMDAgbiAKMDAwMDAwMDAxOSAwMDAwMCBuIAowMDAwMDAxOTcw IDAwMDAwIG4gCjAwMDAwNjE0ODYgMDAwMDAgbiAKMDAwMDA0NzIwOCAwMDAw MCBuIAowMDAwMDQ3MzYzIDAwMDAwIG4gCjAwMDAwNDc1MTggMDAwMDAgbiAK MDAwMDA0NzY3MyAwMDAwMCBuIAowMDAwMDQ3ODEwIDAwMDAwIG4gCjAwMDAw NDc5NDAgMDAwMDAgbiAKMDAwMDA0ODA3MSAwMDAwMCBuIAowMDAwMDQ4MjA5 IDAwMDAwIG4gCjAwMDAwNDgzNDAgMDAwMDAgbiAKMDAwMDA0ODQ3OCAwMDAw MCBuIAowMDAwMDQ4Nzk5IDAwMDAwIG4gCjAwMDAwNDg2NTYgMDAwMDAgbiAK MDAwMDA0ODk0NiAwMDAwMCBuIAowMDAwMDQ5MDc3IDAwMDAwIG4gCjAwMDAw NDkyMTUgMDAwMDAgbiAKMDAwMDA1MDI1MSAwMDAwMCBuIAowMDAwMDQ5MzUw IDAwMDAwIG4gCjAwMDAwNDk1MjYgMDAwMDAgbiAKMDAwMDAwMzYxMiAwMDAw MCBuIAowMDAwMDQ5NjY4IDAwMDAwIG4gCjAwMDAwNDk4MDAgMDAwMDAgbiAK MDAwMDA0OTk4MSAwMDAwMCBuIAowMDAwMDAxOTkxIDAwMDAwIG4gCjAwMDAw NTAxMjMgMDAwMDAgbiAKMDAwMDA1MDQzMiAwMDAwMCBuIAowMDAwMDUwNTYz IDAwMDAwIG4gCjAwMDAwNTA2OTQgMDAwMDAgbiAKMDAwMDA1MDgzMyAwMDAw MCBuIAowMDAwMDUwOTY0IDAwMDAwIG4gCjAwMDAwNTExMDMgMDAwMDAgbiAK MDAwMDA1MTQ4OSAwMDAwMCBuIAowMDAwMDUxNDEyIDAwMDAwIG4gCjAwMDAw NTEzMzIgMDAwMDAgbiAKMDAwMDA1MTIzNCAwMDAwMCBuIAowMDAwMDUxNjE0 IDAwMDAwIG4gCjAwMDAwNTE3NDUgMDAwMDAgbiAKMDAwMDA1MTg4NCAwMDAw MCBuIAowMDAwMDUyMjcwIDAwMDAwIG4gCjAwMDAwNTIxOTMgMDAwMDAgbiAK MDAwMDA1MjExMyAwMDAwMCBuIAowMDAwMDUyMDE1IDAwMDAwIG4gCjAwMDAw NTIzOTUgMDAwMDAgbiAKMDAwMDA1MjUyNiAwMDAwMCBuIAowMDAwMDUyNjY1 IDAwMDAwIG4gCjAwMDAwNTMwNTEgMDAwMDAgbiAKMDAwMDA1Mjk3NCAwMDAw MCBuIAowMDAwMDUyODk0IDAwMDAwIG4gCjAwMDAwNTI3OTYgMDAwMDAgbiAK MDAwMDA1MzE3NiAwMDAwMCBuIAowMDAwMDUzMzA3IDAwMDAwIG4gCjAwMDAw NTM0NDYgMDAwMDAgbiAKMDAwMDA1Mzc0NiAwMDAwMCBuIAowMDAwMDUzNjY3 IDAwMDAwIG4gCjAwMDAwNTM1NzcgMDAwMDAgbiAKMDAwMDAwNDg5MiAwMDAw MCBuIAowMDAwMDA1MDI1IDAwMDAwIG4gCjAwMDAwMDM1OTAgMDAwMDAgbiAK MDAwMDAwNDg3MCAwMDAwMCBuIAowMDAwMDQzMTYyIDAwMDAwIG4gCjAwMDAw MDUwNjIgMDAwMDAgbiAKMDAwMDAwNjc2MyAwMDAwMCBuIAowMDAwMDU0MTMw IDAwMDAwIG4gCjAwMDAwNTQwNTIgMDAwMDAgbiAKMDAwMDA1Mzk3MSAwMDAw MCBuIAowMDAwMDUzODczIDAwMDAwIG4gCjAwMDAwNTQyNTYgMDAwMDAgbiAK MDAwMDA1NDM4OCAwMDAwMCBuIAowMDAwMDU0NTI3IDAwMDAwIG4gCjAwMDAw NTQ2NTkgMDAwMDAgbiAKMDAwMDA1NDc5MSAwMDAwMCBuIAowMDAwMDU0OTMw IDAwMDAwIG4gCjAwMDAwNTU5NzIgMDAwMDAgbiAKMDAwMDA1NTA2NiAwMDAw MCBuIAowMDAwMDU1MjQ0IDAwMDAwIG4gCjAwMDAwMDgzNDggMDAwMDAgbiAK MDAwMDA1NTM4NiAwMDAwMCBuIAowMDAwMDU1NTE5IDAwMDAwIG4gCjAwMDAw NTU3MDEgMDAwMDAgbiAKMDAwMDAwNjc4NSAwMDAwMCBuIAowMDAwMDU1ODQz IDAwMDAwIG4gCjAwMDAwNTYxNTMgMDAwMDAgbiAKMDAwMDA1NjI4NSAwMDAw MCBuIAowMDAwMDU2NDI0IDAwMDAwIG4gCjAwMDAwNTY1NTYgMDAwMDAgbiAK MDAwMDA1NjY5NSAwMDAwMCBuIAowMDAwMDU3MDg0IDAwMDAwIG4gCjAwMDAw NTcwMDYgMDAwMDAgbiAKMDAwMDA1NjkyNSAwMDAwMCBuIAowMDAwMDU2ODI3 IDAwMDAwIG4gCjAwMDAwNTcyMTAgMDAwMDAgbiAKMDAwMDA1NzM0MiAwMDAw MCBuIAowMDAwMDU3NDgxIDAwMDAwIG4gCjAwMDAwNTc4NzMgMDAwMDAgbiAK MDAwMDA1Nzc5NSAwMDAwMCBuIAowMDAwMDU3NzEzIDAwMDAwIG4gCjAwMDAw NTc2MTMgMDAwMDAgbiAKMDAwMDA1Nzk5OSAwMDAwMCBuIAowMDAwMDU4MTMy IDAwMDAwIG4gCjAwMDAwNTgyNzMgMDAwMDAgbiAKMDAwMDA1ODY3MiAwMDAw MCBuIAowMDAwMDU4NTkxIDAwMDAwIG4gCjAwMDAwNTg1MDcgMDAwMDAgbiAK MDAwMDA1ODQwNiAwMDAwMCBuIAowMDAwMDU4ODAwIDAwMDAwIG4gCjAwMDAw NTg5MzMgMDAwMDAgbiAKMDAwMDA1OTA3NCAwMDAwMCBuIAowMDAwMDU5MjA3 IDAwMDAwIG4gCjAwMDAwNTkzNDggMDAwMDAgbiAKMDAwMDA1OTc0NyAwMDAw MCBuIAowMDAwMDU5NjY2IDAwMDAwIG4gCjAwMDAwNTk1ODIgMDAwMDAgbiAK MDAwMDA1OTQ4MSAwMDAwMCBuIAowMDAwMDU5ODkxIDAwMDAwIG4gCjAwMDAw NjAwNDAgMDAwMDAgbiAKMDAwMDA2MDE3MyAwMDAwMCBuIAowMDAwMDYwMzA2 IDAwMDAwIG4gCjAwMDAwNjA0NDcgMDAwMDAgbiAKMDAwMDAwOTgxOSAwMDAw MCBuIAowMDAwMDA5OTUzIDAwMDAwIG4gCjAwMDAwMDgzMjUgMDAwMDAgbiAK MDAwMDAwOTc5NiAwMDAwMCBuIAowMDAwMDQzMjgyIDAwMDAwIG4gCjAwMDAw MDk5OTEgMDAwMDAgbiAKMDAwMDAxMDQ3MCAwMDAwMCBuIAowMDAwMDYwNTgw IDAwMDAwIG4gCjAwMDAwNjA3MTQgMDAwMDAgbiAKMDAwMDA2MDg0OCAwMDAw MCBuIAowMDAwMDYwOTg5IDAwMDAwIG4gCjAwMDAwNjE0MDcgMDAwMDAgbiAK MDAwMDA2MTMyNSAwMDAwMCBuIAowMDAwMDYxMjQwIDAwMDAwIG4gCjAwMDAw NjExMzkgMDAwMDAgbiAKMDAwMDAxMDQ5MiAwMDAwMCBuIAowMDAwMDEwNjI2 IDAwMDAwIG4gCjAwMDAwNjI3ODkgMDAwMDAgbiAKMDAwMDA2MjY3MiAwMDAw MCBuIAowMDAwMDEwNjY0IDAwMDAwIG4gCjAwMDAwMjc4MTEgMDAwMDAgbiAK MDAwMDAyNzgzNSAwMDAwMCBuIAowMDAwMDI4MDQwIDAwMDAwIG4gCjAwMDAw Mjg2NDAgMDAwMDAgbiAKMDAwMDAyOTA4MSAwMDAwMCBuIAowMDAwMDQxNzI0 IDAwMDAwIG4gCjAwMDAwNDE3NDggMDAwMDAgbiAKMDAwMDA0MTk0OCAwMDAw MCBuIAowMDAwMDQyNDE5IDAwMDAwIG4gCjAwMDAwNDI3NDIgMDAwMDAgbiAK MDAwMDA0Mjc4OCAwMDAwMCBuIAowMDAwMDQzNDA0IDAwMDAwIG4gCjAwMDAw NDM4NTIgMDAwMDAgbiAKMDAwMDA0Mzg3NCAwMDAwMCBuIAowMDAwMDQzOTk4 IDAwMDAwIG4gCjAwMDAwNjIwODEgMDAwMDAgbiAKMDAwMDA0NzE0MCAwMDAw MCBuIAowMDAwMDQ3Mjk1IDAwMDAwIG4gCjAwMDAwNDc0NTAgMDAwMDAgbiAK MDAwMDA0NzYwNSAwMDAwMCBuIAowMDAwMDQ3NzYwIDAwMDAwIG4gCjAwMDAw NDc4OTAgMDAwMDAgbiAKMDAwMDA0ODAyMSAwMDAwMCBuIAowMDAwMDQ4MTU5 IDAwMDAwIG4gCjAwMDAwNDgyOTAgMDAwMDAgbiAKMDAwMDA0ODQyOCAwMDAw MCBuIAowMDAwMDQ4NTU5IDAwMDAwIG4gCjAwMDAwNDg2MDQgMDAwMDAgbiAK MDAwMDA0ODc0OSAwMDAwMCBuIAowMDAwMDQ4ODk2IDAwMDAwIG4gCjAwMDAw NDkwMjcgMDAwMDAgbiAKMDAwMDA0OTE2NSAwMDAwMCBuIAowMDAwMDQ5Mjk2 IDAwMDAwIG4gCjAwMDAwNDk0MjggMDAwMDAgbiAKMDAwMDA0OTYxNCAwMDAw MCBuIAowMDAwMDQ5NzQ2IDAwMDAwIG4gCjAwMDAwNDk4NzggMDAwMDAgbiAK MDAwMDA1MDA2OSAwMDAwMCBuIAowMDAwMDUwMjAxIDAwMDAwIG4gCjAwMDAw NTAzODIgMDAwMDAgbiAKMDAwMDA1MDUxMyAwMDAwMCBuIAowMDAwMDUwNjQ0 IDAwMDAwIG4gCjAwMDAwNTA3ODMgMDAwMDAgbiAKMDAwMDA1MDkxNCAwMDAw MCBuIAowMDAwMDUxMDUzIDAwMDAwIG4gCjAwMDAwNTExODQgMDAwMDAgbiAK MDAwMDA1MTU2NCAwMDAwMCBuIAowMDAwMDUxNjk1IDAwMDAwIG4gCjAwMDAw NTE4MzQgMDAwMDAgbiAKMDAwMDA1MTk2NSAwMDAwMCBuIAowMDAwMDUyMzQ1 IDAwMDAwIG4gCjAwMDAwNTI0NzYgMDAwMDAgbiAKMDAwMDA1MjYxNSAwMDAw MCBuIAowMDAwMDUyNzQ2IDAwMDAwIG4gCjAwMDAwNTMxMjYgMDAwMDAgbiAK MDAwMDA1MzI1NyAwMDAwMCBuIAowMDAwMDUzMzk2IDAwMDAwIG4gCjAwMDAw NTM1MjcgMDAwMDAgbiAKMDAwMDA1MzgyMyAwMDAwMCBuIAowMDAwMDU0MjA2 IDAwMDAwIG4gCjAwMDAwNTQzMzggMDAwMDAgbiAKMDAwMDA1NDQ3NyAwMDAw MCBuIAowMDAwMDU0NjA5IDAwMDAwIG4gCjAwMDAwNTQ3NDEgMDAwMDAgbiAK MDAwMDA1NDg4MCAwMDAwMCBuIAowMDAwMDU1MDEyIDAwMDAwIG4gCjAwMDAw NTUxNDUgMDAwMDAgbiAKMDAwMDA1NTMzMiAwMDAwMCBuIAowMDAwMDU1NDY1 IDAwMDAwIG4gCjAwMDAwNTU1OTggMDAwMDAgbiAKMDAwMDA1NTc4OSAwMDAw MCBuIAowMDAwMDU1OTIyIDAwMDAwIG4gCjAwMDAwNTYxMDMgMDAwMDAgbiAK MDAwMDA1NjIzNSAwMDAwMCBuIAowMDAwMDU2Mzc0IDAwMDAwIG4gCjAwMDAw NTY1MDYgMDAwMDAgbiAKMDAwMDA1NjY0NSAwMDAwMCBuIAowMDAwMDU2Nzc3 IDAwMDAwIG4gCjAwMDAwNTcxNjAgMDAwMDAgbiAKMDAwMDA1NzI5MiAwMDAw MCBuIAowMDAwMDU3NDMxIDAwMDAwIG4gCjAwMDAwNTc1NjMgMDAwMDAgbiAK MDAwMDA1Nzk0OSAwMDAwMCBuIAowMDAwMDU4MDgyIDAwMDAwIG4gCjAwMDAw NTgyMjMgMDAwMDAgbiAKMDAwMDA1ODM1NiAwMDAwMCBuIAowMDAwMDU4NzUw IDAwMDAwIG4gCjAwMDAwNTg4ODMgMDAwMDAgbiAKMDAwMDA1OTAyNCAwMDAw MCBuIAowMDAwMDU5MTU3IDAwMDAwIG4gCjAwMDAwNTkyOTggMDAwMDAgbiAK MDAwMDA1OTQzMSAwMDAwMCBuIAowMDAwMDU5ODI1IDAwMDAwIG4gCjAwMDAw NTk5OTAgMDAwMDAgbiAKMDAwMDA2MDEyMyAwMDAwMCBuIAowMDAwMDYwMjU2 IDAwMDAwIG4gCjAwMDAwNjAzOTcgMDAwMDAgbiAKMDAwMDA2MDUzMCAwMDAw MCBuIAowMDAwMDYwNjY0IDAwMDAwIG4gCjAwMDAwNjA3OTggMDAwMDAgbiAK MDAwMDA2MDkzOSAwMDAwMCBuIAowMDAwMDYxMDczIDAwMDAwIG4gCjAwMDAw NjIzMTQgMDAwMDAgbiAKMDAwMDA2MjkyNSAwMDAwMCBuIAowMDAwMDYzMTM1 IDAwMDAwIG4gCnRyYWlsZXIKPDwvU2l6ZSAyNDcvUm9vdCAyNDUgMCBSCi9J bmZvIDI0NiAwIFIKL0lEIFsgPEVGMTc5REE3RTBGNTk5QTIyMUQwQkFDMzU1 MjJCQkUwPgo8RUYxNzlEQTdFMEY1OTlBMjIxRDBCQUMzNTUyMkJCRTA+IF0K L0RvY0NoZWNrc3VtIC9DM0FCNkFBQ0YxOUEzNzIwNkJGMURDNjc4QjdBOEMz Nwo+PgpzdGFydHhyZWYKNjMzNjkKJSVFT0YK --3825401791-984506013-1367543180=:66619-- From edainow@afilias.info Fri May 3 12:21: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 137E021F8B60 for ; Fri, 3 May 2013 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ1xzRa8-4aQ for ; Fri, 3 May 2013 12:21:47 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E1B7221F8B18 for ; Fri, 3 May 2013 12:21:43 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UYLY7-00014c-3t for weirds@ietf.org; Fri, 03 May 2013 19:21:43 +0000 Received: from mail-ie0-f199.google.com ([209.85.223.199]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UYLY7-0004Uj-3P for weirds@ietf.org; Fri, 03 May 2013 19:21:43 +0000 Received: by mail-ie0-f199.google.com with SMTP id s9so9987717iec.2 for ; Fri, 03 May 2013 12:21:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=RPmqll8watTzSLvHGxirGJnc4sHf2zsJDctyYyormxA=; b=S5omazlMw2Cei6XHhY43QEJrjDHKQtPcRdZE7yvp/KoQBMgCWkZfr6lrwDdKiuhXl5 8MECNsV4UKofHNFJbche54qSxAKTD/BKIjuJ6cJ696ZgGBD7MsHXF49zWaoWe8+ch4Je y1zU2Cn/rCpVboEWei1sgNJmn4dgZnRTWEOKuAFlkMDTfLaTtHYCGS6oYd2nd3h4GnTF 3gAvwhQdfWaiQZBSzchqah44ud1xMQKrf+olXMEHrF3Q/NC3Aa/K+fD9dZb1McpDoF0l SSUHsq444JRx5C9r0I4yasYqXwiF/WRFQNrXiJgSFHWveS/8VzGNH1Bak6q5YNXf3QQL jqRA== X-Received: by 10.50.41.41 with SMTP id c9mr10276088igl.79.1367608897572; Fri, 03 May 2013 12:21:37 -0700 (PDT) X-Received: by 10.50.41.41 with SMTP id c9mr10276083igl.79.1367608897496; Fri, 03 May 2013 12:21:37 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id o10sm11555178igh.2.2013.05.03.12.21.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 12:21:36 -0700 (PDT) Message-ID: <51840E3B.9000506@afilias.info> Date: Fri, 03 May 2013 15:21:31 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Angstadt References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn6XeGOmmyj4VVBepWVW7ReonhOhidLCl6wYDRJk5YP7rOBFrGMExkvo9UpLeZ3hx52z1RigMHQjPd3LFSej3kqWxm4fvqsk9lBzUZveydzCg+kOkZhhf1+d149KcnmbSclPt48 Cc: Pete Resnick , Philipp Kewisch , "jcardcal@ietf.org" , weirds@ietf.org Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 May 2013 19:21:53 -0000 On 5/1/2013 8:38 PM, Michael Angstadt wrote: > @Philipp: The first two components of the ADR property are for storing > a post office box and an "extended" address (such as a suite or > apartment number). In the second example, it might be good to > populate these fields with values that will make this more obvious. > Also, in the label, maybe remove the newlines between the town/state > and state/zip-code so that it more closely resembles a mailing label. > For example: > > ["adr", > { "label": "P.O. Box 123\nSuite 456\nSecond Shack\nHometown, PA > 18252\nU.S.A" }, > "text", > [ > "P.O. Box 123", "Suite 456", "Second Shack", "Hometown", "PA", > "18252", "U.S.A." > ] > ] > > @Pete: The syntax of the jCards in your examples aren't *quite* > correct. The first element of the jCard array is the string "vcard". > The second element is an array which contains all of the property > arrays. The "vcard" string is redundant in this context, since the > object field already uses this name, but I am just thinking that > parsers might have trouble parsing the jCard without it. The examples > should look like this: > > { > "handle" : "XXXX", > "vCard" : > [ > "vcard", > [ > [ "version", {}, "text", "4.0" ], > [ "fn", {}, "text", "Joe Bob, Inc." ], > ... > ] > ] > > Thanks, > Mike > > > On Wed, May 1, 2013 at 6:23 PM, Pete Resnick wrote: >> On 5/1/13 5:15 PM, Philipp Kewisch wrote: >> >>> If this is a requirement I'm happy to comply, but since those examples are >>> not about the ADR property but rather about the structured value it uses, I >>> think the "label" parameter is just additional clutter. Or is label becoming >>> mandatory? >> >> Oh, no, if I gave that impression, I apologize. The *ability* to have an >> unstructured (i.e., label) form of the address is a requirement for WEIRDS, >> and since we are writing a document at this break-neck speed for their >> benefit, I think it would be a good thing to show them an example of how one >> does that in the document. But this is not some sort of protocol >> requirement. >> >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> Following from this, it looks like a structured example based on what is in json-response-03 would be: ["adr", {}, "text", [ "P.O. Box 12", "Suite 901", "123 Maple Ave", "Vancouver", "BC", "A1B 2C9, "Canada" ] ] For both structured and unstructured: ["adr", { "label": "123 Maple Ave\nSuite 901\nP.O. Box 12\nVancouver BC\nA1B 2C9\nCanada" }, "text", [ "P.O. Box 12", "Suite 901", "123 Maple Ave", "Vancouver", "BC", "A1B 2C9, "Canada" ] ] For only unstructured, neither the jCard or vCard spec have examples. I'm guessing the following is correct, since "a single structured text value" seems to be required: http://tools.ietf.org/html/rfc6350#section-6.3.1 ["adr", { "label": "123 Maple Ave\nSuite 901\nP.O. Box 12\nVancouver BC\nA1B 2C9\nCanada" }, "text", [] ] -Ernie From mike.angstadt@gmail.com Thu May 2 16:43:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F47721F8FC6; Thu, 2 May 2013 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fknvdl7BRVZo; Thu, 2 May 2013 16:43:38 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id E73AC21F8F41; Thu, 2 May 2013 16:43:35 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id t11so1064219lbd.29 for ; Thu, 02 May 2013 16:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UUXubUo7KCW38UXv3dfvQsfUFl9Cyz4tOEYTcsxB9YQ=; b=TxqwFrq+0EPXwWyJGZ09oAwZhS1OqNG3hNDrYvEgUmolTsHnhRHgmwsN0RubXX+lxG bpqO1ZcfmzXRn24EjXWDfRL1Dql5GiK7W1rOslLgXuGyJfoDkd8KxjuWyXA2ii2JeGuf V9oF3TcDHchtVNXx71OtBLVd1sCWyh+19UWjzR9DEHfxho/yBVMbnPeLWpvVaHY8frzh 7aB1JrYWmXT4ABn4ed9TGooth8JFwCxR190ZYfVmeqPnYLI7/GG75oEq9j4ndD9nXvPd 3zCu6LO+du8Ai73SeJouMErhHAJGp7xK0N1h7pyCw/R29YVjX+gcLe3PsQW8r7b6n6GI 1mEw== MIME-Version: 1.0 X-Received: by 10.112.149.200 with SMTP id uc8mr3526281lbb.9.1367538214176; Thu, 02 May 2013 16:43:34 -0700 (PDT) Received: by 10.112.114.1 with HTTP; Thu, 2 May 2013 16:43:33 -0700 (PDT) In-Reply-To: References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> <518222FC.1090909@viagenie.ca> Date: Thu, 2 May 2013 19:43:33 -0400 Message-ID: From: Michael Angstadt To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 03 May 2013 23:54:01 -0700 Cc: "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 May 2013 23:43:43 -0000 Sorry, I'm just joking. I think it makes sense to leave the "post-office-box" and "extended" components empty too. Thanks, Mike On Thu, May 2, 2013 at 8:22 AM, Michael Angstadt wrote: > On Thu, May 2, 2013 at 4:25 AM, Simon Perreault > wrote: >> Sorry, no. RFC 6350 section 6.3.1 says: >> >> Experience with vCard 3 has shown that the first two components >> (post office box and extended address) are plagued with many >> interoperability issues. To ensure maximal interoperability, >> their values SHOULD be empty. > > Ahem, I do believe that the wording here is "SHOULD" not "MUST". > Also, if I may refer you to the paragraph above (asterisks added for > emphasis): > > Quoting RFC 6350, section 6.3.1, page 33: > > Special notes: The structured type value consists of a sequence of > address components. The component values MUST be specified in > their corresponding position. The structured type value > corresponds, in sequence, to > ** the post office box; ** > ** the extended address (e.g., apartment or suite number); ** > the street address; > the locality (e.g., city); > the region (e.g., state or province); > the postal code; > the country name (full name in the language specified in > Section 5.1). From bje@apnic.net Sun May 5 17:58:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F321F973A for ; Sun, 5 May 2013 17:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0s9-4NZBhse for ; Sun, 5 May 2013 17:58:32 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 9C9F921F97A5 for ; Sun, 5 May 2013 17:58:26 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 6 May 2013 10:54:09 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Mon, 6 May 2013 10:58:22 +1000 From: Byron Ellacott To: Ernie Dainow , Michael Angstadt Thread-Topic: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) Thread-Index: AQHORrsoXoUqDqwF4UiUWDBPSscEbJjwZZYAgALMJYCABCpngA== Date: Mon, 6 May 2013 00:58:21 +0000 Message-ID: In-Reply-To: <51840E3B.9000506@afilias.info> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.236] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , Philipp Kewisch , "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 May 2013 00:58:32 -0000 Hi all, On 4/05/13 5:21 AM, "Ernie Dainow" wrote: >For both structured and unstructured: > ["adr", > { "label": "123 Maple Ave\nSuite 901\nP.O. Box 12\nVancouver >BC\nA1B 2C9\nCanada" }, > "text", [ "P.O. Box 12", "Suite 901", "123 Maple Ave", >"Vancouver", "BC", "A1B 2C9, "Canada" ] > ] The -01 draft I'm looking at shows a "text" value as a single string, not an array of strings: ["adr", { "type": "work" }, "text", ";Suite D2-630;2875 Laurier;Quebec;QC;G1V 2M2;Canada" ], Is the array syntax a valid alternative to the semi-colon separated string that is yet to appear in the draft, or in the draft in a corner I can't find? http://tools.ietf.org/html/draft-kewisch-vcard-in-json-01#appendix-B.1.2 Byron From mike.angstadt@gmail.com Sun May 5 18:59: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 A65E221F85F4; Sun, 5 May 2013 18:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSOg+6jfzeo9; Sun, 5 May 2013 18:59:53 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8FA21F85C0; Sun, 5 May 2013 18:59:53 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa7so1734174pbc.39 for ; Sun, 05 May 2013 18:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K3Y9QN14Ba9bFN2FARQJjSYHzi+LpyOmegiY8N/8HLM=; b=Dhxlb1+kjXkLcGu6+qe781TPBCorl39UnPjlTF3G+AOwx3OBBVAveUqBnGt4E645BB D/iPz6x98T4C31eZ18kn6dl9qyhodcI72et3+hUQ00NLkgX8ye1fLCSZtYszvg91cAEv 5qzh7jeObpFwKeMD5L2rAnYC2slpn0e8bLppzp2Z3Zgr70QZ7PTlbKc3UtK+XFLgyI+O zcdYpAlraLw6waE8o99orZLF8HiC+Bb9vpFnhcZLLJSn2RCJ8C7knv2y7CH2DghtgKRP 8kc4PVLJpIB0hRUyiLhuFadJTES7QjQcVinMLaUGX4Fwe1QbLljXiJl33X5/0ds0iC5z he1Q== MIME-Version: 1.0 X-Received: by 10.66.180.227 with SMTP id dr3mr24011092pac.213.1367805592808; Sun, 05 May 2013 18:59:52 -0700 (PDT) Received: by 10.68.125.201 with HTTP; Sun, 5 May 2013 18:59:52 -0700 (PDT) In-Reply-To: References: <51840E3B.9000506@afilias.info> Date: Sun, 5 May 2013 21:59:52 -0400 Message-ID: From: Michael Angstadt To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 06 May 2013 05:07:43 -0700 Cc: "weirds@ietf.org" , Philipp Kewisch , Pete Resnick , "jcardcal@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 May 2013 01:59:53 -0000 On Sun, May 5, 2013 at 8:58 PM, Byron Ellacott wrote: > Is the array syntax a valid alternative to the semi-colon separated string > that is yet to appear in the draft, or in the draft in a corner I can't > find? The array syntax is *required*. There is no alternative. The semi-colon syntax is only used in traditional, text-based vCards. jCard does not support this. The label parameter is *optional*. -Mike From edainow@afilias.info Wed May 8 11:43:24 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D936F21F8EBD for ; Wed, 8 May 2013 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waIHw97EVvOw for ; Wed, 8 May 2013 11:43:19 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1371021F8A74 for ; Wed, 8 May 2013 11:43:18 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ua9Kg-0007SS-3c for weirds@ietf.org; Wed, 08 May 2013 18:43:18 +0000 Received: from mail-lb0-f169.google.com ([209.85.217.169]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ua9Kf-0006PG-61 for weirds@ietf.org; Wed, 08 May 2013 18:43:18 +0000 Received: by mail-lb0-f169.google.com with SMTP id z5so2256812lbh.28 for ; Wed, 08 May 2013 11:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=iS36NR8YzsZg8smkrrk8KPFiMbaxPe0tUXPN+GO6UQ8=; b=D8mbVoR+IRDpBBJGOTQYYU4puwRRPlqEDUyIgn10c3kfx9DgASxQ55CdvziOUp+rMk D3kONV/d12The3eJN9dG1R24W9E+y9rhuOdrCHVbexkiVDx7YffEayf4dVNU6cVXjTIC rZab7QGza2ogEu/Km/Seaf8uB4/Ytb8u6K96ymHlUBYenAsI9kQLPy/vXq6VBX8Cpv3t nRw8Q+6TWN/TCzZrZPe1k+Q+hPDEz+eMAjdXcujM4f934psMAf3xS9BIa1RdYr7rJxTc iLTmjxwxP5C45wjQnJLyFNHitoKVBo6Mqqjwo/Ewe3gO/0K1cYQGTjo6LPrJS7/c34wU 9NGA== X-Received: by 10.112.149.35 with SMTP id tx3mr3796692lbb.95.1368038591572; Wed, 08 May 2013 11:43:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.149.35 with SMTP id tx3mr3796669lbb.95.1368038590879; Wed, 08 May 2013 11:43:10 -0700 (PDT) Received: by 10.112.210.38 with HTTP; Wed, 8 May 2013 11:43:10 -0700 (PDT) Date: Wed, 8 May 2013 14:43:10 -0400 Message-ID: From: Ernie Dainow To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b342f383faa0804dc394e12 X-Gm-Message-State: ALoCoQnN1+ivv4NlGCqizL1lKapQFOBbhVCOdKOtPGWH1D27Hu63CkHl3l/JSGUCq27bT27uLyQVc5b8x0BrL+u4vzMlYT/2S0KfbCdprhJeNrZDUBMcGebta/T5dQrsRu5ChUiYOKg7 Subject: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 May 2013 18:43:25 -0000 --047d7b342f383faa0804dc394e12 Content-Type: text/plain; charset=ISO-8859-1 It was not easy to find the RDAP support for DNSSEC. A search for "DNSSEC" in draft-ietf-weirds-json-response-03 does not find anything. Adding a background note in 6.3 delegationKeys that this is for DNSSEC might help. Also as noted for another document, references should be expanded to include the RFC title. Instead of RFC 4034 [RFC4034], "Resource Records for the DNS Security Extensions" [RFC4034]. It would be useful to have the following additional information: 1) Create Date - include an Events array 2) Max Signature Life - validity period for the signature in seconds You can't verify the digest in delegationKeys without the following: 3) Flags - identifies whether it is a zone key 4) Protocol - key protocol, currently must be 3 5) Public Key - required to decrypt DS records While many providers may not have all of these, it is better for the standard to specify them rather than ending up with various custom extensions. -Ernie --047d7b342f383faa0804dc394e12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It was not easy to find the RDAP support for DNSSEC. A search for "DN= SSEC" in draft-ietf-weirds-json-response-03 does not find anything. Ad= ding a background note in 6.3 delegationKeys that this is for DNSSEC might = help. Also as noted for another document, references should be expanded to = include the RFC title. Instead of RFC 4034 [RFC4034], "Resource Record= s for the DNS Security Extensions" [RFC4034].

It would be useful to = have the following additional information:
1) Create Date - include an Events array
2) Max Signature Life - =A0validity period fo= r the signature in seconds=A0

You ca= n't verify the digest in=A0delegationKeys=A0without the following:
3) Flags - iden= tifies whether it is a zone key
4) Protocol - ke= y protocol, currently must be 3
5) Public Key - required to decrypt DS records

While = many providers may not have all of these, it is better for the standard to = specify them rather than ending up with various custom extensions.

-Ernie=

= --047d7b342f383faa0804dc394e12-- From edainow@afilias.info Wed May 8 12:13: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 3D43821F909A for ; Wed, 8 May 2013 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuZEe8psWsIN for ; Wed, 8 May 2013 12:12:59 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0D21F8F25 for ; Wed, 8 May 2013 12:12:58 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ua9nN-00026p-5k for weirds@ietf.org; Wed, 08 May 2013 19:12:57 +0000 Received: from mail-ie0-f177.google.com ([209.85.223.177]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ua9nN-0008GJ-5N for weirds@ietf.org; Wed, 08 May 2013 19:12:57 +0000 Received: by mail-ie0-f177.google.com with SMTP id 9so3714481iec.8 for ; Wed, 08 May 2013 12:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uZHz6QcXkapj4a4a61hx5KN69hD/A85siYFh69+izvE=; b=b5ZgjhC1VGmwW31u4wNqTaAQDmjT1FeF9M9W9wDxqn+chd0Of2+6Owj9CvZOJglPfj ypJzK1qTeWm9VKJI2wtWkdL3hLNR9+6TihoGhqrDP8QIioCvWndP4x66ooa+mGeIiqtZ AkdTn6A/00LRRiux5Xl1h5Wf+n65SP/C7FdugBr+Dm/CbeIWCt3ZjZiJx+GnRq5o+l9Q 4zmh9FsJmA5jGGN1p39pZ74oTfI4qCdIPhQbixMuQtMnMOmjDxowP99P4a6rS+8PWpZD 7IThORG9lt3K6P1284UCVN3hR6m5RPgvyQS5CVXH9vaOr+H8tq/JgEzQ3jovIKuJDLr5 cpsw== X-Received: by 10.50.120.102 with SMTP id lb6mr3092538igb.103.1368040372233; Wed, 08 May 2013 12:12:52 -0700 (PDT) X-Received: by 10.50.120.102 with SMTP id lb6mr3092534igb.103.1368040372183; Wed, 08 May 2013 12:12:52 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id j7sm1435331igt.1.2013.05.08.12.12.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 12:12:51 -0700 (PDT) Message-ID: <518AA3AF.9090105@afilias.info> Date: Wed, 08 May 2013 15:12:47 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Angstadt References: <51811C15.5080402@sidn.nl> <5181207D.3090502@viagenie.ca> <51813D18.3040604@qti.qualcomm.com> <518193E7.2090008@gmail.com> <518195FB.8090204@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmDsYrkeD5jcMeeH/a2/xtgRViP8xtbfSFkO7PcwRBpzOALiDIlObukIVprEhG5DQGySPn9qFUW4BFJ4II+clPWnyfmS7Uz2w/IAUYvlHXSDMmQ9yM/AFO33shuhhaNH0B2Ca1S Cc: Pete Resnick , "jcardcal@ietf.org" , weirds@ietf.org Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 May 2013 19:13:04 -0000 On 5/1/2013 8:38 PM, Michael Angstadt wrote: > @Pete: The syntax of the jCards in your examples aren't *quite* > correct. The first element of the jCard array is the string "vcard". > The second element is an array which contains all of the property > arrays. The "vcard" string is redundant in this context, since the > object field already uses this name, but I am just thinking that > parsers might have trouble parsing the jCard without it. The examples > should look like this: > > { > "handle" : "XXXX", > "vCard" : > [ > "vcard", > [ > [ "version", {}, "text", "4.0" ], > [ "fn", {}, "text", "Joe Bob, Inc." ], > ... > ] > ] > > Thanks, > Mike > For RDAP, this is confusing and prone to reversal and case errors. We should use a different name, as in { "handle" : "XXXX", "vcardArray" : [ "vcard", [ -Ernie From aservin@lacnic.net Wed May 8 13:44:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0121F901A for ; Wed, 8 May 2013 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka1J6PDdYjcu for ; Wed, 8 May 2013 13:44:12 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id F34C821F8F43 for ; Wed, 8 May 2013 13:44:11 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [190.90.204.191]) by mail.lacnic.net.uy (Postfix) with ESMTP id DFC42308461; Wed, 8 May 2013 17:43:50 -0300 (UYT) Message-ID: <518AB913.5050806@lacnic.net> Date: Wed, 08 May 2013 15:44:03 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ernie Dainow , weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 May 2013 20:44:16 -0000 Question, do we really want to publish all that information in RDAP? I do not have strong opinions, just query the group. regards, as On 5/8/13 1:43 PM, Ernie Dainow wrote: > It was not easy to find the RDAP support for DNSSEC. A search for > "DNSSEC" in draft-ietf-weirds-json-response-03 does not find anything. > Adding a background note in 6.3 delegationKeys that this is for DNSSEC > might help. Also as noted for another document, references should be > expanded to include the RFC title. Instead of RFC 4034 [RFC4034], > "Resource Records for the DNS Security Extensions" [RFC4034]. > > It would be useful to have the following additional information: > 1) Create Date - include an Events array > 2) Max Signature Life - validity period for the signature in seconds > > You can't verify the digest in delegationKeys without the following: > 3) Flags - identifies whether it is a zone key > 4) Protocol - key protocol, currently must be 3 > 5) Public Key - required to decrypt DS records > > While many providers may not have all of these, it is better for the > standard to specify them rather than ending up with various custom > extensions. > > -Ernie > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From carlosm3011@gmail.com Wed May 8 14:11: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 3572821F8746 for ; Wed, 8 May 2013 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFzCF3B6NZBD for ; Wed, 8 May 2013 14:11:53 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF321F86CA for ; Wed, 8 May 2013 14:11:53 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c11so1300794qcv.18 for ; Wed, 08 May 2013 14:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eJ9/2E13xOQJuWgHTBVqCpKA3KqjPkqX1lFYesI6X0s=; b=v6dTANaPSrEkL2gyXb3Pdet5fnBMuL0ELAn4G0oaMU3WLCt4hwvYxrH3BOF3DD4SpA Smkl5c5sFC8qbvyqE6Xqa9IZ2rVvt43r1HEbcB1fYTUr7bq4sflkaiXGZ52WxggxSuOs dXSX4hYawGioSo6IK1lZAXVLfByELMh0TeMs0jx0bjJeEV6XMRrPo1lf9J40afK0+GFc OAq1hymQ/EO/7tLHQFSBV1/b5N8yFQ2ZkSu8KOytX25+1q8ulEakhF61JmO7GtAxr3d3 YtqKmWZqyiYmnxQFL8TYB4QVA3LTyUnlpNc0ihgdsq/frHdZJ7xkL3UiprYKFYSKp92o 6+4w== X-Received: by 10.229.164.3 with SMTP id c3mr2579098qcy.124.1368047513099; Wed, 08 May 2013 14:11:53 -0700 (PDT) Received: from bonaire.local ([190.90.204.4]) by mx.google.com with ESMTPSA id do6sm1039392qab.12.2013.05.08.14.11.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 14:11:52 -0700 (PDT) Message-ID: <518ABF99.6080603@gmail.com> Date: Wed, 08 May 2013 16:11:53 -0500 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ernie Dainow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 May 2013 21:11:55 -0000 I'm basically fine with it. However, I'm a bit worried that, given enough time, every different stakeholder will find some attribute he/she might want to add. I think we need to define how we are going extend rdap-response without keeping it as a draft until the heat death of the Universe. regards, ~Carlos On 5/8/13 1:43 PM, Ernie Dainow wrote: > It was not easy to find the RDAP support for DNSSEC. A search for > "DNSSEC" in draft-ietf-weirds-json-response-03 does not find anything. > Adding a background note in 6.3 delegationKeys that this is for DNSSEC > might help. Also as noted for another document, references should be > expanded to include the RFC title. Instead of RFC 4034 [RFC4034], > "Resource Records for the DNS Security Extensions" [RFC4034]. > > It would be useful to have the following additional information: > 1) Create Date - include an Events array > 2) Max Signature Life - validity period for the signature in seconds > > You can't verify the digest in delegationKeys without the following: > 3) Flags - identifies whether it is a zone key > 4) Protocol - key protocol, currently must be 3 > 5) Public Key - required to decrypt DS records > > While many providers may not have all of these, it is better for the > standard to specify them rather than ending up with various custom > extensions. > > -Ernie > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From marc.blanchet@viagenie.ca Thu May 9 04:10: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 9A80421F898B for ; Thu, 9 May 2013 04:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBgNzkz2Wj36 for ; Thu, 9 May 2013 04:10:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F321F89B2 for ; Thu, 9 May 2013 04:10:34 -0700 (PDT) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D406A41597 for ; Thu, 9 May 2013 07:10:32 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1429A56E-EF27-4717-BA8D-293A037F2231@viagenie.ca> Date: Thu, 9 May 2013 12:10:28 +0100 To: "weirds@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [weirds] weirds interop day: saturday before Berlin IETF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 11:10:36 -0000 Hello, we are organizing a weirds interop day on saturday July 27th in Berlin, = prior to IETF, most likely in the afternoon. (Details to be announced = later, such as location, exact time). We have contacted some of the = implementors we know and they are in. We are working on a test plan and = test suite that would be used during that session. If you have an = implementation or want to participate, please contact me directly and = I'll put you in the mailing list. Anonymized results of the interop and = any impact on the specifications could be presented at the weirds = meeting. Regards, Marc.= From andy@arin.net Thu May 9 07:15:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F7321F8EAC for ; Thu, 9 May 2013 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5fQU2SOIIzt for ; Thu, 9 May 2013 07:15:02 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF721F8EEC for ; Thu, 9 May 2013 07:15:02 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 41DE3165296; Thu, 9 May 2013 10:14:59 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id EA040165290; Thu, 9 May 2013 10:14:58 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 9 May 2013 10:14:40 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 9 May 2013 10:14:57 -0400 From: Andy Newton To: "Carlos M. martinez" , Ernie Dainow Thread-Topic: [weirds] DNSSEC Thread-Index: AQHOTBwUxAfhzI3uIEKL0X83GeR37Jj8DCmAgADayYA= Date: Thu, 9 May 2013 14:14:56 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> In-Reply-To: <518ABF99.6080603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 14:15:08 -0000 On 5/8/13 5:11 PM, "Carlos M. martinez" wrote: >I'm basically fine with it. Ditto. > >However, I'm a bit worried that, given enough time, every different >stakeholder will find some attribute he/she might want to add. > >I think we need to define how we are going extend rdap-response without >keeping it as a draft until the heat death of the Universe. Are you speaking of something other than the current ability to add registry specific JSON attributes? -andy From andy@arin.net Thu May 9 07:18: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 6BC9D21F8EED; Thu, 9 May 2013 07:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuznnF1+n47h; Thu, 9 May 2013 07:18:47 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1221F8EBC; Thu, 9 May 2013 07:18:47 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 2E7032136B3; Thu, 9 May 2013 10:18:47 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id A1188213652; Thu, 9 May 2013 10:18:46 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 9 May 2013 10:18:25 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 9 May 2013 10:18:39 -0400 From: Andy Newton To: Ernie Dainow , Michael Angstadt Thread-Topic: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) Thread-Index: AQHORrtVX/QJ1Dm96EOjkW94NLZayJjxUEcAgAqlXYCAAP0YgA== Date: Thu, 9 May 2013 14:18:38 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E7D@CHAXCH01.corp.arin.net> In-Reply-To: <518AA3AF.9090105@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <8FA3F620BA9E074B8F97C20F77726F8E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 14:18:52 -0000 On 5/8/13 3:12 PM, "Ernie Dainow" wrote: > >On 5/1/2013 8:38 PM, Michael Angstadt wrote: >> @Pete: The syntax of the jCards in your examples aren't *quite* >> correct. The first element of the jCard array is the string "vcard". >> The second element is an array which contains all of the property >> arrays. The "vcard" string is redundant in this context, since the >> object field already uses this name, but I am just thinking that >> parsers might have trouble parsing the jCard without it. The examples >> should look like this: >> >> { >> "handle" : "XXXX", >> "vCard" : >> [ >> "vcard", >> [ >> [ "version", {}, "text", "4.0" ], >> [ "fn", {}, "text", "Joe Bob, Inc." ], >> ... >> ] >> ] >> >> Thanks, >> Mike >> > >For RDAP, this is confusing and prone to reversal and case errors. We >should use a different name, as in > >{ > "handle" : "XXXX", > "vcardArray" : > [ > "vcard", > [ > I agree. -andy From ed.lewis@neustar.biz Thu May 9 07:42: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 5CB1721F87D2 for ; Thu, 9 May 2013 07:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx7EK+XQZw1V for ; Thu, 9 May 2013 07:42:51 -0700 (PDT) Received: from smtp73.ord1c.emailsrvr.com (smtp73.ord1c.emailsrvr.com [108.166.43.73]) by ietfa.amsl.com (Postfix) with ESMTP id 24B6421F880F for ; Thu, 9 May 2013 07:42:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A38C61E8118; Thu, 9 May 2013 10:42:50 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 62B8C1E807A; Thu, 9 May 2013 10:42:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3F9990B-1EEE-4997-93ED-E28C2C9D6103" From: Edward Lewis In-Reply-To: <518AB913.5050806@lacnic.net> Date: Thu, 9 May 2013 10:42:49 -0400 Message-Id: References: <518AB913.5050806@lacnic.net> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 14:42:55 -0000 --Apple-Mail=_B3F9990B-1EEE-4997-93ED-E28C2C9D6103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm pretty much a lazy lurker, but this subject caught my eye. My opinion is against having the DNSSEC meta-data in "the WhoIs" (and by = that I mean any form of Registry database content inspection mechanism). = Not strongly against as in I think it is wrong, but in the sense that = you can get this data from "port 53" anyway. The DNS is inherently a history-free protocol, so I question the value = of knowing when a record appeared in the DNS when solving operational = problems. I do have a research project that does track DNSSEC record = lifetimes, but that is research, not operations. I do the work by = remembering what I've seen in DNS responses over time. I realize that today some registries do publish DNSSEC meta-data in port = 43 WhoIs and some do not. I think path a registry chooses ultimately = doesn't matter - in the sense that I wouldn't tell anyone doing it that = they shouldn't, even if I wouldn't add the information. In that sense, = if it is in RDAP, fine, make it optional and yes, one form for this is = better than 12 (in the sense that it's one aspect). But I would not = have designed in to the response the DNSSEC meta-data. Scratching the back of my head, I can't think of any reason why I'd ask = "the WhoIs" for the DNSSEC meta-data for a domain object. If I can't = get it from the DNS itself, the DNSSEC stuff isn't going to help me in = any way. Even thinking for historical or escrow purposes, the DNS zone = file is already an adequate vehicle for the DNSSEC meta-data. On May 8, 2013, at 16:44, Arturo Servin wrote: >=20 > Question, do we really want to publish all that information in = RDAP? >=20 > I do not have strong opinions, just query the group. >=20 > regards, > as >=20 > On 5/8/13 1:43 PM, Ernie Dainow wrote: >> It was not easy to find the RDAP support for DNSSEC. A search for >> "DNSSEC" in draft-ietf-weirds-json-response-03 does not find = anything. >> Adding a background note in 6.3 delegationKeys that this is for = DNSSEC >> might help. Also as noted for another document, references should be >> expanded to include the RFC title. Instead of RFC 4034 [RFC4034], >> "Resource Records for the DNS Security Extensions" [RFC4034]. >>=20 >> It would be useful to have the following additional information: >> 1) Create Date - include an Events array >> 2) Max Signature Life - validity period for the signature in seconds=20= >>=20 >> You can't verify the digest in delegationKeys without the following: >> 3) Flags - identifies whether it is a zone key >> 4) Protocol - key protocol, currently must be 3 >> 5) Public Key - required to decrypt DS records >>=20 >> While many providers may not have all of these, it is better for the >> standard to specify them rather than ending up with various custom >> extensions. >>=20 >> -Ernie >>=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 = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_B3F9990B-1EEE-4997-93ED-E28C2C9D6103 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The DNS is inherently a = history-free protocol, so I question the value of knowing when a record = appeared in the DNS when solving operational problems.  I do have a = research project that does track DNSSEC record lifetimes, but that is = research, not operations.  I do the work by remembering what I've = seen in DNS responses over time.

I realize that = today some registries do publish DNSSEC meta-data in port 43 WhoIs and = some do not.  I think path a registry chooses ultimately doesn't = matter - in the sense that I wouldn't tell anyone doing it that they = shouldn't, even if I wouldn't add the information.  In that sense, = if it is in RDAP, fine, make it optional and yes, one form for this is = better than 12 (in the sense that it's one aspect).  But I would = not have designed in to the response the DNSSEC = meta-data.

Scratching the back of my head, I = can't think of any reason why I'd ask "the WhoIs" for the DNSSEC = meta-data for a domain object.  If I can't get it from the DNS = itself, the DNSSEC stuff isn't going to help me in any way.  Even = thinking for historical or escrow purposes, the DNS zone file is already = an adequate vehicle for the DNSSEC meta-data.

On May = 8, 2013, at 16:44, Arturo Servin wrote:


Question, do we really want to = publish all that information in RDAP?

I do not = have strong opinions, just query the = group.

regards,
as

On 5/8/13 1:43 PM, Ernie Dainow = wrote:
It was not easy to find the RDAP = support for DNSSEC. A search for
"DNSSEC" in draft-ietf-weirds-json-response-03 does not = find anything.
Adding a = background note in 6.3 delegationKeys that this is for = DNSSEC
might help. Also as = noted for another document, references should = be
expanded to include the RFC = title. Instead of RFC 4034 [RFC4034],
"Resource Records for the DNS Security Extensions" = [RFC4034].

It would be = useful to have the following additional = information:
1) Create Date - = include an Events array
2) Max = Signature Life -  validity period for the signature in seconds =

You can't verify the digest in delegationKeys without the = following:
3) Flags - = identifies whether it is a zone key
4) Protocol - key protocol, currently must be = 3
5) Public Key - required to = decrypt DS records

While many = providers may not have all of these, it is better for = the
standard to specify them = rather than ending up with various custom
extensions.

-Ernie



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

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

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=_B3F9990B-1EEE-4997-93ED-E28C2C9D6103-- From shollenbeck@verisign.com Thu May 9 08:32: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 F190E21F905B for ; Thu, 9 May 2013 08:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xnawbXB2C80 for ; Thu, 9 May 2013 08:32:30 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id DA84021F8FDD for ; Thu, 9 May 2013 08:32:28 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUYvBjF9R3vPbEkQ6qZDHSSJgFPCsrbEL@postini.com; Thu, 09 May 2013 08:32:30 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r49FWPwA015269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 11:32:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 9 May 2013 11:32:24 -0400 From: "Hollenbeck, Scott" To: Marc Blanchet , "weirds@ietf.org" Thread-Topic: [weirds] weirds interop day: saturday before Berlin IETF Thread-Index: AQHOTKXWsm5E7V5o8EiCrMwTHCbvoJj8+zPg Date: Thu, 9 May 2013 15:32:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24383471@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1429A56E-EF27-4717-BA8D-293A037F2231@viagenie.ca> In-Reply-To: <1429A56E-EF27-4717-BA8D-293A037F2231@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Summers, Dow" Subject: Re: [weirds] weirds interop day: saturday before Berlin IETF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 15:32:35 -0000 Marc, Verisign should have an implementation ready by then and we'd like to= participate. Please add me and Dow Summers (cc'd here) to the mailing list= . Scott > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Thursday, May 09, 2013 7:10 AM > To: weirds@ietf.org > Subject: [weirds] weirds interop day: saturday before Berlin IETF >=20 > Hello, > we are organizing a weirds interop day on saturday July 27th in > Berlin, prior to IETF, most likely in the afternoon. (Details to be > announced later, such as location, exact time). We have contacted some > of the implementors we know and they are in. We are working on a test > plan and test suite that would be used during that session. If you > have an implementation or want to participate, please contact me > directly and I'll put you in the mailing list. Anonymized results of > the interop and any impact on the specifications could be presented at > the weirds meeting. >=20 > Regards, Marc. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From aservin@lacnic.net Thu May 9 08:39: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 1CE6521F9180 for ; Thu, 9 May 2013 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Y7in6WpyTw for ; Thu, 9 May 2013 08:39:48 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id D4CFF21F905F for ; Thu, 9 May 2013 08:39:47 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (unknown [190.90.204.191]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3373830847D for ; Thu, 9 May 2013 12:39:30 -0300 (UYT) Message-ID: <518BC341.9090103@lacnic.net> Date: Thu, 09 May 2013 10:39:45 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: weirds@ietf.org References: <1429A56E-EF27-4717-BA8D-293A037F2231@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F24383471@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24383471@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [weirds] weirds interop day: saturday before Berlin IETF X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 15:39:52 -0000 I imagine that we would need to support the last version of the drafts or to a specific version. There has been some changes in the documents since Orlando (and our implementation is not longer compatible with the latest ones.) I think we should agree to support the last or a set of specific versions (if were the last, probably we should agree to do not change the specifications after a certain date to prepare our code). Regards as On 5/9/13 10:32 AM, Hollenbeck, Scott wrote: > Marc, Verisign should have an implementation ready by then and we'd like to participate. Please add me and Dow Summers (cc'd here) to the mailing list. > > Scott > > >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Marc Blanchet >> Sent: Thursday, May 09, 2013 7:10 AM >> To: weirds@ietf.org >> Subject: [weirds] weirds interop day: saturday before Berlin IETF >> >> Hello, >> we are organizing a weirds interop day on saturday July 27th in >> Berlin, prior to IETF, most likely in the afternoon. (Details to be >> announced later, such as location, exact time). We have contacted some >> of the implementors we know and they are in. We are working on a test >> plan and test suite that would be used during that session. If you >> have an implementation or want to participate, please contact me >> directly and I'll put you in the mailing list. Anonymized results of >> the interop and any impact on the specifications could be presented at >> the weirds meeting. >> >> Regards, Marc. >> _______________________________________________ >> 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 johnl@iecc.com Thu May 9 08:39:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A5F21F905F for ; Thu, 9 May 2013 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEsFhlGTkhlR for ; Thu, 9 May 2013 08:39:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1173421F90F1 for ; Thu, 9 May 2013 08:39:49 -0700 (PDT) Received: (qmail 5303 invoked from network); 9 May 2013 15:39:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 May 2013 15:39:49 -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; s=518bc345.xn--yuvv84g.k1305; i=johnl@user.iecc.com; bh=kIMBHWv7PBeV8BkfAv18eUPa/Mr9+HEPE7Hh+a/7O3E=; b=kzjUOwxDZLwwzlULxnfTs81y82mum2bHJ4+zzO1AM0XIxB946zssJrtdgnFqCL31t7sB3o2nIin6PifmTLbkNWpVUA9Aam53D62JfXpvwGXGfPnIBXPAWy91gVd8z69VsDAFSq52Yd1FU+l/+V+NyRwjjbvxp/KJugVGNLXm7wM= 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; s=518bc345.xn--yuvv84g.k1305; olt=johnl@user.iecc.com; bh=kIMBHWv7PBeV8BkfAv18eUPa/Mr9+HEPE7Hh+a/7O3E=; b=YkWNH6IBFXPcexHMQh7+jJ2hNYxN+GLf/6Nrv1kGupuiVVDMzqB+C45z9w1ECLFOpZ+KfmqGLwBQnNa/6aTErYm4Mbk5pkhYjTD/9o+FJYJ+1uhpj9D2Xn1EFCucYrFtXHXYwtV1dh3vyATBeVmJynFzDlNlsTQ9WFITf6d5scQ= Date: 9 May 2013 15:39:27 -0000 Message-ID: <20130509153927.40912.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: 8bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 15:39:54 -0000 >I realize that today some registries do publish DNSSEC meta-data in port 43 WhoIs >and some do not. This seems like a bad idea. If the results from port 43 and port 53 disagree, who do you believe? On the other hand, everyone's whois publishes the nameservers, same issue. From fneves@registro.br Thu May 9 08:57:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBB221F9418 for ; Thu, 9 May 2013 08:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im-WlVGwC1ab for ; Thu, 9 May 2013 08:57:13 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEE721F9410 for ; Thu, 9 May 2013 08:57:12 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 5DE61E04F9; Thu, 9 May 2013 12:57:08 -0300 (BRT) Date: Thu, 9 May 2013 12:57:08 -0300 From: Frederico A C Neves To: Edward Lewis Message-ID: <20130509155708.GE26525@registro.br> References: <518AB913.5050806@lacnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: weirds@ietf.org Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 15:57:14 -0000 Ed, On Thu, May 09, 2013 at 10:42:49AM -0400, Edward Lewis wrote: > I'm pretty much a lazy lurker, but this subject caught my eye. > > My opinion is against having the DNSSEC meta-data in "the WhoIs" (and by that I mean any form of Registry database content inspection mechanism). Not strongly against as in I think it is wrong, but in the sense that you can get this data from "port 53" anyway. > So why publish the NS set? We've being arguing over the DS/KEY publishing since crisp DREG2. Some of us still think this is the only public OOB way of the DNS publication of verifying the content of the registry. I do know that some registries don't keep in-sync rdap but some does and this has value. As almost all information on rdap is optional I would like to keep this on the base spec. The ones that don't think this way have the ability to simply omit this information. Fred From ed.lewis@neustar.biz Thu May 9 09:17:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E812421F9347 for ; Thu, 9 May 2013 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtA6N3FkCZ4h for ; Thu, 9 May 2013 09:17:35 -0700 (PDT) Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9645B21F92A5 for ; Thu, 9 May 2013 09:17:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3DC791702D6; Thu, 9 May 2013 12:17:35 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id E80E51700B8; Thu, 9 May 2013 12:17:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EEE441B1-0E71-483A-BE6E-F0E9E805318F" From: Edward Lewis In-Reply-To: <20130509155708.GE26525@registro.br> Date: Thu, 9 May 2013 12:17:34 -0400 Message-Id: References: <518AB913.5050806@lacnic.net> <20130509155708.GE26525@registro.br> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 16:17:56 -0000 --Apple-Mail=_EEE441B1-0E71-483A-BE6E-F0E9E805318F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The value in the NS list...is that it contributes to reachability, = albeit in oddball cases. (*) Back in the days before ip6.int was erased from the DNS, there was a = situation where all of the servers for ip6.int also hosted all of the = children of ip6.int. The reason I was debugging this was that I had a = copy of ip6.int on a server I managed and none of the NS list matched = the set of servers that held the data. Because of the set up, no matter = how anyone without administrative access tried to get the data in = ip6.int, they could not get the NS set for the children of Ip6.int. Any query that went to the ip6.int server would be responded to from the = child zone, with the authoritative list and not the "glue" list = registered with ip6.int. The situation that caused this was one I'll tell you over beer sometime. Oddly, it wasn't an operation issue because every query was answered. = The trouble was trying to move the server offering the slave service. = Had there been an ip6.int whois, I could have seen easily the what was = supposed to be the "glue" set. We don't have this problem with DNSSEC. Do you recall "roll over and = die?" (http://www.potaroo.net/ispcol/2010-02/rollover.html) The root = cause was that the "strategy for panicking" when you couldn't find a = working NS did not translate to when you could not find a working = DS/DNSKEY. Although NS and DS are very analogous (delegation of name = space versus delegation of security space), they are not completely the = same. Underscore this with - I don't see any "sin against humanity" in putting = DNSSEC information into "the WhoIs", but I have my reasons why I = wouldn't. (*) In normal situations, there's not reason I consult the NS list in = "the Whois." I guess there are times when the authoritative list I get = is a subset of the "glue version" and if this is due to an active = persistent threat, having the NS in "the WhoIs" (which today is = unprotected, so ...) is a good second path. But once I can reach the NS = that is listed, I can get everything else from there. 'Course, if the = APT is hitting the routing substrate, all bets are off...even getting to = "the WhoIs." I suppose we ought to think of benign and malicious meltdowns, systemic = and random no longer apply. ;) On May 9, 2013, at 11:57, Frederico A C Neves wrote: > Ed, >=20 > On Thu, May 09, 2013 at 10:42:49AM -0400, Edward Lewis wrote: >> I'm pretty much a lazy lurker, but this subject caught my eye. >>=20 >> My opinion is against having the DNSSEC meta-data in "the WhoIs" (and = by that I mean any form of Registry database content inspection = mechanism). Not strongly against as in I think it is wrong, but in the = sense that you can get this data from "port 53" anyway. >>=20 >=20 > So why publish the NS set? We've being arguing over the DS/KEY > publishing since crisp DREG2. >=20 > Some of us still think this is the only public OOB way of the DNS > publication of verifying the content of the registry. I do know that > some registries don't keep in-sync rdap but some does and this has > value. As almost all information on rdap is optional I would like to > keep this on the base spec. The ones that don't think this way have > the ability to simply omit this information. >=20 > Fred = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_EEE441B1-0E71-483A-BE6E-F0E9E805318F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The situation that caused this was one = I'll tell you over beer sometime.

Oddly, it = wasn't an operation issue because every query was answered.  The = trouble was trying to move the server offering the slave service. =  Had there been an ip6.int whois, I could have seen easily the what = was supposed to be the "glue" set.

We don't = have this problem with DNSSEC.  Do you recall "roll over and die?" = (http://www.po= taroo.net/ispcol/2010-02/rollover.html)  The root cause was = that the "strategy for panicking" when you couldn't find a working NS = did not translate to when you could not find a working DS/DNSKEY. =  Although NS and DS are very analogous (delegation of name space = versus delegation of security space), they are not completely the = same.

Underscore this with - I don't see any = "sin against humanity" in putting DNSSEC information into "the WhoIs", = but I have my reasons why I wouldn't.

(*) In normal = situations, there's not reason I consult the NS list in "the Whois." =  I guess there are times when the authoritative list I get is a = subset of the "glue version" and if this is due to an active persistent = threat, having the NS in "the WhoIs" (which today is unprotected, so = ...) is a good second path.  But once I can reach the NS that is = listed, I can get everything else from there.  'Course, if the APT = is hitting the routing substrate, all bets are off...even getting to = "the WhoIs."

I suppose we ought to think of benign = and malicious meltdowns, systemic and random no longer apply. = ;)

On May 9, 2013, at 11:57, Frederico A C Neves = wrote:

Ed,

On Thu, May 09, 2013 at 10:42:49AM -0400, = Edward Lewis wrote:
I'm pretty much a lazy = lurker, but this subject caught my eye.

My opinion is = against having the DNSSEC meta-data in "the WhoIs" (and by that I mean = any form of Registry database content inspection mechanism).  Not = strongly against as in I think it is wrong, but in the sense that you = can get this data from "port 53" anyway.


So why publish the NS set? =  We've being arguing over the DS/KEY
publishing since crisp = DREG2.

Some of us still think this is the only public OOB way of = the DNS
publication of verifying the content of the registry. I do = know that
some registries don't keep in-sync rdap but some does and = this has
value. As almost all information on rdap is optional I would = like to
keep this on the base spec. The ones that don't think this = way have
the ability to simply omit this = information.

Fred

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=_EEE441B1-0E71-483A-BE6E-F0E9E805318F-- From jaap@NLnetLabs.nl Thu May 9 09:28: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 8D82121F9360 for ; Thu, 9 May 2013 09:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dva7oOtAuOrf for ; Thu, 9 May 2013 09:28:56 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 76A4321F86C1 for ; Thu, 9 May 2013 09:28:50 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.6) with ESMTP id r49GSjkY081846; Thu, 9 May 2013 18:28:46 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201305091628.r49GSjkY081846@bela.nlnetlabs.nl> To: Frederico A C Neves From: Jaap Akkerhuis In-reply-to: <20130509155708.GE26525@registro.br> References: <518AB913.5050806@lacnic.net> <20130509155708.GE26525@registro.br> Comments: In-reply-to Frederico A C Neves message dated "Thu, 09 May 2013 12:57:08 -0300." Date: Thu, 09 May 2013 18:28:45 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Thu, 09 May 2013 18:28:48 +0200 (CEST) Cc: Edward Lewis , weirds@ietf.org Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 16:28:57 -0000 Ed, On Thu, May 09, 2013 at 10:42:49AM -0400, Edward Lewis wrote: > I'm pretty much a lazy lurker, but this subject caught my eye. > > My opinion is against having the DNSSEC meta-data in "the WhoIs" (and bythat I mean any form of Registry database content inspection mechanism). Not strongly against as in I think it is wrong, but in the sense that you can get this data from "port 53" anyway. > So why publish the NS set? We've being arguing over the DS/KEY publishing since crisp DREG2. The NS in whois is the set the registry (Parent) has in their database but the authoritative data is in the child. Their might be differences between parent and child. jaap From mike.angstadt@gmail.com Thu May 9 09:31: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 D5DA421F910D; Thu, 9 May 2013 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR1tEEI2fD+4; Thu, 9 May 2013 09:31:24 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4162021F850F; Thu, 9 May 2013 09:31:23 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id z5so3262157lbh.14 for ; Thu, 09 May 2013 09:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QbAD2/NlOz331bhj/d5CtkZobIfgFEHiOp5wO+4Y/FU=; b=qMBKbCnBR5BQpFNH3UCqucw967qqdPKLfciqQ2qBcy1zY/EevN02f9RMJWG93z8fB3 EkG8/jWGG0IwS0/JaNQOJ0OunueOUntzwX5GBzQPaLwo/ExA+GGIbEe5ULxkY3UZmYYM NirtI3IiBB6vFBtH5MMGmKWW0h6/zqOAIlQNYyGZkiRDyQO91wFrYtQSkY13RW3FC+xc neAEk3Tkmm4AhBf6h8CKaYf/yAdwl49AdKoCCbY4es0bgiqK0UJd9VopghS15IBJmEJ4 ODU56a/Na8AsgOtyEzMyeu3M5vXxnL8jc1zHniu0sZlQ1zJ49SzcRCxNIvDZEi4Dm1yH CpcQ== MIME-Version: 1.0 X-Received: by 10.152.18.230 with SMTP id z6mr5820841lad.47.1368117081556; Thu, 09 May 2013 09:31:21 -0700 (PDT) Received: by 10.112.163.136 with HTTP; Thu, 9 May 2013 09:31:21 -0700 (PDT) In-Reply-To: <51895B9A.7010005@gmail.com> References: <51840E3B.9000506@afilias.info> <51895B9A.7010005@gmail.com> Date: Thu, 9 May 2013 12:31:21 -0400 Message-ID: From: Michael Angstadt To: Philipp Kewisch Content-Type: text/plain; charset=ISO-8859-1 Cc: "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 16:31:29 -0000 On Tue, May 7, 2013 at 3:52 PM, Philipp Kewisch wrote: > Even this should work out, although its probably the solution least > compatible to the spec. > > [ "adr", { "label": "foo bar baz" }, "text" ] I think that example is pushing it, but I agree that an empty ADR value should be valid. From carlosm3011@gmail.com Thu May 9 10:09: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 CAAE121F931B for ; Thu, 9 May 2013 10:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9i82oNdRpTs for ; Thu, 9 May 2013 10:09:40 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62621F8696 for ; Thu, 9 May 2013 10:09:40 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so784458yho.16 for ; Thu, 09 May 2013 10:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C5K0HPs0KRHQqYt4nlz/LmGhkfRAkQvwtUwrWV4wopw=; b=OOHTo/An6njtb0n1znebgNVoTZL8Sw4DsQKTnxZIVgCPL47n9r1z1owBCQCgj03CMO eQXl27gd+gpLJWsyFY8KDEYHdSw1/lqJ+DyMg5COd5DvwqSsp7tvw9p5QbFuF4ScSZfR IVQSJ+V4cLABDGfcRJvLduHCbyGlphyTL7whMbTKOcq/JNJw2Mi2KKOJ61jmhxOLsSp2 EYGn4e8x77n+y+2j3JnYo/IUS6wX4nVW41/GLU5usRdqEswvMN22f5AAQEKZ50oBWoJ7 Y7CmS7KhG6oVIt4H0oXjqrrRb/LCbyVbsSIkEiawu6HykEOJNV8zjCjagWSQGpYu0QYu JjDw== X-Received: by 10.236.73.68 with SMTP id u44mr9404152yhd.152.1368119379746; Thu, 09 May 2013 10:09:39 -0700 (PDT) Received: from bonaire.local ([190.90.204.4]) by mx.google.com with ESMTPSA id s45sm5016651yhk.22.2013.05.09.10.09.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 10:09:38 -0700 (PDT) Message-ID: <518BD855.9010101@gmail.com> Date: Thu, 09 May 2013 12:09:41 -0500 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 17:09:40 -0000 Hey, On 5/9/13 9:14 AM, Andy Newton wrote: > On 5/8/13 5:11 PM, "Carlos M. martinez" wrote: > >> I'm basically fine with it. > > Ditto. > >> >> However, I'm a bit worried that, given enough time, every different >> stakeholder will find some attribute he/she might want to add. >> >> I think we need to define how we are going extend rdap-response without >> keeping it as a draft until the heat death of the Universe. > > Are you speaking of something other than the current ability to add > registry specific JSON attributes? Well, maybe yes. The way I read the original post, I understood the intent was to add attributes X or Y to the base spec. While I agree that having the ability to extend the protocol in registry-specific ways is all important, there may be cases where someone will think that adding an attribute to the base spec is needed. I'm not saying that DNSSEC is the case though, the more I think about it I rather believe it should be a registry-specific thing. regards ~Carlos > > -andy > From fobispo@isc.org Thu May 9 10:57: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 9707721F8A48 for ; Thu, 9 May 2013 10:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmhxGFos0892 for ; Thu, 9 May 2013 10:57:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 05B9121F89D5 for ; Thu, 9 May 2013 10:57:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id ED9E8C94B3; Thu, 9 May 2013 17:56:59 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368122222; bh=07GpoPXu/Q2NpICieNm6Gq8414BRZcoM8fcoBJTmnDU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nT/waVWyrPS5hzoAcmwFuKKx/Jn89ducD72jWat89dPGg01TBN5MVvJYC6Y8djxL7 T3+KXHUDzETpmEcPqSoMia02GQ3Xb5nbDNdBe9BzsVqf1ZvXj54Zyqdr1/p20v4nUU yDdWFer1NKd+Eqk89VKEPnYagdf8coMkrT8eUH4k= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 9 May 2013 17:56:59 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:65:8130:e0ec:9f2e:f57] (unknown [IPv6:2001:4f8:3:65:8130:e0ec:9f2e:f57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E07C3216C40; Thu, 9 May 2013 17:56:59 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <518BD855.9010101@gmail.com> Date: Thu, 9 May 2013 10:56:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63D9C9DD-2B7D-44C7-A278-5EC06D4171C2@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> <518BD855.9010101@gmail.com> To: Carlos M. martinez X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 May 2013 17:57:03 -0000 The main question is whether we are proposing a data format with = transport, or the specification for a service. Some of this things will be mandatory by groups outside of the IETF, = such as ICANN, and registry policy. Unfortunately not every single use = case will fall under the same umbrella, and the fact that the protocol = does not require any specific fields, generate a problem and a grey area = with regards to functionality. francisco On May 9, 2013, at 10:09 AM, Carlos M. martinez = wrote: > Well, maybe yes. The way I read the original post, I understood the > intent was to add attributes X or Y to the base spec. >=20 > While I agree that having the ability to extend the protocol in > registry-specific ways is all important, there may be cases where > someone will think that adding an attribute to the base spec is = needed. >=20 > I'm not saying that DNSSEC is the case though, the more I think about = it > I rather believe it should be a registry-specific thing. >=20 > regards >=20 > ~Carlos Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From kewisch@gmail.com Tue May 7 12:53:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18A21F912C; Tue, 7 May 2013 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejl2FKKuagfC; Tue, 7 May 2013 12:53:17 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1400D21F8F3C; Tue, 7 May 2013 12:53:16 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id rp8so642061pbb.8 for ; Tue, 07 May 2013 12:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:content-type; bh=avT5TcTVZ67gX36xu3Uvkk0zrLxAxOUfd63P0QdKNpI=; b=jYtbgLEXRYBwMiSmvxTSHwyyR8l5jOIq5ql1wzS/NYB//RcwNyiyopGJBH0FnIGAsl ZecgxkkkP6Ox5wLz4WNQTJ+KWxiLDCm2p220ojhM8lXX4NyWd8koCel79oyGPeuvMzOR +rHp3jQnuTpkRPdiZbXW/NrtnUFLuMTrVCAyEy0A/Oxmhb+m/3KaP1sMoAA7SgZiVdZq DfrKCWiwLUlAENYAg7O4lbVi7c9bMPNKiBUJFiBDzyJWVwJW8Hl2gdn1xiTYp07uWSCP MLEvYRHnpdWPNDK0nOEuxZ2L+Zqun6DIWNxTc+okxTdCKeN6RTCy3OWotb0mag6gpb+H mP9w== X-Received: by 10.68.37.68 with SMTP id w4mr4033401pbj.105.1367956392281; Tue, 07 May 2013 12:53:12 -0700 (PDT) Received: from oskar.local (e177213041.adsl.alicedsl.de. [85.177.213.41]) by mx.google.com with ESMTPSA id qb1sm29364113pbb.33.2013.05.07.12.53.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 12:53:11 -0700 (PDT) Message-ID: <51895B9A.7010005@gmail.com> Date: Tue, 07 May 2013 21:52:58 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 References: <51840E3B.9000506@afilias.info> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050303060604050109020503" X-Mailman-Approved-At: Sat, 11 May 2013 10:34:33 -0700 Cc: "jcardcal@ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [Jcardcal] LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 May 2013 19:53:22 -0000 This is a multi-part message in MIME format. --------------050303060604050109020503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/6/13 3:59 AM, Michael Angstadt wrote: > On Sun, May 5, 2013 at 8:58 PM, Byron Ellacott wrote: >> Is the array syntax a valid alternative to the semi-colon separated string >> that is yet to appear in the draft, or in the draft in a corner I can't >> find? > The array syntax is *required*. There is no alternative. The > semi-colon syntax is only used in traditional, text-based vCards. > jCard does not support this. The label parameter is *optional*. > > -Mike So for your unstructured-value-only property is a text property without a value. This is allowed per vCard spec with the following abnf: value = text / text-list / date-list / .... text = *TEXT-CHAR TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII / %x21-2B / %x2D-5B / %x5D-7E This gives you the following property: ADR;LABEL="foo bar baz": Foremost, this is a text property. Parsers are instructed to always check the type since it may turn out to be a structured value. Therefore, using: [ "adr", { "label": "foo bar baz" }, "text", "" ] shouldn't cause parsers to break. As ADR is a structured property, this would be fine too: [ "adr", { "label": "foo bar baz" }, "text", [] ] Even this should work out, although its probably the solution least compatible to the spec. [ "adr", { "label": "foo bar baz" }, "text" ] I guess this isn't 100% clear, although given the first two options should both work per spec, I don't know if I should add clarification. --------------050303060604050109020503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/6/13 3:59 AM, Michael Angstadt wrote:
On Sun, May 5, 2013 at 8:58 PM, Byron Ellacott <bje@apnic.net> wrote:

Is the array syntax a valid alternative to the semi-colon separated string
that is yet to appear in the draft, or in the draft in a corner I can't
find?

The array syntax is *required*.  There is no alternative.  The
semi-colon syntax is only used in traditional, text-based vCards.
jCard does not support this.  The label parameter is *optional*.

-Mike

So for your unstructured-value-only property is a text property without a value. This is allowed per vCard spec with the following abnf:

value = text / text-list / date-list / ....
text = *TEXT-CHAR
TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII / %x21-2B / %x2D-5B / %x5D-7E

This gives you the following property:
ADR;LABEL="foo bar baz":

Foremost, this is a text property. Parsers are instructed to always check the type since it may turn out to be a structured value. Therefore, using:

[ "adr", { "label": "foo bar baz" }, "text", "" ]

shouldn't cause parsers to break. As ADR is a structured property, this would be fine too:

[ "adr", { "label": "foo bar baz" }, "text", [] ]

Even this should work out, although its probably the solution least compatible to the spec.

[ "adr", { "label": "foo bar baz" }, "text" ]

I guess this isn't 100% clear, although given the first two options should both work per spec, I don't know if I should add clarification.

--------------050303060604050109020503-- From internet-drafts@ietf.org Mon May 13 11:02:07 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD921F93FF; Mon, 13 May 2013 11:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTtEEuinunJW; Mon, 13 May 2013 11:02:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C19421F8F6E; Mon, 13 May 2013 11:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513180206.1852.34168.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 11:02:06 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-05.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, 13 May 2013 18:02:07 -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 : HTTP usage in the Registration Data Access Protocol (RDA= P) Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-05.txt Pages : 15 Date : 2013-05-13 Abstract: This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From carlosm3011@gmail.com Tue May 14 09:51:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD021F915B for ; Tue, 14 May 2013 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH7Xph9H0Rbo for ; Tue, 14 May 2013 09:51:27 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75721F90C1 for ; Tue, 14 May 2013 09:51:27 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so2229678qae.6 for ; Tue, 14 May 2013 09:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=enQcDey5uNvYc9CJOrE38mbVuLB6oZn4jROSphXOp3Y=; b=HC0IP6BJvyaRQ0QUT7RVJrqYLfDHbmeIyNodV4idc3k5rKi0qG+AmeDli6XEZWyRAj XP8GjuGWyq5CE2nb+LiJVzU2bl7aZCeweKhiMifm4cTvmNkVB/Ke15wkfjX3qWlIQi/V 4HT1RzIuCqICM/0kvAjFPV2YeQFtENPF7Pat4vPsmZ+J4gRoFOTCT5LNQ9xvNw0SIgdH O5572LjMpz5twp4rQFNpvLZmbw16zXHmeRGL/xrUOcBLQx0gj+HXjmp46uYn0E5HsRFK F1oADGMHi30fRgq0C7cIuJT0aIWaow+Xk76lNabfCmKiTW+GTunLgvQA9RFfsNvNGJkz twYQ== X-Received: by 10.49.35.72 with SMTP id f8mr29254341qej.4.1368550287051; Tue, 14 May 2013 09:51:27 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.57]) by mx.google.com with ESMTPSA id hs4sm15402733qeb.8.2013.05.14.09.51.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 09:51:26 -0700 (PDT) Message-ID: <51926B8D.9040905@gmail.com> Date: Tue, 14 May 2013 13:51:25 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Francisco Obispo References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> <518BD855.9010101@gmail.com> <63D9C9DD-2B7D-44C7-A278-5EC06D4171C2@isc.org> In-Reply-To: <63D9C9DD-2B7D-44C7-A278-5EC06D4171C2@isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC 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: Tue, 14 May 2013 16:51:29 -0000 Francisco/All, I rather now believe this requirement would be better served by a registry-specific extension. However, in order to avoid the silly situation where every registry requiring DNSSEC info for their RDAP output names the fields differently, maybe a short I-D describing the names of the fields would be useful. If ICANN makes the use of these extensions a requirement, well, having a uniform naming and field semantics would definitely help and can even be referenced by ICANN. However, as not everyone will need to implement it (for example, us in the 'numbers' field are not very likely to use it), IMO, the correct place for it is in a 'standardized extension field' set, if you catch my drift :D cheers! ~C. On 5/9/13 2:56 PM, Francisco Obispo wrote: > The main question is whether we are proposing a data format with transport, or the specification for a service. > > Some of this things will be mandatory by groups outside of the IETF, such as ICANN, and registry policy. Unfortunately not every single use case will fall under the same umbrella, and the fact that the protocol does not require any specific fields, generate a problem and a grey area with regards to functionality. > > francisco > > > On May 9, 2013, at 10:09 AM, Carlos M. martinez wrote: > >> Well, maybe yes. The way I read the original post, I understood the >> intent was to add attributes X or Y to the base spec. >> >> While I agree that having the ability to extend the protocol in >> registry-specific ways is all important, there may be cases where >> someone will think that adding an attribute to the base spec is needed. >> >> I'm not saying that DNSSEC is the case though, the more I think about it >> I rather believe it should be a registry-specific thing. >> >> regards >> >> ~Carlos > > Francisco Obispo > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > From fobispo@isc.org Tue May 14 09:58: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 8889321F85EB for ; Tue, 14 May 2013 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecBGMTde0Y0c for ; Tue, 14 May 2013 09:58:49 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 222A121F8529 for ; Tue, 14 May 2013 09:58:49 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B953B5F98B6; Tue, 14 May 2013 16:58:39 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368550728; bh=8K/M5ScHQT/z7ii5y2ZhviBQOxSmA8Y4sc2AWsbmBRg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iBElgYFThZQUmJMpMPAjp2xpFqOqUlfh0w3M6PsU3L83p3xG0bD+youe4XiYZuTdJ Wxci+j0mtRNEjc4aYa3ZY1Apjz4sohh74sjS2t7VuDoGXi2/g8iBXqeSM8QUURfStp yhOUbgl1+6ZyTekiG+9nDmU/Ia3GteL5QGBKxgkA= Received: from [IPv6:2001:470:1f05:1326:a947:cb9d:f4d9:9ed3] (unknown [IPv6:2001:470:1f05:1326:a947:cb9d:f4d9:9ed3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F1017216C43; Tue, 14 May 2013 16:58:37 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <51926B8D.9040905@gmail.com> Date: Tue, 14 May 2013 09:58:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <332CCB6D-856D-428B-8989-DE4DC8EB8F6C@isc.org> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> <518BD855.9010101@gmail.com> <63D9C9DD-2B7D-44C7-A278-5EC06D4171C2@isc.org> <51926B8D.9040905@gmail.com> To: carlos@lacnic.net X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 14 May 2013 16:58:50 -0000 We can do an extension, However, I do believe that Number registries will make use of this too, since you = do manage "in-addr" zones, and people do use DNSSEC on them as well. So is the rule of thumb is that everything that number registries are = going to use go into the draft and the rest extensions? Because if that's not it, we should probably then make clear = distinctions of the content vs transport by presenting more 'response' = documents and not attempting to have one type fits all type of solution. Francisco On May 14, 2013, at 9:51 AM, "Carlos M. Martinez" = wrote: > >=20 > I rather now believe this requirement would be better served by a > registry-specific extension. >=20 > However, in order to avoid the silly situation where every registry > requiring DNSSEC info for their RDAP output names the fields > differently, maybe a short I-D describing the names of the fields = would > be useful. >=20 > If ICANN makes the use of these extensions a requirement, well, having = a > uniform naming and field semantics would definitely help and can even = be > referenced by ICANN. >=20 > However, as not everyone will need to implement it (for example, us in > the 'numbers' field are not very likely to use it), IMO, the correct > place for it is in a 'standardized extension field' set, if you catch = my > drift :D >=20 > Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From andy@arin.net Tue May 14 10:09:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B621F91B7 for ; Tue, 14 May 2013 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+o1Z-JrX7Jy for ; Tue, 14 May 2013 10:09:06 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 8A00921F915B for ; Tue, 14 May 2013 10:09:05 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 09468164F8C; Tue, 14 May 2013 13:09:05 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id AD607164F3B; Tue, 14 May 2013 13:09:04 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 14 May 2013 13:08:48 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 14 May 2013 13:08:58 -0400 From: Andy Newton To: "carlos@lacnic.net" , Francisco Obispo Thread-Topic: [weirds] DNSSEC Thread-Index: AQHOTBwUxAfhzI3uIEKL0X83GeR37Jj8DCmAgADayYCAAEAulIAICkCA///B1AA= Date: Tue, 14 May 2013 17:08:56 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC050D6@CHAXCH01.corp.arin.net> In-Reply-To: <51926B8D.9040905@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <469283A4B84AB943A8B61DF16DCC0A27@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 14 May 2013 17:09:12 -0000 On 5/14/13 12:51 PM, "Carlos M. Martinez" wrote: >However, as not everyone will need to implement it (for example, us in >the 'numbers' field are not very likely to use it), IMO, the correct >place for it is in a 'standardized extension field' set, if you catch my >drift :D There are a good number of parts in the current spec that number registries will use which domain registries will not use. So I don't see the logic here. I think it is perfectly fine to try to define those JSON values now and get it in the current spec. This is not an unknown area, and so should be easy to accomplish. A standard extension would just result in all clients trying to support it anyway. Does anyone want to take a stab at the JSON for this? -andy From zhoulinlin@cnnic.cn Wed May 15 04:05: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 629A721F8F32 for ; Wed, 15 May 2013 04:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIjWUFHsbAnS for ; Wed, 15 May 2013 04:05:30 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id E681C21F901B for ; Wed, 15 May 2013 04:05:02 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 15 May 2013 19:04:53 +0800 From: "Linlin Zhou" To: , "'Francisco Obispo'" References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC03E67@CHAXCH01.corp.arin.net> <518BD855.9010101@gmail.com> <63D9C9DD-2B7D-44C7-A278-5EC06D4171C2@isc.org> <51926B8D.9040905@gmail.com> In-Reply-To: <51926B8D.9040905@gmail.com> Date: Wed, 15 May 2013 19:04:53 +0800 Message-ID: <00d501ce515c$0771c260$16554720$@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: Ac5Qw04h8isblnhiQUWJKx9zhZPYYQAl5CpQ Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] DNSSEC X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 May 2013 11:05:35 -0000 > > > > I rather now believe this requirement would be better served by a > registry-specific extension. > > However, in order to avoid the silly situation where every registry requiring > DNSSEC info for their RDAP output names the fields differently, maybe a short > I-D describing the names of the fields would be useful. > > If ICANN makes the use of these extensions a requirement, well, having a > uniform naming and field semantics would definitely help and can even be > referenced by ICANN. > I think this changed mind is better :) I have a question that whether we would define the standardized extension in the same response draft or a new I-D? Shall we first think about what are the standardized extension for RDAP? > However, as not everyone will need to implement it (for example, us in the > 'numbers' field are not very likely to use it), IMO, the correct place for it is in a > 'standardized extension field' set, if you catch my drift :D > > > From pieter.vandepitte@dnsbelgium.be Wed May 15 09:06: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 8740221F9017 for ; Wed, 15 May 2013 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTbFNzGFSCMW for ; Wed, 15 May 2013 09:06:42 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id C1DCB21F86BB for ; Wed, 15 May 2013 09:06:40 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 1C9E7426000A for ; Wed, 15 May 2013 18:06:39 +0200 (CEST) Message-ID: <5193B28E.1030103@dnsbelgium.be> Date: Wed, 15 May 2013 18:06:38 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 May 2013 16:06:58 -0000 Hi, some stuff is still unclear to me: Quoting from http://tools.ietf.org/html/draft-ietf-weirds-using-http-05 > If the receiving server does not have the information being > requested and does not have knowledge of where the information > can be found, it returns a 404 response. and > If a server wishes to respond that it has no information regarding > the query, it MUST return a 404 response code. Optionally, it MAY > include additional information regarding the negative answer in the > HTTP entity body. Strictly speaking, when a receiving server replies with a status equal to available for a particular request, it DOES have information about the requested domain: i.e. the domain is available and can be registered. So in the case of a domain status = available (and if the domain name in the request does comply to the parent domain policies and if the server is authoritative for that information), I would implement the current draft as returning a 200. On the other hand it is a common practice in restful services to return a 404 when the object is not found (= the domain is not found = the domain is available) This topic was already touched by Maarten Wullink (http://www.ietf.org/mail-archive/web/weirds/current/msg02444.html) but I couldn't find any clear answers on that. Any recommendations? Kind regards Pieter From bje@apnic.net Wed May 15 17:26: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 7AA7811E80E8 for ; Wed, 15 May 2013 17:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.223 X-Spam-Level: ** X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, SARE_URI_CONS9=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvK-OWkaQ7do for ; Wed, 15 May 2013 17:26:27 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 8442E11E80D7 for ; Wed, 15 May 2013 17:26:22 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 16 May 2013 10:26:19 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852::11) with Microsoft SMTP Server (TLS) id 14.1.421.2; Thu, 16 May 2013 10:26:19 +1000 Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Thu, 16 May 2013 10:26:18 +1000 From: Byron Ellacott To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] 404 Thread-Index: AQHOUYY9E6LDWRn6DUuvXGB04yXZD5kG9OgA Date: Thu, 16 May 2013 00:26:18 +0000 Message-ID: In-Reply-To: <5193B28E.1030103@dnsbelgium.be> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.101.249] Content-Type: text/plain; charset="us-ascii" Content-ID: <183FB79E9C4778489462E36063C98E13@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 May 2013 00:26:31 -0000 Hi Pieter, On 16/05/13 2:06 AM, "Pieter Vandepitte" wrote: >Hi, some stuff is still unclear to me: > >Quoting from http://tools.ietf.org/html/draft-ietf-weirds-using-http-05 > >> If the receiving server does not have the information being >> requested and does not have knowledge of where the information >> can be found, it returns a 404 response. > >and > >> If a server wishes to respond that it has no information regarding >> the query, it MUST return a 404 response code. Optionally, it MAY >> include additional information regarding the negative answer in the >> HTTP entity body. > >Strictly speaking, when a receiving server replies with a status equal >to available for a particular request, it DOES have information about >the requested domain: i.e. the domain is available and can be registered. That particular information does not lie in the registration data context, though. RDAP answers questions about registration data, and a separate service could answer questions about name availability. My exhaustive test of one registrar suggests that their current port 43 behaviour does this: if I search for fdkajsfhlksdjhflsa.com, I get a "no match" response, not an "available" response. Byron From maarten.wullink@sidn.nl Thu May 16 00:23: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 73A9F21F8DFC for ; Thu, 16 May 2013 00:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.551 X-Spam-Level: * X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_39=0.6, SARE_URI_CONS9=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7m4qjxqDarN for ; Thu, 16 May 2013 00:23:17 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 326C221F8AA6 for ; Thu, 16 May 2013 00:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=Do+VMP2ra6YJr3XtJXb7J5QMljccecGT2b7ipVQ9XGI=; b=FlN8R6Ze+cc3zuJH8y1CBlobB+YrZZwKfmbUCtuNLDOY5901ZPa49XKjbAWOIRJZmPWqnPIJjBYa/mZXIXku30tlDItZ5lWnmyy8nLWXnhPxfywDs2P2KeM7hNgQMO1pMuc8A5EYnGagTY2z1ksXK7ZW6UhypHOCOIWNz/itfHo= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r4G7NAST010017-r4G7NASV010017 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 16 May 2013 09:23:10 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 16 May 2013 09:23:10 +0200 Received: from [94.198.152.215] (94.198.152.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 16 May 2013 09:23:10 +0200 Message-ID: <5194895D.8070409@sidn.nl> Date: Thu, 16 May 2013 09:23:09 +0200 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Byron Ellacott References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.215] Cc: "weirds@ietf.org" Subject: Re: [weirds] 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 May 2013 07:23:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My exhaustive test of one registrar suggests that their current > port 43 behaviour does this: if I search for > fdkajsfhlksdjhflsa.com, I get a "no match" response, not an > "available" response. at the .nl ccTLD we support the "is " syntax for our port 43 service. Which returns yes if the name exists otherwise it returns no. I would be nice to support this with weirds, the current draft says that when a 404 is returned, additional information may be added to the entity body. Maybe we can describe a "availability" response? This is something a number of different user types would be interested in. something like this for names that are not in the registry and may be registered? { "ldhName" : "thisnamedoesnotexist.example.com", "available": "yes" } and for currently registered names. { "ldhName" : "example.com", "available": "no" } > > Byron > > _______________________________________________ weirds mailing > list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds > - -- Maarten Wullink MSc|Technical advisor / R&D engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05 maarten.wullink@sidn.nl | www.sidn.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRlIldAAoJEHZPQ3qFDFN1MGgIAMEJ2QOAl6fW5uRSJAaolT/C E7M1tMI3nupcG6iaDw2Wz5W1QqaAN0XtvfIkwbKKjCm+L9MDIetXHohyBsdoNd3d Fz7TvE/2GHfAL2WTI7Hhii9c/5Fpz0b71BMO027yrP6619fboqvD+IIKTeFp5Kaj AjjWSSVF4XEMjq0LtPS+3lFMHjLMcznqIn2a5JTlE9z6S6wCHjqLqAGnpkM06aby 7QAqGaJ4Otyzu2aw/6eTZF/B9zoDMSY843vI1YvQPYKDsqUx7hJMDNi1si9B79wi 2Srt+g5jz/svEvlgJ1HzPBAd5Zg8DmNcNGRzqPQI1wofOO2RPw7mJ62TlARj/ZY= =bno4 -----END PGP SIGNATURE----- From andy@arin.net Thu May 16 03:14: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 3918621F8EF7 for ; Thu, 16 May 2013 03:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE1fL6H6+nc0 for ; Thu, 16 May 2013 03:14:29 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id DA98321F8EF2 for ; Thu, 16 May 2013 03:14:28 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 32721165578; Thu, 16 May 2013 06:14:28 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 7B2AA165576; Thu, 16 May 2013 06:14:25 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 16 May 2013 06:13:58 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 16 May 2013 06:13:14 -0400 From: Andy Newton To: Maarten Wullink , Byron Ellacott Thread-Topic: [weirds] 404 Thread-Index: AQHOUYY5r2yAfCs0p0uWUoYtS2nAg5kHN/gAgAB0eID//+y4gA== Date: Thu, 16 May 2013 10:14:11 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC05CB7@CHAXCH01.corp.arin.net> In-Reply-To: <5194895D.8070409@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 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] 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 May 2013 10:14:33 -0000 On 5/16/13 3:23 AM, "Maarten Wullink" wrote: >something like this for names that are not in the registry and may be >registered? > > { > "ldhName" : "thisnamedoesnotexist.example.com", > "available": "yes" > } > > >and for currently registered names. > > { > "ldhName" : "example.com", > "available": "no" > } There is already an "unregistered" value for variants. We could have the same value for status. { "ldhName" : "thisnamedoesnotexist.example.com", "status": [ "unregistered" ] } But Byron's point still stands. The behavior of current Whois systems is usually to return no-answer. So for interoperability purposes, is it 404 or a status of "unregistered"? Having some systems do one and some systems do the other seems like a recipe for confusion. From an RIR perspective, the answer should be 404 as in-addr.arpa domains aren't available for registration. Just curious what others think. This strays into the territory of a separate DAC protocol (started here: http://www.ietf.org/mail-archive/web/weirds/current/msg02495.html), which I still think is a good idea. -andy From pieter.vandepitte@dnsbelgium.be Thu May 16 04:56: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 7447B21F8D71 for ; Thu, 16 May 2013 04:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjmXC51SBewO for ; Thu, 16 May 2013 04:56:55 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1640421F8D31 for ; Thu, 16 May 2013 04:56:54 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 9AF9C4260045; Thu, 16 May 2013 13:56:51 +0200 (CEST) Message-ID: <5194C982.1040209@dnsbelgium.be> Date: Thu, 16 May 2013 13:56:50 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC05CB7@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC05CB7@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 May 2013 11:56:59 -0000 I agree to some degree with Andy and Byron. I would definitely not invent a new property, but rather extend the existing set of values. Besides that, a 404 would be appropriate in the case of a "no match". On the other hand, I'm not a proponent of yet another protocol. I think it could perfectly fit into this protocol. Could we combine both approaches (404 and extending status) and specify something into the draft like: "A server MUST return a 404 when it is authoritative for the requested object. It MAY return an object response containing further information." e.g. HTTP/1.1 404 Not Found Content-Type: application/rdap+json { "ldhName": "thisnamedoesnotexist.example.com", "status": ["unregistered"], "remarks" : [ { "description" : [ "You can register your domain name at www.example.com", "Originally written by Terry Sullivan." ] } ] } There should be several extra statusses, like "unregistered", "restricted registration", "not allowed" What do you think? Pieter On 05/16/2013 12:14 PM, Andy Newton wrote: > On 5/16/13 3:23 AM, "Maarten Wullink" wrote: > >> something like this for names that are not in the registry and may be >> registered? >> >> { >> "ldhName" : "thisnamedoesnotexist.example.com", >> "available": "yes" >> } >> >> >> and for currently registered names. >> >> { >> "ldhName" : "example.com", >> "available": "no" >> } > > There is already an "unregistered" value for variants. We could have the > same value for status. > > { > "ldhName" : "thisnamedoesnotexist.example.com", > "status": [ "unregistered" ] > } > > But Byron's point still stands. The behavior of current Whois systems is > usually to return no-answer. So for interoperability purposes, is it 404 > or a status of "unregistered"? Having some systems do one and some systems > do the other seems like a recipe for confusion. From an RIR perspective, > the answer should be 404 as in-addr.arpa domains aren't available for > registration. Just curious what others think. > > This strays into the territory of a separate DAC protocol (started here: > http://www.ietf.org/mail-archive/web/weirds/current/msg02495.html), which > I still think is a good idea. > > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From francisco.arias@icann.org Thu May 16 16:31:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36C21F8F6E for ; Thu, 16 May 2013 16:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2D4887tjwW9 for ; Thu, 16 May 2013 16:31:08 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5929321F8F43 for ; Thu, 16 May 2013 16:31:08 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 16 May 2013 16:31:08 -0700 From: Francisco Arias To: "weirds@ietf.org" Date: Thu, 16 May 2013 16:31:02 -0700 Thread-Topic: gtld-tech mailing list Thread-Index: Ac5SjXDO9/0Eu2qfTZuxNmXQnQqdIQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] gtld-tech mailing list X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 May 2013 23:31:08 -0000 Colleagues, This is to let you know that we are launching a public, open mailing list for technical discussions regarding gTLD registries and registrars. The intention is to provide a forum for discussion of issues that may appear during ongoing operation and particularly with the upcoming launch of new gTLDs. You can subscribe to the list at: https://mm.icann.org/mailman/listinfo/gtld-tech Regards, --=20 Francisco Arias ICANN technical staff From superuser@gmail.com Thu May 16 17:26:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E960B11E8129 for ; Thu, 16 May 2013 17:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7gDZVCgJLKd for ; Thu, 16 May 2013 17:26:02 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 43C9A11E80A3 for ; Thu, 16 May 2013 17:26:02 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so383228wib.4 for ; Thu, 16 May 2013 17:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oP3JyvEoGcPIWCNWq7wkRgk55GfXrFflfuBK2Nc0CtM=; b=jBjtfIcBLTD278zjsTLnSwGHer2jrda4xAKFXT5zIwymP8CoYlMHpnd1vsOsg0WW8r pjK9K31Ly5+2Bn9O6oGgCw/NbJBOYUx5Irv4p7i7IohG8d2t1TDMb4MIK1gksdhtxY6N YKQL3vNys5bPnZGyXQ5C9q96VM5STMLJYtCfukJ4pdpiICxXPalU4003NyPQQKK3iyfX x4APPksusjuYLcOhrdIm1PSgOcAq4X/TO+heQCQTIulvTkZxaSwk8ChZZeGon8x99u8L JIxaP/CXOgnxn7k/teSfIhquhJlogHTPuzMcRDKDByq9U639gNli+wxfytwpJGcKokDa wF8w== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr29019886wij.20.1368750361251; Thu, 16 May 2013 17:26:01 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 17:26:01 -0700 (PDT) In-Reply-To: <00d801ce46f9$b5158310$1f408930$@cn> References: <00d801ce46f9$b5158310$1f408930$@cn> Date: Thu, 16 May 2013 17:26:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Linlin Zhou Content-Type: multipart/alternative; boundary=e89a8f50335a11947704dcdf077b Cc: "weirds@ietf.org" , shenshuo Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 May 2013 00:26:03 -0000 --e89a8f50335a11947704dcdf077b Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 1, 2013 at 10:55 PM, Linlin Zhou wrote: > Since the response draft has a reference of the inventory draft, I suggest > to complete it before the response draft. Maybe July or August is > appropriate.**** > > > This document has four authors. Are they all satisfied with an August milestone? The absence of more than one reply to this question has me worried. Are there any other opinions about this? Will we have enough reviewers to be able to move the document forward? -MSK, WEIRDS co-chair --e89a8f50335a11947704dcdf077b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 1, 2013 at 10:55 PM, Linlin Zhou <zhoulinli= n@cnnic.cn> wrote:

Since the re= sponse draft has a reference of the inventory draft, I suggest to complete = it before the response draft. Maybe July or August is appropriate.



This document has four authors.=A0 Are = they all satisfied with an August milestone?

The absence of more than one reply to this question has me w= orried.=A0 Are there any other opinions about this?=A0 Will we have enough = reviewers to be able to move the document forward?

-MSK, = WEIRDS co-chair

--e89a8f50335a11947704dcdf077b-- From superuser@gmail.com Thu May 16 17:27:16 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28E911E8129 for ; Thu, 16 May 2013 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aoh1vE8CYOG for ; Thu, 16 May 2013 17:27:16 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 398F011E80A3 for ; Thu, 16 May 2013 17:27:13 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so195118wgh.5 for ; Thu, 16 May 2013 17:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=nEEX/An6lUyCdmrvOGjbZjQFu6SxNe0OtmgOkE1erd4=; b=T3MlvMjFaPVBZxpC+H+cgPpxcWuXsnrkWiTgG+nmFkjuEcS3izkJacdvtzM1aijvYC 1oGfkN66tUW/QDCNqgNLsUv9bGgfntoBYrb0B9i9nAxrzYQy9fDhCz/U/N/tGx/fzWw6 h1K7Ub+NzAlOOKm2t6+znNnhoctdBP46L4+sGs/3NRKvfhDEowA1nMMQyBFZB4jQXO7Q KDmyKdC22mZgCyar5aOqLuGmbXczjOM7+EZ/yrhLB9gFFV+LsdWSFqnuiD8ZIGgNlP+r GKbovrA0E12qNlob/V/oCqON1yhznr19Q2imD9fyJT5WYeO2Cm2Fta2CY8ZHALiNiWda FliA== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr29023798wij.20.1368750432412; Thu, 16 May 2013 17:27:12 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 17:27:12 -0700 (PDT) Date: Thu, 16 May 2013 17:27:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f50335a4f6aab04dcdf0bb8 Subject: [weirds] draft-ietf-weirds-rdap-sec submitted X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 May 2013 00:27:16 -0000 --e89a8f50335a4f6aab04dcdf0bb8 Content-Type: text/plain; charset=ISO-8859-1 WEIRDS FYI: draft-ietf-weirds-rdap-sec has been submitted to the IESG for review and publication. Thanks to the authors and reviewers for their diligence. Onward! -MSK, WEIRDS co-chair --e89a8f50335a4f6aab04dcdf0bb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
WEIRDS FYI:

draft-ietf-weirds-rdap-= sec has been submitted to the IESG for review and publication.=A0 Thanks to= the authors and reviewers for their diligence.

Onward!

-MSK, WEIRDS co-chair

--e89a8f50335a4f6aab04dcdf0bb8-- From nkong@cnnic.cn Thu May 16 17:56:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4601311E8137 for ; Thu, 16 May 2013 17:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0L95X4666lY for ; Thu, 16 May 2013 17:56:51 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id C14E211E8132 for ; Thu, 16 May 2013 17:56:50 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.58]) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 17 May 2013 08:56:42 +0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_42EC799F-1BB3-489D-AFFC-F9C87DB5C08F" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: Date: Fri, 17 May 2013 08:56:43 +0800 Message-Id: <8EE8800A-F059-4B63-A579-0A2429873AC9@cnnic.cn> References: <00d801ce46f9$b5158310$1f408930$@cn> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" , shenshuo Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 May 2013 00:56:56 -0000 --Apple-Mail=_42EC799F-1BB3-489D-AFFC-F9C87DB5C08F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > This document has four authors. Are they all satisfied with an August = milestone? I think the milestone of draft-ietf-weirds-object-inventory should be = earlier than the one of draft-ietf-weirds-json-response. So either = August or July is fine. Cheers, Ning= --Apple-Mail=_42EC799F-1BB3-489D-AFFC-F9C87DB5C08F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

This = document has four authors.  Are they all satisfied with an August = milestone?

I think the milestone = of draft-ietf-weirds-object-inventory should be earlier than the = one of draft-ietf-weirds-json-response. So either August or July is = fine.

Cheers,
Ning
= --Apple-Mail=_42EC799F-1BB3-489D-AFFC-F9C87DB5C08F-- From shollenbeck@verisign.com Fri May 17 04:39:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775D421F93F1 for ; Fri, 17 May 2013 04:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwMMN9Ar9bAu for ; Fri, 17 May 2013 04:39:39 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82D21F8E84 for ; Fri, 17 May 2013 04:39:10 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUZYW2VHx5sC+6sjfkcYNiBbQiNJAeE2M@postini.com; Fri, 17 May 2013 04:39:39 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4HBd2WU009714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 07:39:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 17 May 2013 07:39:02 -0400 From: "Hollenbeck, Scott" To: Francisco Arias , "weirds@ietf.org" Thread-Topic: gtld-tech mailing list Thread-Index: Ac5SjXDOEvF6HHGDRSKXQPz3UL6jOAAZN4AA Date: Fri, 17 May 2013 11:39:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24387A56@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] gtld-tech mailing list X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 May 2013 11:39:43 -0000 There was a list created at NLnetLabs some time ago for what appears to be = a very similar purpose: http://www.cafax.se/ietf-provreg/maillist/2010-03/msg00014.html http://nlnetlabs.nl/mailman/listinfo/regops Nothing has been posted to the list since July 2012, but do we really need = two lists? Scott > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Francisco Arias > Sent: Thursday, May 16, 2013 7:31 PM > To: weirds@ietf.org > Subject: [weirds] gtld-tech mailing list >=20 > Colleagues, >=20 > This is to let you know that we are launching a public, open mailing > list > for technical discussions regarding gTLD registries and registrars. The > intention is to provide a forum for discussion of issues that may > appear > during ongoing operation and particularly with the upcoming launch of > new > gTLDs. >=20 > You can subscribe to the list at: >=20 > https://mm.icann.org/mailman/listinfo/gtld-tech >=20 > Regards, >=20 > -- > Francisco Arias > ICANN technical staff >=20 >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From olaf@NLnetLabs.nl Mon May 20 06:26:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F9321F9058 for ; Mon, 20 May 2013 06:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoNuTXHC5DOe for ; Mon, 20 May 2013 06:26:03 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB0D21F9048 for ; Mon, 20 May 2013 06:26:03 -0700 (PDT) Received: from [IPv6:2001:980:2282:1:d9b8:de05:1518:f04a] ([IPv6:2001:980:2282:1:d9b8:de05:1518:f04a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r4KDPxdd064207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 15:26:01 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.2 open.nlnetlabs.nl r4KDPxdd064207 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1369056361; bh=cwP6nnvgloc0rFYVggAZ5VFFHqKlRake4FqC2kyXZTc=; h=From:Subject:Date:Cc:To; b=tRbmHgnRKQoO4K+F/Tq7/AyhrmOwaE/vPY90EUT9iYuAw4CN84vdglZ6gWtlja2OQ QSYiaaedfbubtkuLoYj2wfyWwGp4IKo0UBTXNUGEpsjgGqW8oWSqUjyr5Z56WhdOhs ePphIGnJBACZlm9kSdXOMXvj1ZGrCQTt1ACECoPg= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_9C74AC12-1120-43D4-A02C-F0296EC34646"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 20 May 2013 15:25:59 +0200 Message-Id: <7C828A77-734E-4D12-BE16-B46CCB1D1AE8@NLnetLabs.nl> To: "weirds@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 20 May 2013 15:26:01 +0200 (CEST) Cc: Pete Resnick Subject: [weirds] Publication Requested for: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 13:26:04 -0000 --Apple-Mail=_9C74AC12-1120-43D4-A02C-F0296EC34646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folk, draft-ietf-weirds-using-http-05.txt is out of the door. During the shepherd write-up RFC 6839 was reported as a down-ref. I = decided not to block but submit the document. However, it would be good = to have an answer on why that document needs to be normative so that it = can be offered to the AD before he needs to ask.=20 Anyway, milestone made. --Olaf PS: Run idnits early and often ;-)= --Apple-Mail=_9C74AC12-1120-43D4-A02C-F0296EC34646 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQIcBAEBAgAGBQJRmiRnAAoJEFRqER47aqpkNcgQALgqOe4e4v0XYvF2PmwytC7L YMbw82t0EdW0hGR6avG3CG+Ct3I9P5tPnjEwKTe5xpgBLJmkz4Iaajd9gCKW5NVS oHp96YfYofoGuPDdPOQf/SRJ5S+0i/aWmLbpLVhoccS8BW7cq/vJDUPkNLFfMCIp T+ERmgux8/BSHypCBZP/Aa4NaiRl5Fgqkxry+WPG2ErlKnlbeDzf4zNK06bKBDku eK4u4H/pSov9nPjGQFdMIpAZkD6p4X4sGeBtmRDHkfsts2y27C3B98IDZZdPPuIt fVhY0s1VMrJDGnY3tLfuKrOBZwCkHE7tawBkOtlCC8K9b/FNR6NOCj3SY0nqALwZ fdGaAR8Ut0JQArB5upEwU19N4WDShzoXLtMfxtrbH7fWcdYpF5caUbUJCLTkYxvF QsQXmz874QrsRN9SL0dV9PhjTKxQ5Zp4931oq+4RprGpMj7aoBxhl6J62PzOTdwg 0/PT9C+7fw1omydMMus4ym0xA+itt8adyxKt1MzsbinVbCP/2ii6iNbe9qX5I7+v Cpb0Zh7Mc/ukkDrHIVmXeeZPvx7a9+2gLYK+LGOS+7nCK+00o1liTUCf16Vjx3F1 kPFxdy3bxeeN4/6aCasq4r8omx9MeOFiSN/yMhps/gcInJSXEYMx3S+KGA8mQeT7 7lbYoMJTLO5OWnRmfwA3 =/c+I -----END PGP SIGNATURE----- --Apple-Mail=_9C74AC12-1120-43D4-A02C-F0296EC34646-- From andy@arin.net Mon May 20 07:49: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 F181D21F9301 for ; Mon, 20 May 2013 07:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4aQPIwgkLtw for ; Mon, 20 May 2013 07:49:16 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5021F92BB for ; Mon, 20 May 2013 07:49:15 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id E2F48213691; Mon, 20 May 2013 10:49:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id A55922135CF for ; Mon, 20 May 2013 10:49:14 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 20 May 2013 10:49:09 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 20 May 2013 10:49:14 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: redundant description in IP networks Thread-Index: AQHOVWkxjDAjIvNLVEiecNTiyVdqug== Date: Mon, 20 May 2013 14:49:13 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC07860@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <68CE4AEF59003D449D89659D212A9A08@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] redundant description in IP networks X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 May 2013 14:49:21 -0000 All, Now that we have a more structured remarks structure used by all the object classes, I think the "description" array of strings in the IP network object class (Section 6.4) is redundant. Unless there are objections, I'd like to remove it. -andy From presnick@qti.qualcomm.com Mon May 20 13:56: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 7027621F965B for ; Mon, 20 May 2013 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LitkqxNjYafK for ; Mon, 20 May 2013 13:56:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA8321F8F41 for ; Mon, 20 May 2013 13:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369083360; x=1400619360; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pxmdlSiiT5bCLtfzCiQea8EKhwGmicrfPs/pKaYr4Wc=; b=YD81EjbVF4tkZEqek1f7uFonJmGg2fE6Vltiv1lVfk8BMPkO7c5ZvmCR xs0SQpYDcKmWDFVX7hsA6ig96besXmGGpjxVzDe5E3iQsGvHP3/DPTmnK /q75kU8UG7fc2asybsoEUh+Vau9u746TpOsdnVT5Y7DphS1h+V+l884qq M=; X-IronPort-AV: E=Sophos;i="4.87,709,1363158000"; d="scan'208";a="48956471" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 20 May 2013 13:55:59 -0700 X-IronPort-AV: E=Sophos;i="4.87,709,1363158000"; d="scan'208";a="477060921" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 May 2013 13:55:58 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 20 May 2013 13:55:58 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 20 May 2013 13:55:58 -0700 Message-ID: <519A8DDC.4070502@qti.qualcomm.com> Date: Mon, 20 May 2013 15:55:56 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "weirds@ietf.org" Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 May 2013 20:56:04 -0000 On 4/29/13 10:09 PM, Murray S. Kucherawy wrote: > Now that we have adopted the above draft as a WG document, we need to > add it to our charter with a projected milestone. Could someone > suggest a month by which we could reasonably commit to being done with it? Folks: Murray forwarded the request for the milestone, but I have a question: Do we really think that this document is going to be of interest to anyone else a year or more from now? My impression is that this is important internal work product for the WG, that it is of great use to the WG in the preparation of the protocol and probably warrants a huge acknowledgment in our documents, but it's not clear to me that it is going to be of any particular interest to the rest of the community as a stable publication. I can imagine needing it for future WEIRDS development, but then it will likely need to be updated by re-running the survey to see the current data. Can someone explain to me why this would be useful as a permanent publication? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From superuser@gmail.com Mon May 20 17:01:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5121F96D3 for ; Mon, 20 May 2013 17:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0XEn9zfHeXR for ; Mon, 20 May 2013 17:01:53 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7793F21F96E7 for ; Mon, 20 May 2013 17:01:53 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ey16so11269wid.17 for ; Mon, 20 May 2013 17:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vDytEm04UwCLF/CECcf6our3/1KwEbSNO7ga6HWTyQg=; b=Qw9XJz5ULGik6BeE4pH3twm4o3LfoVnH4E0gXPe7/jxSbgJf20rIHsZDWoqNjmF110 1dn0gn6CiDDmGo8rTFrsUVncmcq1LuaThUQt3bZT+x6cwPf7Xnqj9ng1wPbOB4LAagGp 9PFP6r06mnUBbAb9ZYxyS47nZ9mTbLDNRzQcZ0ba9PpMTNn7g8KePLzAwzcT7rDnq4Ph 3XJOT6ESCSoA7eZ/EjDvHYtYa74yM/SvkMTIjXc97H5knI9fVfz89Kk/tNt2t7mXQ4Su BJTXTddX+TrcoMZGjCUQkR013qjFW+1fOueaZ6GI3gpBSbrJ3+s2D/JZxzBG2KZlKK/p 03hw== MIME-Version: 1.0 X-Received: by 10.180.72.195 with SMTP id f3mr18484780wiv.32.1369094512637; Mon, 20 May 2013 17:01:52 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 17:01:52 -0700 (PDT) Date: Mon, 20 May 2013 17:01:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7b8c16fc9704dd2f282a Subject: [weirds] Call for IETF 87 (Berlin) agenda items X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 May 2013 00:01:56 -0000 --f46d043c7b8c16fc9704dd2f282a Content-Type: text/plain; charset=ISO-8859-1 Colleagues, Scheduling of working group sessions for IETF 87 is now open. The due date for a meeting request is June 3rd (two weeks). As usual, the questions we have for the group are: 1) Do you think we need to meet? 2) If "yes", do you have specific open issues you'd like to discuss? These can be open document issues, presentations relevant to document development, procedural discussions, etc. 3) Are there any specific presentations we should seek out? -MSK, WEIRDS co-chair --f46d043c7b8c16fc9704dd2f282a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

Scheduling of working = group sessions for IETF 87 is now open.=A0 The due date for a meeting reque= st is June 3rd (two weeks).=A0 As usual, the questions we have for the grou= p are:

1) Do you think we need to meet?

2) If &qu= ot;yes", do you have specific open issues you'd like to discuss?= =A0 These can be open document issues, presentations relevant to document d= evelopment, procedural discussions, etc.

3) Are there any specific presentations we should seek out?<= br>

-MSK, WEIRDS co-chair
=
--f46d043c7b8c16fc9704dd2f282a-- From superuser@gmail.com Tue May 21 10:52: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 D1D1321F9917 for ; Tue, 21 May 2013 10:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YiyKKMFgDR9 for ; Tue, 21 May 2013 10:52:35 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9D21F9914 for ; Tue, 21 May 2013 10:52:34 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so479125wgh.30 for ; Tue, 21 May 2013 10:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MkGWQ7sD6VOK6lgl7WlOx4HgK6bO0OWaxnDQoJAngYg=; b=vN6T1UGViF8Uuimwra4k30Kz/EuLOX6gTVoRwp8tu6BnqFCzvIE8RRigI1Sdyr1i0f SJdvMCt+8+luScNVsA9tNNGza0qQGXAI6J0mEPea8rnHBcescdqnL/13brOOgC6JR4ek HQXT3J/jCX+U71YAVFrDRwpIS93gTUdH02Y7IZ6mk1qvUEsrm3K88gRrZTj0iu+5oLgE 6HyoYkKacY30e8lwyH6rkidMl9TIlZfyat1jDjMS/z2wYPz8jX4CZapYQYugUdJ05bCW gnTaY3idZQvmFj6StrwA7mQNqtGvc0i01CwOncFsgzx8Pp4acwRZbcF9f12ZbXTEoVE/ d72g== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr7113051wij.20.1369158753636; Tue, 21 May 2013 10:52:33 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 21 May 2013 10:52:33 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43@CHAXCH01.corp.arin.net> Date: Tue, 21 May 2013 10:52:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=e89a8f50335a26d88c04dd3e1d24 Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 May 2013 17:52:36 -0000 --e89a8f50335a26d88c04dd3e1d24 Content-Type: text/plain; charset=ISO-8859-1 Hey all, Where did we land with this "help" link relation suggestion? There seemed to be general support for the idea, but Andy requested proposed text and I don't see that he got any. -MSK On Mon, Apr 15, 2013 at 10:39 AM, Andy Newton wrote: > From: Ernie Dainow > Date: Monday, April 15, 2013 11:11 AM > To: Andrew Newton > Cc: "weirds@ietf.org" > Subject: Re: [weirds] help > > There are several cases where the user may not get a JSON response and > so does not receive the notices array or anything else. For example, after > HTTP Unauthorized or Not Found. A standard way to get help independently of > looking for a link somewhere in a JSON response makes things a lot easier. > > > No matter the response code, it is always possible to return an HTTP > body. And the errorCode object (Section 7) can have a links array, though I > guess that should be given in an example or made more explicit. > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --e89a8f50335a26d88c04dd3e1d24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey all,

Where did we land with this "help&quo= t; link relation suggestion?=A0 There seemed to be general support for the = idea, but Andy requested proposed text and I don't see that he got any.=

-MSK


On Mon, Apr 15, 2013 at 10:39 AM, Andy Newton <andy@arin.net> wrote:
From: Ernie Dainow <edainow@afilias.info><= br> Date: Monday, April 15, 2013 11:11 = AM
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] help

There are several cases where the user may not get a JSON response and= so does not receive the notices array or anything else. For example, after= HTTP=A0Unauthorized or=A0Not Found. A standard way to get help independent= ly of looking for a link somewhere in a JSON response makes things a lot easier.

No matter the response code, it is always possible to return an HTTP b= ody. And the errorCode object (Section 7) can have a links array, though I = guess that should be given in an example or made more explicit.

-andy

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


--e89a8f50335a26d88c04dd3e1d24-- From superuser@gmail.com Tue May 21 10:53: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 BBFFF21F9936 for ; Tue, 21 May 2013 10:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRic-OhV04FC for ; Tue, 21 May 2013 10:53:34 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C421F9932 for ; Tue, 21 May 2013 10:53:30 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so3072119wib.8 for ; Tue, 21 May 2013 10:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gz2YbfdoLi5xvsCob3m7A9XzWz8ByV2Cd54NKe8lee8=; b=EASc+C3WHyWjtPu2l6EZDPPPs+MSJ1ix66u1le3h4/Z4YZwV9DsH0K8Tt7PvXbcON9 7TPAR2RjLO9un8PfWMa/l7yFtpgOH654gvi2M+fsR65OntIhoIMXmJNWsm/TBiF9fTMr iVYdYD9zsRhaECxOzyumixOxUsyQ6JjslPZlxyaWg7Qq81Q5kUSOdn6DGW8X4cqSmLzG CuRPajZvMHdqkvtP/8ax0roNaSIFPchwEhAQCw3GQqZUSmgINFgQWCZHtqSH8lCTB21F ctUDWjdRKc3dDpYvcLJLxpDSbszQIObIh4r+6krBB28eAlvyGTMwtxuts5I2qlWFz+EM qb8w== MIME-Version: 1.0 X-Received: by 10.180.72.227 with SMTP id g3mr25896997wiv.1.1369158806643; Tue, 21 May 2013 10:53:26 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 21 May 2013 10:53:26 -0700 (PDT) Date: Tue, 21 May 2013 10:53:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c81924fabc504dd3e2089 Subject: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 May 2013 17:53:44 -0000 --f46d043c81924fabc504dd3e2089 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, Next up on our milestones list is the rdap-query draft, which is due to the IESG next month. I believe what's posted is current with our most recent discussions, but I'd like to get some more reviews and commentary on the record, especially from implementers. We also don't appear to have any kind of consensus about search. There are two documents proposed, but also some claims (one based on a registrar survey) that we don't really need it for a first version of WEIRDS. My thinking is that if there are going to be search capabilities in the query protocol, they would at least need to be referenced from this document. -MSK --f46d043c81924fabc504dd3e2089 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

Next up on our milestones lis= t is the rdap-query draft, which is due to the IESG next month.=A0 I believ= e what's posted is current with our most recent discussions, but I'= d like to get some more reviews and commentary on the record, especially fr= om implementers.

We also don't appear to have any kind of consensus about sear= ch.=A0 There are two documents proposed, but also some claims (one based on= a registrar survey) that we don't really need it for a first version o= f WEIRDS.=A0 My thinking is that if there are going to be search capabiliti= es in the query protocol, they would at least need to be referenced from th= is document.

-MSK
--f46d043c81924fabc504dd3e2089-- From shollenbeck@verisign.com Tue May 21 11:03:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957B21F97BC for ; Tue, 21 May 2013 11:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPHSIajyzHOP for ; Tue, 21 May 2013 11:03:05 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8415B21F97C2 for ; Tue, 21 May 2013 11:03:03 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUZu21wvKo2L4YGMphVZ+P68QzWkq7/jZ@postini.com; Tue, 21 May 2013 11:03:04 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4LI2sfi003203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:02:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 21 May 2013 14:02:54 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] rdap-query draft Thread-Index: AQHOVkxFOfiTk6KZ/U2YoRJ1GU0TLJkP7RTA Date: Tue, 21 May 2013 18:02:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243899E3@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_831693C2CDA2E849A7D7A712B24E257F243899E3BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 May 2013 18:03:11 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243899E3BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Murray, I read John Levine's search inventory message a little differently.= He noted that a small number of registry operators (who happen to be admin= ister multiple large TLDs) provide very limited search functionality. That = tends to support my suggestion to document basic search functions in a "cor= e" search document and defer the more complicated functions to a second doc= ument. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, May 21, 2013 1:53 PM To: weirds@ietf.org Subject: [weirds] rdap-query draft Colleagues, Next up on our milestones list is the rdap-query draft, which is due to the= IESG next month. I believe what's posted is current with our most recent = discussions, but I'd like to get some more reviews and commentary on the re= cord, especially from implementers. We also don't appear to have any kind of consensus about search. There are= two documents proposed, but also some claims (one based on a registrar sur= vey) that we don't really need it for a first version of WEIRDS. My thinki= ng is that if there are going to be search capabilities in the query protoc= ol, they would at least need to be referenced from this document. -MSK --_000_831693C2CDA2E849A7D7A712B24E257F243899E3BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Murray, I read John Levine’s search = inventory message a little differently. He noted that a small number of reg= istry operators (who happen to be administer multiple large TLDs) provide very limited search functionality. That tends to support my sugges= tion to document basic search functions in a “core” search docu= ment and defer the more complicated functions to a second document.

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 21, 2013 1:53 PM
To: weirds@ietf.org
Subject: [weirds] rdap-query draft

 

Colleagues,

Next up on our milestones list is the rdap-query draft, which is due to the= IESG next month.  I believe what's posted is current with our most re= cent discussions, but I'd like to get some more reviews and commentary on t= he record, especially from implementers.

We also don't appear = to have any kind of consensus about search.  There are two documents p= roposed, but also some claims (one based on a registrar survey) that we don= 't really need it for a first version of WEIRDS.  My thinking is that if there are going to be search capabili= ties in the query protocol, they would at least need to be referenced from = this document.

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F243899E3BRN1WNEXMBX01vc_-- From superuser@gmail.com Tue May 21 11:09: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 8724F21F925A for ; Tue, 21 May 2013 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc3TWg6MQPbb for ; Tue, 21 May 2013 11:09:41 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1921F91B8 for ; Tue, 21 May 2013 11:09:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so523079wgg.4 for ; Tue, 21 May 2013 11:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dV9Bj1xAeYK3VhZlaTqsj82NQkhXATbGBtqpnifJmKU=; b=MXJbvizX7SRNOl/LsBlracMFZC+M/P2zm3LNYcRffZi2t7bDhy0wPf7kFL9Dge/PG9 hRKwzojWSmS5YNXMjJ+BrBwp0P2b/m4U9ovZyesEyIRGIIFieetxGjdKCG3ACHisN+Bv ZyYuDYq56cl9ApbNkDDdGyBDJnI/uqHbC55pxiWhrT70QmYtp4xipA2xY9wXoEMOenlc cPcaXnI5fZ55Q5GUcV3iEgdWcRR9pjFJCle/3+G1OuEsrjQeD/tjQ5qsjV0ri7N2Mqq8 53nHsWSbubLldz2V869dfeboer8JI3kSQe5TAy9wXp6Dno4mnOKooNCnNCbQnAmHLR5i EPcg== MIME-Version: 1.0 X-Received: by 10.180.72.195 with SMTP id f3mr25868884wiv.32.1369159780195; Tue, 21 May 2013 11:09:40 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 21 May 2013 11:09:40 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243899E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243899E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 21 May 2013 11:09:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=f46d043c7b8c56ebb704dd3e5a7a Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 May 2013 18:09:43 -0000 --f46d043c7b8c56ebb704dd3e5a7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, May 21, 2013 at 11:02 AM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > Murray, I read John Levine=92s search inventory message a little > differently. He noted that a small number of registry operators (who happ= en > to be administer multiple large TLDs) provide very limited search > functionality. That tends to support my suggestion to document basic sear= ch > functions in a =93core=94 search document and defer the more complicated > functions to a second document.**** > > ** > Hi Scott, I'm fine with any interpretation that achieves consensus. This thread is my way of starting to figure out where that might fall. An admittedly cursory review of the rdap-query document suggests that the search features described there don't exactly match the ones found in the survey. Do you think implementers would rather move toward what you've described in rdap-query, or should rdap-query move in the direction of what the survey found? Also, I believe Section 3 of the draft is begging for an ABNF description of the syntax, but that's secondary to the main question above. -MSK --f46d043c7b8c56ebb704dd3e5a7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, May 21, 2013 at 11:02 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

Murray, I read John Levine=92s search inve= ntory message a little differently. He noted that a small number of registr= y operators (who happen to be administer multiple large TLDs) provide very limited search functionality. That tends to support my sugges= tion to document basic search functions in a =93core=94 search document and= defer the more complicated functions to a second document.



Hi Scott,

I'm fine with any interpretat= ion that achieves consensus.=A0 This thread is my way of starting to figure= out where that might fall.

An admittedly cursory review of the rdap-query document sugg= ests that the search features described there don't exactly match the o= nes found in the survey.=A0 Do you think implementers would rather move tow= ard what you've described in rdap-query, or should rdap-query move in t= he direction of what the survey found?

Also, I believe Section 3 of the draft is begging for an ABN= F description of the syntax, but that's secondary to the main question = above.

-MSK
--f46d043c7b8c56ebb704dd3e5a7a-- From zhoulinlin@cnnic.cn Tue May 21 17:47: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 8F6D521F92C5 for ; Tue, 21 May 2013 17:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFEI-qxd0R8G for ; Tue, 21 May 2013 17:47:53 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 1AEC321F905F for ; Tue, 21 May 2013 17:47:52 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 22 May 2013 08:47:45 +0800 From: "Linlin Zhou" To: "'Pete Resnick'" , "'Murray S. Kucherawy'" References: <519A8DDC.4070502@qti.qualcomm.com> In-Reply-To: <519A8DDC.4070502@qti.qualcomm.com> Date: Wed, 22 May 2013 08:47:45 +0800 Message-ID: <01f301ce5685$f9a39710$eceac530$@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: Ac5VnHn5O86WQblISHWZlwfpIGEdsgAT0LLQ Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 00:47:58 -0000 > Folks: > > Murray forwarded the request for the milestone, but I have a question: > > Do we really think that this document is going to be of interest to anyone else a > year or more from now? My impression is that this is important internal work > product for the WG, that it is of great use to the WG in the preparation of the > protocol and probably warrants a huge acknowledgment in our documents, but > it's not clear to me that it is going to be of any particular interest to the rest of > the community as a stable publication. I can imagine needing it for future > WEIRDS development, but then it will likely need to be updated by re-running > the survey to see the current data. > > Can someone explain to me why this would be useful as a permanent > publication? > > pr > Firstly, I think this inventory draft is a useful reference for response draft. It helps make the choices of the objects adopted by the response draft. When we develop RDAP protocols, we use the JSON/XML data format defined in response draft for data transfer. We found that we also need a object name mapping rules for displaying object names in various clients. So I feel that the inventory draft may give us a suggestion on picking the most popular names in the data presentation layer. This is the second reason I think it is useful. The current inventory results reflect some data distribution trends and user preference of the old WHOIS. What I am guessing is that re-running survey will have almost the same results unless adopting a different approach. We have the data, and I think what we can dig more from the data is more important. Regards, Linlin From shollenbeck@verisign.com Wed May 22 04:00: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 BCB3D21F9600 for ; Wed, 22 May 2013 04:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xUOFwyrvoLa for ; Wed, 22 May 2013 04:00:19 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3712B21F93DE for ; Wed, 22 May 2013 04:00:18 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUZylQSIY9MIhZilTtdnbcWcn+jUTe2+T@postini.com; Wed, 22 May 2013 04:00:19 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4MB0EZs018294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 07:00:14 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 22 May 2013 07:00:14 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] rdap-query draft Thread-Index: AQHOVk5ebKo16+S5YUeCvhqkV2m+opkRCZBw Date: Wed, 22 May 2013 11:00:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24389CCF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243899E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F24389CCFBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 11:00:25 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24389CCFBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Do you think implementers would rather move toward what you've described = in rdap-query, or should rdap-query move in the direction of what the surve= y found? rdap-search should move in the direction of what the survey found. Scott From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Tuesday, May 21, 2013 2:10 PM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: Re: [weirds] rdap-query draft On Tue, May 21, 2013 at 11:02 AM, Hollenbeck, Scott > wrote: Murray, I read John Levine's search inventory message a little differently.= He noted that a small number of registry operators (who happen to be admin= ister multiple large TLDs) provide very limited search functionality. That = tends to support my suggestion to document basic search functions in a "cor= e" search document and defer the more complicated functions to a second doc= ument. Hi Scott, I'm fine with any interpretation that achieves consensus. This thread is m= y way of starting to figure out where that might fall. An admittedly cursory review of the rdap-query document suggests that the s= earch features described there don't exactly match the ones found in the su= rvey. Do you think implementers would rather move toward what you've descr= ibed in rdap-query, or should rdap-query move in the direction of what the = survey found? Also, I believe Section 3 of the draft is begging for an ABNF description o= f the syntax, but that's secondary to the main question above. -MSK --_000_831693C2CDA2E849A7D7A712B24E257F24389CCFBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Do you think implementers would rather move toward what you've descr= ibed in rdap-query, or should rdap-query move in the direction of what the = survey found?

 

rdap-search should move in the direction o= f what the survey found.

 

Scott

 

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Tuesday, May 21, 2013 2:10 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] rdap-query draft

 

On Tue, May 21, 2013 at 11:02 AM, Hollenbeck, Scott = <shollenbe= ck@verisign.com> wrote:

Murray, I read John Levine’s search inventory mess= age a little differently. He noted that a small number of registry operators (who happen to be administer multiple large TLDs) provide very l= imited search functionality. That tends to support my suggestion to documen= t basic search functions in a “core” search document and defer = the more complicated functions to a second document.

 

 

Hi Scott,

I'm fine with any interpretation that achieves consensus.  This thread= is my way of starting to figure out where that might fall.

An admittedly cursory= review of the rdap-query document suggests that the search features descri= bed there don't exactly match the ones found in the survey.  Do you th= ink implementers would rather move toward what you've described in rdap-query, or should rdap-query move in the dire= ction of what the survey found?

Also, I believe Section 3 of the draft is begging fo= r an ABNF description of the syntax, but that's secondary to the main quest= ion above.

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F24389CCFBRN1WNEXMBX01vc_-- From johnl@iecc.com Wed May 22 07:33: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 C869021F920E for ; Wed, 22 May 2013 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.034 X-Spam-Level: X-Spam-Status: No, score=-111.034 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCZqrRsNDrLz for ; Wed, 22 May 2013 07:33:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 580DB21F9092 for ; Wed, 22 May 2013 07:33:28 -0700 (PDT) Received: (qmail 35227 invoked from network); 22 May 2013 14:33:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 May 2013 14:33:27 -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; s=519cd737.xn--yuvv84g.k1305; i=johnl@user.iecc.com; bh=rr+gyBr8VaY5nGKcnRyHTpyzgBVFVx0UKAm57o2cwRs=; b=QPAWrlHzNseOfSDvQ7ij0/1OQv+Y2t2cxHbpqIs/5FwRHZ4RENH2d0G13GNiql/DNBT+UyU1ZeUByRIIo1A2yuHvxG1G1B7+vWsXu/KpqByTt3eC/iZsQRUiOfJx2iERqcH8yJ/qk/xVYpLZTUA7MhxKaoqz7xq+PqgJJrsU7YQ= 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; s=519cd737.xn--yuvv84g.k1305; olt=johnl@user.iecc.com; bh=rr+gyBr8VaY5nGKcnRyHTpyzgBVFVx0UKAm57o2cwRs=; b=pCYFQ3hWO1KDWDJsBhCTFQxx0+Y4kpLOkeBxYRhSWebv4W03nRRWMrOx9xavFn82Ykd11Q6yescr7IWTzOaCjBECAKY78RYffzOWeXmj6p/9nrz9F6/gzvzfS37tjgbqee250GnkHurqR1e6AfYLhU7DMk5W5Vrw90WW1vJqgqM= Date: 22 May 2013 14:33:04 -0000 Message-ID: <20130522143304.12961.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24389CCF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 14:33:33 -0000 >rdap-search should move in the direction of what the survey found. We found that the usual gTLD suspects provide a simple prefix matching search on various fields, including domain names. The only ccTLDs that provide any search I could find were ones that happened to use one of the gTLD back ends. I didn't see any more complex search, which isn't surprising since prefix matching is easy to implement using typical database backends, and anything else is vastly harder and/or slower. While I wouldn't be opposed on principle to fancy searching with regular expressions or the like, I doubt anyone would ever provide it other than at toy scale. So my suggestion would be to spec a prefix match on the any of the fields that TLDs currently allow to search, and return values of here's all the matches, here's some of the matches but you exceeded a match limit, nothing matched, and we don't have search on that field. I don't see much use for a query about what searches are allowed; just try it and see if it works. From hsalgado@nic.cl Wed May 22 07:44: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 B61E821F867B for ; Wed, 22 May 2013 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2SlCqfxsV5m for ; Wed, 22 May 2013 07:44:52 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) by ietfa.amsl.com (Postfix) with ESMTP id E08A321F856D for ; Wed, 22 May 2013 07:44:49 -0700 (PDT) Received: from mail.nic.cl (localhost.localdomain [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id A4498CC8138 for ; Wed, 22 May 2013 10:44:48 -0400 (CLT) Received: from vulcano.intra.nic.cl (unknown [IPv6:2001:1398:4:1:225:64ff:fee6:2946]) by mail.nic.cl (Postfix) with ESMTP id 96E28CC8137 for ; Wed, 22 May 2013 10:44:48 -0400 (CLT) Message-ID: <519CD9E0.3040103@nic.cl> Date: Wed, 22 May 2013 10:44:48 -0400 From: Hugo Salgado User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <20130522143304.12961.qmail@joyce.lan> In-Reply-To: <20130522143304.12961.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 OpenPGP: id=B525FA6E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on Wed May 22 10:44:48 2013 -0400 (CLT) Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 14:44:52 -0000 On 05/22/2013 10:33 AM, John Levine wrote: >> rdap-search should move in the direction of what the survey found. > > We found that the usual gTLD suspects provide a simple prefix matching > search on various fields, including domain names. The only ccTLDs > that provide any search I could find were ones that happened to use > one of the gTLD back ends. > > I didn't see any more complex search, which isn't surprising since > prefix matching is easy to implement using typical database backends, > and anything else is vastly harder and/or slower. While I wouldn't be > opposed on principle to fancy searching with regular expressions or > the like, I doubt anyone would ever provide it other than at toy > scale. > Hi John. We at .CL provide search capabilities in prefix, suffix, and middle of domain names. These capabilities are only in the web interface. The whois/43 has only exact match. We're aware that this capability is not popular outside .CL, but is a feature we officially support and will be maintained in a future restful web interface. Regards, Hugo From edainow@afilias.info Wed May 22 09:01: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 C847921F9060 for ; Wed, 22 May 2013 09:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vWSBJn2IYmE for ; Wed, 22 May 2013 09:01:08 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id BC84B21F8A54 for ; Wed, 22 May 2013 09:00:49 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UfBT6-0007O7-4T for weirds@ietf.org; Wed, 22 May 2013 16:00:48 +0000 Received: from mail-la0-f46.google.com ([209.85.215.46]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UfBT6-0004TK-3G for weirds@ietf.org; Wed, 22 May 2013 16:00:48 +0000 Received: by mail-la0-f46.google.com with SMTP id er20so2174044lab.19 for ; Wed, 22 May 2013 09:00:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tYS3Rvgj6u4QcWM6o7KlOcgJ/YpFSD9uCkwoi0UJzZA=; b=LjYQ0Mhert30dQXODknW30nxccKBq98ZJmyzx8a89RnqnduZGrNa0lzPEfJ0Qec43e SkIVTqXHSpL1QOksZrV3SDG+G1ovbe2R5ZT4acPDmo0wWoo5CR+xySVuHBUoKDfALXX5 CRLYx062Uy4D/jF2zyotIbY7yZquxBmwwB8BnH0dh987HL0d+9to6psCeQNw7RchZIFI 64fRJeqduIBrpLulnYD69W5cqjdNZ3kc5WOJ2MoY6IfamnALrxJlz8b2sZuXlZS8ekmh lWi1bifIPlJBdT+cdU4NPX1RRnd8us3fdL7FuCTrKpfI8Q7prjFvKA0gTnQJNHZYwxou cIBA== X-Received: by 10.112.169.37 with SMTP id ab5mr4390584lbc.25.1369238441695; Wed, 22 May 2013 09:00:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.169.37 with SMTP id ab5mr4390580lbc.25.1369238441577; Wed, 22 May 2013 09:00:41 -0700 (PDT) Received: by 10.112.156.225 with HTTP; Wed, 22 May 2013 09:00:41 -0700 (PDT) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43@CHAXCH01.corp.arin.net> Date: Wed, 22 May 2013 12:00:41 -0400 Message-ID: From: Ernie Dainow To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c34b4aec5e4504dd50aaad X-Gm-Message-State: ALoCoQles6s23DDFKTE6nU9cNrAvrX8MdcrhW+LY9XAbHekbgE9Jp6J6Z50NVQDV40cngshF0rt5fecAES7aV4eZDmxhQGbEydVtiJsKiJnPNkSmBVkxbJcMJiHkhur1iSVOhEJOVayG Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 16:01:13 -0000 --001a11c34b4aec5e4504dd50aaad Content-Type: text/plain; charset=ISO-8859-1 My comment on April 12 was intended to provide some basic text. Perhaps that got missed in the follow-up discussion about whether a standard url to a help page should be standardized or whether it was sufficient to embed help/about links in RDAP objects. -Ernie On Tue, May 21, 2013 at 1:52 PM, Murray S. Kucherawy wrote: > Hey all, > > Where did we land with this "help" link relation suggestion? There seemed > to be general support for the idea, but Andy requested proposed text and I > don't see that he got any. > > -MSK > > > On Mon, Apr 15, 2013 at 10:39 AM, Andy Newton wrote: > >> From: Ernie Dainow >> Date: Monday, April 15, 2013 11:11 AM >> To: Andrew Newton >> Cc: "weirds@ietf.org" >> Subject: Re: [weirds] help >> >> There are several cases where the user may not get a JSON response and >> so does not receive the notices array or anything else. For example, after >> HTTP Unauthorized or Not Found. A standard way to get help independently of >> looking for a link somewhere in a JSON response makes things a lot easier. >> >> >> No matter the response code, it is always possible to return an HTTP >> body. And the errorCode object (Section 7) can have a links array, though I >> guess that should be given in an example or made more explicit. >> >> -andy >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> >> > --001a11c34b4aec5e4504dd50aaad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My comment on April 12 was intended to provide some basic = text. Perhaps that got missed in the follow-up discussion about whether a s= tandard url to a help page should be standardized or whether it was suffici= ent to embed help/about links in RDAP objects.

-Ernie



On Tue, May 21, 2013 at= 1:52 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:=
Hey all,

Where did w= e land with this "help" link relation suggestion?=A0 There seemed= to be general support for the idea, but Andy requested proposed text and I= don't see that he got any.

-MSK


On Mon, Apr 15, 2013 at 10:39 AM,= Andy Newton <andy@arin.net> wrote:
From: Ernie Dainow <edainow@afilias.info><= br> Date: Monday, April 15, 2013 11:11 = AM
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] help

There are several cases where the user may not get a JSON response and= so does not receive the notices array or anything else. For example, after= HTTP=A0Unauthorized or=A0Not Found. A standard way to get help independent= ly of looking for a link somewhere in a JSON response makes things a lot easier.

No matter the response code, it is always possible to return an HTTP b= ody. And the errorCode object (Section 7) can have a links array, though I = guess that should be given in an example or made more explicit.
=

-andy

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



--001a11c34b4aec5e4504dd50aaad-- From superuser@gmail.com Wed May 22 09:09:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0621F9671 for ; Wed, 22 May 2013 09:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhv8izMoNR1g for ; Wed, 22 May 2013 09:09:19 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 71EC921F96AA for ; Wed, 22 May 2013 09:09:19 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so1339622wes.18 for ; Wed, 22 May 2013 09:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T232YZhbCLme7kOoPLwIFP7zfL++1hEDN4nC1mJprbQ=; b=MVr4iJEiUl/gMrWvEy5dJcxuoORrE7wpsJp6DJy6zWPMTmfAMjFMD/3+FJjIkvHO4v C4oFVCDmYMm5yfdYcpBG0O4N9FpafGxUw+XcgEhCbBXC1FISINQoQdFsoL8Wi8brfSq8 XMqzU2x/aKdO52nNTWgeh2ZjMIYcpl1ZqPuxUhPCL0WBzbW+M0EEgntGqSsgD1uUcq31 V2IDWAXwOWw9O4t5s8LCq9C4bf3ZWcz6WfmCHzApIUtIAVsUKO9DojsysOP+C9UZ4gzy QYaTE2VGV6yExnN82M6Klm65ZvQ3g9s5tYiG67tGQhE3sLytrErm9pwKqrmKz1vyT+x+ LUcg== MIME-Version: 1.0 X-Received: by 10.180.37.109 with SMTP id x13mr34544569wij.20.1369238958414; Wed, 22 May 2013 09:09:18 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Wed, 22 May 2013 09:09:18 -0700 (PDT) In-Reply-To: <20130522143304.12961.qmail@joyce.lan> References: <831693C2CDA2E849A7D7A712B24E257F24389CCF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130522143304.12961.qmail@joyce.lan> Date: Wed, 22 May 2013 09:09:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=e89a8f6473f5baa3ae04dd50c967 Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 16:09:22 -0000 --e89a8f6473f5baa3ae04dd50c967 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 7:33 AM, John Levine wrote: > >rdap-search should move in the direction of what the survey found. > > We found that the usual gTLD suspects provide a simple prefix matching > search on various fields, including domain names. The only ccTLDs > that provide any search I could find were ones that happened to use > one of the gTLD back ends. > Just to be clear, by "prefix matching", you mean something like a search for "foo*"? (In my head, the "matching" happens when the wildcard is resolved, so you might mean "*foo".) -MSK --e89a8f6473f5baa3ae04dd50c967 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 7:33 AM, John Levine <johnl@taugh.c= om> wrote:
>rdap-search should move in the direction of what the = survey found.

We found that the usual gTLD suspects provide a simple prefix matchin= g
search on various fields, including domain names. =A0The only ccTLDs
that provide any search I could find were ones that happened to use
one of the gTLD back ends.

Just to be c= lear, by "prefix matching", you mean something like a search for = "foo*"?

(In my head, the "matching" h= appens when the wildcard is resolved, so you might mean "*foo".)<= br>
-MSK

--e89a8f6473f5baa3ae04dd50c967-- From johnl@taugh.com Wed May 22 09:20:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6F21F8F1E for ; Wed, 22 May 2013 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrlOkYxgZ8fh for ; Wed, 22 May 2013 09:20:48 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7FA21F9701 for ; Wed, 22 May 2013 09:20:45 -0700 (PDT) Received: (qmail 59439 invoked from network); 22 May 2013 16:20:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=e82e.519cf05c.k1305; bh=Vg2io9KktRi+EXEBwZfy7uVGSnYZc/e2swNqUbjB7bs=; b=ZBT5v2lkky61cgXRGjnxwlLhp1cJiaBQJQVYJpoSCF8fOqg9juZBUgZwuwG5opWFrgi6P+xH+wivwGjwWcKHIbgKQohKE3alul7v9YpWxTEEKY166qRNrJeAwJtafQ2fS2i5XDQ79r39isYH/bqmZDxJHwNbktAbzwG5LLDi22o= 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:user-agent:cleverness; s=e82e.519cf05c.k1305; bh=Vg2io9KktRi+EXEBwZfy7uVGSnYZc/e2swNqUbjB7bs=; b=fI4iyzVFHFBqgtZ8sGQPXLR2IVl9nZO0gwCFIlYMHaWGkcjX3U5oQnHLRNr58H8Zk416ljz826KtVJ64OfpxXhct9Ix0YQOlW82Ga/WR9DVphaHFRc8UH8v3ywRnx2mwcvET7CYgBivuRRf5KgADmR+r/2S1c/FLGnXAttwW6YA= Received: (ofmipd 127.0.0.1); 22 May 2013 16:20:22 -0000 Date: 22 May 2013 12:20:44 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <831693C2CDA2E849A7D7A712B24E257F24389CCF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130522143304.12961.qmail@joyce.lan> 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-2030569955-1369239644=:12383" Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 May 2013 16:20:51 -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-2030569955-1369239644=:12383 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> We found that the usual gTLD suspects provide a simple prefix matching >> search on various fields, including domain names. The only ccTLDs >> that provide any search I could find were ones that happened to use >> one of the gTLD back ends. >> > > Just to be clear, by "prefix matching", you mean something like a search > for "foo*"? Yes, you give it a string, it finds the items that start with that string. For databases using typical B-tree indices, this is one or two disk fetches, no scanning needed. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-2030569955-1369239644=:12383 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIyMTYyMDQ0WjAjBgkqhkiG 9w0BCQQxFgQUDGJUuTdAbbQiEH0uLErRXJnaSP0weQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAsOjk3cIXpxT6 V3Q6loQ7FIHFJ7/S/z7S6JS0inRfP5vXu2f5nxGkdM3blq7fiE4cYCLhtk6g Fwo0CC2skwNp43lKdpiGvTCedcM74u2VtojHG0T7ZdW8XAy67pq3b0ro0Fl7 zGXf4VdY9hohab6QFERyr6fpLbTaTc1EfijfnMKeglpKEmfLZYZmn2hyK0zq DRWNoV5XI/wKz7AvhV50X01JVDeOP4Uix1EfwOuxew8ugjq/PyM0SD18qpZ6 69FG18aISRt0bWKS+KT4XjYZz5jPJTbcIVni17F3PwfWq62e8NK8YChw7QLW pf3lQ0UErL6jTgdWje9RnCW6xuJLKA== --3825401791-2030569955-1369239644=:12383-- From presnick@qti.qualcomm.com Thu May 23 07:05: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 B988B21F960F for ; Thu, 23 May 2013 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-uq5036DX36 for ; Thu, 23 May 2013 07:05:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7076A21F960D for ; Thu, 23 May 2013 07:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369317952; x=1400853952; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rxYn5NxNwT+fuB0D+v38NUmMc3fzQqo94cNQx1SwVKE=; b=Hv7L5XiE3+jYNVc74sajjjvOdn+G65Rq/V+haqsLivRYLWkitYm9R9Rj UadRWQBoYv93dH/pmAHrD19F0eOhMkKk4qEbPUyHJRWGn/bNBt8wbbnx8 EWZhBCTeNzDN+9sq95GOJqY0nzjpbggS8v4H+M4jol9vi8vojz4rWAVRh I=; X-IronPort-AV: E=Sophos;i="4.87,728,1363158000"; d="scan'208";a="50065589" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 23 May 2013 07:05:52 -0700 X-IronPort-AV: E=Sophos;i="4.87,728,1363158000"; d="scan'208";a="452623076" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 May 2013 07:05:51 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 23 May 2013 07:05:51 -0700 Message-ID: <519E223D.8000504@qti.qualcomm.com> Date: Thu, 23 May 2013 09:05:49 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Linlin Zhou References: <519A8DDC.4070502@qti.qualcomm.com> <01f301ce5685$f9a39710$eceac530$@cn> In-Reply-To: <01f301ce5685$f9a39710$eceac530$@cn> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: weirds@ietf.org Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 May 2013 14:05:57 -0000 On 5/21/13 7:47 PM, Linlin Zhou wrote: >> Folks: >> >> Murray forwarded the request for the milestone, but I have a question: >> >> Do we really think that this document is going to be of interest to >> anyone else a year or more from now? My impression is that this is >> important internal work product for the WG, that it is of great use >> to the WG in the preparation of the protocol and probably warrants a >> huge acknowledgment in our documents, but it's not clear to me that >> it is going to be of any particular interest to the rest of the >> community as a stable publication. I can imagine needing it for >> future WEIRDS development, but then it will likely need to be updated >> by re-running the survey to see the current data. >> >> Can someone explain to me why this would be useful as a permanent >> publication? > > Firstly, I think this inventory draft is a useful reference for > response draft. It helps make the choices of the objects adopted by > the response draft. I understood that this was the intention, but I don't see *why* that means that we need to publish the inventory draft. Again, will this be of interest to other people eventually, or be useful for future work. > When we develop RDAP protocols, we use the JSON/XML data format > defined in response draft for data transfer. We found that we also > need a object name mapping rules for displaying object names in > various clients. So I feel that the inventory draft may give us a > suggestion on picking the most popular names in the data presentation > layer. This is the second reason I think it is useful. But again, won't this be folded into the RDAP documents? Is there a need to keep this document separately? > The current inventory results reflect some data distribution trends > and user preference of the old WHOIS. What I am guessing is that > re-running survey will have almost the same results unless adopting a > different approach. We have the data, and I think what we can dig more > from the data is more important. OK. Still, I'd like to understand why this is useful to publish. If others in the WG can explain, that would be helpful. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From andy@arin.net Thu May 23 09:32: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 AEEFD21F974B for ; Thu, 23 May 2013 09:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3brT8F5xyMXg for ; Thu, 23 May 2013 09:31:49 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EB7EE21F971B for ; Thu, 23 May 2013 09:31:10 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 67FBF16530C; Thu, 23 May 2013 12:31:10 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id E6DF11652F6; Thu, 23 May 2013 12:31:09 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 23 May 2013 12:30:47 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.35]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 23 May 2013 12:31:01 -0400 From: Andy Newton To: Pete Resnick , Linlin Zhou Thread-Topic: [weirds] Milestone for draft-ietf-weirds-object-inventory Thread-Index: AQHORVBLg42LHrx7ukSAW1bkZEkmupkO8UYAgAHTGYCAAnFPgP//5YAA Date: Thu, 23 May 2013 16:31:00 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC0936F@CHAXCH01.corp.arin.net> In-Reply-To: <519E223D.8000504@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D44C4FB1ADEA443BB4F127A4E94C9C4@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Milestone for draft-ietf-weirds-object-inventory X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 May 2013 16:32:05 -0000 On 5/23/13 10:05 AM, "Pete Resnick" wrote: >OK. > >Still, I'd like to understand why this is useful to publish. If others >in the WG can explain, that would be helpful. Pete, One of the questions that repeatedly comes up in discussions of the RDAP data model is one of "have you considered X" where X is some data element in a subset of Whois services. It is very helpful to point people to the inventory draft to answer those types of questions. Maybe another way of putting it is that the inventory draft shows the outside world that we did our homework. -andy From andy@arin.net Thu May 23 09:40: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 AB9B621F9246 for ; Thu, 23 May 2013 09:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUT7AgAa4GHy for ; Thu, 23 May 2013 09:39:49 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3F21F96D5 for ; Thu, 23 May 2013 09:38:10 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 968341652EF; Thu, 23 May 2013 12:38:10 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 06C881650E8; Thu, 23 May 2013 12:38:08 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 23 May 2013 12:37:43 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.35]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 23 May 2013 12:38:01 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] rdap-query draft Thread-Index: AQHOVkw7BY/cEVrTi0asdpCOVD4Rr5kS+yqA Date: Thu, 23 May 2013 16:38:00 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09385@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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC09385CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 May 2013 16:40:04 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC09385CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Tuesday, May 21, 2013 1:53 PM To: "weirds@ietf.org" > Subject: [weirds] rdap-query draft We also don't appear to have any kind of consensus about search. There are= two documents proposed, but also some claims (one based on a registrar sur= vey) that we don't really need it for a first version of WEIRDS. My thinki= ng is that if there are going to be search capabilities in the query protoc= ol, they would at least need to be referenced from this document. Murray, Honing in on the last sentence, I do not think that is the case nor is it d= esirable. We have an extensible model and can add other URI paths in the fu= ture for search capabilities. Additionally, since lookups are 99% of Whois = queries, I don't think it is necessary to hold up our current work for what= amounts to a small subset of queries with requirements that are not well u= nderstood. Forgive me if I've misunderstood your point though. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC09385CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <6538C130A4A26E429868CDCCE2B9CA49@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Tuesday, May 21, 2013 1:53 PM=
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] rdap-query draft<= br>

We also don't appear to have any kind of consensus about search.  There = are two documents proposed, but also some claims (one based on a registrar = survey) that we don't really need it for a first version of WEIRDS.  M= y thinking is that if there are going to be search capabilities in the query protocol, they would at least need to be = referenced from this document.

Murray,

Honing in on the last sentence, I do not think that is the case nor is= it desirable. We have an extensible model and can add other URI paths in t= he future for search capabilities. Additionally, since lookups are 99% of W= hois queries, I don't think it is necessary to hold up our current work for what amounts to a small subset o= f queries with requirements that are not well understood.

Forgive me if I've misunderstood your point though.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC09385CHAXCH01corpari_-- From andy@arin.net Thu May 23 09:49: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 3ABA621F87FB for ; Thu, 23 May 2013 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy621xUXL+yu for ; Thu, 23 May 2013 09:49:39 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1221F9766 for ; Thu, 23 May 2013 09:45:55 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id EA58E2136A6; Thu, 23 May 2013 12:45:54 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 538D621365A; Thu, 23 May 2013 12:45:54 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 23 May 2013 12:45:32 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.35]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 23 May 2013 12:45:47 -0400 From: Andy Newton To: Ernie Dainow , "Murray S. Kucherawy" Thread-Topic: [weirds] help Thread-Index: AQHN/yVXgFevBTQie06p/bwbzsClcJhivVeAgADQSQCAAF5jgP//r9gAgABZOwD//66qgIBv+sCAgAEfGoCAA14pgP//5l2ABxtSh4AALmJvgAAre3iA Date: Thu, 23 May 2013 16:45:46 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1@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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1CHAXCH01corpari_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 May 2013 16:49:55 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow > Date: Wednesday, May 22, 2013 12:00 PM To: "Murray S. Kucherawy" > Cc: Andrew Newton >, "weirds@ietf.org" > Subject: Re: [weirds] help My comment on April 12 was intended to provide some basic text. Perhaps tha= t got missed in the follow-up discussion about whether a standard url to a = help page should be standardized or whether it was sufficient to embed help= /about links in RDAP objects. I believe you are correct with how the thread has progressed. To paraphrase John Levine, any client not dealing with the rdap+json media = type is not an RDAP client. Therefore a /help path that does not return rda= p+json is not focused on serving RDAP clients and is not RDAP (at least if = you follow the logic). I'm not against implementers having a /help that returns HTML or plain text= , but that sounds more like a BCP rather than part of the RDAP standard. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <003CA6D60EC3FD4CAA7A2E507B6F30B4@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Ernie Dainow <edainow@afilias.info>
Date: Wednesday, May 22, 2013 12:00= PM
To: "Murray S. Kucherawy"= <superuser@gmail.com>
Cc: Andrew Newton <andy@arin.net>, "weirds@ietf.org" <w= eirds@ietf.org>
Subject: Re: [weirds] help

My comment on April 12 was intended to provide some basic text. Perhaps that = got missed in the follow-up discussion about whether a standard url to a he= lp page should be standardized or whether it was sufficient to embed help/a= bout links in RDAP objects.

I believe you are correct with how the thread has progressed.

To paraphrase John Levine, any client not dealing with the rdap+js= on media type is not an RDAP client. Therefore a /help path that does not r= eturn rdap+json is not focused on serving RDAP clients and is not RDAP = (at least if you follow the logic).

I'm not against implementers having a /help that returns HTML or plain= text, but that sounds more like a BCP rather than part of the RDAP standar= d.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1CHAXCH01corpari_-- From superuser@gmail.com Thu May 23 16:16: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 7563D21F8F61 for ; Thu, 23 May 2013 16:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF9mMlrT1VWp for ; Thu, 23 May 2013 16:16:52 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1021F8F7A for ; Thu, 23 May 2013 16:16:52 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so154644wib.3 for ; Thu, 23 May 2013 16:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e8aHbU/DUdHD2hlu9QGkKD5C2cVwHQLnd5bIeejkkfU=; b=QWDoa8iKVYi4A8XCPjsVeR/ATeGSgAKy2LSZWxIyjbAaBwwtL9Ef4G7lFubWevG60B 1b4Dfr/FLjfl6caISV1pt11pHC30pU2WF1ko9mpNhR+ale5IpB+i2mGloOSZUmdPzCl2 Np9Gcgcj3hERGreWqqfzyI6yj6ffcwMmr5KF+DxBSo3B4F9rlbIYDtRVnmH8UoVdT+Wk qFYkbOdt9UNCPl9rw7T9vhHOIoN7S0toTpAvbZzSlW9Z6wUd4+QRMlyBIahGiWPBefK1 we/tXBRl+f9MquSdWrlHlQz1heVDIb+fHC6lSx3tm7es4eDlwCAZwOpgkthDCJS9DZ4G SiZw== MIME-Version: 1.0 X-Received: by 10.180.74.172 with SMTP id u12mr1134693wiv.0.1369351011049; Thu, 23 May 2013 16:16:51 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 23 May 2013 16:16:50 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09385@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09385@CHAXCH01.corp.arin.net> Date: Thu, 23 May 2013 16:16:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=f46d0438900196539504dd6ae0ab Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 May 2013 23:16:53 -0000 --f46d0438900196539504dd6ae0ab Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 9:38 AM, Andy Newton wrote: > From: "Murray S. Kucherawy" > Date: Tuesday, May 21, 2013 1:53 PM > To: "weirds@ietf.org" > Subject: [weirds] rdap-query draft > > We also don't appear to have any kind of consensus about search. There > are two documents proposed, but also some claims (one based on a registrar > survey) that we don't really need it for a first version of WEIRDS. My > thinking is that if there are going to be search capabilities in the query > protocol, they would at least need to be referenced from this document. > > > Murray, > > Honing in on the last sentence, I do not think that is the case nor is > it desirable. We have an extensible model and can add other URI paths in > the future for search capabilities. Additionally, since lookups are 99% of > Whois queries, I don't think it is necessary to hold up our current work > for what amounts to a small subset of queries with requirements that are > not well understood. > > Forgive me if I've misunderstood your point though. > > -andy > Hi Andy, The idea I have is that rdap-query and json-response together would ideally provide at least all the current capabilities of port 43 WHOIS, and if we agree that rudimentary search is part of what we're replacing then it should at least be referenced there. But if we'd rather do two drafts that are pure query-response, then your way is fine. I'm happy to go with consensus on this one, as long as I know what it is. :-) -MSK, participatin' --f46d0438900196539504dd6ae0ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 9:38 AM, Andy Newton <andy@arin.net> wrote:
From: "Murray S. Kucherawy&quo= t; <superuser@g= mail.com>
Date: Tuesday, May 21, 2013 1:53 PM=
To: "weirds@ietf.org" <weirds@ietf.org>
Subject: [weirds] rdap-query draft<= br>

We also don't appear to have any kind of consensus about search.=A0 There= are two documents proposed, but also some claims (one based on a registrar= survey) that we don't really need it for a first version of WEIRDS.=A0= My thinking is that if there are going to be search capabilities in the query protocol, they would at least need to be = referenced from this document.

Murray,

Honing in on the last sentence, I do not think that is the case nor is= it desirable. We have an extensible model and can add other URI paths in t= he future for search capabilities. Additionally, since lookups are 99% of W= hois queries, I don't think it is necessary to hold up our current work for what amounts to a small subset o= f queries with requirements that are not well understood.

Forgive me if I've misunderstood your point though.

-andy

Hi Andy,

The idea I have is that rdap-query and json-r= esponse together would ideally provide at least all the current capabilitie= s of port 43 WHOIS, and if we agree that rudimentary search is part of what= we're replacing then it should at least be referenced there.=A0 But if= we'd rather do two drafts that are pure query-response, then your way = is fine.

I'm happy to go with consensus on = this one, as long as I know what it is.=A0 :-)

-MSK, participatin= 9;
--f46d0438900196539504dd6ae0ab-- From edainow@afilias.info Fri May 24 07:54:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59D321F8CA0 for ; Fri, 24 May 2013 07:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpPJc6C8dwbN for ; Fri, 24 May 2013 07:54:50 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E34E621F8616 for ; Fri, 24 May 2013 07:54:46 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UftOI-0007mo-3X for weirds@ietf.org; Fri, 24 May 2013 14:54:46 +0000 Received: from mail-oa0-f48.google.com ([209.85.219.48]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UftOH-0003Ql-6C for weirds@ietf.org; Fri, 24 May 2013 14:54:46 +0000 Received: by mail-oa0-f48.google.com with SMTP id i4so6239725oah.21 for ; Fri, 24 May 2013 07:54:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=/p21ahMbM4bjskPJsBPtdgvIVcQm2IAUR2e2bp5/Mj4=; b=VV9iZ4Nix4nYOqpHhx6VxWacIe/KRC2ik1jbZYk9mb7emK1NgVDUbtHHSAvqOutj5u fHsf3M8owCVj4GIjkSE98LzjtkvUqCQBwvjzYtad7hQj7uXKD+6o+nyqATbB646WwTVZ 3YmhpCOFJ8w5fNaQiTbBhWb/NOqHLJ7QPykErCm5+zz9e6t+jmpvmYqwGNwLEdkmxYYQ AjRPotJjWxxaOP/Age5fUNKRNcUvgndViogBqGIzggaxOHI2aPaGhq7iukaObVeYQncQ i9DNzYMqmPZol8jQDA0+5qElqalj/2gVcvaevknHnIBSQ2d4hGhOb8vwANxUAj+lD5Tf PO/Q== X-Received: by 10.60.142.7 with SMTP id rs7mr12345404oeb.106.1369407280409; Fri, 24 May 2013 07:54:40 -0700 (PDT) X-Received: by 10.60.142.7 with SMTP id rs7mr12345398oeb.106.1369407280333; Fri, 24 May 2013 07:54:40 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id n5sm17319199obi.8.2013.05.24.07.54.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 07:54:39 -0700 (PDT) Message-ID: <519F7F2A.1040706@afilias.info> Date: Fri, 24 May 2013 10:54:34 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC093D1@CHAXCH01.corp.arin.net> Content-Type: multipart/alternative; boundary="------------080302000803020004030106" X-Gm-Message-State: ALoCoQmdO9AhgtuqU2poBjsHwn1smsj7HedPKW3+WItCtyBzvfdhgLZE05iNicKmFDvqebAIpUNEMfHjpRwNsPBkTS4QpwoB+FwHsn6HfjFuONf+ebTYuxUXwwqg3Zgqk2AfmCaUctxy Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 24 May 2013 14:54:57 -0000 This is a multi-part message in MIME format. --------------080302000803020004030106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So we could have a simple rdap/help query that returns rdap+json with help information. The issue is not whether the response is html, links or even a remarks array but rather a standard way for people to get the basic information they need to successfully use the service, especially when encountering the errors outlined earlier. -Ernie On 5/23/2013 12:45 PM, Andy Newton wrote: > From: Ernie Dainow > > Date: Wednesday, May 22, 2013 12:00 PM > To: "Murray S. Kucherawy" > > Cc: Andrew Newton >, > "weirds@ietf.org " > > Subject: Re: [weirds] help > > My comment on April 12 was intended to provide some basic text. > Perhaps that got missed in the follow-up discussion about whether > a standard url to a help page should be standardized or whether it > was sufficient to embed help/about links in RDAP objects. > > > I believe you are correct with how the thread has progressed. > > To paraphrase John Levine, any client not dealing with the rdap+json > media type is not an RDAP client. Therefore a /help path that does not > return rdap+json is not focused on serving RDAP clients and is not > RDAP (at least if you follow the logic). > > I'm not against implementers having a /help that returns HTML or plain > text, but that sounds more like a BCP rather than part of the RDAP > standard. > > -andy --------------080302000803020004030106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So we could have a simple rdap/help query that returns rdap+json with help information. The issue is not whether the response is html, links or even a remarks array but rather a standard way for people to get the basic information they need to successfully use the service, especially when encountering the errors outlined earlier.

-Ernie


On 5/23/2013 12:45 PM, Andy Newton wrote:
From: Ernie Dainow <edainow@afilias.info>
Date: Wednesday, May 22, 2013 12:00 PM
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Andrew Newton <andy@arin.net>, "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] help

My comment on April 12 was intended to provide some basic text. Perhaps that got missed in the follow-up discussion about whether a standard url to a help page should be standardized or whether it was sufficient to embed help/about links in RDAP objects.

I believe you are correct with how the thread has progressed.

To paraphrase John Levine, any client not dealing with the rdap+json media type is not an RDAP client. Therefore a /help path that does not return rdap+json is not focused on serving RDAP clients and is not RDAP (at least if you follow the logic).

I'm not against implementers having a /help that returns HTML or plain text, but that sounds more like a BCP rather than part of the RDAP standard.

-andy

--------------080302000803020004030106-- From johnl@iecc.com Fri May 24 16:57: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 C0E8D21E8088 for ; Fri, 24 May 2013 16:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.782 X-Spam-Level: X-Spam-Status: No, score=-110.782 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_44=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiyGEpniWlnd for ; Fri, 24 May 2013 16:57:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5142E21E804E for ; Fri, 24 May 2013 16:57:38 -0700 (PDT) Received: (qmail 19671 invoked from network); 24 May 2013 23:57:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 May 2013 23:57:37 -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; s=519ffe71.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=DfeX0ytr9ZVRw4pv1fISPzf2dkyJkHMmXx/CUyRmwqQ=; b=HRN/Puy+pdXqHMXdHY348qbYckNYT5AEfUAr64cD1E5es6okNkRug78KIoI7ASzIeKIuQGA4jgu4M5CdHY7jpOv4knVPFgpaMboJcwZt685Ja8RYJJsAk2bER1ZJLUHsg6eY6+7GTA4xQXe9gJLEucVhDprRrVR86ura0PFxOu0= 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; s=519ffe71.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=DfeX0ytr9ZVRw4pv1fISPzf2dkyJkHMmXx/CUyRmwqQ=; b=QdUs0+Zo0PtbEKm0dg5eiwWlJHAUZJ7n8it+wN4Ipqp1NQ1uVjnt3o5iwUmWFAWFWZKn/emA71WEKbuw4PZEEMe/R983Wv7pps3ATCL73GODi/DnsP0/f96s/nH+HIIOazqUrVKoGTHvP/ovEK/2UgG31aPOPGvbcWqgHVbVMfo= Date: 24 May 2013 23:57:15 -0000 Message-ID: <20130524235715.80830.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <519F7F2A.1040706@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 24 May 2013 23:57:42 -0000 In article <519F7F2A.1040706@afilias.info> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >So we could have a simple rdap/help query that returns rdap+json with >help information. The issue is not whether the response is html, links >or even a remarks array but rather a standard way for people to get the >basic information they need to successfully use the service, especially >when encountering the errors outlined earlier. RDAP is intended to be fetched and parsed by machines. I understand that people help might want help info, but I don't see any advantage of shoehorning it into RDAP. What would the JSON contain that would be useful to a machine? Also, if we do our work properly, an RDAP client shouldn't need anything beyond the base URL of an RDAP server to work, and that's the boostrapping problem that we've deferred for now. If clients have to do something customized for each server to get useful results, RDAP will be pretty useless. From edainow@afilias.info Mon May 27 09:14:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7521F9675 for ; Mon, 27 May 2013 09:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTXVgWsSvqBi for ; Mon, 27 May 2013 09:14:37 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 25CAC21F911B for ; Mon, 27 May 2013 09:14:34 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Uh049-0003Hv-4N for weirds@ietf.org; Mon, 27 May 2013 16:14:33 +0000 Received: from mail-ie0-f175.google.com ([209.85.223.175]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Uh049-0001qF-48 for weirds@ietf.org; Mon, 27 May 2013 16:14:33 +0000 Received: by mail-ie0-f175.google.com with SMTP id tp5so2175096ieb.20 for ; Mon, 27 May 2013 09:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=mBsQ9fkDI8BB/gGpcoKiBNkpV6joITKje2cbdSTCc4Q=; b=VpxjAkg3nJgPAp581spmDPwMze7i76+C/gbQrH+woGCG8L5eJHDFurkZpE4opipFev 5jvyl89apelxwPjWPcX3wUApDsRhCwBDboJH3+4JHIoWacDy/Q4v+DciuLg9AGe0y8Pu +I44WD9P5UKh+TKfNkvwLnhoPOWQNbQP7Yz8YV3FknUw2zz/wvmybgbeGTlnEkDD5QOk w8xN9WAexd5lxq8QJ1qQt0qjy6bW1albN7jjKYd7NhJLMO0pXpavPnKzS98ABubZQSdm Oa+RjUKNIzISYjDrLpcYRRDMYtqXi/a5QFfnl22YTyYvmx+jD+Gldqm/cZjQrA6ybVOW 3ODA== X-Received: by 10.50.102.41 with SMTP id fl9mr5126796igb.18.1369671267879; Mon, 27 May 2013 09:14:27 -0700 (PDT) X-Received: by 10.50.102.41 with SMTP id fl9mr5126793igb.18.1369671267784; Mon, 27 May 2013 09:14:27 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id ua6sm13736415igb.0.2013.05.27.09.14.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 09:14:26 -0700 (PDT) Message-ID: <51A3865F.9000901@afilias.info> Date: Mon, 27 May 2013 12:14:23 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton , "weirds@ietf.org" References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC050D6@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC050D6@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktVYTHzkF9BlKax5erk7S+ZR88ZEVYp0/icElizr3VsNXmbrfhsQWpmQgjil5J6fXMMZNIDnK5P8BD8tzfkb0TgEIOAkb+YNwHPVrJW67SAXuh3w1GBlVbYXem9eBaihq5CFcN Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 16:14:43 -0000 On 5/14/2013 1:08 PM, Andy Newton wrote: > There are a good number of parts in the current spec that number > registries will use which domain registries will not use. So I don't see > the logic here. > > I think it is perfectly fine to try to define those JSON values now and > get it in the current spec. This is not an unknown area, and so should be > easy to accomplish. A standard extension would just result in all clients > trying to support it anyway. > > Does anyone want to take a stab at the JSON for this? > > -andy > Here is a draft for a DNSSEC section in draft-ietf-weirds-json-response. This is based on what is in RFC5910, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" and the following Whois requirement in ICANN's New gTLD Agreement, Sec 1.5 http://newgtlds.icann.org/en/applicants/agb/base-agreement-specs-29apr13-en.pdf DNSSEC: signedDelegation DNSSEC: unsigned __________________________________________________ DNS Security Extensions (DNSSEC) DNSSEC provides data integrity for DNS through digital signing of resource records. To enable DNSSEC, the zone is signed by one or more private keys and the signatures stored as RRSIG records. To complete the chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record (which contains the public key) must be loaded into the parent zone, stored as Delegation Signer (DS) records and signed by the parent's private key (RRSIG DS record), "Resource Records for the DNS Security Extensions" [RFC4034]. Creating the DS records in the parent zone can be done by the registration authority, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" [RFC5910]. Only DS related information is provided by RDAP, since other information is not generally stored in the registration database. Other DNSSEC related information can be retrieved with other DNS tools such as dig. The following is the "DS Data Interface" [RFC5910], where the registration data provides the information for one or more DS records. "secDNS": [ "zoneSigned": true, "delegationSigned": true, "maxSigLife:" 604800, { "dsData": [ { "keyTag": 12345, "algorithm": 3, "digestType": 1, "digest:": "49FD46E6C4B45C55D4AC", "events": [ { "eventAction": "registration", "eventDate": "2011-07-26T16:25:08Z" } ] }, ... ] } ] The following is the "Key Data Interface" [RFC5910], where the registration data provides the actual key data from one or more DNSKEY records that are used to create the DS records. "secDNS": [ "zoneSigned": true, "delegationSigned": true, "maxSigLife:" 604800, { "keyData": [ { "flags": 257, "protocol": 3, "algorithm": 1, "publicKey": "AQPJ////4Q==", "events": [ { "eventAction": "last changed", "eventDate": "2012-07-23T05:15:47Z" } ] }, ... ] } ] * zoneSigned -- boolean true if the zone has been signed, false otherwise. * delegationSigned -- boolean true if there are DS records in the parent, false otherwise. * maxSigLife -- signature life time in seconds to be used when creating the RRSIG DS record in the parent zone [RFC5910]. * keyTag -- an integer as specified by the key tag field of the DS record [RFC5910]. * algorithm -- a DNSSEC algorithm type as specified in "DNS Security (DNSSEC) Algorithm Numbers" [IANA] * digestType -- an integer as specified by the digest type field of the DS record [RFC5910]. * digest -- a hex-encoded binary string of the digest field of the DS record [RFC5910]. * events -- see Section 5.5 * flags -- the flags field value in the DNSKEY record [RFC5910]. * protocol -- the protocol field value in the DNSKEY record [RFC5910]. * publicKey -- the base64Binary encoded string of the public key in the DNSKEY record [RFC5910]. ________________________________________________ -Ernie From edainow@afilias.info Mon May 27 10:19: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 462E521F969F for ; Mon, 27 May 2013 10:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb96KAo8W7D3 for ; Mon, 27 May 2013 10:19:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9D21F9692 for ; Mon, 27 May 2013 10:19:15 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Uh14k-0001Ki-56 for weirds@ietf.org; Mon, 27 May 2013 17:19:14 +0000 Received: from mail-ie0-f172.google.com ([209.85.223.172]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Uh14k-0005Wu-4Y for weirds@ietf.org; Mon, 27 May 2013 17:19:14 +0000 Received: by mail-ie0-f172.google.com with SMTP id 16so19241870iea.3 for ; Mon, 27 May 2013 10:19:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=TmtVAFMlHVVnIWvc9oxynFXhajnbbHxrcQFZlve69OA=; b=YOAbs7t5VDq7L5FsnBMe+YetqEvJYJC5mQBrEI2prJRhMyoyg3z0frHGPhC544jfL6 JlAxu78stnqErhc1OHVDaVCvQ6kHQQxIiFwl/Aj8rPVztnz6/jDtFqfcb5hDuK5VDKCu N4JXOv/tEpEhuqZQ3mpBFqJrw8LcBwNF2GrrfzX+U0jm/T4EB93fHY14ErrHkqx/syoL XNROM5TdNa11RqdF+wZKDBrxMTj/Y/zd9wTkeTlLEDK/eJVvWFl08FQgR8fZ0swG89di wwrmyCITjNzwq9WhCFt03WZCfL5Gs+SwojXcvxHh8EQZdN4IF4wrLV5m60RlIX6AZzVR WOnA== X-Received: by 10.50.108.17 with SMTP id hg17mr5205704igb.57.1369675148995; Mon, 27 May 2013 10:19:08 -0700 (PDT) X-Received: by 10.50.108.17 with SMTP id hg17mr5205698igb.57.1369675148907; Mon, 27 May 2013 10:19:08 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id gz1sm1400866igb.5.2013.05.27.10.19.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 10:19:08 -0700 (PDT) Message-ID: <51A39589.7000409@afilias.info> Date: Mon, 27 May 2013 13:19:05 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09385@CHAXCH01.corp.arin.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010809080006000906000605" X-Gm-Message-State: ALoCoQnrVxM+L40iS2LAWgDA6/I/bpj6aR/q1vanNK+Iqw2r7b7lnkOuvmID+8ajbzGqLphCBOzCLTTe1gORRzxYwdyv4vBNPsppTCdRMyAaXwmUczP3EJQgjxzfU/ciUJU0lG2DdRL7 Cc: "weirds@ietf.org" Subject: Re: [weirds] rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 17:19:26 -0000 This is a multi-part message in MIME format. --------------010809080006000906000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/23/2013 7:16 PM, Murray S. Kucherawy wrote: > On Thu, May 23, 2013 at 9:38 AM, Andy Newton > wrote: > > From: "Murray S. Kucherawy" > > Date: Tuesday, May 21, 2013 1:53 PM > To: "weirds@ietf.org " > > Subject: [weirds] rdap-query draft > > We also don't appear to have any kind of consensus about > search. There are two documents proposed, but also some > claims (one based on a registrar survey) that we don't really > need it for a first version of WEIRDS. My thinking is that if > there are going to be search capabilities in the query > protocol, they would at least need to be referenced from this > document. > > > Murray, > > Honing in on the last sentence, I do not think that is the case > nor is it desirable. We have an extensible model and can add other > URI paths in the future for search capabilities. Additionally, > since lookups are 99% of Whois queries, I don't think it is > necessary to hold up our current work for what amounts to a small > subset of queries with requirements that are not well understood. > > Forgive me if I've misunderstood your point though. > > -andy > > > Hi Andy, > > The idea I have is that rdap-query and json-response together would > ideally provide at least all the current capabilities of port 43 > WHOIS, and if we agree that rudimentary search is part of what we're > replacing then it should at least be referenced there. But if we'd > rather do two drafts that are pure query-response, then your way is fine. > > I'm happy to go with consensus on this one, as long as I know what it > is. :-) > > -MSK, participatin' > There are Whois search requirements in Sec 1.10 of ICANN's New gTLD Agreement that are beyond simple prefix matching. Since many operators will be launching new TLDs starting late 2013 or early 2014, the RDAP spec should address this requirement on first publication (current charter target Dec 2013). Prefix matching search that is compatible with most legacy Whois services should be rdapConformance level 0 with the new gTLD search at level 1. Since both search requirements need to be published around the same time, it would be simplest to specify them both in one document (either search or query). -Ernie --------------010809080006000906000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/23/2013 7:16 PM, Murray S. Kucherawy wrote:
On Thu, May 23, 2013 at 9:38 AM, Andy Newton <andy@arin.net> wrote:
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tuesday, May 21, 2013 1:53 PM
To: "weirds@ietf.org" <weirds@ietf.org>
Subject: [weirds] rdap-query draft

We also don't appear to have any kind of consensus about search.  There are two documents proposed, but also some claims (one based on a registrar survey) that we don't really need it for a first version of WEIRDS.  My thinking is that if there are going to be search capabilities in the query protocol, they would at least need to be referenced from this document.

Murray,

Honing in on the last sentence, I do not think that is the case nor is it desirable. We have an extensible model and can add other URI paths in the future for search capabilities. Additionally, since lookups are 99% of Whois queries, I don't think it is necessary to hold up our current work for what amounts to a small subset of queries with requirements that are not well understood.

Forgive me if I've misunderstood your point though.

-andy

Hi Andy,

The idea I have is that rdap-query and json-response together would ideally provide at least all the current capabilities of port 43 WHOIS, and if we agree that rudimentary search is part of what we're replacing then it should at least be referenced there.  But if we'd rather do two drafts that are pure query-response, then your way is fine.

I'm happy to go with consensus on this one, as long as I know what it is.  :-)

-MSK, participatin'


There are Whois search requirements in Sec 1.10 of ICANN's New gTLD Agreement that are beyond simple prefix matching. Since many operators will be launching new TLDs starting late 2013 or early 2014, the RDAP spec should address this requirement on first publication (current charter target Dec 2013).

Prefix matching search that is compatible with most legacy Whois services should be rdapConformance level 0 with the new gTLD search at level 1. Since both search requirements need to be published around the same time, it would be simplest to specify them both in one document (either search or query).

-Ernie


--------------010809080006000906000605-- From edainow@afilias.info Mon May 27 10:50: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 F226E21F9418 for ; Mon, 27 May 2013 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94u4AvZZ0Qvc for ; Mon, 27 May 2013 10:49:58 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id A33FE21F93C4 for ; Mon, 27 May 2013 10:49:58 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Uh1YT-0003oT-5f for weirds@ietf.org; Mon, 27 May 2013 17:49:57 +0000 Received: from mail-ie0-f174.google.com ([209.85.223.174]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Uh1YT-0006wH-5P for weirds@ietf.org; Mon, 27 May 2013 17:49:57 +0000 Received: by mail-ie0-f174.google.com with SMTP id 10so18818208ied.19 for ; Mon, 27 May 2013 10:49:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=aFNhTZEfQ8YSMQAZ8km6JKyjXJKTIBMzGwiMy8jxceU=; b=U1cGDghihutRuvtk5HDXOjr8PBpb0gjnszQpVSpWaDbxYYU/hy7diovBbpKjjCFVrh zcv5j+pzL3VSGW3dZutjjx+/465hVEunPSMz94CL0jjd52QSi27C2X4UBjdF5vpI/Uio NBSx34n+wDZYd1zuJJISDv4edY3YDjkNuBcbj/nYMC03CfMBeQC6QJp5yInXoCVeiKEh vGrk2a5dXdT/09dyXEApqLBQLZ6nMohPYWAw9OlULAfpSsOvZnaPSGSqNzwofLHMXONY +ekm+FoxS0P0/faHFTp00stVh9VulCT0gCUaU2lxMD2QCT/Xm/7ks27TlVTn/kDjI11S VT1g== X-Received: by 10.50.132.103 with SMTP id ot7mr3638632igb.99.1369676992231; Mon, 27 May 2013 10:49:52 -0700 (PDT) X-Received: by 10.50.132.103 with SMTP id ot7mr3638628igb.99.1369676992154; Mon, 27 May 2013 10:49:52 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id d9sm14080047igr.4.2013.05.27.10.49.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 10:49:51 -0700 (PDT) Message-ID: <51A39CBC.8040307@afilias.info> Date: Mon, 27 May 2013 13:49:48 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130524235715.80830.qmail@joyce.lan> In-Reply-To: <20130524235715.80830.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkXKLGCk41kMAIE1CtYqBuXm1fJ9D3W5xMWOPhuuIzrq5gC54lp6Xlb/dzJC6DKCVn0uMX5jCGNtKnNDXE2/ecTRuRhJ/Lh6YMuQca8+iv14Kb5KyuHSAq2ceYigx6D+srCzMxA Cc: weirds@ietf.org Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 17:50:05 -0000 On 5/24/2013 7:57 PM, John Levine wrote: > > RDAP is intended to be fetched and parsed by machines. I understand > that people help might want help info, but I don't see any advantage > of shoehorning it into RDAP. What would the JSON contain that would > be useful to a machine? > > Also, if we do our work properly, an RDAP client shouldn't need > anything beyond the base URL of an RDAP server to work, and that's the > boostrapping problem that we've deferred for now. > > If clients have to do something customized for each server to get > useful results, RDAP will be pretty useless. > > Take as a representative case an RDAP client built to display data on a web page. If the client encounters an authentication error, I doubt it will have the smarts or the knowledge to create a request for authentication credentials. This is information the end user will need. Beyond the end user, consider the developer trying to write an RDAP client. If the server has documented limitations or optional parts of the spec that are not supported, the developer can build this into the client. Otherwise, the end user will likely encounter errors with say some TLDs and not others. Without documentation, software is built with trial and error and rarely handles errors well. RDAP servers should make it easy for developers to get the information they need to build good clients. Other information that should be in a help are: - What objects the server supports and names of a few objects that exist so that a client (developer) can do some basic tests. - Description of any extensions. - What is the rate limiting policy so that a client can set appropriate delays. - Typical "Release Notes" that may cover limitations, fixes or version differences. - How to get technical support for problems. -Ernie From johnl@taugh.com Mon May 27 11:46: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 A7E7121F8E9D for ; Mon, 27 May 2013 11:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXQtMfFLoIIn for ; Mon, 27 May 2013 11:46:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C6F8821F8AD1 for ; Mon, 27 May 2013 11:46:03 -0700 (PDT) Received: (qmail 84575 invoked from network); 27 May 2013 18:46:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=14a5e.51a3a9ee.k1305; bh=DU+IBRB51jLRkhM8zrnRQdTptZ72sneYqRZ5tX1v85M=; b=WZNoTx6Xy8ndq5mmxmIJDzsIa+TCjql6J3gXj6q3Z8n9+6USGavcef0BUHdHxCAoRFxEbiJTMKg1v9JmAtdTn80pvB+UBF8L2uo7xqDi0T/49bC4Ie57lZ1Rkoa4UtoL5Jhxw9kUmpz6rqnbGq8fFEB+BQwfYqeAjn1I0/rvG2g= 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:user-agent:cleverness; s=14a5e.51a3a9ee.k1305; bh=DU+IBRB51jLRkhM8zrnRQdTptZ72sneYqRZ5tX1v85M=; b=klG1kHTFQSVskVAb4EZ0GlFfI4i5MIU1Ip8vOlIJCmJzkisT+tSb/K0l6M/g79TKf4x+allOUH80L1ULKL/gXm8UX1uIkwHNEExDBVyus4lE7iOjzfFqTnpg+c2z2zzs9eDc8DSVadO8KZT+yjYJtzEx1F3JTUoCAkKYKK0b6S0= Received: (ofmipd 127.0.0.1); 27 May 2013 18:45:44 -0000 Date: 27 May 2013 14:46:02 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51A39CBC.8040307@afilias.info> References: <20130524235715.80830.qmail@joyce.lan> <51A39CBC.8040307@afilias.info> 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] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 18:46:04 -0000 > Take as a representative case an RDAP client built to display data on a web > page. If the client encounters an authentication error, I doubt it will have > the smarts or the knowledge to create a request for authentication > credentials. This is information the end user will need. As I think I said, I agree that help text might be useful. But I still don't see any reason to encode it in JSON, as opposed to a conventional URL that returns a free form web page people can look at. R's, John PS: Also, what kind of lame client wouldn't be able to tell that an autnentication error on an unauthenticated request means that it wants credentials? HTTP authentication in browsers has dealt with this situation for approximately 20 years. From johnl@iecc.com Mon May 27 12:36:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364FB21F8F12 for ; Mon, 27 May 2013 12:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.9 X-Spam-Level: X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sjg4aXFgZtB for ; Mon, 27 May 2013 12:36:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D0BB221F8CE9 for ; Mon, 27 May 2013 12:36:06 -0700 (PDT) Received: (qmail 93641 invoked from network); 27 May 2013 19:36:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 May 2013 19:36:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51a3b5a5.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=O2ZJjW/YHq8VuS6GSH5/omI1Lu5TkOjqu3X4tTmobjk=; b=MCPh5cez+ZIiGOIZ7N4SHyvl1XpaX9fZsbb5MwnzqeryPnQwmpZ7qZ5Kbhb9g45sE6EiLJUBuP8+fSW+4PhL0HL+JTD40OhS7sO2T92pzZxIEniBFJfz5v59HTV7hr04CFRU+/0N8/ki03VcXfu7cXqtUjhXGlJ5f1kd0gFdNno= 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; s=51a3b5a5.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=O2ZJjW/YHq8VuS6GSH5/omI1Lu5TkOjqu3X4tTmobjk=; b=lJNp+HUrwjLQYTYbbBPJ9e5oElBJSL+kp4T6jxjfHu5DF9meJRqlqmw0bNVzOAsR0Bi6HMF0npR9iaYnoMptp8SPPIWSZ6dUxfZaMU4srgweNoJkdNupNVb9sy817B0ia5M29lTzhR9UF5fQKgEee2fyhWnnC3wvjIz9nzchUmM= Date: 27 May 2013 19:35:43 -0000 Message-ID: <20130527193543.13490.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51A39589.7000409@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 19:36:11 -0000 >There are Whois search requirements in Sec 1.10 of ICANN's New gTLD >Agreement that are beyond simple prefix matching. There is no section 1.10 of the new gTLD agreement. I expect you're referring to Appendix A, Specification 4, section 1.10, which describes WHOIS searching. What I see there is basically prefix matching with and/or/not combinations of matches on various fields. Many of the applications with Neustar as the back end say they're going to provide regular expression matching, but I have to say that I don't understand how they expect to do searches on large domains, since I am fairly sure that the only way to implement general REs is to scan the entire data set, with no way to speed them up using indexes like you can with prefix matching. (Is anyone from Neustar here who can enlighten us?) Given the uncertainty about what new gTLDs will really implement, your suggestion about prefix matching now, gTLD whatever later is probably the best we can do. From andy@arin.net Mon May 27 15:43:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FCF21F8FDD for ; Mon, 27 May 2013 15:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl-HOsAWbwm9 for ; Mon, 27 May 2013 15:43:38 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4721F8FA5 for ; Mon, 27 May 2013 15:43:38 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 9E5F821366F; Mon, 27 May 2013 18:43:37 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 0660A213640; Mon, 27 May 2013 18:43:37 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 27 May 2013 18:43:18 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.35]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 27 May 2013 18:43:23 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] DNSSEC - proposed text Thread-Index: AQHOWvVLBq3yf/lRj0yWr15ktd4cwZkZoUCA Date: Mon, 27 May 2013 22:43:22 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D24@CHAXCH01.corp.arin.net> In-Reply-To: <51A3865F.9000901@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 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 Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 22:43:47 -0000 Terrific work, Ernie! I have two comments inline... On 5/27/13 12:14 PM, "Ernie Dainow" wrote: >DNS Security Extensions (DNSSEC) > >DNSSEC provides data integrity for DNS through digital signing of >resource records. To enable DNSSEC, the zone is signed by one or more >private keys and the signatures stored as RRSIG records. To complete the >chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record >(which contains the public key) must be loaded into the parent zone, >stored as Delegation Signer (DS) records and signed by the parent's >private key (RRSIG DS record), "Resource Records for the DNS Security >Extensions" [RFC4034]. Creating the DS records in the parent zone can be >done by the registration authority, "Domain Name System (DNS) Security >Extensions Mapping for the Extensible Provisioning Protocol (EPP)" >[RFC5910]. That last sentence the reference to EPP is unnecessary and a little misleading. Not all domains are maintained with EPP. For example, we put DS records in the reverse but do not have an EPP interface. >Only DS related information is provided by RDAP, since other information >is not generally stored in the registration database. Other DNSSEC >related information can be retrieved with other DNS tools such as dig. > >The following is the "DS Data Interface" [RFC5910], where the >registration data provides the information for one or more DS records. > >"secDNS": >[ > "zoneSigned": true, > "delegationSigned": true, > "maxSigLife:" 604800, > { > "dsData": > [ > { > "keyTag": 12345, > "algorithm": 3, > "digestType": 1, > "digest:": "49FD46E6C4B45C55D4AC", > "events": > [ > { > "eventAction": "registration", > "eventDate": "2011-07-26T16:25:08Z" > } > ] > }, > ... > ] > } >] > >The following is the "Key Data Interface" [RFC5910], where the >registration data provides the actual key data from one or more DNSKEY >records that are used to create the DS records. > >"secDNS": >[ > "zoneSigned": true, > "delegationSigned": true, > "maxSigLife:" 604800, > { > "keyData": > [ > { > "flags": 257, > "protocol": 3, > "algorithm": 1, > "publicKey": "AQPJ////4Q=3D=3D", > "events": > [ > { > "eventAction": "last changed", > "eventDate": "2012-07-23T05:15:47Z" > } > ] > }, > ... > ] > } >] > >* zoneSigned -- boolean true if the zone has been signed, false >otherwise. >* delegationSigned -- boolean true if there are DS records in the >parent, false otherwise. >* maxSigLife -- signature life time in seconds to be used when creating >the RRSIG DS record in the parent zone [RFC5910]. >* keyTag -- an integer as specified by the key tag field of the DS >record [RFC5910]. >* algorithm -- a DNSSEC algorithm type as specified in "DNS Security >(DNSSEC) Algorithm Numbers" [IANA] >* digestType -- an integer as specified by the digest type field of the >DS record [RFC5910]. >* digest -- a hex-encoded binary string of the digest field of the DS >record [RFC5910]. >* events -- see Section 5.5 Why is it necessary to have a separate events structure for the DNSSEC data. Isn't 'secDNS' suppose to be part of the domain object class? >* flags -- the flags field value in the DNSKEY record [RFC5910]. >* protocol -- the protocol field value in the DNSKEY record [RFC5910]. >* publicKey -- the base64Binary encoded string of the public key in the >DNSKEY record [RFC5910]. Again, excellent work. Thank you very much! -andy From andy@arin.net Mon May 27 15:51:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AFB21F85E6 for ; Mon, 27 May 2013 15:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Oh97v0FcWRU for ; Mon, 27 May 2013 15:51:23 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id B32E021F8FDD for ; Mon, 27 May 2013 15:51:22 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 44D6A165064; Mon, 27 May 2013 18:50:52 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id C7A31164FF0; Mon, 27 May 2013 18:50:51 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 27 May 2013 18:50:33 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.35]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 27 May 2013 18:50:39 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] searching in rdap-query draft Thread-Index: AQHOWxF259ZjMVfMNEe80vrmJQnH65kZow2A Date: Mon, 27 May 2013 22:50:38 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D40@CHAXCH01.corp.arin.net> In-Reply-To: <20130527193543.13490.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.4.130416 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 Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 May 2013 22:51:29 -0000 On 5/27/13 3:35 PM, "John Levine" wrote: >>There are Whois search requirements in Sec 1.10 of ICANN's New gTLD >>Agreement that are beyond simple prefix matching. > >There is no section 1.10 of the new gTLD agreement. I expect you're >referring to Appendix A, Specification 4, section 1.10, which >describes WHOIS searching. It is my understanding that this is optional and a nice to have but not a requirement. Also, we must remember that ICANN gTLDs are not the only community being served by this spec. I would rather not hold up the work of RDAP for the RIR community on search. The RIR Whois services also have search capabilities but the RIRs have purposefully set aside those needs for the time being so that the IETF can publish a base spec that meets the needs of 99% of Whois queries. Search is a larger topic than just the needs of the ICANN gTLD requirements. -andy From dblumenthal@pir.org Mon May 27 17:04: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 9A0F821F9080 for ; Mon, 27 May 2013 17:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzlEd3kJwBdV for ; Mon, 27 May 2013 17:04:40 -0700 (PDT) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6145921F8FF3 for ; Mon, 27 May 2013 17:04:40 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Mon, 27 May 2013 20:04:39 -0400 From: Don Blumenthal To: Andy Newton , "weirds@ietf.org" Date: Mon, 27 May 2013 20:04:34 -0400 Thread-Topic: [weirds] searching in rdap-query draft Thread-Index: Ac5bNvF7FkK4CCDRR3Sw+jPHn5a/YA== Message-ID: In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D40@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 00:04:44 -0000 You are correct about search capabilities being optional. Keep in mind also that current and pending documents relate to the existing system. The agreements' WHOIS-related language will have to be redrafted should RDAP become the law of ICANNland. The draft Registry Agreements alludes to that fact at the beginning of Specification 4.1 on Registration Data Directory Services: "Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at =8A." Don On 5/27/13 6:50 PM, "Andy Newton" wrote: >On 5/27/13 3:35 PM, "John Levine" wrote: > >>There is no section 1.10 of the new gTLD agreement. I expect you're >>referring to Appendix A, Specification 4, section 1.10, which >>describes WHOIS searching. > >It is my understanding that this is optional and a nice to have but not a >requirement. > >Also, we must remember that ICANN gTLDs are not the only community being >served by this spec. I would rather not hold up the work of RDAP for the >RIR community on search. The RIR Whois services also have search >capabilities but the RIRs have purposefully set aside those needs for the >time being so that the IETF can publish a base spec that meets the needs >of 99% of Whois queries. Search is a larger topic than just the needs of >the ICANN gTLD requirements. > >-andy > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Mon May 27 19:35: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 5737F21F9007 for ; Mon, 27 May 2013 19:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FReGoX3asy-M for ; Mon, 27 May 2013 19:35:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2691021F9347 for ; Mon, 27 May 2013 19:35:26 -0700 (PDT) Received: (qmail 84822 invoked from network); 28 May 2013 02:35: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:user-agent:cleverness; s=14b55.51a417f4.k1305; bh=BakGNxzYXXBg1OEaOCRc0IZHbYZUKHkuHXky521LdHs=; b=Ff8Xg1KPRgFqxtK1PYq2eoVUbBGYLW6tZmSfKfL3vtTK+KrXKct5ytl5YzY10Yjjj+ttaoHrEnOGJQHlIs5L3OP3mvXWkrMLDxZx71cmarJhHSgx0tRv+o0m7X5+/zx5pGFgyilozDWwlak1T6rkTlTXutD+ckD+bxM3/Pr4hIY= 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:user-agent:cleverness; s=14b55.51a417f4.k1305; bh=BakGNxzYXXBg1OEaOCRc0IZHbYZUKHkuHXky521LdHs=; b=jbcdOVDPo107mcIeUCMxTMNKVIncCOKybpjfOnOdiSayUjSDD2hCEpu8RUPXQFpD2L/xZCvaaEaAVrz57AUFZ8KJTakHiviRFxG/qAakMnnuu425tyMtxhzef2clMrjfROgxgk4ks/t4k0zpUfjtvD83d+bMWMsMoX0rsl8f06s= Received: (ofmipd 127.0.0.1); 28 May 2013 02:35:10 -0000 Date: 27 May 2013 22:35:25 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D40@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D40@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1211207365-1369708526=:45947" Cc: "weirds@ietf.org" Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 02:35:30 -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-1211207365-1369708526=:45947 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> There is no section 1.10 of the new gTLD agreement. I expect you're >> referring to Appendix A, Specification 4, section 1.10, which >> describes WHOIS searching. > > It is my understanding that this is optional and a nice to have but not a > requirement. You're right, it's optional, but if a new gTLD offers search at all, it has to do what's in that section. > Also, we must remember that ICANN gTLDs are not the only community being > served by this spec. I would rather not hold up the work of RDAP for the > RIR community on search. Agreed, although this strikes me as one of the areas where the RIRs and domains will always be different, so we can just leave a placeholder for domain search without affecting RIRs. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1211207365-1369708526=:45947 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI4MDIzNTI1WjAjBgkqhkiG 9w0BCQQxFgQUdYOV2dNKIxiFmV9NfHqYOgweS7UweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEARaQb3fB5DYDR FPazNDvzfWyJQTilP9apY+0lA91j3PfGgfNR62gWi+ikByEbMjZusxNJFFNB ejrT0Enhx3TfEbUrV5LUAXD7s3fqaEuui++eb/qAeEMvOnjdBEJbNla/WS0k KHJGHfnYcpiFxhOXKlPRSRfbUhIPiozewXM/p6gijDb5+3WnxmBLXuyGsfT6 59siSMwEk2RC61eNHPUKbYrSjdoRSFJFpTgYoBf9HruEeZdFTkSaThMVoA/X dIYGmwjDEy0J6m8VmdGdjczQey8pSs4yyAzrlDq12vjfttnc6/VR/T23Rbzt /IX9VuGVnIMXkN/xsQI6ILCgkKeB3g== --3825401791-1211207365-1369708526=:45947-- From johnl@iecc.com Mon May 27 19:46:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E357921F8F0F for ; Mon, 27 May 2013 19:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.333 X-Spam-Level: X-Spam-Status: No, score=-110.333 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j83pds5FpMFx for ; Mon, 27 May 2013 19:46:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7266F21F8E2C for ; Mon, 27 May 2013 19:46:05 -0700 (PDT) Received: (qmail 13814 invoked from network); 28 May 2013 02:46:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 May 2013 02:46:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51a41a68.xn--hew.k1305; i=johnl@user.iecc.com; bh=A3Zxji8hHGLoVenwK/cHrrwhD4986yw4neFziaCK2GQ=; b=mQgbx2LR9qC3OCO+g0GKnwCMo6mJqY5ZQ1gpeiUUxNROr+16O4KYfTwaZw+HSwaPG4ab++72OV4ApeBXVqdNp+l8Had3IKEHeYsLaojCYkZ/u+cDbgpt8stBqycGQ6S0DSZgg7DU5T4fCIP6D7YIsQo+UBF1+nZJxY5S4Ai0t7U= 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; s=51a41a68.xn--hew.k1305; olt=johnl@user.iecc.com; bh=A3Zxji8hHGLoVenwK/cHrrwhD4986yw4neFziaCK2GQ=; b=iSepuFeXOBYO2+c+VuPEE2cR7HknINQm926FC1VE8q2ZM0UqqY75oSqj9jccts/XYf7n+aORaci2j3oLMuMur1H6J8ULHnpd0iXRCrlggJA1bx7ubgFzsn7BlbsaykUK1RCH884mPuYJVG2HXdLscUd0+pRAyNo2P1CREuiDBA8= Date: 28 May 2013 02:45:38 -0000 Message-ID: <20130528024538.49009.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: 8bit Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 02:46:10 -0000 >Keep in mind also that current and pending documents relate to the >existing system. The agreements' WHOIS-related language will have to be >redrafted should RDAP become the law of ICANNland. ... But the current draft for new TLDs says: Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at providing free public query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than 135 days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry. [ followed by a description of the current thick whois ] From dblumenthal@pir.org Mon May 27 19:55: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 829C321F9385 for ; Mon, 27 May 2013 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY2-8pHtLoxn for ; Mon, 27 May 2013 19:55:33 -0700 (PDT) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0621F9362 for ; Mon, 27 May 2013 19:55:33 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Mon, 27 May 2013 22:55:31 -0400 From: Don Blumenthal To: John Levine , "weirds@ietf.org" Date: Mon, 27 May 2013 22:55:25 -0400 Thread-Topic: [weirds] searching in rdap-query draft Thread-Index: Ac5bTtCAP1/FoUs2S0u22hskIdJLMQ== Message-ID: In-Reply-To: <20130528024538.49009.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.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 02:55:38 -0000 That's what I quoted from, the 04/01 version. The additional text, especially the second paragraph, strike me as supporting my point that we not get too wrapped around the axle on what's currently required. On 5/27/13 10:45 PM, "John Levine" wrote: >>Keep in mind also that current and pending documents relate to the >>existing system. The agreements' WHOIS-related language will have to be >>redrafted should RDAP become the law of ICANNland. ... > >But the current draft for new TLDs says: > > Registration Data Directory Services. Until ICANN requires a different > protocol, Registry Operator will operate a WHOIS service available via > port 43 in accordance with RFC 3912, and a web-based Directory Service > at providing free public query-based access to at > least the following elements in the following format. ICANN reserves > the right to specify alternative formats and protocols, and upon such > specification, the Registry Operator will implement such alternative > specification as soon as reasonably practicable. > > Registry Operator shall implement a new standard supporting access to > domain name registration data (SAC 051) no later than 135 days after > it is requested by ICANN if: 1) the IETF produces a standard (i.e., it > is published, at least, as a Proposed Standard RFC as specified in RFC > 2026); and 2) its implementation is commercially reasonable in the > context of the overall operation of the registry. > > [ followed by a description of the current thick whois ] > > From dblumenthal@pir.org Mon May 27 19:57: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 70B1B21F91A5 for ; Mon, 27 May 2013 19:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gACoub2uNlt for ; Mon, 27 May 2013 19:57:30 -0700 (PDT) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id 32CDB21F859B for ; Mon, 27 May 2013 19:57:30 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Mon, 27 May 2013 22:57:29 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Mon, 27 May 2013 22:57:26 -0400 Thread-Topic: [weirds] searching in rdap-query draft Thread-Index: Ac5bTxc4fjWEqz6NS9icYzp2cspWaA== Message-ID: 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.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] FW: searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 02:57:35 -0000 Correction. Search isn't required. On what's in specifications concerning WHOIS. On 5/27/13 10:55 PM, "Don Blumenthal" wrote: >That's what I quoted from, the 04/01 version. The additional text, >especially the second paragraph, strike me as supporting my point that we >not get too wrapped around the axle on what's currently required. > > >On 5/27/13 10:45 PM, "John Levine" wrote: > >>>Keep in mind also that current and pending documents relate to the >>>existing system. The agreements' WHOIS-related language will have to be >>>redrafted should RDAP become the law of ICANNland. ... >> >>But the current draft for new TLDs says: >> >> Registration Data Directory Services. Until ICANN requires a different >> protocol, Registry Operator will operate a WHOIS service available via >> port 43 in accordance with RFC 3912, and a web-based Directory Service >> at providing free public query-based access to at >> least the following elements in the following format. ICANN reserves >> the right to specify alternative formats and protocols, and upon such >> specification, the Registry Operator will implement such alternative >> specification as soon as reasonably practicable. >> >> Registry Operator shall implement a new standard supporting access to >> domain name registration data (SAC 051) no later than 135 days after >> it is requested by ICANN if: 1) the IETF produces a standard (i.e., it >> is published, at least, as a Proposed Standard RFC as specified in RFC >> 2026); and 2) its implementation is commercially reasonable in the >> context of the overall operation of the registry. >> >> [ followed by a description of the current thick whois ] >> >> > From dblumenthal@pir.org Mon May 27 20:19: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 AEE7A21F9385 for ; Mon, 27 May 2013 20:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtwqKqHUZoMR for ; Mon, 27 May 2013 20:19:45 -0700 (PDT) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7B21F93F1 for ; Mon, 27 May 2013 20:19:45 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Mon, 27 May 2013 23:19:44 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Mon, 27 May 2013 23:19:39 -0400 Thread-Topic: [weirds] searching in rdap-query draft Thread-Index: Ac5bUjJ7qChCEuJyTOmPOQm13+lPpg== Message-ID: 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.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] FW: searching in rdap-query draft X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 03:19:49 -0000 Correction deux. The current version is 04-29, not 04-01. For anybody who REALLY has nothing else to do, http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm. On 5/27/13 10:55 PM, "Don Blumenthal" wrote: >That's what I quoted from, the 04/01 version. The additional text, >especially the second paragraph, strike me as supporting my point that we >not get too wrapped around the axle on what's currently required. > > >On 5/27/13 10:45 PM, "John Levine" wrote: > >>>Keep in mind also that current and pending documents relate to the >>>existing system. The agreements' WHOIS-related language will have to be >>>redrafted should RDAP become the law of ICANNland. ... >> >>But the current draft for new TLDs says: >> >> Registration Data Directory Services. Until ICANN requires a different >> protocol, Registry Operator will operate a WHOIS service available via >> port 43 in accordance with RFC 3912, and a web-based Directory Service >> at providing free public query-based access to at >> least the following elements in the following format. ICANN reserves >> the right to specify alternative formats and protocols, and upon such >> specification, the Registry Operator will implement such alternative >> specification as soon as reasonably practicable. >> >> Registry Operator shall implement a new standard supporting access to >> domain name registration data (SAC 051) no later than 135 days after >> it is requested by ICANN if: 1) the IETF produces a standard (i.e., it >> is published, at least, as a Proposed Standard RFC as specified in RFC >> 2026); and 2) its implementation is commercially reasonable in the >> context of the overall operation of the registry. >> >> [ followed by a description of the current thick whois ] >> >> > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From edainow@afilias.info Tue May 28 08:57:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF421F9777 for ; Tue, 28 May 2013 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGOMuo5Mwqhl for ; Tue, 28 May 2013 08:57:05 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7483321F9725 for ; Tue, 28 May 2013 08:57:05 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UhMGm-0003XR-4X for weirds@ietf.org; Tue, 28 May 2013 15:57:04 +0000 Received: from mail-oa0-f43.google.com ([209.85.219.43]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UhMGm-0004Cz-4G for weirds@ietf.org; Tue, 28 May 2013 15:57:04 +0000 Received: by mail-oa0-f43.google.com with SMTP id o6so10195336oag.16 for ; Tue, 28 May 2013 08:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=XOquxTG9MMZZdg+h4Frcv2P7Bq6FnmCnSsFVTBtefcw=; b=eaVuzTfYQpIOtZeLiiEEDXcoD4OOsuh5sKgFyXQMG3n+4MEdwaDbdNubZfhSFdR0Ff 0YLH5MuzP6yUJw4Tsxh4vuYHbIAufjx6oHNmio7Le7atEPxDcOMXNpBk4rYCxbrttvGs K9dala+wWU5Te/nT5/3YL5YHyS8vvNNVm049i8r9W06MtBI88otJkCoH1sscTqdgqLe7 TQrw9jdIoIv0QyphMz5Mj0XfKp+eQavYdltKi4va2L6F08JL7s36NqR4ssZm27vYsFJk ky8A46SVd6uU0kDyw+SBST1PXXSAdPCpQFk0jf3ojVTFK9dPM9kOo0qsGY9QVY9i3Tn7 rFCQ== X-Received: by 10.60.36.136 with SMTP id q8mr1821668oej.90.1369756618791; Tue, 28 May 2013 08:56:58 -0700 (PDT) X-Received: by 10.60.36.136 with SMTP id q8mr1821664oej.90.1369756618713; Tue, 28 May 2013 08:56:58 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id jt9sm35254556obc.0.2013.05.28.08.56.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 08:56:57 -0700 (PDT) Message-ID: <51A4D3C5.3010409@afilias.info> Date: Tue, 28 May 2013 11:56:53 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D24@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC09D24@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn9a3/AOZHXIkHhGRQ7U4MmthiGmfkgrE1rDnEuoCW+1TIyZYkYCCXonJAwqBlagw0/QJOcMxRn6JkW8M9YRkIuVXw3sAwNtWy0KOrPeh8FWEfmV+njOzpUjICiwBiTPWYhtspJ Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 28 May 2013 15:57:11 -0000 Some replies to comments below ... On 5/27/2013 6:43 PM, Andy Newton wrote: > Terrific work, Ernie! I have two comments inline... > > > On 5/27/13 12:14 PM, "Ernie Dainow" wrote: > >> DNS Security Extensions (DNSSEC) >> >> DNSSEC provides data integrity for DNS through digital signing of >> resource records. To enable DNSSEC, the zone is signed by one or more >> private keys and the signatures stored as RRSIG records. To complete the >> chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record >> (which contains the public key) must be loaded into the parent zone, >> stored as Delegation Signer (DS) records and signed by the parent's >> private key (RRSIG DS record), "Resource Records for the DNS Security >> Extensions" [RFC4034]. Creating the DS records in the parent zone can be >> done by the registration authority, "Domain Name System (DNS) Security >> Extensions Mapping for the Extensible Provisioning Protocol (EPP)" >> [RFC5910]. > That last sentence the reference to EPP is unnecessary and a little > misleading. Not all domains are maintained with EPP. For example, we put > DS records in the reverse but do not have an EPP interface. I think the reference is important for DNRs as it provides the rationale for the small subset of DNSSEC information that is provided by RDAP. The structures defined here match what is in RFC5910. Can you add a sentence and reference if appropriate for RIRs? >> * events -- see Section 5.5 > Why is it necessary to have a separate events structure for the DNSSEC > data. Isn't 'secDNS' suppose to be part of the domain object class? Each key may be added or changed at different times (Sec 5.2.5 in RFC5910), so events are shown as a sub element of each key. As elsewhere, event information is optional. A provider could decide that the Domain event information was sufficient and not report detailed timestamps for DNSSEC data. -Ernie From andy@arin.net Wed May 29 07:40: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 A2A8821F87FB for ; Wed, 29 May 2013 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUeSD+pC29Dd for ; Wed, 29 May 2013 07:40:53 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id BED3221F8556 for ; Wed, 29 May 2013 07:40:53 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 325DA165055; Wed, 29 May 2013 10:40:23 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id AF044165028; Wed, 29 May 2013 10:40:20 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 29 May 2013 10:40:08 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 29 May 2013 10:40:20 -0400 From: Andy Newton To: John R Levine , Ernie Dainow Thread-Topic: [weirds] help Thread-Index: AQHN/yVXgFevBTQie06p/bwbzsClcJhivVeAgADQSQCAAF5jgP//r9gAgABZOwD//66qgIBv+sCAgAEfGoCAA14pgP//5l2ABxtSh4AALmJvgAAre3iAADbKnAAAEvP4gACKCo0AAAH2xAAAU55DgA== Date: Wed, 29 May 2013 14:40:19 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A4E@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.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E241467DB7BBA42A3445C2193E82D11@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 14:40:59 -0000 On 5/27/13 2:46 PM, "John R Levine" wrote: >As I think I said, I agree that help text might be useful. But I still >don't see any reason to encode it in JSON, as opposed to a conventional >URL that returns a free form web page people can look at. John, Can we compromise here? Can we have a standard /help path that returns a JSON "notices" object that may also have links? Personally I think this will be seldom used, but it isn't harmful either. -andy From andy@arin.net Wed May 29 07:47: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 CEFD321F90EE for ; Wed, 29 May 2013 07:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKIwXzZAG7Ch for ; Wed, 29 May 2013 07:47:18 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B23B121F8899 for ; Wed, 29 May 2013 07:47:17 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 5FDC5213694; Wed, 29 May 2013 10:47:17 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id BDC7C213640; Wed, 29 May 2013 10:47:16 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 29 May 2013 10:47:04 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 29 May 2013 10:47:16 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] DNSSEC - proposed text Thread-Index: AQHOWvVLBq3yf/lRj0yWr15ktd4cwZkZoUCAgAFj1ICAATvOgA== Date: Wed, 29 May 2013 14:47:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A62@CHAXCH01.corp.arin.net> In-Reply-To: <51A4D3C5.3010409@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 14:47:24 -0000 On 5/28/13 11:56 AM, "Ernie Dainow" wrote: >>>Extensions" [RFC4034]. Creating the DS records in the parent zone can be >>> done by the registration authority, "Domain Name System (DNS) Security >>> Extensions Mapping for the Extensible Provisioning Protocol (EPP)" >>> [RFC5910]. >> That last sentence the reference to EPP is unnecessary and a little >> misleading. Not all domains are maintained with EPP. For example, we put >> DS records in the reverse but do not have an EPP interface. > >I think the reference is important for DNRs as it provides the rationale >for the small subset of DNSSEC information that is provided by RDAP. The >structures defined here match what is in RFC5910. Can you add a sentence >and reference if appropriate for RIRs? Ok. I think we're fine so long as this is an informative reference. > >>> * events -- see Section 5.5 >> Why is it necessary to have a separate events structure for the DNSSEC >> data. Isn't 'secDNS' suppose to be part of the domain object class? > >Each key may be added or changed at different times (Sec 5.2.5 in >RFC5910), so events are shown as a sub element of each key. As >elsewhere, event information is optional. A provider could decide that >the Domain event information was sufficient and not report detailed >timestamps for DNSSEC data. My concern is the consistency of the data model. We don't break out events for other sub structures, such as remarks or status. While the complexity is not great for the server implementation, it is more complex for a general purpose client. I happen to be writing a general purpose RDAP client and I don't see the utility in this but I do see the complexity in conveying the information. -andy From presnick@qti.qualcomm.com Wed May 29 08:04:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF5121F931B for ; Wed, 29 May 2013 08:04:30 -0700 (PDT) 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.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73pe7ZnAJxDW for ; Wed, 29 May 2013 08:04:24 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 508AB21F92FC for ; Wed, 29 May 2013 08:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369839864; x=1401375864; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=I6Z/xsFyUW6dCQVK74YWGwn5nn8yiDz56O8fBUhSxEc=; b=g0a7QescBNX90d6VvURS7/38ZR/uZkOTz50TP5z4HAFGAjJ4isUGEVba E1JLpGBLnEizK3q7tvPxjVl7gyV2IFT1T1BBZ8vKepPrrpjbQprxKTYCu rak2njhuj+xNLm+m0GTM6uFzVU6hLnWlhlga4p2DxUGsiscGdP/LbD+gA 4=; X-IronPort-AV: E=Sophos;i="4.87,764,1363158000"; d="scan'208";a="42312495" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 29 May 2013 08:04:23 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 May 2013 08:04:23 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 29 May 2013 08:04:22 -0700 Message-ID: <51A618F4.8020802@qti.qualcomm.com> Date: Wed, 29 May 2013 10:04:20 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 15:04:32 -0000 (Directly Cc'ing Olaf at his request.) Greetings all, Below is my AD Evaluation of -using-http-05. I have tried to do this review as "blind" as possible, coming to it as an implementer who has not seen the discussion in the WG. Hopefully I've made some useful catches. Might I suggest that the authors and/or Olaf do the initial responding before others pile on. If you have something to add after the authors get a chance to respond, that's fine. I just don't want the list (or my Inbox) to explode on something for which the authors can just pat me on the head and say, "No, Pete, you blew it." So, here's my review. Once we clear these issues up, I'll issue the IETF Last Call. ---- Section 3 says: Second, multiple response formats are supported by this protocol. At present the IETF Web Extensible Internet Data Service (WEIRDS) working group is defining only a JSON [RFC4627] response format, but server operators may use other data formats when those formats are requested. However, section 4.1 says: RDAP clients MUST include an Accept: header field specifying application/rdap+json, application/json, or both. Servers receiving an RDAP request MUST return an entity with Content-Type application/ rdap+json. Why are those two not contradictory? Section 5.1: it encodes the answer in the format most appropriate according to the standard and defined rules for processing the HTTP Accept header field, and return that answer in the body of a 200 response. The first part is a little convoluted. Does it simply mean, "it encodes the answer appropriately based on the HTTP Accept header field"? Also, grammatical nit: s/return/returns. Section 5.2: If a server wishes to inform a client that the answer to a given query can be found elsewhere, it MUST return a 301 response code to indicate a permanent move, or a 307 response code to indicate a non- permanent redirection, and include an HTTP(s) URL in the Location: header field. Is that MUST there for interoperability reasons? That is, is it plausible that a server might choose something other than 301 or 307 and this document is specifically limiting the server to only choose 301 or 307? The same question for including the URL in the Location header field. If it *is* a specific limitation, I suggest a minor rewording to make it clearer: If a server wishes to inform a client that the answer to a given query can be found elsewhere, it MUST return either a 301 response code to indicate a permanent move, or a 307 response code to indicate a non- permanent redirection, and it MUST include an HTTP(s) URL in the Location: header field. If it is not a limitation, but rather just a statement of what the server does, I suggest: If a server wishes to inform a client that the answer to a given query can be found elsewhere, it returns a 301 response code to indicate a permanent move, or a 307 response code to indicate a non- permanent redirection, and includes an HTTP(s) URL in the Location: header field. I have similar questions for the MUSTs in 5.3 and 5.4 and the SHOULD in 5.5. Section 6: I'd like to understand the exceptions that exist that justify SHOULD/SHOULD NOT instead of MUST/MUST NOT for the name syntax. The syntax itself allows a name of "X______". It also imposes no length limit. Is that OK? Section 8.2: Shouldn't this registration go in draft-ietf-weirds-json-response? Also, the reference to 6839 is Informative, not Normative, as far as I can tell. Section 9.1: I think the MAYs in there could turn out badly. Might I suggest instead: Clients can use IRIs [RFC3987] for internal use 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 again clients can transform these URIs to IRIs for internal use as they see fit. The MAYs seem to imply that there are places in the protocol where they MAY use IRIs, and AFAICT that's not true. Appendix B: s/MAY/can. You're not really specifying a protocol option here. Appendix C: A note in here for the RFC Editor to remove this section would be useful. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From johnl@taugh.com Wed May 29 08:39: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 D92A021F940D for ; Wed, 29 May 2013 08:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJZFrhJE9-HS for ; Wed, 29 May 2013 08:39:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E97AC21F8FE9 for ; Wed, 29 May 2013 08:39:48 -0700 (PDT) Received: (qmail 67866 invoked from network); 29 May 2013 15:39:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=10917.51a62149.k1305; bh=9ANRBKKoYOc2uOzH8M+u+5+mztSsOjZVonGMyTga6Lc=; b=IlhAqEwuMPp/s77mLYvSQEHEVJNezF+7fDvO5WK66s6ly6CgRLUSqV3mEN19w67PSr/2MxlFjJ0Idkp3g9U35sIuCU9fcM9ZiO6I7HfAixuva11+4OG2KzhbfRXRXPuOj6ZAWEV582MyehjSuTVfc4mth+IAv49/aphrk36YqMY= 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:user-agent:cleverness; s=10917.51a62149.k1305; bh=9ANRBKKoYOc2uOzH8M+u+5+mztSsOjZVonGMyTga6Lc=; b=H11kHWMXmf8lhqN+6EOyCE/SZADhbaUipexAtCABj7TA7eQ+ExQ5nKjSIpW1GubzCYTc4WJ8UNjZYrYv2TSlVbhrLwNGtkHqe+WzJeemfOSlFR2sAG53F29koyUW/7htXqRcogG2znofLJdfkMuaUHy/jMEVwOZ0oUqTyJnpXRU= Received: (ofmipd 127.0.0.1); 29 May 2013 15:39:31 -0000 Date: 29 May 2013 11:39:47 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A4E@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A4E@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-501585556-1369841987=:10045" Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 15:39:50 -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-501585556-1369841987=:10045 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >> As I think I said, I agree that help text might be useful. But I still >> don't see any reason to encode it in JSON, as opposed to a conventional >> URL that returns a free form web page people can look at. > > Can we compromise here? Can we have a standard /help path that returns a > JSON "notices" object that may also have links? I agree that a help path that nobody uses isn't likely to cause a lot of damage, but I'm getting the impression that Ernie and I have completely different models about what WEIRDS is for. In particular, I expect the fraction of WEIRDS lookups that have a human user nearby who might ask for the help link to be within rounding error of zero. The whole point (as I understand it) is to have a way to query for WHOIS data that works reliably for automated clients, so they don't have to do web page scraping, or try to pick bits out of free format port 43 queries. That's why I feel pretty strongly that if a query doesn't return JSON that the client can process, there's no point to having the query. Hence, BCP to have a help page nearby for users and developers good, help page that returns unusable JSON bad. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-501585556-1369841987=:10045 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI5MTUzOTQ3WjAjBgkqhkiG 9w0BCQQxFgQUcRG9Uo5VG99P+y5X7lB9D2zx5sUweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAb2dIzYF19g0A GIxsUwqdjGGsTVs73CPeWlmKqEsSQL1ioSgvJ2L9RctHRj4FpsTbc/DRqa9i qiFCAPIBeIrgVXlEt36+DaKyzaJPK7LYoJlQogPFWA8xSGAaU/0fVPRZoPMp /oqSNylNv0Df+dNE4YXT3td6tZoJhWu8YVrNKqU56QZ+7BmXpYc42QcBI774 3kVk7aygu8ZJrXylWPO+8jJtmz/oC51JyLxxRyRvhO5sU6iW9SHs2ICoWjif 3uEqpZ7MlHdUuJV81nFO9GeMgFHPo+1nCgckHdXwxVacVBBGf8u5HW0llaKJ PKWiwQj80M0ZhvsTDtwuTvzP3CRMgw== --3825401791-501585556-1369841987=:10045-- From presnick@qti.qualcomm.com Wed May 29 09:36: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 1F7C921F9552 for ; Wed, 29 May 2013 09:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsfSMfjAgsaG for ; Wed, 29 May 2013 09:36:14 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72421F9545 for ; Wed, 29 May 2013 09:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369845374; x=1401381374; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=45dArhSEVYOFTMm5ujnAW3sEHrCX+GR4C/Pps0J5yC4=; b=pRt9WOkMLu6P6U87GuveJlnFmT1sv4oC6Zss0v8w6W3E0oyrk0bWO8J6 ulAeaGfIS33RGtzCZLfcEMo1gHnO7tv76MIfYAHPRd3FkSBEM7fN/bpri Ze23TLRiD3fQx/7rvSf4vdNThxVUdMCyKKBlhtCuIv0lZdu/PPb5XtR5x s=; X-IronPort-AV: E=Sophos;i="4.87,765,1363158000"; d="scan'208";a="51755732" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 29 May 2013 09:36:13 -0700 X-IronPort-AV: E=Sophos;i="4.87,765,1363158000"; d="scan'208";a="481514981" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 May 2013 09:36:13 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 29 May 2013 09:36:12 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 29 May 2013 09:36:12 -0700 Message-ID: <51A62E7B.1020906@qti.qualcomm.com> Date: Wed, 29 May 2013 11:36:11 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 16:36:19 -0000 As with -using-http, please give the authors and/or Murray the chance to respond first: Overall, I'm not clear on why this wasn't folded in to the -using-http document, more or less as the security considerations section, but I have no objection to keeping them separate. Section 3.1: 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. Specifying that a protocol MUST do something (as against an implementation or an actor in the protocol) is...weird. Don't you really mean, "RDAP's authentication framework needs to accomodate..."? There are no specific protocol/implementation requirements here. Section 3.2: 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. The same as in 3.1. I suggest, "An RDAP server MUST provide granular access controls (that is, on a per registration data object basis) in order to implement authorization policies." RFCs 4732, 5280, and 6749 strike me as Informative, not Normative references. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From stpeter@stpeter.im Wed May 29 10:48:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076E21F9500 for ; Wed, 29 May 2013 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8NdlEjwXAgN for ; Wed, 29 May 2013 10:48:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0089221F9501 for ; Wed, 29 May 2013 10:48:08 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D4B404115C for ; Wed, 29 May 2013 12:00:57 -0600 (MDT) Message-ID: <51A63F57.7030009@stpeter.im> Date: Wed, 29 May 2013 11:48:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: weirds@ietf.org References: <46A1DF3F04371240B504290A071B4DB63D768680@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D768680@szxeml558-mbx.china.huawei.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <46A1DF3F04371240B504290A071B4DB63D768680@szxeml558-mbx.china.huawei.com> Content-Type: multipart/mixed; boundary="------------070905050007090702000603" Subject: [weirds] Fwd: [Jcardcal] WGLC on jCard specification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 17:48:14 -0000 This is a multi-part message in MIME format. --------------070905050007090702000603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI. Sorry that we neglected to forward this earlier. -------- Original Message -------- Subject: [Jcardcal] WGLC on jCard specification Date: Thu, 23 May 2013 05:58:35 +0000 From: Bert Greevenbosch To: jcardcal@ietf.org Dear all, This message initiates a Working Group Last Call on draft-ietf-jcardcal-jcard. Please send comments by the end of the day, Friday, June 7, 2013. The document can be found at . Best regards, Peter and Bert --------------070905050007090702000603 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ jcardcal mailing list jcardcal@ietf.org https://www.ietf.org/mailman/listinfo/jcardcal --------------070905050007090702000603-- From edainow@afilias.info Wed May 29 11:03: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 40C0621F8A6B for ; Wed, 29 May 2013 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY1qzqBmgd4T for ; Wed, 29 May 2013 11:02:58 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D153521F89EB for ; Wed, 29 May 2013 11:01:42 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UhkgY-0002E2-66 for weirds@ietf.org; Wed, 29 May 2013 18:01:18 +0000 Received: from mail-oa0-f50.google.com ([209.85.219.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UhkgY-0002sX-5q for weirds@ietf.org; Wed, 29 May 2013 18:01:18 +0000 Received: by mail-oa0-f50.google.com with SMTP id l20so11969845oag.37 for ; Wed, 29 May 2013 11:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=m+8jGncoNoEqLgacg89QdMSaZ+3lEhtkTuV6a3iBERw=; b=CSANkI6TkJ1E986avjqnixEFBHvuzWhTbUftmOrMMA+xQTUCs9KGc6uDTrWtIaCar5 9StfHPz/jB7XnY1Zm+BOvte/SqRZQNW4z2nNrtRB97X0uTWjpdtxFxcNDrNfC3VSwINE p4704wgem4vdaG59SZ+Ngi9O8baG2ZYmSxqOBfj8u/Gpi3n6hsWEnTlE+CMseJ9RmG1G +Yql1LdjysFwpiV8XqDKP+6P5GGewYiz4lZHGEMAFNVr/6JhbHUsqDeh/3dfRUOI0cTm o3dA41JzHs5h05nLCvNIo+MxAgV+Gr0L/FaQ3w2Mz9MdRVavsIQVMg6pR+BpW0vRhTbb rl5g== X-Received: by 10.60.17.231 with SMTP id r7mr2423944oed.13.1369850473349; Wed, 29 May 2013 11:01:13 -0700 (PDT) X-Received: by 10.60.17.231 with SMTP id r7mr2423939oed.13.1369850473245; Wed, 29 May 2013 11:01:13 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id z5sm41019039obw.4.2013.05.29.11.01.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 11:01:12 -0700 (PDT) Message-ID: <51A64262.6080905@afilias.info> Date: Wed, 29 May 2013 14:01:06 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A62@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A62@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlY3qkCwqyI7m8fZwR/Q4miyaSpLM7ny/xFNrEMZBswH0oYkrpuiAOc4f65nMfOHaS61omkJ0+iNv4RXCt+yxy81Or5EXHHsK53Jn57x829f6+ueljO5z4dNKqQ2kib6SWFic/F Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 18:03:04 -0000 On 5/29/2013 10:47 AM, Andy Newton wrote: > On 5/28/13 11:56 AM, "Ernie Dainow" wrote: > >>>> * events -- see Section 5.5 >>> Why is it necessary to have a separate events structure for the DNSSEC >>> data. Isn't 'secDNS' suppose to be part of the domain object class? >> Each key may be added or changed at different times (Sec 5.2.5 in >> RFC5910), so events are shown as a sub element of each key. As >> elsewhere, event information is optional. A provider could decide that >> the Domain event information was sufficient and not report detailed >> timestamps for DNSSEC data. > My concern is the consistency of the data model. We don't break out events > for other sub structures, such as remarks or status. > > While the complexity is not great for the server implementation, it is > more complex for a general purpose client. I happen to be writing a > general purpose RDAP client and I don't see the utility in this but I do > see the complexity in conveying the information. > I think the more important question is what is the value of this additional information to people using RDAP. I don't think timestamps of key creation are publicly available with other DNS tools. Would this be useful when investigating DNSSEC problems or discrepancies? Perhaps people with operational experience with DNSSEC could comment. We currently do report this information in Whois for some TLDs: $ whois pir.org ... DNSSEC:Signed DS Created 1:26-Mar-2010 16:52:50 UTC DS Key Tag 1:54135 Algorithm 1:5 Digest Type 1:1 Digest 1:225F055ACB65C8B60AD18B3640062E8C23A5FD89 DS Maximum Signature Life 1:1814400 seconds -Ernie From shollenbeck@verisign.com Wed May 29 11:09: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 7B7A221F95E7 for ; Wed, 29 May 2013 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DipdER3D00Tx for ; Wed, 29 May 2013 11:09:44 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9121F95E9 for ; Wed, 29 May 2013 11:09:42 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUaZEZhHcwVrWj4mE/0C6TGpVK15OqE72@postini.com; Wed, 29 May 2013 11:09:43 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r4TI9drR018039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 14:09:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 29 May 2013 14:09:38 -0400 From: "Hollenbeck, Scott" To: Pete Resnick , "weirds@ietf.org" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 Thread-Index: AQHOXIqoS2b5MIkv0UCoWcNg6C3lGJkcdUPg Date: Wed, 29 May 2013 18:09:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51A62E7B.1020906@qti.qualcomm.com> In-Reply-To: <51A62E7B.1020906@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 18:09:50 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Pete Resnick > Sent: Wednesday, May 29, 2013 12:36 PM > To: weirds@ietf.org > Subject: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 >=20 > As with -using-http, please give the authors and/or Murray the chance > to > respond first: >=20 > Overall, I'm not clear on why this wasn't folded in to the -using-http > document, more or less as the security considerations section, but I > have no objection to keeping them separate. >=20 > Section 3.1: >=20 > 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. >=20 > Specifying that a protocol MUST do something (as against an > implementation or an actor in the protocol) is...weird. Don't you > really > mean, "RDAP's authentication framework needs to accomodate..."? There > are no specific protocol/implementation requirements here. Yes, you're right. > Section 3.2: >=20 > 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. >=20 > The same as in 3.1. I suggest, "An RDAP server MUST provide granular > access controls (that is, on a per registration data object basis) in > order to implement authorization policies." Yes, agreed again. > RFCs 4732, 5280, and 6749 strike me as Informative, not Normative > references. Yes, yes, and yes. Assuming Ning and others agree, these are all easy chang= es. Scott From superuser@gmail.com Wed May 29 11:35: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 47DCD21F8899 for ; Wed, 29 May 2013 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SikeURb4cyD for ; Wed, 29 May 2013 11:35:33 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4F54121F826B for ; Wed, 29 May 2013 11:35:33 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so7021509wgg.16 for ; Wed, 29 May 2013 11:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P76W6eAxCCqPeEWevFu97E9IgyJGzhm+BUs7lvLnQaA=; b=p827pc71gLYg0aZc5RGdkWXdx2BxrRcav6K7BEqERnjvXdeus2W9di2y+5pP8oyKZb CYY4tUtN8EQVayi9eFrixJrKiSS6tJSKhfoT8RAK/mL7HnDXRHIJYKX98Ikr5oJsHjGg YKDAGEqwEHFdxKFYKPXDwu0m8oM8HivT4ShJRonFWbgdvrkuGUzCjw1KW4RQ2p+Dxo1Z YZB1CjdBTfSX2ZSCbVQyuBsRYGhsHqrO7ZLuTDhl5ungAWHrIaWyoP7wyjqjy7LQTrmx wYPJSdMZaOeJbJlDTYwNMzXuDg6/V+9V2X8ZmXdRGs+eAhiOBeXjjmGS/9BuSF38JUHy 37NQ== MIME-Version: 1.0 X-Received: by 10.180.206.180 with SMTP id lp20mr15824123wic.41.1369852532460; Wed, 29 May 2013 11:35:32 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 29 May 2013 11:35:32 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51A62E7B.1020906@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 29 May 2013 11:35:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c380b097933204dddfa519 Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 18:35:34 -0000 --001a11c380b097933204dddfa519 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 11:09 AM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > > Overall, I'm not clear on why this wasn't folded in to the -using-http > > document, more or less as the security considerations section, but I > > have no objection to keeping them separate. > > My own view: If one were to remove all of the HTTP specific stuff from this draft (which is actually not all that much), it remains a security considerations and requirements guide for providing RDAP service, ostensibly over some other transport. All of the remaining text would still be pertinent. To that end, I like that they're separate. That's not a particularly strong opinion though. If the WG would like to merge them, I'd be fine with that. -MSK --001a11c380b097933204dddfa519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 11:09 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> Overall, I'm not = clear on why this wasn't folded in to the -using-http
> document, more or less as the security considerations section, but I > have no objection to keeping them separate.


My own view:

I= f one were to remove all of the HTTP specific stuff from this draft (which = is actually not all that much), it remains a security considerations and re= quirements guide for providing RDAP service, ostensibly over some other tra= nsport.=A0 All of the remaining text would still be pertinent.=A0 To that e= nd, I like that they're separate.

That's not a particularly strong opinion though.=A0 If t= he WG would like to merge them, I'd be fine with that.

-MSK
<= /div>
--001a11c380b097933204dddfa519-- From shollenbeck@verisign.com Wed May 29 12:58: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 43D7721F8FD0 for ; Wed, 29 May 2013 12:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkMsJGuwJL1F for ; Wed, 29 May 2013 12:58:45 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66821F909A for ; Wed, 29 May 2013 12:58:39 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUaZd7qWrkOyMkt3KCQZyDSpvIBQO0W2W@postini.com; Wed, 29 May 2013 12:58:40 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4TJwZJ5012663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 15:58:35 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 29 May 2013 15:58:35 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 Thread-Index: AQHOXJtMS2b5MIkv0UCoWcNg6C3lGJkclDnA Date: Wed, 29 May 2013 19:58:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2439D99D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51A62E7B.1020906@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F2439D99DBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 19:58:53 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2439D99DBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tend to think of the security document as being applicable to more than j= ust the http document, but as you say I don't have a strong opinion on stan= dalone vs. integrated. The text just needs to exist somewhere. Scott From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Wednesday, May 29, 2013 2:36 PM To: Hollenbeck, Scott Cc: Pete Resnick; weirds@ietf.org Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 On Wed, May 29, 2013 at 11:09 AM, Hollenbeck, Scott > wrote: > Overall, I'm not clear on why this wasn't folded in to the -using-http > document, more or less as the security considerations section, but I > have no objection to keeping them separate. My own view: If one were to remove all of the HTTP specific stuff from this draft (which= is actually not all that much), it remains a security considerations and r= equirements guide for providing RDAP service, ostensibly over some other tr= ansport. All of the remaining text would still be pertinent. To that end,= I like that they're separate. That's not a particularly strong opinion though. If the WG would like to m= erge them, I'd be fine with that. -MSK --_000_831693C2CDA2E849A7D7A712B24E257F2439D99DBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I tend to think of the security document a= s being applicable to more than just the http document, but as you say I do= n’t have a strong opinion on standalone vs. integrated. The text just needs to exist somewhere.

 

Scott

 

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Wednesday, May 29, 2013 2:36 PM
To: Hollenbeck, Scott
Cc: Pete Resnick; weirds@ietf.org
Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03=

 

On Wed, May 29, 2013 at 11:09 AM, Hollenbeck, Scott = <shollenbe= ck@verisign.com> wrote:

> Overall, I'm not= clear on why this wasn't folded in to the -using-http
> document, more or less as the security considerations section, but I > have no objection to keeping them separate.

 

My own view:

If one were to remove= all of the HTTP specific stuff from this draft (which is actually not all = that much), it remains a security considerations and requirements guide for= providing RDAP service, ostensibly over some other transport.  All of the remaining text would still be = pertinent.  To that end, I like that they're separate.

That's not a particularly strong opinion though.&nbs= p; If the WG would like to merge them, I'd be fine with that.

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F2439D99DBRN1WNEXMBX01vc_-- From edainow@afilias.info Wed May 29 13:37:56 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9B221F9761 for ; Wed, 29 May 2013 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY2CKfHBC1P1 for ; Wed, 29 May 2013 13:37:29 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDA621F962A for ; Wed, 29 May 2013 13:37:27 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Uhn7f-0003v4-3N for weirds@ietf.org; Wed, 29 May 2013 20:37:27 +0000 Received: from mail-ob0-f173.google.com ([209.85.214.173]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Uhn7e-0004jD-6C for weirds@ietf.org; Wed, 29 May 2013 20:37:26 +0000 Received: by mail-ob0-f173.google.com with SMTP id wc20so3485541obb.32 for ; Wed, 29 May 2013 13:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=EHewYZdrJ+Iwss+Hd9+RekxGxe5KAIku4L0amYAf2T4=; b=cGgcbumr9eIR6dhozeBgO1v7p8nU8lx/VwKPp6fzEzhFmKPmc8rYx5YY54c60Pfe/i G+7ijX9JQtS8PYJRKFbvTWBeIDPQ0gBu21DrfEj8N+7/ydrlWfnb1X6hxMkNX4qnnbRN WN2HMISVCoiHb2xbZUfc1DVZQfwLFL0jsNSgKnKl/C26akXnTq2dNNPAU0qMGXxmZwUN NZf1PDySTxjEma1+pQGFoEUndYuHcYhpwRGxevE/36etsen7lnKCohiz8ggmYMBQuoTA dAURt8x38BFi4cGNbDZiKsRMtADui2pSuqAXLCMT0UltHe9h5JBKuCCQPWpMTUlzcG7g uh4g== X-Received: by 10.60.134.71 with SMTP id pi7mr2683364oeb.107.1369859841404; Wed, 29 May 2013 13:37:21 -0700 (PDT) X-Received: by 10.60.134.71 with SMTP id pi7mr2683358oeb.107.1369859841332; Wed, 29 May 2013 13:37:21 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id p3sm34322862oel.0.2013.05.29.13.37.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 13:37:20 -0700 (PDT) Message-ID: <51A666FA.1060009@afilias.info> Date: Wed, 29 May 2013 16:37:14 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John R Levine References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A4E@CHAXCH01.corp.arin.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkShW3FbITAXZpd7oYlrn3LUhxD62YYRAYkn5U5mOzXFBUyqfAkHBNhCFNLCr6rHKzw75MlvrnQ8wiGzCw2aeGYUeYWfIiLB2ucnSaek8kDMgBSsZ5WhTUZhshzxGn995U00xCI Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 20:37:56 -0000 On 5/29/2013 11:39 AM, John R Levine wrote: >> >>> As I think I said, I agree that help text might be useful. But I still >>> don't see any reason to encode it in JSON, as opposed to a conventional >>> URL that returns a free form web page people can look at. >> >> Can we compromise here? Can we have a standard /help path that returns a >> JSON "notices" object that may also have links? > > I agree that a help path that nobody uses isn't likely to cause a lot > of damage, but I'm getting the impression that Ernie and I have > completely different models about what WEIRDS is for. In particular, > I expect the fraction of WEIRDS lookups that have a human user nearby > who might ask for the help link to be within rounding error of zero. > > The whole point (as I understand it) is to have a way to query for > WHOIS data that works reliably for automated clients, so they don't > have to do web page scraping, or try to pick bits out of free format > port 43 queries. That's why I feel pretty strongly that if a query > doesn't return JSON that the client can process, there's no point to > having the query. > > Hence, BCP to have a help page nearby for users and developers good, > help page that returns unusable JSON bad. > I don't think there is a difference in understanding of what WIERDS is for. But some people seem to expect that implementations will all just work automagically and there will be no inter-operable problems. I have yet to see software or a standard that has achieved these goals. When failures occur, help information is one place to start to investigate the problem. I don't care if help information is in a BCP or in RDAP, as long as it is easily and universally available. We should try to avoid the current state of Whois, where it is really difficult to find help. It took me months to discover how to do wildcard searches and on which domains it was supported. It seems that the easiest way to provide standard access to help information is via a defined RDAP query. If returning a link in JSON to a help query is bad, then why do we have links throughout the other structures? A BCP that simply recommends a help page is insufficient unless it defines a common way that people can locate that page. If someone can draft a BCP that makes it clear how end users and developers will get information from all servers, that meets the goal. -Ernie From johnl@taugh.com Wed May 29 13:53: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 73A3421F961C for ; Wed, 29 May 2013 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMxO5m9cC50w for ; Wed, 29 May 2013 13:53:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7011821F93FB for ; Wed, 29 May 2013 13:53:40 -0700 (PDT) Received: (qmail 56335 invoked from network); 29 May 2013 20:53:42 -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:user-agent:cleverness; s=dc0e.51a66ad6.k1305; bh=MnBrU1pRdt6OtwuCSbwFg+cV00X/jHNnPK/jvK/MEJw=; b=JBCW36F5SWhTyjI4MBEO+jPboCp6oUlX6aCvkF2HQrujWE4mQoFfMGDBGTShe9u0gdq6onDvK5D+6JeU2Pp7vMJNuwcaPKVlC+9SilKmL6v3AEIKDH8GVRs4It14QSmQezqJmdNq69ZNIy/t+4AzzoYYK6J8zawDYw5e/kDDtFw= 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:user-agent:cleverness; s=dc0e.51a66ad6.k1305; bh=MnBrU1pRdt6OtwuCSbwFg+cV00X/jHNnPK/jvK/MEJw=; b=R9tRguH51ufQZX4wwwieneo/6J7LDAerROn3sVZgJZeTwkiOhyC9rDfPpPO6LSOpglWT5FzInjUcuDRmURN+focKNuIJGaqGU4RhRf7kntLjZKZ4RYx1grn2AKDl4G4XE5UIXBqfMYPx2gPxPfGNudfRNVpFIxOJ8N+vjaGbxPs= Received: (ofmipd 127.0.0.1); 29 May 2013 20:53:20 -0000 Date: 29 May 2013 16:53:36 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51A666FA.1060009@afilias.info> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD2A4E@CHAXCH01.corp.arin.net> <51A666FA.1060009@afilias.info> 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-561158424-1369860816=:10193" Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 29 May 2013 20:53:55 -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-561158424-1369860816=:10193 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > I don't think there is a difference in understanding of what WIERDS is for. > But some people seem to expect that implementations will all just work > automagically and there will be no inter-operable problems. I have yet to see > software or a standard that has achieved these goals. When failures occur, > help information is one place to start to investigate the problem. No disagreement there. > It seems that the easiest way to provide standard access to help information > is via a defined RDAP query. If returning a link in JSON to a help query is > bad, then why do we have links throughout the other structures? Because, for the umpteenth time, the other fields have defined semantics beyond "someone might want to look at this." > A BCP that simply recommends a help page is insufficient unless it defines a > common way that people can locate that page. If someone can draft a BCP that > makes it clear how end users and developers will get information from all > servers, that meets the goal. How about http:///help where the hostname is the one for the RDAP server. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-561158424-1369860816=:10193 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTI5MjA1MzM2WjAjBgkqhkiG 9w0BCQQxFgQUbLwQj7MFF4vzSYdP7YMT2MTw9VIweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAjoaSc2+4lJ9i o+hJd0OkDm9ij5KdCt8gwdAwbEH0uLNBGT1wFF02SpCG6hNjwPBDsxAz0yGh udAKntItpWMXTY1OrHC7mjU/83Fflk4FyZzaXQdyOP5x1k/leDWkTXDjjfUs mT2sRoLfRaRfrIj5ORePhvmnHWzif8jzmO3xMGRFU/f92tn06eCritkr+Klk LwGejzeZUsZZojJV9xWuq+lJz+YVbzij4VwB2Kg3NFE6lqAgkxZMy6Y2eAg/ dAjkvqM2vRHMti9q6peKQPt50BRw8Ebp6FPvtwGU98r8izSLEHCQgM65V0aa hiCowDEfzj+RKdS+uc2ic51PYitfLQ== --3825401791-561158424-1369860816=:10193-- From nkong@cnnic.cn Wed May 29 19:50: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 5E5E521F93A6 for ; Wed, 29 May 2013 19:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up2B-Ls7gETB for ; Wed, 29 May 2013 19:50:00 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id D53B621F92EC for ; Wed, 29 May 2013 19:49:59 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [192.168.1.76]) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 30 May 2013 10:49:52 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 29 May 2013 22:49:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8BCC02-E579-4443-A560-7B2C8FB7094A@cnnic.cn> References: <51A62E7B.1020906@qti.qualcomm.com> <831693C2CDA2E849A7D7A712B24E257F2439D8E3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1503) Cc: Pete Resnick , "weirds@ietf.org" Subject: Re: [weirds] AD Evaluation of draft-ietf-weirds-rdap-sec-03 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 02:50:05 -0000 > Yes, yes, and yes. Assuming Ning and others agree, these are all easy = changes. +1, +1 and +1. Ning From andy@arin.net Thu May 30 04:06: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 1767F21F8EEA for ; Thu, 30 May 2013 04:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfrddZKr8Nwx for ; Thu, 30 May 2013 04:06:01 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 2695C21F8EC2 for ; Thu, 30 May 2013 04:06:00 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A2BE816503E; Thu, 30 May 2013 07:06:00 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 2EAE0165035; Thu, 30 May 2013 07:06:00 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 30 May 2013 07:05:39 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 30 May 2013 07:05:54 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] DNSSEC - proposed text Thread-Index: AQHOWvVLBq3yf/lRj0yWr15ktd4cwZkZoUCAgAFj1ICAATvOgIAAeTwAgADbQAA= Date: Thu, 30 May 2013 11:05:53 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DAC@CHAXCH01.corp.arin.net> In-Reply-To: <51A64262.6080905@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C82B978EBB2944EA14934856FAB9D52@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 11:06:06 -0000 On 5/29/13 2:01 PM, "Ernie Dainow" wrote: >We currently do report this information in Whois for some TLDs: >$ whois pir.org >... >DNSSEC:Signed >DS Created 1:26-Mar-2010 16:52:50 UTC >DS Key Tag 1:54135 >Algorithm 1:5 >Digest Type 1:1 >Digest 1:225F055ACB65C8B60AD18B3640062E8C23A5FD89 >DS Maximum Signature Life 1:1814400 seconds This trumps my argument about a pretty data model. :) -andy From andy@arin.net Thu May 30 04:10:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02DF21F8FD0 for ; Thu, 30 May 2013 04:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LDZm42uc+Cn for ; Thu, 30 May 2013 04:10:20 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id AAFD321F8FA9 for ; Thu, 30 May 2013 04:10:19 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 40A83165275; Thu, 30 May 2013 07:09:49 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 79EED16525F; Thu, 30 May 2013 07:09:48 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 30 May 2013 07:09:24 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 30 May 2013 07:09:41 -0400 From: Andy Newton To: John R Levine , Ernie Dainow Thread-Topic: [weirds] help Thread-Index: AQHN/yVXgFevBTQie06p/bwbzsClcJhivVeAgADQSQCAAF5jgP//r9gAgABZOwD//66qgIBv+sCAgAEfGoCAA14pgP//5l2ABxtSh4AALmJvgAAre3iAADbKnAAAEvP4gACKCo0AAAH2xAAAU55DgAAKdb2AAApjaQAAAJJVAAAVhDaA Date: Thu, 30 May 2013 11:09:40 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@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.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <29D0EF33E4F6A74F815F18B835FA0619@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 11:10:29 -0000 On 5/29/13 4:53 PM, "John R Levine" wrote: >>A BCP that simply recommends a help page is insufficient unless it >>defines a=20 >> common way that people can locate that page. If someone can draft a BCP >>that=20 >> makes it clear how end users and developers will get information from >>all=20 >> servers, that meets the goal. > >How about http:///help where the hostname is the one for the >RDAP server. Isn't this exactly the interaction we've already defined? If you ask for HTML content at /help you may get HTML content. If you ask for RDAP content at /help you should get RDAP content. I think you two are in agreement. -andy From edainow@afilias.info Thu May 30 08:29: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 946B221F92E8 for ; Thu, 30 May 2013 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY-xWtQhezYp for ; Thu, 30 May 2013 08:28:56 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5059321F8B45 for ; Thu, 30 May 2013 08:28:56 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ui4mb-0002rc-50 for weirds@ietf.org; Thu, 30 May 2013 15:28:53 +0000 Received: from mail-ob0-f175.google.com ([209.85.214.175]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ui4mb-0005h7-4h for weirds@ietf.org; Thu, 30 May 2013 15:28:53 +0000 Received: by mail-ob0-f175.google.com with SMTP id xn12so849031obc.20 for ; Thu, 30 May 2013 08:28:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=lUf6Di+d/e2m+1X5DOCgcL10sI/tUOtLmqr1M/vI5A4=; b=JEF/oaFPc/vSQ0P1WFCWSRpWHn2F7bu7VT+Id+v9NFF6bVWlpKXln6esB8O7xFtrjx M1c4hpSEsWIIwtIJMhcvpBixluPQykXdq/0raP20LJBnDN9ddjMEobag7CAdGIGktV3d 32Uh125//7/iKxVkFKTVVaHTczFmpCVKYqIXUn3WAcSU1IvgIkK889cOLElvagA1ksMZ AMxxStroxYBbAKo3jdrHMaFA2Hxmb4XDS/g9OV56BGYPLiPbqxaEV7N2Q+VFuJsLeCU8 j3VkFz0oBvYJyj1B3PACrIH3jBNCHfyIAyBaD6ETPjhqFh3cTS84g8+0hImYv2ROlIyY pfpA== X-Received: by 10.60.93.34 with SMTP id cr2mr637491oeb.127.1369927727943; Thu, 30 May 2013 08:28:47 -0700 (PDT) X-Received: by 10.60.93.34 with SMTP id cr2mr637484oeb.127.1369927727831; Thu, 30 May 2013 08:28:47 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id lz18sm3104229oeb.7.2013.05.30.08.28.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 08:28:46 -0700 (PDT) Message-ID: <51A77029.6050603@afilias.info> Date: Thu, 30 May 2013 11:28:41 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmllfBI/m7LGOl7Bpp/w7ls6mCFacDzn7xN9OOv4Bv3g8vvC3oj9egDBc6szDvvGNlZ3xc1+d1tXpdOm0BGn0uXU9pO2KqsttOco8VS7jszop2WKnqnJJdC0uSmS2pQ1OtM3fV0 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 15:29:03 -0000 On 5/30/2013 7:09 AM, Andy Newton wrote: > On 5/29/13 4:53 PM, "John R Levine" wrote: >>> A BCP that simply recommends a help page is insufficient unless it >>> defines a >>> common way that people can locate that page. If someone can draft a BCP >>> that >>> makes it clear how end users and developers will get information from >>> all >>> servers, that meets the goal. >> How about http:///help where the hostname is the one for the >> RDAP server. > Isn't this exactly the interaction we've already defined? If you ask for > HTML content at /help you may get HTML content. If you ask for RDAP > content at /help you should get RDAP content. > > I think you two are in agreement. > > Sounds good to me. Do we really need a separate BCP document for this? Are there are other topics that might make it worth adding a new document? A section on error handling could be useful. There was some discussion about distinguishing between the different causes of HTTP 404 by adding information in an RDAP Error Response Body. But it might be better just to have these examples in the response doc. -Ernie From johnl@taugh.com Thu May 30 08:41:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2AC21F95E5 for ; Thu, 30 May 2013 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp+DmhzhKXc3 for ; Thu, 30 May 2013 08:41:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78621F937A for ; Thu, 30 May 2013 08:40:55 -0700 (PDT) Received: (qmail 18281 invoked from network); 30 May 2013 15:40:54 -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:user-agent:cleverness; s=4768.51a77306.k1305; bh=4CAMQgp9dbGkEf/C2JB4DpNpXBDEcLwji1JdWHy6/2U=; b=PhoApAbBoUoqKA79fHPZJBzqV0x/5aGukGd1p9HRcGq2FFfoJKIczQMPZwiCWH59+YZFfJC712UNw4coXq62IyezPfjw1b98RZ6IblaGQxL904tLnlGaiBOS2js72UkuDvjdFwg4IZi9S2LPbP9Z8ZZVTmnbssKXX8qk5xERBnE= 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:user-agent:cleverness; s=4768.51a77306.k1305; bh=4CAMQgp9dbGkEf/C2JB4DpNpXBDEcLwji1JdWHy6/2U=; b=ZP1/ohpQXM4hp+uFhSVjoHdFvIQPrM72RBftlqYYT8S3GaEWSRHlKT37TEF4l4QE6F48SeOj7YVdnZqFL9HBCGzE1wASMxG7NgQCbG51L3oZkWVpi3RzbHXF4NUODHHb3wlaGdTG3zPsPNjrOG+qk9Q/KfBdhdA6nwX0oZMQ2Zg= Received: (ofmipd 127.0.0.1); 30 May 2013 15:40:32 -0000 Date: 30 May 2013 11:40:48 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51A77029.6050603@afilias.info> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> <51A77029.6050603@afilias.info> 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-1906022565-1369928448=:2349" Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 15:41:03 -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-1906022565-1369928448=:2349 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Sounds good to me. Just out of perverse curiosity, could you give an example of the JSON that a /help would return, and what the client would do with it? You can assume the client is not running in a browser, or a console window, or anything else with a person watching. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1906022565-1369928448=:2349 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTU0MDQ4WjAjBgkqhkiG 9w0BCQQxFgQUxZmfjl3DRyxTohryBULHUQOAnqEweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAPh/iQNpkCipP 79vq7mHMV4qEZnv4AcuOsf9+BGNdbyqKmiJWUJD1fgBUmeNbWt1NJ8lLxUZZ xQgFYyGKjFqFnZ/lEEhCWAOD55YQhL5YYbeRVrnIe/g8EZEHOYnGy3j3Gq6Q /6h7TtmCJB2ZeOfIyhgBb9fdqDdLq1/+L9rSc8E9PHETeLuJhrK/FeP+AE8H SloT8jSVLCAhi0B5Qy6Cq6XEYyqkR5azqwphv3s/KPmJr2N7yoa2W5NqfPuD N+PggBKVEKeim+tQzD4WPFrlziangG1Wu8sTBnRZJY1PAetFubLCW2oRpMwJ 2JDhT9Uyt4KUb6lRj1hZeQCakodEGQ== --3825401791-1906022565-1369928448=:2349-- From edainow@afilias.info Thu May 30 10:03: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 23FC221F8FEC for ; Thu, 30 May 2013 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Maj7fhpFsHtX for ; Thu, 30 May 2013 10:03:13 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9B21F8733 for ; Thu, 30 May 2013 10:03:12 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ui6Fs-0006yc-4K for weirds@ietf.org; Thu, 30 May 2013 17:03:12 +0000 Received: from mail-ob0-f172.google.com ([209.85.214.172]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ui6Fs-0003aW-40 for weirds@ietf.org; Thu, 30 May 2013 17:03:12 +0000 Received: by mail-ob0-f172.google.com with SMTP id wo10so1097798obc.17 for ; Thu, 30 May 2013 10:03:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=rTjclrFC7fxrt1esK8fP8lnCGsRuCvslQ6sPwbNigG0=; b=EBsCNV3++ZX96qgB3/5G6wf4czoVkbQjf57mkl3xop9rNHfD1tRKquS9TGQIjazBec EY/9/TQ3vQbCt9GV9pKPB2U4KF1PIj3ko5UZoC8WURFIfPZTaYUWS7umOaXS6T7KCdLd 3YYlKj9vGa5dPVbjHLtwPn4fkoX50fXkZt6LY6LIBfLbcmCUzkivkG4nQIL8JLxKQSDG +58jl25+NzYYs9nbWqLOH9+jcpkevh6MCIHKovhxXZsQiCsCTC5DYByXrNuwsSyxJhW5 wTAuhAyjyxn/YaAHKEwn3VUZzx5rV31GQF9bPzAqpBoiDNE4YBniQE6ipErJXgeYLKWx M8LA== X-Received: by 10.60.133.240 with SMTP id pf16mr4565728oeb.28.1369933386753; Thu, 30 May 2013 10:03:06 -0700 (PDT) X-Received: by 10.60.133.240 with SMTP id pf16mr4565726oeb.28.1369933386668; Thu, 30 May 2013 10:03:06 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id hv3sm43117188obb.7.2013.05.30.10.03.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 10:03:05 -0700 (PDT) Message-ID: <51A78644.1090006@afilias.info> Date: Thu, 30 May 2013 13:03:00 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John R Levine References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> <51A77029.6050603@afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmTrjhvOyrf7Ep+fhf2cmyph3IupmOkt8JakktOG0EjYx02a+cF3f739bgnC8/c1fvj2BeYqJDIr1EHRr5sUpC/PFm+TxQXRvO+0hKSRqhGVQ9FcRm8hp2tXyobeV6KDTJrNJOF Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 17:03:19 -0000 On 5/30/2013 11:40 AM, John R Levine wrote: >> Sounds good to me. > > Just out of perverse curiosity, could you give an example of the JSON > that a /help would return, and what the client would do with it? > > You can assume the client is not running in a browser, or a console > window, or anything else with a person watching. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. Here's an example that contains a link to an html help page. An alternative is a remarks array that contains the help text. "links": [ { "href": "http://...", "rel": "help", "value": "http://..." }, { "href": "http://example.com/help", "rel": "self", "value": "http://example.com/help" } ], "notices": [ { "description": [ "Access is provided to ... " ], "title": "TERMS OF USE" } ], "rdapConformance": [ "rdap_level_0" ] An automated client won't get this unless it makes a specific request for it. It can be useful to an automated client to verify the release level of the server software before continuing. Many APIs have a simple version request for this purpose. A client implementing a web RDAP display for end users could use this if the user requested help. If it is smart enough and the user encounters an authentication failure, it could pop up the help page, since one of the things the help should provide is information about authentication credentials. A developer would copy/paste the help link into a browser to get information like release notes, test objects, access to technical support. -Ernie From andy@arin.net Thu May 30 11:15: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 7240921F8F44 for ; Thu, 30 May 2013 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fABRelc36TFq for ; Thu, 30 May 2013 11:15:21 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 38D7321F8F43 for ; Thu, 30 May 2013 11:15:21 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id CE7192135F5; Thu, 30 May 2013 14:15:16 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 12B18213698 for ; Thu, 30 May 2013 14:14:38 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 30 May 2013 14:14:16 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 30 May 2013 14:14:32 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: NicInfo - an open source RDAP client Thread-Index: AQHOXWGIs+4MxQHSYUqe8AePNeWa1w== Date: Thu, 30 May 2013 18:14:31 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5782@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <24E4BACBCE3AD049B17EF528A7628243@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] NicInfo - an open source RDAP client X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 18:15:25 -0000 All, ARIN is making available NicInfo, an open source, general purpose RDAP client. You can find more information here: http://projects.arin.net/nicinfo/index.html Features include caching, bootstrapping, jCard support, and structural presentation of data. It is written in Ruby and should work on any platform that supports that language. -andy From johnl@taugh.com Thu May 30 11:47: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 28EA921F91B2 for ; Thu, 30 May 2013 11:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE2mKe8AR3rL for ; Thu, 30 May 2013 11:47:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EBF1B21F9193 for ; Thu, 30 May 2013 11:47:55 -0700 (PDT) Received: (qmail 83703 invoked from network); 30 May 2013 18:47:57 -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:user-agent:cleverness; s=146f6.51a79edd.k1305; bh=8KYA0Gc1x2c6FE7qwJqfKcoFUMh4g4DEU4qVH/kqlM8=; b=PtSz83b6C4BGngwhkOygMx7njNruIx8eaqHHH8ncvDpKhmOjESP7bik0s3LD/mAJpFq9CNF/niLbiVgKx1r2zXmjCxRFJcKK8DEjqeo7EtABxISWkqPBmohHRtB00VaIMqBwg/WOhZyCdWUkSeBDFRndBeaha4ep+k3NioXdlLI= 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:user-agent:cleverness; s=146f6.51a79edd.k1305; bh=8KYA0Gc1x2c6FE7qwJqfKcoFUMh4g4DEU4qVH/kqlM8=; b=ZwVfFWX9q4Eya2PL87fPgX7YhsadUfTxgx25SvQObiALGw3Mj3uPTxu7t1/He2bj7G01zBus9y4wxU7XKxbs2yKRObDXuR8KwK4fj+zm6Pawkjx/L5CBMI9Q5A114Q86MLMZ+Y0Qtvw8fd7UxtblPQi2QxXk0vrksKCW4QvcEKk= Received: (ofmipd 127.0.0.1); 30 May 2013 18:47:35 -0000 Date: 30 May 2013 14:47:51 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: <51A78644.1090006@afilias.info> References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> <51A77029.6050603@afilias.info> <51A78644.1090006@afilias.info> 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-652739173-1369939671=:2349" Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 18:47:57 -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-652739173-1369939671=:2349 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Other than the version number, which I think we have handled somewhere else, it strikes me as an overcomplex way for someone to look at a well known URL, but it's not worth further argument. The notices thing is an actively bad idea. I can tell you from years of people trying to put no-spam notices in SMTP banners that notices presented to other computers are meaningless. R's, John On Thu, 30 May 2013, Ernie Dainow wrote: > > On 5/30/2013 11:40 AM, John R Levine wrote: >>> Sounds good to me. >> >> Just out of perverse curiosity, could you give an example of the JSON that >> a /help would return, and what the client would do with it? >> >> You can assume the client is not running in a browser, or a console window, >> or anything else with a person watching. >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> "I dropped the toothpaste", said Tom, crestfallenly. > > Here's an example that contains a link to an html help page. An alternative > is a remarks array that contains the help text. > > "links": [ > { > "href": "http://...", > "rel": "help", > "value": "http://..." > }, > { > "href": "http://example.com/help", > "rel": "self", > "value": "http://example.com/help" > } > ], > "notices": [ > { > "description": [ > "Access is provided to ... " > ], > "title": "TERMS OF USE" > } > ], > "rdapConformance": [ > "rdap_level_0" > ] > > An automated client won't get this unless it makes a specific request for it. > It can be useful to an automated client to verify the release level of the > server software before continuing. Many APIs have a simple version request > for this purpose. > > A client implementing a web RDAP display for end users could use this if the > user requested help. If it is smart enough and the user encounters an > authentication failure, it could pop up the help page, since one of the > things the help should provide is information about authentication > credentials. > > A developer would copy/paste the help link into a browser to get information > like release notes, test objects, access to technical support. > > -Ernie > > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-652739173-1369939671=:2349 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTMwMTg0NzUxWjAjBgkqhkiG 9w0BCQQxFgQUm/cFl109L/5bl9r5xwRuMjiqb5oweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAPUzaWrDoewOI 2hTtQQHEgDRuJEuQlxvAm4N2FrqZ8/TXY5Mv9QVw9XsrOxne/s4WHgGGkX0t IAFrOLvONiJtWmmLE0eHzGfcNZ0n4fAV1v44Hc8DxdW7t+vgxfovWvhIk8Yz 5vB5ARJwxUqA1g05TSG9P/Dn8ajamBOgXQo5fu8vOn4dfijnNs41Zp88Fdwz gswW3IuYeF8Me3iqOsvqeKT9tujgiwVEOQYoAIyDAMRREVXqvUD6NNo5yoC/ XT7BBMD6BxX99U6yo3f/+bOGbQjSUL9+kk40Puo8wdZS2xlbmeozzminvSs3 55bDapxcSEvQeJELEjnRa6qopnXBDA== --3825401791-652739173-1369939671=:2349-- From edainow@afilias.info Thu May 30 12:52:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2898021F91CE for ; Thu, 30 May 2013 12:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 004H4X8-BE8G for ; Thu, 30 May 2013 12:52:31 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 43FB821F87BB for ; Thu, 30 May 2013 12:52:31 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ui8ti-0003PY-5Y for weirds@ietf.org; Thu, 30 May 2013 19:52:30 +0000 Received: from mail-ob0-f175.google.com ([209.85.214.175]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ui8ti-00062i-5G for weirds@ietf.org; Thu, 30 May 2013 19:52:30 +0000 Received: by mail-ob0-f175.google.com with SMTP id xn12so1468191obc.34 for ; Thu, 30 May 2013 12:52:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Lc/xxULi4B+MZ5+p8IcsqwKxsdSDNl2NMSeqiS7BsvQ=; b=G11EC14ANvhO2mv5uYFcOZCVr06z+Gkfwb85OfOBNvo6vfVqEfCBnRTLG6W+wvYCln /sdvTvn58edFWmRPRoJQ5PlswtHk5lIYapG60zbxZ1pBu9J2Scu6+mK9k/7plBF3zj/1 rkFdSOnzZb9UY4c8p3Z2QuuBLk7JzQVbAqCcthl6MV69duCObnlTYpHmBzWNjZqANZy7 rqJooEvQcVJog9JV6RjmrHLafHmGnoY87E1HVM5xdVZV0/SlyOD/AExAHQ9CxLrCNlde XoyY91iXKSesUnlVDUOjAiS15vqI6YMqthG3/R/5o8bVOvH1Pgxl7lmN+sD5bE/PIubW O9GA== X-Received: by 10.182.171.9 with SMTP id aq9mr4747262obc.16.1369943545046; Thu, 30 May 2013 12:52:25 -0700 (PDT) X-Received: by 10.182.171.9 with SMTP id aq9mr4747256obc.16.1369943544864; Thu, 30 May 2013 12:52:24 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id c20sm44450259oez.4.2013.05.30.12.52.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 12:52:23 -0700 (PDT) Message-ID: <51A7ADF2.60102@afilias.info> Date: Thu, 30 May 2013 15:52:18 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "weirds@ietf.org" References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DAC@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DAC@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkweSyclAwpjvXwR9cRU7FWNWfg/oS73++TMZahaUrI5tsKvLyHAmKO5pJSRIDxcjWjkr3gFLBdUSOCAGgoSuOYcahLf9wzmwyZErn3GRcszKhWUwKjRPgKKaKl7ChaD4Ur+fOZ Subject: Re: [weirds] DNSSEC - proposed text X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 19:52:41 -0000 A few syntax corrections for : inside the " The following is the "DS Data Interface" [RFC5910], where the registration data provides the information for one or more DS records. "secDNS": [ "zoneSigned": true, "delegationSigned": true, "maxSigLife": 604800, { "dsData": [ { "keyTag": 12345, "algorithm": 3, "digestType": 1, "digest": "49FD46E6C4B45C55D4AC", "events": [ { "eventAction": "registration", "eventDate": "2011-07-26T16:25:08Z" } ] }, ... ] } ] The following is the "Key Data Interface" [RFC5910], where the registration data provides the actual key data from one or more DNSKEY records that are used to create the DS records. "secDNS": [ "zoneSigned": true, "delegationSigned": true, "maxSigLife": 604800, { "keyData": [ { "flags": 257, "protocol": 3, "algorithm": 1, "publicKey": "AQPJ////4Q==", "events": [ { "eventAction": "last changed", "eventDate": "2012-07-23T05:15:47Z" } ] }, ... ] } ] -Ernie From edainow@afilias.info Thu May 30 13:19: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 3293421F9254 for ; Thu, 30 May 2013 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njyyswIa-Ddr for ; Thu, 30 May 2013 13:19:24 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E585721F920B for ; Thu, 30 May 2013 13:19:23 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ui9Ji-00087d-4x for weirds@ietf.org; Thu, 30 May 2013 20:19:22 +0000 Received: from mail-ob0-f181.google.com ([209.85.214.181]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ui9Ji-0008CL-4i for weirds@ietf.org; Thu, 30 May 2013 20:19:22 +0000 Received: by mail-ob0-f181.google.com with SMTP id 16so1500768obc.26 for ; Thu, 30 May 2013 13:19:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=UNKpIRpmUmSkYyuX7UnDIpj9qg51QdE+rJnXQsk5R+Y=; b=nuBj1IiAKwdn1YgpVo7Syir7NYhbDqIajkfdKPJdqEip3gd371KgTj/uMzUzz4DY7n sb2dsnRyL9Fkyj25sHBitVySANLQOr7tGZ71HjdSd4O67mGx/ui2a4gX54ZuEZokFMnR FfgM3R/pBLrnhlcLB+qqZqFPnwKdQ8MBiQSOH1YFWsSsPy0K5Ou74uFUsPAgqMXmvHLZ dSWr3wqRlarUdliijdg0yudaBnrGpRYS/0R1ofkD1Uys6I2GTApCWnjCx6sML9GJ0Pnk CilJJdYEacmYkDdrMhkYHd7OPvymhdb2holh/F/wihWEp1jGYOGy0XBT8Lsh0TIxqHUc bNzA== X-Received: by 10.60.33.202 with SMTP id t10mr4789774oei.2.1369945156981; Thu, 30 May 2013 13:19:16 -0700 (PDT) X-Received: by 10.60.33.202 with SMTP id t10mr4789768oei.2.1369945156908; Thu, 30 May 2013 13:19:16 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id jw8sm43268856obb.14.2013.05.30.13.19.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 13:19:15 -0700 (PDT) Message-ID: <51A7B43E.7050303@afilias.info> Date: Thu, 30 May 2013 16:19:10 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Newton Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnzZ3IFId4/qx6JXINBRZ6hUi7ZCk2vpscyFyDMYQcMi4shBMgly7dom3BbYa4Y0nYSuFlh6tDpAvimXvMcq2JvgpY2+XqiTGiwHbg1gV6pLg9i/wGkWFGsHoiWGzoUnFashrjd Cc: "weirds@ietf.org" Subject: [weirds] number type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 20:19:30 -0000 Shouldn't the following be numbers instead of strings? "startAutnum" : "10", "endAutnum" : "15", (in 6.5 Autonomous System Number Entity Object Class, draft-ietf-weirds-json-response-03) -Ernie From edainow@afilias.info Thu May 30 13:32: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 2B9E521F8F5D for ; Thu, 30 May 2013 13:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8TFVBzFdAp8 for ; Thu, 30 May 2013 13:32:07 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id BF3E621F84E7 for ; Thu, 30 May 2013 13:32:06 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Ui9W1-0000bn-6J for weirds@ietf.org; Thu, 30 May 2013 20:32:05 +0000 Received: from mail-ob0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Ui9W1-0000T3-63 for weirds@ietf.org; Thu, 30 May 2013 20:32:05 +0000 Received: by mail-ob0-f178.google.com with SMTP id fb19so1504847obc.23 for ; Thu, 30 May 2013 13:32:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=+AxHaZuKI0doMUsjxJxeoVKrhOPFpjPIrde4Zyq9ors=; b=eW1K4Jpm1k/hPNK0EO1Q+5ruZ5QhToMoUIOVIUvfirtt3PQG+kvfosZWcgwwxAh6B0 t8M47VGxGH8U6HqKVHVPFNNlzoi+rITNdsMJVrZXm0CBZwDVLgJUK6ijjw6PODXiB7AA Ru1iciLxxhD6aMEXY5k/fi+lR7LFSeAZllEQnTHpgZTZkpDXLTp0p1riMZFl0vr/ggDx xrHiKAXv0ym4Y0jMG+kJk1sQfhiy2eZnECFNLV7RFy0uNgOTaYcZdrZ4a/bFxsyNrSqH FCsgrJV2FvaDsnU9cFHHmZ44FBu6q3ZA9nx8ThQnBAwBuDtijV7XmOghtJN26UiSX3PB mAfg== X-Received: by 10.60.124.67 with SMTP id mg3mr4727352oeb.1.1369945920366; Thu, 30 May 2013 13:32:00 -0700 (PDT) X-Received: by 10.60.124.67 with SMTP id mg3mr4727351oeb.1.1369945920280; Thu, 30 May 2013 13:32:00 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id i2sm13672824obz.11.2013.05.30.13.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 13:31:59 -0700 (PDT) Message-ID: <51A7B73A.7050506@afilias.info> Date: Thu, 30 May 2013 16:31:54 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John R Levine References: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD4DC9@CHAXCH01.corp.arin.net> <51A77029.6050603@afilias.info> <51A78644.1090006@afilias.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkZDsF31EVy6W3w3+Kv3pY/LBVjuwnQPHTLnkSJ/aPq0pHmUybjr0IK7e5kF73+pOJLpLWbwn2acYr/0m0yh3ikwpUhLXxO0tJUaZf4kJYzOPJ39T+A3O5vbKPN7DHOHLJBzeSr Cc: "weirds@ietf.org" Subject: Re: [weirds] help X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 20:32:13 -0000 On 5/30/2013 2:47 PM, John R Levine wrote: > Other than the version number, which I think we have handled somewhere > else, it strikes me as an overcomplex way for someone to look at a > well known URL, but it's not worth further argument. The version is a common structure that is supposed to appear in all high level objects. It's not a well known url unless a standard for it is established and published, which is the whole point of this discussion. > > The notices thing is an actively bad idea. I can tell you from years > of people trying to put no-spam notices in SMTP banners that notices > presented to other computers are meaningless. Notices is another common structure that is supposed to appear in all top objects. It was defined a while ago in draft-ietf-weirds-json-response-01. -Ernie From andy@arin.net Thu May 30 14:16: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 616F221F8FF3 for ; Thu, 30 May 2013 14:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.313 X-Spam-Level: X-Spam-Status: No, score=-4.313 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YAQlCcb16zB for ; Thu, 30 May 2013 14:16:22 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3D21F88A9 for ; Thu, 30 May 2013 14:16:21 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C97D42136A6; Thu, 30 May 2013 17:16:19 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id BB8CD213649; Thu, 30 May 2013 17:16:18 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 30 May 2013 17:16:02 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 30 May 2013 17:16:18 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: number type Thread-Index: AQHOXXL6wkYuOcib2EOVJag7AQfY5pkeOpEA Date: Thu, 30 May 2013 21:16:12 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5968@CHAXCH01.corp.arin.net> In-Reply-To: <51A7B43E.7050303@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] number type X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 May 2013 21:16:27 -0000 On 5/30/13 4:19 PM, "Ernie Dainow" wrote: >Shouldn't the following be numbers instead of strings? > "startAutnum" : "10", > "endAutnum" : "15", >(in 6.5 Autonomous System Number Entity Object Class, >draft-ietf-weirds-json-response-03) I think the answer is yes. -andy From pieter.vandepitte@dnsbelgium.be Fri May 31 05:43:47 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8C121F938E for ; Fri, 31 May 2013 05:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V8w-z72OuH4 for ; Fri, 31 May 2013 05:43:32 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id D59CC21F92C5 for ; Fri, 31 May 2013 05:43:30 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 9533E4260012 for ; Fri, 31 May 2013 14:43:28 +0200 (CEST) Message-ID: <51A89AEF.60705@dnsbelgium.be> Date: Fri, 31 May 2013 14:43:27 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] RDAP CA X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 12:43:47 -0000 Hi all, Does anyone know if ICANN has plans to setup a PKI for RDAP? Usages I have in mind: * release certain content to ICANN accredited registrars (certificates signed by ICANN directly or a proxy CA specifically for accredited registrars) * Same for gTLD's or ccTLD's: less restrictive content filtering, partnerships, ... * ... kind regards Pieter From dblumenthal@pir.org Fri May 31 05:53:50 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AFE21F9622 for ; Fri, 31 May 2013 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqbKbLYzrU00 for ; Fri, 31 May 2013 05:53:46 -0700 (PDT) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60221F93DA for ; Fri, 31 May 2013 05:53:46 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 31 May 2013 08:53:44 -0400 From: Don Blumenthal To: Pieter Vandepitte , "weirds@ietf.org" Date: Fri, 31 May 2013 08:53:41 -0400 Thread-Topic: [weirds] RDAP CA Thread-Index: Ac5d/eG95rUb2QnXTJ6wKu80YkUaRg== Message-ID: In-Reply-To: <51A89AEF.60705@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] RDAP CA X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 12:53:50 -0000 PKI wasn't part of the ICANN RFP for a pilot Restful system, http://www.icann.org/en/news/rfps/restful-whois-16may12-en.pdf, which was awarded to CNNIC last October. Formal policy decisions on RDAP won't be made until after ICANN adopts RDAP, although the report of the directory services Expert Working Group might have something useful on the issue. Obviously, I don't know what might be "planned" behind the scenes. :) Don On 5/31/13 8:43 AM, "Pieter Vandepitte" wrote: >Hi all, > >Does anyone know if ICANN has plans to setup a PKI for RDAP? > >Usages I have in mind: >* release certain content to ICANN accredited registrars (certificates >signed by ICANN directly or a proxy CA specifically for accredited >registrars) >* Same for gTLD's or ccTLD's: less restrictive content filtering, >partnerships, ... >* ... > >kind regards > >Pieter >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From johnl@iecc.com Fri May 31 07:08: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 3FF3221F96EC for ; Fri, 31 May 2013 07:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU0WpNybZHkZ for ; Fri, 31 May 2013 07:08:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BDBBE21F96EF for ; Fri, 31 May 2013 07:08:35 -0700 (PDT) Received: (qmail 31940 invoked from network); 31 May 2013 14:08:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 May 2013 14:08:40 -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; s=51a8aee2.xn--yuvv84g.k1305; i=johnl@user.iecc.com; bh=1+wycbVaQYzfywDl0dD6F/U43E/wzxi8kee9NNR7nEY=; b=cSE0QgWElcPI8/4z523c/TUTi0qs+GaHv4geFLSXsioiasTG/WwKq53r+oNkLvDziy6EmELPFLCdASvoH67PTf2y1yByZxna5rihyHkoTPiqxhhUw40GtTRtTZ3g8nv/O+eOrF/PAo/PBVGnYZJxUz3qFGCTRWmTAjPKUEVmqLY= 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; s=51a8aee2.xn--yuvv84g.k1305; olt=johnl@user.iecc.com; bh=1+wycbVaQYzfywDl0dD6F/U43E/wzxi8kee9NNR7nEY=; b=sED5zwUaKUlE+Vp3WrBo2F9GFe74QduqUO52eHXEFlH43oQLZa2OyAOyOxvqJnBTG/nODOIqzh10WRsPnKiT43Sp0rP4yZ5yN0l1u3K2njOyes9d58SQl0a1BdLbK3B+ftRwms/uan318+oUfWl61iDGvahdCeE8YXC7F+ye9BQ= Date: 31 May 2013 14:08:11 -0000 Message-ID: <20130531140811.8796.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <51A89AEF.60705@dnsbelgium.be> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] RDAP CA X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 14:08:40 -0000 In article <51A89AEF.60705@dnsbelgium.be> you write: >Hi all, > >Does anyone know if ICANN has plans to setup a PKI for RDAP? RDAP runs on top of http, so you can set up whatever PKI you want using https. While RDAP has general provisions for tiered access, I'd be surprised if anyone had given much thought to what the tiers would be, or who would be given access to what. From edainow@afilias.info Fri May 31 11:31: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 8062A21F8F0C for ; Fri, 31 May 2013 11:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgkIt6AL9lMo for ; Fri, 31 May 2013 11:31:39 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8A21F84F9 for ; Fri, 31 May 2013 11:31:36 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UiU6x-0006zf-4E for weirds@ietf.org; Fri, 31 May 2013 18:31:35 +0000 Received: from mail-ob0-f169.google.com ([209.85.214.169]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UiU6x-00040m-3z for weirds@ietf.org; Fri, 31 May 2013 18:31:35 +0000 Received: by mail-ob0-f169.google.com with SMTP id up14so3701576obb.0 for ; Fri, 31 May 2013 11:31:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=RTC3odfFlqfIuDC4aDid0KYyDOZ0/Cc0s7p1OmB3Ca8=; b=YUoPdA2c8kGt8/T0YWRlY/UcdPqS1e3+SmO/zYr82ER6ren/H/viWELGnf+7BZTZsu OxC3JLgL8xFxe/SHjlWoiXbspcYs22XALUMNDkpEwQ89M0y8KWulVuLr3WElTylVy2nl jnPp+IC1bhVbaYz5LYOHRptBU/d9SNnOfiv4ia6gozChLxU+vyhqWp4oPH9jRq8/I7Jz /Exh8yHvozwoaAYI2CWOPRPCL46iOdedR1ZTKmfcvgFetdPRH7ToqSKLKy7NBykiOVTo 3GPRdr5eZ58Ov9pAgsQwxhrtOjmJnAJstkJkt00TjnLXUYYG2A11Ro6mdOX1HYsUzOru HH5A== X-Received: by 10.182.32.34 with SMTP id f2mr6446560obi.86.1370025089758; Fri, 31 May 2013 11:31:29 -0700 (PDT) X-Received: by 10.182.32.34 with SMTP id f2mr6446558obi.86.1370025089675; Fri, 31 May 2013 11:31:29 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id i2sm14416400obz.11.2013.05.31.11.31.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 11:31:28 -0700 (PDT) Message-ID: <51A8EC7B.8050001@afilias.info> Date: Fri, 31 May 2013 14:31:23 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkQesLgf3LVGLBxzbFc8tGaSrbDkEnM9zcTynw0WBK80Cur5jpdbD74LJdaxIcRUHMdjpy5c0HQhmWrECReKqGuHDMEUzHWaEMeDHsh2MaAK9m846oH4YmMvPx2vb77LZEjuHPw Subject: [weirds] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 18:31:44 -0000 Registrars and Contacts are represented as Entities (Appendix B.1 in draft-ietf-weirds-json-response-03). While this is a neat, concise model, I have encountered two problems with it. 1. Contacts often have a 'sponsoring' registrar. There is no field within an entity to show this. However, the previous version, draft-ietf-weirds-json-response-02, had a "sponsoredBy" field which could be used within an entity (example on page 26-27). 2. Some Registrar entities have contacts within them. For example, the following Registrar has Tech and Admin contacts: whois -h whois.pir.org registrar id R63-LROR One way to address both of these is to allow entities to contain other entities, as in: "entities": [ { "handle": "424-AS", "roles": [ "Tech", "Admin" ], "vcardArray": [ ... ], "entities": [ { "handle": "284-RS", "roles": [ "registrar" ], "vcardArray": [ ... ] ] }, ... ] The other way, which avoids nested entities objects and is probably simpler, is to separate out Registrars as separate from Contacts. Registrars would have the same structure as Entities, except that the roles element would be redundant and unneeded. This approach would also require another RDAP url query path for registrars, as distinct from entities. Simply restoring "sponsoredBy" does not provide an adequate solution, since it does not provide a way to get the actual Registrar data via a handle, a link or the vCard data itself. -Ernie From shollenbeck@verisign.com Fri May 31 11:59: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 1459421F918C for ; Fri, 31 May 2013 11:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnkhKxnfdaJ8 for ; Fri, 31 May 2013 11:59:50 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65421F910D for ; Fri, 31 May 2013 11:59:29 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUajzEHzIi48MnVFGCc2xvcW56DXMCyCT@postini.com; Fri, 31 May 2013 11:59:50 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r4VIxPjU012099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 14:59:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 31 May 2013 14:59:24 -0400 From: "Hollenbeck, Scott" To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] Registrars versus Contacts Thread-Index: AQHOXi0cNWFSoS8JGka35AdKhZnTY5kfpPVg Date: Fri, 31 May 2013 18:59:25 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2439EF50@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <51A8EC7B.8050001@afilias.info> In-Reply-To: <51A8EC7B.8050001@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 18:59:55 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Ernie Dainow > Sent: Friday, May 31, 2013 2:31 PM > To: weirds@ietf.org > Subject: [weirds] Registrars versus Contacts >=20 > Registrars and Contacts are represented as Entities (Appendix B.1 in > draft-ietf-weirds-json-response-03). While this is a neat, concise > model, I have encountered two problems with it. >=20 > 1. Contacts often have a 'sponsoring' registrar. There is no field > within an entity to show this. However, the previous version, > draft-ietf-weirds-json-response-02, had a "sponsoredBy" field which > could be used within an entity (example on page 26-27). >=20 > 2. Some Registrar entities have contacts within them. For example, the > following Registrar has Tech and Admin contacts: > whois -h whois.pir.org registrar id R63-LROR >=20 > One way to address both of these is to allow entities to contain other > entities, as in: > "entities": [ > { > "handle": "424-AS", > "roles": [ > "Tech", > "Admin" > ], > "vcardArray": [ > ... > ], > "entities": [ > { > "handle": "284-RS", > "roles": [ > "registrar" > ], > "vcardArray": [ > ... > ] > ] > }, > ... > ] >=20 > The other way, which avoids nested entities objects and is probably > simpler, is to separate out Registrars as separate from Contacts. > Registrars would have the same structure as Entities, except that the > roles element would be redundant and unneeded. This approach would also > require another RDAP url query path for registrars, as distinct from > entities. I don't know that I buy the "registrars are special" argument, but nested e= ntities may make sense if entities truly have a hierarchical relationship. = It seems silly to duplicate a data structure only to eliminate one element. Scott From andy@arin.net Fri May 31 12:15: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 566C821F972C for ; Fri, 31 May 2013 12:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdGl-+NkkE72 for ; Fri, 31 May 2013 12:15:36 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0E21F957B for ; Fri, 31 May 2013 12:15:35 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A79081653D0; Fri, 31 May 2013 15:15:29 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 2CDE01653C9; Fri, 31 May 2013 15:15:27 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 31 May 2013 15:15:01 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 31 May 2013 15:15:20 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] Registrars versus Contacts Thread-Index: AQHOXi3HVxjLU9kvtEmQPThdNpETpJkfqgQA Date: Fri, 31 May 2013 19:15:20 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5DB2@CHAXCH01.corp.arin.net> In-Reply-To: <51A8EC7B.8050001@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <0031A3C1E093B64B978AE45D1AFF8B8A@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 19:15:40 -0000 On 5/31/13 2:31 PM, "Ernie Dainow" wrote: >1. Contacts often have a 'sponsoring' registrar. There is no field >within an entity to show this. However, the previous version, >draft-ietf-weirds-json-response-02, had a "sponsoredBy" field which >could be used within an entity (example on page 26-27). That was moved to a "sponsor" role type. See Appendix A.3 >2. Some Registrar entities have contacts within them. For example, the >following Registrar has Tech and Admin contacts: >whois -h whois.pir.org registrar id R63-LROR > >One way to address both of these is to allow entities to contain other >entities, as in: >"entities": [ > { > "handle": "424-AS", > "roles": [ > "Tech", > "Admin" > ], > "vcardArray": [ > ... > ], > "entities": [ > { > "handle": "284-RS", > "roles": [ > "registrar" > ], > "vcardArray": [ > ... > ] > ] > }, > ... >] I agree with Scott. Nested entities make more sense. Registrars with contacts really are no different than ISPs with contacts, which is what we have in the RIR world (in some RIRs, not all). -andy From pieter.vandepitte@dnsbelgium.be Fri May 31 13:39: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 CF48E21F8F0C for ; Fri, 31 May 2013 13:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0gKHf7P51GN for ; Fri, 31 May 2013 13:39:01 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 16C5C21F84F2 for ; Fri, 31 May 2013 13:38:54 -0700 (PDT) Received: from lpieterv.dns.be (d54C08A4A.access.telenet.be [84.192.138.74]) by nug.nucleus.be (Postfix) with ESMTPSA id 0CB344260002; Fri, 31 May 2013 22:38:53 +0200 (CEST) Message-ID: <51A90A5C.20302@dnsbelgium.be> Date: Fri, 31 May 2013 22:38:52 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <51A8EC7B.8050001@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5DB2@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5DB2@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 20:39:06 -0000 I like the idea of nested entities and would even go one step further and define it for all object classes (also nameservers) Pieter P.S. I noticed you used vCardArray, which is currently not part of the draft. But It made me thinking that it could probably provide a solution for you. If we adapt entities so that it can contain an array of vCards, one could make use of ROLES or CATEGORIES to distinguish between the different types. Strictly speaking we even don't need an array of vCards, since vCard properties can have parameters (most notably TYPE). On the other hand, this might probably lead to a bunch of custom TYPEs and or ROLEs/CATEGORIES. Moreover you get in trouble if you want to define the handle of the sponsor in vCard... (unless we register vCard extensions for RDAP properties ;-)) Open question: is there a need to change vCard to vCardArray? On Fri 31 May 2013 09:15:20 PM CEST, Andy Newton wrote: > On 5/31/13 2:31 PM, "Ernie Dainow" wrote: > >> 1. Contacts often have a 'sponsoring' registrar. There is no field >> within an entity to show this. However, the previous version, >> draft-ietf-weirds-json-response-02, had a "sponsoredBy" field which >> could be used within an entity (example on page 26-27). > > That was moved to a "sponsor" role type. See Appendix A.3 > >> 2. Some Registrar entities have contacts within them. For example, the >> following Registrar has Tech and Admin contacts: >> whois -h whois.pir.org registrar id R63-LROR >> >> One way to address both of these is to allow entities to contain other >> entities, as in: >> "entities": [ >> { >> "handle": "424-AS", >> "roles": [ >> "Tech", >> "Admin" >> ], >> "vcardArray": [ >> ... >> ], >> "entities": [ >> { >> "handle": "284-RS", >> "roles": [ >> "registrar" >> ], >> "vcardArray": [ >> ... >> ] >> ] >> }, >> ... >> ] > > I agree with Scott. Nested entities make more sense. Registrars with > contacts really are no different than ISPs with contacts, which is what we > have in the RIR world (in some RIRs, not all). > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From edainow@afilias.info Fri May 31 14:18: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 203C921F8F0C for ; Fri, 31 May 2013 14:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz-GdDbKwWMQ for ; Fri, 31 May 2013 14:18:35 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D808D21F888F for ; Fri, 31 May 2013 14:18:34 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UiWiY-0003wS-3W for weirds@ietf.org; Fri, 31 May 2013 21:18:34 +0000 Received: from mail-oa0-f48.google.com ([209.85.219.48]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UiWiX-0005cj-6K for weirds@ietf.org; Fri, 31 May 2013 21:18:34 +0000 Received: by mail-oa0-f48.google.com with SMTP id i4so287460oah.7 for ; Fri, 31 May 2013 14:18:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=lnhwhcRUX+LMPbp29qGk7xAjepG1wH1QiT/1/Asm1qw=; b=Tw8rzUfiwXYyPwHp5mWbJuu4Ij0vrFUDc4OrzMgcbgl9gZ1l9hfKWTYNcwZjh7B47e 6VwVrqW9b2AMBmsSK/Y51bAZL1X8ayXLYoP63XiTccn8/LolnKIa55ez4lPzXWYSfW1l LlbDz9qQ2yR8KAYkuPVaCjrh1I5hbGIErQnUWXZIjAmcGmlneozB6guvRbapGYVsbwIL ZFR2fCBitixMuur9UNtydGbvL7BhG9yUgMQacJ/pCB1vtr/qfresbjlmHU1ZuLmSWMZz 0OdxNzWLs6EBlm8zbG3L0/JjkW6/0a99r6RJBjXxiBw16K1l2UGtCm/7TwyQxngIUtfr sF+Q== X-Received: by 10.182.226.162 with SMTP id rt2mr6728570obc.9.1370035108400; Fri, 31 May 2013 14:18:28 -0700 (PDT) X-Received: by 10.182.226.162 with SMTP id rt2mr6728566obc.9.1370035108305; Fri, 31 May 2013 14:18:28 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id b5sm44206139oby.12.2013.05.31.14.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 14:18:27 -0700 (PDT) Message-ID: <51A9139D.9090205@afilias.info> Date: Fri, 31 May 2013 17:18:21 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pieter Vandepitte References: <51A8EC7B.8050001@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD5DB2@CHAXCH01.corp.arin.net> <51A90A5C.20302@dnsbelgium.be> In-Reply-To: <51A90A5C.20302@dnsbelgium.be> Content-Type: multipart/alternative; boundary="------------090600030704030406040306" X-Gm-Message-State: ALoCoQlBZT3Fq7SVCo/zDyONaFOLsPNLp0yWyiu8qbzkon1EzleD+iDpF/4S0T2dDLMW3OzXpeFxdzyj9526A/Y1w8YiE7Vj7i/qW9njqUjJZX80bU20xyP13X0ASjIobY6XkDTZB14u Cc: "weirds@ietf.org" Subject: Re: [weirds] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 21:18:40 -0000 This is a multi-part message in MIME format. --------------090600030704030406040306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/31/2013 4:38 PM, Pieter Vandepitte wrote: > I like the idea of nested entities and would even go one step further > and define it for all object classes (also nameservers) > > Pieter > > P.S. > I noticed you used vCardArray, which is currently not part of the > draft. But It made me thinking that it could probably provide a > solution for you. If we adapt entities so that it can contain an array > of vCards, one could make use of ROLES or CATEGORIES to distinguish > between the different types. Strictly speaking we even don't need an > array of vCards, since vCard properties can have parameters (most > notably TYPE). > > On the other hand, this might probably lead to a bunch of custom TYPEs > and or ROLEs/CATEGORIES. Moreover you get in trouble if you want to > define the handle of the sponsor in vCard... (unless we register vCard > extensions for RDAP properties ;-)) > > Open question: is there a need to change vCard to vCardArray? > > It's a minor name change of the RDAP key from vCard to vcardArray, based on the following thread: LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03) On 5/1/2013 8:38 PM, Michael Angstadt wrote: > @Pete: The syntax of the jCards in your examples aren't *quite* > correct. The first element of the jCard array is the string "vcard". > The second element is an array which contains all of the property > arrays. The "vcard" string is redundant in this context, since the > object field already uses this name, but I am just thinking that > parsers might have trouble parsing the jCard without it. The examples > should look like this: > > { > "handle" : "XXXX", > "vCard" : > [ > "vcard", > [ > [ "version", {}, "text", "4.0" ], > [ "fn", {}, "text", "Joe Bob, Inc." ], > ... > ] > ] > > Thanks, > Mike > For RDAP, this is confusing and prone to reversal and case errors. We should use a different name, as in { "handle" : "XXXX", "vcardArray" : [ "vcard", [ -Ernie --------------090600030704030406040306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/31/2013 4:38 PM, Pieter Vandepitte wrote:
I like the idea of nested entities and would even go one step further 
and define it for all object classes (also nameservers)

Pieter

P.S.
I noticed you used vCardArray, which is currently not part of the 
draft. But It made me thinking that it could probably provide a 
solution for you. If we adapt entities so that it can contain an array 
of vCards, one could make use of ROLES or CATEGORIES to distinguish 
between the different types. Strictly speaking we even don't need an 
array of vCards, since vCard properties can have parameters (most 
notably TYPE).

On the other hand, this might probably lead to a bunch of custom TYPEs 
and or ROLEs/CATEGORIES. Moreover you get in trouble if you want to 
define the handle of the sponsor in vCard... (unless we register vCard 
extensions for RDAP properties ;-))

Open question: is there a need to change vCard to vCardArray?
It's a minor name change of the RDAP key from vCard to vcardArray, based on the following thread: LABEL parameter for ADR (Was: vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03)

On 5/1/2013 8:38 PM, Michael Angstadt wrote:
@Pete: The syntax of the jCards in your examples aren't *quite*
correct.  The first element of the jCard array is the string "vcard".
The second element is an array which contains all of the property
arrays.  The "vcard" string is redundant in this context, since the
object field already uses this name, but I am just thinking that
parsers might have trouble parsing the jCard without it.  The examples
should look like this:

{
   "handle" : "XXXX",
   "vCard" :
   [
     "vcard",
     [
       [ "version", {}, "text", "4.0" ],
       [ "fn", {}, "text", "Joe Bob, Inc." ],
       ...
     ]
   ]

Thanks,
Mike


For RDAP, this is confusing and prone to reversal and case errors. We should use a different name, as in

{
  "handle" : "XXXX",
  "vcardArray" :
  [
    "vcard",
    [


-Ernie


--------------090600030704030406040306-- From pieter.vandepitte@dnsbelgium.be Fri May 31 14:27: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 6FF9321F8F4D for ; Fri, 31 May 2013 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yygBbBH181u for ; Fri, 31 May 2013 14:27:07 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 19AFD21F8F41 for ; Fri, 31 May 2013 14:27:05 -0700 (PDT) Received: from lpieterv.dns.be (d54C08A4A.access.telenet.be [84.192.138.74]) by nug.nucleus.be (Postfix) with ESMTPSA id E56144260002 for ; Fri, 31 May 2013 23:27:04 +0200 (CEST) Message-ID: <51A915A8.5070509@dnsbelgium.be> Date: Fri, 31 May 2013 23:27:04 +0200 From: Pieter Vandepitte User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: "weirds@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] Accept-Language header X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 21:27:13 -0000 I have a question about http://tools.ietf.org/html/draft-ietf-weirds-using-http-05#section-9.3 What's the rationale behind the rule that servers should ignore the Accept-Language header? It would be nice if a client could inform the server about its preferred language in some way, so that e.g. a Terms of Use in a Notice object can be sent back in the most appropriate language (i.e. the language of the requester if available, otherwise english). The accept-language header seems the most appropriate to me in this case... Kind regards Pieter From andy@arin.net Fri May 31 14:46:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2F21F8B64 for ; Fri, 31 May 2013 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwM-Amh1gEDe for ; Fri, 31 May 2013 14:46:03 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id AE00D21F9052 for ; Fri, 31 May 2013 14:46:02 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 9E16621366D; Fri, 31 May 2013 17:45:45 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 3631A21364F; Fri, 31 May 2013 17:45:45 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 31 May 2013 17:45:06 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 31 May 2013 17:45:26 -0400 From: Andy Newton To: Pieter Vandepitte Thread-Topic: [weirds] Registrars versus Contacts Thread-Index: AQHOXi3HVxjLU9kvtEmQPThdNpETpJkfqgQAgABaZwD//8+FgA== Date: Fri, 31 May 2013 21:45:25 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD6F55@CHAXCH01.corp.arin.net> In-Reply-To: <51A90A5C.20302@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 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] Registrars versus Contacts X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 21:46:09 -0000 On 5/31/13 4:38 PM, "Pieter Vandepitte" wrote: >I like the idea of nested entities and would even go one step further >and define it for all object classes (also nameservers) I agree. Nameservers needs them too. There are enough changes queued up for this draft now that I'll try to respin it as soon as possible. -andy From andy@arin.net Fri May 31 14:49: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 2DF5B21F852D for ; Fri, 31 May 2013 14:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4ZQ3slNDB72 for ; Fri, 31 May 2013 14:48:55 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id DF49421F8556 for ; Fri, 31 May 2013 14:48:54 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 7B0AF1653EC; Fri, 31 May 2013 17:48:13 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 14F241653E9; Fri, 31 May 2013 17:48:13 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 31 May 2013 17:47:52 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.96]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 31 May 2013 17:48:12 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] Accept-Language header Thread-Index: AQHOXkY+uk1UjyngakOw1r96KaF6pJkf1IkA Date: Fri, 31 May 2013 21:48:11 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E5E2DD6F69@CHAXCH01.corp.arin.net> In-Reply-To: <51A915A8.5070509@dnsbelgium.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DB7C658DD1A754BB529C7566351319D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Accept-Language header X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 31 May 2013 21:49:00 -0000 On 5/31/13 5:27 PM, "Pieter Vandepitte" wrote: >I have a question about >http://tools.ietf.org/html/draft-ietf-weirds-using-http-05#section-9.3 > >What's the rationale behind the rule that servers should ignore the >Accept-Language header? It would be nice if a client could inform the >server about its preferred language in some way, so that e.g. a Terms of >Use in a Notice object can be sent back in the most appropriate language >(i.e. the language of the requester if available, otherwise english). >The accept-language header seems the most appropriate to me in this >case... I don't pretend to know the reason, but our I18N experts tell us that such usage is inappropriate. There have been long, long discussions on internationalization. But the result was that if you want to present the notices in different languages, differentiate them using the 'lang' property. I do think it will be rare for a registry to support more than a handful of languages. -andy