From shollenbeck@verisign.com Mon Apr 1 05:12: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 DBAB021F8EC1 for ; Mon, 1 Apr 2013 05:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 FdOyBdW61l8i for ; Mon, 1 Apr 2013 05:12:41 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8B21F8EEA for ; Mon, 1 Apr 2013 05:12:25 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUVl5qIYICFA75NYWY5xargX+TnQwMul4@postini.com; Mon, 01 Apr 2013 05:12: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 r31CCKoi005888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Apr 2013 08:12:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 1 Apr 2013 08:12:20 -0400 From: "Hollenbeck, Scott" To: Peter Saint-Andre , Olaf Kolkman Thread-Topic: [weirds] U-label support Thread-Index: AQHOIQahSUF3Xaljl0iew25pnt8hOJil1i/QgBaoabqAAFPHgIAAFR+AgAA9CoCAABLEgIAABPeAgAQl7jA= Date: Mon, 1 Apr 2013 12:12:19 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2434B601@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243357C5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6.2.5.6.2.20130327101012.0c52b348@resistor.net> <2D45C91B-36CF-42B6-85ED-BDD71FB353D9@NLnetLabs.nl> <6.2.5.6.2.20130329032209.0bd9fed0@resistor.net> <4D66203B-EE64-4FFF-A8DE-3C5090E4550C@NLnetLabs.nl> <5155B29D.3000301@stpeter.im> <48791875-50CB-4D54-9A36-DBAD8700E453@NLnetLabs.nl> <5155C685.9070609@stpeter.im> In-Reply-To: <5155C685.9070609@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] U-label support X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 12:12:42 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Peter Saint-Andre > Sent: Friday, March 29, 2013 12:51 PM > To: Olaf Kolkman > Cc: weirds@ietf.org > Subject: Re: [weirds] U-label support >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/29/13 10:33 AM, Olaf Kolkman wrote: > > > > On Mar 29, 2013, at 4:26 PM, Peter Saint-Andre > > wrote: >=20 > >> Are we looking for documentation examples or examples for real-world > >> testing? > > > > Documentation. >=20 > In that case just do names of the form *.example (from RFC 2606). Ack, will do. Scott From maarten.wullink@sidn.nl Mon Apr 1 06:44:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5A21F9359 for ; Mon, 1 Apr 2013 06:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_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 PkDwloeu8CXX for ; Mon, 1 Apr 2013 06:44:45 -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 C0C2621F9355 for ; Mon, 1 Apr 2013 06:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=5rwJwXm5le3pPSUG6ZilhaR/cLE3/s53NXRfJhbCmDA=; b=c7KlRXjTZsEdrBulFRhr5EhBmHZssk6xm9lgoayaa0HKTFSLgOIVCakZHojvLUrBNUjwPD4mJRb0ufD9Th4JrUCJ8KfzA3rbzTtJ5hgl1DD2OK+4kAPwtNYkIBW8IY50vV7zn/D+AQUdzo/WudINGzi9E671FT5VFXxc+JmrSmo= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r31Dihrn023265-r31Dihrp023265 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 1 Apr 2013 15:44:43 +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; Mon, 1 Apr 2013 15:44:43 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcas1.SIDN.local ([fe80::dff:8232:1563:3a16%14]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 15:44:43 +0200 From: Maarten Wullink To: "weirds@ietf.org" Thread-Topic: Notice object description issue Thread-Index: Ac4u3mBN7pt99Px6QIeInl+oc4PLRQ== Date: Mon, 1 Apr 2013 13:44:42 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] Notice object description issue X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Apr 2013 13:44:46 -0000 In section "5.2 Notices" : http://tools.ietf.org/html/draft-ietf-weirds-jso= n-response-02#section-5.2 It says: " an optional "links" object"=20 The example given there shows the "links" object as an array of links, I as= sume that the text should be changed to=20 Something like "an optional array of link objects" ? 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=20 From edainow@afilias.info Mon Apr 1 12:07: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 EC66011E80E4 for ; Mon, 1 Apr 2013 12:07:33 -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 5GB1gzBqfLx4 for ; Mon, 1 Apr 2013 12:07:33 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4845611E80E6 for ; Mon, 1 Apr 2013 12:07:33 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UMk4q-0004Fy-5N for weirds@ietf.org; Mon, 01 Apr 2013 19:07:32 +0000 Received: from mail-bk0-f69.google.com ([209.85.214.69]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UMk4q-0007MS-4q for weirds@ietf.org; Mon, 01 Apr 2013 19:07:32 +0000 Received: by mail-bk0-f69.google.com with SMTP id i18so3706155bkv.4 for ; Mon, 01 Apr 2013 12:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vyr/zzasYbbdj//sgKCjy3sEqaU6768jM3IDSClPPBs=; b=ACOabIqOjUchDpnmRNtHuTkHoInmtLGUjHEyg5XuW4HEWm4FX4JyMYmjm1tu3rWW8a 8YCfPM3IHZIF6VeHvIuBwegTEWVO04+/4IUE/BUjenffo/JLkbXVeYqDpFXWqafuBWA0 VKf0PyU38maXRJvTwn7LNRilBvGq21nMsCKYiRlWThJbao1AsYg9F60C82yYIWUHcQjy 42ciACTJrfoGrG1HL+yyIt0BkvW+dBfFwYRGYpuPaAn7srzfBZLC39zBgq7dYR4kX+Yh C68rzguMcUmuhzaz6o9t9A5RDav6RgX1M9AQXuz3dGvrU1BOFl3WU/bGYS7YSPdTBSgq EfJA== X-Received: by 10.112.9.104 with SMTP id y8mr6235677lba.132.1364843246246; Mon, 01 Apr 2013 12:07:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.9.104 with SMTP id y8mr6235668lba.132.1364843246111; Mon, 01 Apr 2013 12:07:26 -0700 (PDT) Received: by 10.112.44.2 with HTTP; Mon, 1 Apr 2013 12:07:25 -0700 (PDT) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> Date: Mon, 1 Apr 2013 15:07:25 -0400 Message-ID: From: Ernie Dainow To: John R Levine Content-Type: multipart/alternative; boundary=e0cb4efe2ee6dbeb1104d9515421 X-Gm-Message-State: ALoCoQmzPT6woEiPsylYtWm/tDuE4S8OafRURimMs3xPTkMsrC+g0ly9KW28gd+7Ogl6U8HvtEsg/c7UfhS9/YehNMWQ3N++EyTZSrBmc9WetRDO6ddJm4FEpAxhKBsb9USmTHWwbDSe Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:07:34 -0000 --e0cb4efe2ee6dbeb1104d9515421 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 29, 2013 at 12:50 PM, John R Levine wrote: > No. A client that doesn't send an Accept: header is not an rdap >>>> client, so it makes sense to return a generic format that a generic >>>> client (e.g. a web browser) can render. >>>> >>>> This generic format (probably html based) is described in an other >>> (future) weirds document? >>> >> > It is JSON, specified in draft-ietf-weirds-json-**response. >> > > Other way around. An rdap client asks for a json response, and gets a > json response. > > A non-rdap client asks for something else. Since it's not rdap, the > server can return whatever it wants. This is not an interoperability > issue, so there's no reason to define it further. > > The non-normative note suggests that since the non-rdap clients is likely > to be a web browser, something a browser could render would be nice. This > is in fact what Andy's protoype does. > It is very useful to be able to use a browser with an RDAP server, for developers debugging client applications as well as end users who just want quick access to verify something on a server. We should make a stronger recommendation that servers SHOULD support browsers by returning a simple content-type like "text/plain". Some of the current implementations do not do this and you have to save/download the response and then open it with a text editor to see the server response. -Ernie > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > --e0cb4efe2ee6dbeb1104d9515421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 29, 2013 at 12:50 PM, John R= Levine <johnl@taugh.com> wrote:
No. =A0A client that doesn't send an Accept: header is not an rdap
client, so it makes sense to return a generic format that a generic
client (e.g. a web browser) can render.

This generic format (probably html based) is described in an other
(future) weirds document?

It is JSON, specified in draft-ietf-weirds-json-response.

Other way around. =A0An rdap client asks for a json response, and gets a js= on response.

A non-rdap client asks for something else. =A0Since it's not rdap, the = server can return whatever it wants. =A0This is not an interoperability iss= ue, so there's no reason to define it further.

The non-normative note suggests that since the non-rdap clients is likely t= o be a web browser, something a browser could render would be nice. This is= in fact what Andy's protoype does.

It is very useful to be able to use a browser with an RDAP server, for= developers debugging client applications as well as end users who just wan= t quick access to verify something on a server. We should make a stronger r= ecommendation that servers SHOULD support browsers by returning a simple co= ntent-type like "text/plain". Some of the current implementations= do not do this and you have to save/download the response and then open it= with a text editor to see the server response.

-Ernie
=A0
johnl@tau= gh.com, Taughannock Networks, Trumansburg NY


--e0cb4efe2ee6dbeb1104d9515421-- From edainow@afilias.info Mon Apr 1 12:39: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 6893721F8EB2 for ; Mon, 1 Apr 2013 12:39: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 G4M2ltEGUh42 for ; Mon, 1 Apr 2013 12:39:12 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D506521F8EAF for ; Mon, 1 Apr 2013 12:39:11 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UMkZT-0005tr-47 for weirds@ietf.org; Mon, 01 Apr 2013 19:39:11 +0000 Received: from mail-ia0-f197.google.com ([209.85.210.197]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UMkZT-0008Nx-3r for weirds@ietf.org; Mon, 01 Apr 2013 19:39:11 +0000 Received: by mail-ia0-f197.google.com with SMTP id r13so10116798iar.0 for ; Mon, 01 Apr 2013 12:39:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:user-agent:mime-version :to:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=QCk1FqrwW7KzcYU27M9mAc8y4hXoogSLYp6wRvj8900=; b=j3NtqwVvZtPhDaOG65N7AlFyh5xWb+6it9BMcUhHDBroPDldnY8pVi5AkijpRTaybF EVZfgYUMGyy58k6cXOhSnbVik7MrDrJWl4GL9HWprpFOJIrQDlpZUh0ERqWiqnQRLVx8 bN1krWlQuleZ/JBNnbreoiS8syR+CsQSZUhvxltk8SENathJpWPH+JIrxPhf3eMkzy/Y K2bydLqQBFJQ7+XqH+WHy4G4zWY4JrVGmCC2NM8XKViyZzqxandT/+f40kLj3R+BkDoR b9f2wfXwGt+ZqzvkhWU1In5i21pGLt06/F4ImvoCo+EzhvwC1fcaiu1JM4ndEZunY/9S XqaA== X-Received: by 10.50.169.33 with SMTP id ab1mr4000159igc.103.1364845145655; Mon, 01 Apr 2013 12:39:05 -0700 (PDT) X-Received: by 10.50.169.33 with SMTP id ab1mr4000157igc.103.1364845145539; Mon, 01 Apr 2013 12:39:05 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id dy5sm5746084igc.1.2013.04.01.12.39.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 12:39:04 -0700 (PDT) Message-ID: <5159E255.9040507@afilias.info> Date: Mon, 01 Apr 2013 15:39:01 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> <20130330172157.4969.qmail@joyce.lan> <6.2.5.6.2.20130330173603.0c790e20@resistor.net> <6.2.5.6.2.20130330190045.0c2fcf18@resistor.net> In-Reply-To: <6.2.5.6.2.20130330190045.0c2fcf18@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQloREJLDNlcKEp9gq2Yu8O55AkWLkmM2yTDqcUV8Fn0bBASV9C8KQS9OohdTF1fVDQAEvr+UUXgW/WkVqbWZF8OjXx7Tmfq736ltxd04j/S7edpMiQ+QcbujQLXJ1gNxfO3HGD0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:39:12 -0000 Section 8.1 Clients MAY use IRIs as they see fit, but MUST transform them to URIs [RFC3986] RFC3986 does not address IRIs or URI/IRI transforms, the reference should be RFC3987. -Ernie From johnl@taugh.com Mon Apr 1 12:44: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 2D13521F936F for ; Mon, 1 Apr 2013 12:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8hVAD13EYcv for ; Mon, 1 Apr 2013 12:44:41 -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 2448C21F937D for ; Mon, 1 Apr 2013 12:44:40 -0700 (PDT) Received: (qmail 18906 invoked from network); 1 Apr 2013 19:44: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:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=49d9.5159e3a8.k1304; bh=iftpl52+0dby7ATdRSkPB/hcbvjYmgLpodId66ju7C8=; b=mHdX0NM0mdVU1a9u8ohOO/BvZui08BF8W7nQJnO4t4Ndf5r8koaydlurg45f47OJcMc7O+eQlGH1jPuad74hC31Q2tqAbhyqeoVfO4PgZLKTibvQ91lUka1ysQ8FCNoF4DDKVRfhfm3nVNb4HTLR9SdGuP+1tON8D0WK08xADvU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=49d9.5159e3a8.k1304; bh=iftpl52+0dby7ATdRSkPB/hcbvjYmgLpodId66ju7C8=; b=wYTbrw3Mob9REBPiZSxcMNEic4jLYXl74/k34T5RtZMrQ4mxc8mmNEUbHT+B+oR/zZgbmyNM5Z1CN+D45RBPuXBafmZDTvd/3hEAjGTuk6q4HkbEo6DpFLFiQZ1lvQmCG1ne1Ys31WRsf/cIkyrhkSY031pQOxQVM38hqxsq0B0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 1 Apr 2013 19:44:18 -0000 Date: 1 Apr 2013 15:44:39 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2130032906-1364845479=:4616" Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:44:42 -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-2130032906-1364845479=:4616 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > It is very useful to be able to use a browser with an RDAP server, for > developers debugging client applications as well as end users who just want > quick access to verify something on a server. We should make a stronger > recommendation that servers SHOULD support browsers by returning a simple > content-type like "text/plain". Some of the current implementations do not > do this and you have to save/download the response and then open it with a > text editor to see the server response. No doubt, but we're writing a standard. How would this affect interoperability among RDAP clients and servers? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a bad idea to try to specify that. --3825401791-2130032906-1364845479=:4616 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAxMTk0NDM5WjAjBgkqhkiG 9w0BCQQxFgQUGMVTOkZVGzWuq+d1JjZspQecoxwweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAXasIO60bpnC5 kOHZR0ySDHLVSxh0cJpFm1sch+bN+8+kCvFWVHRKneDV6lzhuWWGpljn7de3 41w84Ugx9xl5n1EWMrbEqcbzEI6dTN5p+M3pkqQhE/0209V/RbIfg0rvYvxe tPDu/w+lpMoT02bDvw0xJ/6zOap23uB+bLRobgkJm5MVzdWZDKoH+yYob2i5 kbpqec3QRGLFWZCOB1wsmtApGvTvOSEdnDIJAtgmUguQzdEbGGKZleSJpr37 7tJuMFUr5M+WaHJvW8WRgaI9BLh4XNxxqkRkN4Ukea4YAs3csci+L/vckY87 yVl2hMX9JBEvKOYHrWX/rtVMLythyQ== --3825401791-2130032906-1364845479=:4616-- From internet-drafts@ietf.org Mon Apr 1 12: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 5A42011E80E6; Mon, 1 Apr 2013 12:49:55 -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.101, 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 TRRlR3BVGXzP; Mon, 1 Apr 2013 12:49:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A394111E80E8; Mon, 1 Apr 2013 12:49:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401194954.11301.92497.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 12:49:54 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-04.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, 01 Apr 2013 19:49:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Registration Data Access Protocol Lookup Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-04.txt Pages : 12 Date : 2013-04-01 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Mon Apr 1 12:55: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 38FAF1F0D17 for ; Mon, 1 Apr 2013 12:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.354 X-Spam-Level: X-Spam-Status: No, score=-4.354 tagged_above=-999 required=5 tests=[AWL=2.245, 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 YjOiNUiQuziM for ; Mon, 1 Apr 2013 12:55:06 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 77F911F0C74 for ; Mon, 1 Apr 2013 12:55:06 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUVnmGsXYKNn5z3C9pHMPNN+iUbgTq1qs@postini.com; Mon, 01 Apr 2013 12:55:06 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 r31Jt3M1002747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Apr 2013 15:55:05 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 1 Apr 2013 15:55:02 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-04.txt Thread-Index: AQHOLxIXWE5iAWkUf0+iLNsK2DfMaJjBxktA Date: Mon, 1 Apr 2013 19:55:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2434C22F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130401194954.11301.92497.idtracker@ietfa.amsl.com> In-Reply-To: <20130401194954.11301.92497.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-04.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, 01 Apr 2013 19:55:07 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, April 01, 2013 3:50 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. >=20 > Title : Registration Data Access Protocol Lookup Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-04.txt > Pages : 12 > Date : 2013-04-01 Updated per recent feedback: -04: Updated the domain and name server sections to use .example IDN U-labels. Added text to note that mixed IDN labels SHOULD NOT be used. Fixed broken sentences in Section 5. ...and I just noticed that the text above should say ".example IDN *A*-labe= ls". Oh, well. Scott From edainow@afilias.info Mon Apr 1 13:10: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 BE0EC11E80EE for ; Mon, 1 Apr 2013 13:10:09 -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 0jnScLZEpahh for ; Mon, 1 Apr 2013 13:10:09 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2004711E80E9 for ; Mon, 1 Apr 2013 13:10:09 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UMl3N-00080n-6K for weirds@ietf.org; Mon, 01 Apr 2013 20:10:05 +0000 Received: from mail-wi0-f198.google.com ([209.85.212.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UMl3N-0001LU-5r for weirds@ietf.org; Mon, 01 Apr 2013 20:10:05 +0000 Received: by mail-wi0-f198.google.com with SMTP id hj8so3063099wib.9 for ; Mon, 01 Apr 2013 13:09:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2odDxdyuggnsK+YqD2i1k1VatwX/zaRuzC2iszOXiHQ=; b=R76CHddlNr9vwffzLdW6SMeXj5524rqod7caejk7OXlmG1SEDigCywRT8isD8rJxQF f99yK9pCA/YmgnHd7Jq0mRuYOQJS+GYJzJ9oUTNJF+yZqQHEhthsdXzSzuh+yJtYPR8B xE7N2NpwSJOnZrriuf83xWw0H1aogffXjMffhVVaKnwiuFjl2vBc2wWzA9Nh03Wqgf1A TMlL9+XQSlV13eECh8ygyiSteF7HbTOGXIISdXvQfsm28guAtdKiaybWiwkKncLVbefm Iz2wV2QpLmHKONzqm9DxvDUBMjHgufEmwMKzW3NJYm4AYNC1/NVug8xZBsjy5z2nxMia sDVQ== X-Received: by 10.112.34.200 with SMTP id b8mr6453118lbj.3.1364846999563; Mon, 01 Apr 2013 13:09:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.34.200 with SMTP id b8mr6453116lbj.3.1364846999440; Mon, 01 Apr 2013 13:09:59 -0700 (PDT) Received: by 10.112.44.2 with HTTP; Mon, 1 Apr 2013 13:09:59 -0700 (PDT) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> Date: Mon, 1 Apr 2013 16:09:59 -0400 Message-ID: From: Ernie Dainow To: John R Levine Content-Type: multipart/alternative; boundary=14dae947381d9328cf04d952346d X-Gm-Message-State: ALoCoQnOGXiJw7lhzalPKE0Y6v+yUliH3cel8/lJ6uA14K+kOQhAIFEMUNN0qTgYLfL+qtpnWEqlApPgEr7zVYHCaI2MaBU0NOn7k6oFYzwwjlBgwl9GuH0rHGsekZdPzo+dtsgqHXpt Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:10:09 -0000 --14dae947381d9328cf04d952346d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 1, 2013 at 3:44 PM, John R Levine wrote: > It is very useful to be able to use a browser with an RDAP server, for >> developers debugging client applications as well as end users who just >> want >> quick access to verify something on a server. We should make a stronger >> recommendation that servers SHOULD support browsers by returning a simple >> content-type like "text/plain". Some of the current implementations do not >> do this and you have to save/download the response and then open it with a >> text editor to see the server response. >> > > No doubt, but we're writing a standard. How would this affect > interoperability among RDAP clients and servers? > > When there is an interoperability failure between a client and server, it really helps to have simple browser support to determine if the fault is on the server or client. Visual inspection of the server response can determine if it is out of spec, without having to write or use debugging code. -Ernie > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a > bad idea to try to specify that. --14dae947381d9328cf04d952346d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 1, 2013 at 3:44 PM, John R L= evine <johnl@taugh.com> wrote:
It is very useful to be able to use a browser with an RDAP server, for
developers debugging client applications as well as end users who just want=
quick access to verify something on a server. We should make a stronger
recommendation that servers SHOULD support browsers by returning a simple content-type like "text/plain". Some of the current implementatio= ns do not
do this and you have to save/download the response and then open it with a<= br> text editor to see the server response.

No doubt, but we're writing a standard. =A0How would this affect intero= perability among RDAP clients and servers?

=A0
When there is an interoperability failure betwee= n a client and server, it really helps to have simple browser support to de= termine if the fault is on the server or client. Visual inspection of the s= erver response can determine if it is out of spec, without having to write = or use debugging code.

-Ernie



Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

PS: I'm not saying it's a bad idea to return a web page, I'm sa= ying it's a bad idea to try to specify that.

--14dae947381d9328cf04d952346d-- From johnl@taugh.com Mon Apr 1 13:15: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 C5C5B21F8CF5 for ; Mon, 1 Apr 2013 13:15:32 -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 0-ctW6iAWA+D for ; Mon, 1 Apr 2013 13:15:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92721F86D3 for ; Mon, 1 Apr 2013 13:15:31 -0700 (PDT) Received: (qmail 30290 invoked from network); 1 Apr 2013 20:15:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:vbr-info:user-agent:cleverness; s=764d.5159eae3.k1304; bh=LlTs+otN3ifp1Is66vWmgoUE2ThHxmcge9iqYHU2xQs=; b=DJk5nPbJ6DqKMs4iEdAnAPTKdtFSO8vl4Jd47prVfbZ6MNCY8T/A/TRvx29i0Ge4oXc8Qm2IQFHL+tQTPcPLuYFyqb9Xm8dvnSKONK/jjlOYsmxT69GtgrroDKSTtBwyCx2vZJd0qlL4RuXMUToR5X85/6X+supiLa8mp+E2Ovg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:vbr-info:user-agent:cleverness; s=764d.5159eae3.k1304; bh=LlTs+otN3ifp1Is66vWmgoUE2ThHxmcge9iqYHU2xQs=; b=Tj3O+65r213xff+PWfykXa+MBHtJTM1ymiVhIx5kW3ANSDpZgbT9brHe6bIMO04QNdA4FLJDahDYG6z6wn5eKzWp/kPFDmjUxoNx78JYk6MZsH3HTfzsdGFrO6pC+4SuvVehS8ac6AbKDWvf4JGdDZEC802l4BNS5Sj1UvTS6ik= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 1 Apr 2013 20:15:09 -0000 Date: 1 Apr 2013 16:15:30 -0400 Message-ID: From: "John R Levine" To: weirds@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-ID: Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:15:32 -0000 > When there is an interoperability failure between a client and server, it > really helps to have simple browser support to determine if the fault is on > the server or client. Visual inspection of the server response can > determine if it is out of spec, without having to write or use debugging > code. Like I said: >> PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a >> bad idea to try to specify that. It already has a hint to developers that they return a web page to generic clients. If people aren't inclined to take the hint, that's a quality of implementation issue. Personally, I'd prefer that it always return JSON, since if I'm debugging a JSON client, I want to see what the client sees. But I realize that tastes can differ. R's, John From andy@arin.net Mon Apr 1 13:20: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 CEA2C21E80AE for ; Mon, 1 Apr 2013 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kvbaBL5S9q5t for ; Mon, 1 Apr 2013 13:20: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 ED06321E8051 for ; Mon, 1 Apr 2013 13:20:05 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 0207F213650; Mon, 1 Apr 2013 16:19:59 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 810BF21364A; Mon, 1 Apr 2013 16:19: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; Mon, 1 Apr 2013 16:19:24 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 16:19:58 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i90qRegADwfICAAxNTAA== Date: Mon, 1 Apr 2013 20:19:58 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8C5F@CHAXCH01.corp.arin.net> In-Reply-To: <20130330172157.4969.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:20:08 -0000 On 3/30/13 1:21 PM, "John Levine" wrote: >> >> "Depending on the data format of the response, servers MAY include >> data in character sets other than ASCII and languages other than >> English (the data format will most likely be in Unicode and almost >> certainly languages other than English will be encountered)." >> >>This comes out as hand-waving the internationalization >>question. From the charter: > >I agree that we should either say UTF-8 or nothing. This isn't a policy >issue, it's an interop issue. Then it should say nothing. Our JSON response is UTF-8. -andy From andy@arin.net Mon Apr 1 13:21: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 459D421E803C for ; Mon, 1 Apr 2013 13:21: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 6jjXkI9cGndY for ; Mon, 1 Apr 2013 13:21:04 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 54A9A21F8842 for ; Mon, 1 Apr 2013 13:20:59 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 003C716518D; Mon, 1 Apr 2013 16:20:58 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 7959216518B; Mon, 1 Apr 2013 16:20:58 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 1 Apr 2013 16:20:52 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 16:20:57 -0400 From: Andy Newton To: Maarten Wullink , "weirds@ietf.org" Thread-Topic: [weirds] Notice object description issue Thread-Index: Ac4u3mBN7pt99Px6QIeInl+oc4PLRQAOAcOA Date: Mon, 1 Apr 2013 20:20:57 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8C7E@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B74EC7640990F4E8E05C3A0782FDB37@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Notice object description issue X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Apr 2013 20:21:05 -0000 On 4/1/13 9:44 AM, "Maarten Wullink" wrote: > >In section "5.2 Notices" : >http://tools.ietf.org/html/draft-ietf-weirds-json-response-02#section-5.2 > >It says: " an optional "links" object" >The example given there shows the "links" object as an array of links, I >assume that the text should be changed to >Something like "an optional array of link objects" ? Thanks. I'm in the process of cleaning all that up. It should be "links" array. -andy From johnl@taugh.com Mon Apr 1 13:25: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 B41E321E80B4 for ; Mon, 1 Apr 2013 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRT6hjSXHwVh for ; Mon, 1 Apr 2013 13:25:00 -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 9D62921E803C for ; Mon, 1 Apr 2013 13:24:57 -0700 (PDT) Received: (qmail 33442 invoked from network); 1 Apr 2013 20:24: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:vbr-info:user-agent:cleverness; s=82a1.5159ed19.k1304; bh=kAWIyZOPu6CliduwKrtlZAg61vCQBHopo3/GSk0j+y4=; b=EO9bgqFWQnvOXDyVnThAS0otdoFQUO3u1I6UI89FDUVrWRJgCb86lgjE1mueSHnb6UyW+o7YEK7t0f5gy/4anNZe4nl1wu7QPTzOw/DUl39xebRdJtUJaVKuBFXPS5v7y1nwq8bDJWZIgCvmddofM8wyKfYKod3Z4Ni/CWkmz/E= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=82a1.5159ed19.k1304; bh=kAWIyZOPu6CliduwKrtlZAg61vCQBHopo3/GSk0j+y4=; b=I+6wdt6WsMA2dFep3S5n2PkSnT98F3fsHqBZpM9sf4mk6C0RuanWOYsBbICZUR+cAFiUXE8N+np9BIEbUlgJSMQAF8RCDQYkvIg3v1etqI3lINUnb90HlyskLBvkNql8CvP7M+h4r3RNHctzIjLBgF6gdPfVqcVewG5E0aDvOjA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 1 Apr 2013 20:24:35 -0000 Date: 1 Apr 2013 16:24:56 -0400 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8C5F@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8C5F@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:25:09 -0000 >> I agree that we should either say UTF-8 or nothing. This isn't a policy >> issue, it's an interop issue. > > Then it should say nothing. Our JSON response is UTF-8. I would have a minor preference to say that servers that return non-ASCII results do so encoded as UTF-8, but it's not a big deal. Is there any reason not to specify UTF-8 for non-ASCII responses? Is anyone we're aware of planning to use any other encoding? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From edainow@afilias.info Mon Apr 1 13:59: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 20CE821E8053 for ; Mon, 1 Apr 2013 13:59:08 -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 Hhs+QLa9p5Hq for ; Mon, 1 Apr 2013 13:59:07 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0D89621E80AA for ; Mon, 1 Apr 2013 13:59: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.69) (envelope-from ) id 1UMloo-0001mq-5A for weirds@ietf.org; Mon, 01 Apr 2013 20:59:06 +0000 Received: from mail-wi0-f199.google.com ([209.85.212.199]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UMloo-0002gm-4d for weirds@ietf.org; Mon, 01 Apr 2013 20:59:06 +0000 Received: by mail-wi0-f199.google.com with SMTP id c10so3115286wiw.6 for ; Mon, 01 Apr 2013 13:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jQoSQlFz6s2+rp56MCPEbBl0pKKKi4wd3nZP8T2Rvww=; b=i5vE6QY6gZ6Hr8LK06d+6/g+87QbJEnyyoiWsRKWp+AvFD6xHH8FieSXVARMEEOvB+ x+8XtpIN6rphUH0EEOGijnyi2WJSULqe1WFiU6bCAmpEF4WJ1ALebeXxvZl/tpvCojCl QVXbxmHaXNlChdrBo2VPRdzJZDeampznyfc5LaeR/WZ+mNLVilsobSN+oxqfdbAY0ffJ Cx+obu3sPr0qzl9zbgb4PWfFuilKxdeoWrBPsN2hY+tTSTSupyPj+u1Qs5dfe8fyjg85 /hzj3LBGR63LVJwQYyi+S2r1a9qOW6+VabFWn8tnzKSF4czBKoaYemxdB8AfKaGxU0x6 LG7g== X-Received: by 10.112.87.132 with SMTP id ay4mr6413313lbb.87.1364849940148; Mon, 01 Apr 2013 13:59:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.87.132 with SMTP id ay4mr6413308lbb.87.1364849939992; Mon, 01 Apr 2013 13:58:59 -0700 (PDT) Received: by 10.112.44.2 with HTTP; Mon, 1 Apr 2013 13:58:59 -0700 (PDT) In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> Date: Mon, 1 Apr 2013 16:58:59 -0400 Message-ID: From: Ernie Dainow To: "John R. Levine" Content-Type: multipart/alternative; boundary=f46d0401f8fbd86d4f04d952e3c4 X-Gm-Message-State: ALoCoQnKVTtlNP8xs1tXpSQhMAHtSSAUSgXKdVME5eS02cJQ0zRtvPKGfiPA5s3Lh76aKQaEs9kDldF2zCPrNvbvH3H78c5bHrz9WH12tgE4C9womYrzpN+lwts68dTP1VFyfrsvF0B6 Cc: John R Levine , "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:59:08 -0000 --f46d0401f8fbd86d4f04d952e3c4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 1, 2013 at 4:14 PM, John R. Levine wrote: > When there is an interoperability failure between a client and server, it >> really helps to have simple browser support to determine if the fault is >> on >> the server or client. Visual inspection of the server response can >> determine if it is out of spec, without having to write or use debugging >> code. >> > > Like I said: > > PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a >>> bad idea to try to specify that. >>> >> > It already has a hint to developers that they return a web page to generic > clients. If people aren't inclined to take the hint, that's a quality of > implementation issue. > > Personally, I'd prefer that it always return JSON, since if I'm debugging > a JSON client, I want to see what the client sees. But I realize that > tastes can differ. > That's why I suggested text/plain, not text/html. It's the same content as application/rdap+json. For text/plain results, we also indent the json structure, which makes it easy for humans to read. http://rdg.afilias.info/rdap/domain/dog.info -Ernie > R's, > John --f46d0401f8fbd86d4f04d952e3c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 1, 2013 at 4:14 PM, John R. = Levine <johnl@iecc.com> wrote:
When there is an interoperability failure between a client and server, it really helps to have simple browser support to determine if the fault is on=
the server or client. Visual inspection of the server response can
determine if it is out of spec, without having to write or use debugging code.

Like I said:

PS: I'm not saying it's a bad idea to return a web page, I'm sa= ying it's a
bad idea to try to specify that.

It already has a hint to developers that they return a web page to generic = clients. =A0If people aren't inclined to take the hint, that's a qu= ality of implementation issue.

Personally, I'd prefer that it always return JSON, since if I'm deb= ugging a JSON client, I want to see what the client sees. =A0But I realize = that tastes can differ.

That's why = I suggested text/plain, not text/html. It's the same content as applica= tion/rdap+json. For=A0text/plain=A0results, we also indent the json structu= re, which makes it easy for humans to read.

=A0
= -Ernie


R's,
John

--f46d0401f8fbd86d4f04d952e3c4-- From johnl@taugh.com Mon Apr 1 14:01: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 D604921F91A5 for ; Mon, 1 Apr 2013 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqPLF8CupSun for ; Mon, 1 Apr 2013 14:01:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4F15721F919D for ; Mon, 1 Apr 2013 14:01:37 -0700 (PDT) Received: (qmail 45896 invoked from network); 1 Apr 2013 21:01: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:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b347.5159f5b1.k1304; bh=CHLidgUj6hAxEyDnl8DE4piahqM0DLd+kR3iHiy9Dvo=; b=LlWPVQF5bfY4yNOPif2kfyIb0inH4OKjEPaSMMabo2Jq3Yg97TI3pVlMnzLaxNnyRglLMxyUThM4ZVymt1JL8W2pynGTeRsrNYAlG9VHjTtWX00QdUdKN4vG4nW6JPWUkAVqiBifqYOHOn4WMpugTu8HhlJahvAqMUZyo/VB7cA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=b347.5159f5b1.k1304; bh=CHLidgUj6hAxEyDnl8DE4piahqM0DLd+kR3iHiy9Dvo=; b=hpZqGlFFPKjQVmy8b9xe+9QoRw8NxGVuceb0zXXYaOilmevTpuuQ/LNXCb6M/EgAxJj7qBVP+S/MqYhn0e825pOuxZWEZ4TRq9kPNef9/O/GNM5kKXmKR5ea/InPnYQ7hfYwSRG57TN4eBym3mhsMD64Wd9ZHZz4gT0b5AU4DNs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 1 Apr 2013 21:01:15 -0000 Date: 1 Apr 2013 17:01:36 -0400 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF822E@CHAXCH01.corp.arin.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1155500389-1364850096=:4960" Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:01:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1155500389-1364850096=:4960 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> Personally, I'd prefer that it always return JSON, since if I'm debugging >> a JSON client, I want to see what the client sees. But I realize that >> tastes can differ. > > That's why I suggested text/plain, not text/html. It's the same content as > application/rdap+json. For text/plain results, we also indent the json > structure, which makes it easy for humans to read. > http://rdg.afilias.info/rdap/domain/dog.info Andy's prototype returns xml with a link to a stylesheet that makes it look nice in a browser. I wouldn't say that was wrong, which is why I really REALLY do not think that further advice in this section is useful. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1155500389-1364850096=:4960 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDAxMjEwMTM2WjAjBgkqhkiG 9w0BCQQxFgQUhlmsqUd495+BCWVaL/KDC3gBAKsweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAsDJr7RfYdUg2 QIcJ05p3IruJE7CwASMa1nzmOEDV9XnEL68c2Wia3sisdGeN/0vX3pmdsAVW scPyPYGfYlPCnhOHfNa/ZZKcbQAgLK1NOTiKvDN4kelHZhpRObtF7g77G4PX R4cbFdoV9CkNvYQhLTnVut0Z16S5K10q+YaXQ5eSa7u+Y2sDFdDCjQt15TGy tD7uyQcWptHblqKJNjS3kkMS5vUmoSbcOeWFIsCwzrR/h88CbZD88v8mCTcZ zDOPfaHSBZdEjXi/Y7Mo5XtKeC/ecoNxhaQ/oeqAq1UiQj4fB8xiltUo+EMT Sc8t735EHyOzB8kko7PkyKQ2TllKIw== --3825401791-1155500389-1364850096=:4960-- From maarten.wullink@sidn.nl Mon Apr 1 23:35: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 319FC21F9814 for ; Mon, 1 Apr 2013 23:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_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 4Z1oTCH5baXT for ; Mon, 1 Apr 2013 23:35:04 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 7877121F986F for ; Mon, 1 Apr 2013 23:34:56 -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=yguyz80kKqHVa8qXJXZ7DrSdduCsCTbMcVgST4nv5pY=; b=gMDRDXhVAkm5x02xVdqKB9ZC6e0/myxeu+CzwknFjtWYpQcwudL8GNj935uaPgnUlBa46hw7z2/O52XsMLAUIhtVbYIlJfWtNA7Dt7zoIAfzOeJQc9HQv1ScKQl9AZBeTKPLPlrJXb84IKIg2MdIvP1y5BRzQunUM0cq97ChBns= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r326Yr4i012099-r326Yr4k012099 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 2 Apr 2013 08:34:53 +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; Tue, 2 Apr 2013 08:34:52 +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; Tue, 2 Apr 2013 08:34:52 +0200 Message-ID: <515A7C0C.6060703@sidn.nl> Date: Tue, 2 Apr 2013 08:34:52 +0200 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton , "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] Nameserver ip version and usage of variants in domain object examples X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 06:35:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reading throught the response document (http://tools.ietf.org/html/draft-ietf-weirds-json-response-02) i noticed the following. In section "8. The Nameserver Object Class" The description of a nameserver includes a "ipAddresses" element with an array of ip addresses. There is no attribute there for the ip address with which one can determine if it is an v4 of v6 address. The IP address description in section "10. The IP Network Object Class" does however have a "ipVersion" element which can have value 4 or 6. Is it an option to change the nameserver object to also include the ip version attribute like this? "ipAddresses" : [ {"2001:db8::123", 6}, {"192.0.2.1", 4} ], Also In Appendix "C. IDN Query and Response Model" The example given uses a notation of the "variants" element that does not match the description of the element given in section 9.2. 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) iQEcBAEBAgAGBQJRWnwMAAoJEHZPQ3qFDFN19ZgIAKOv1LDsugfBHTP+XOEvLzmy /h2Jo+W1t8BmWj0pc98Z47/1+P098BeCrfrgk4YdOB+peAAk7AB5jbvWDi0N7r7y o1f1aaGbBOCdQpmUGWPApkSY4SDJrnhLQGeSUp8btvyniZU1QHN91dSUkjxbCn1o DFlCF/rB0g861/nXQ1bfOKEbEsDu7fyDVwGqYwg/EywqEajxinH+hkN1DxolDE6l hshbbCMh8VaMGd97iX56pGXBHpVP6n8HnMMtYsLchV/+Qk2G+dlxzjwWVGG5KBAP GLrNSRDlitE1BAg9P3Aqh1RHM9UgRZl/M6z/9rkoTdskCuuSg20mTzvhbmkeGyw= =yyZV -----END PGP SIGNATURE----- From fobispo@isc.org Mon Apr 1 23:37: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 7A52421F9874 for ; Mon, 1 Apr 2013 23:37:29 -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 8kthNaXMBx-8 for ; Mon, 1 Apr 2013 23:37:28 -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 C082421F9873 for ; Mon, 1 Apr 2013 23:37:28 -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 891565F9974; Tue, 2 Apr 2013 06:37:20 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1364884648; bh=azQIV8BEsI+A0q5DIJaxM9uUMxXXnbCUz4TjTLaw4vM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=anA2MD2uoVRaA2qrWOS5ihXrxST+tR+zPEGJQIMvnljWr3G8qa8lUUUSFL4jmHHKG fZqJdWulVKlcLy0bas4ZddBIVre6CuEgCSw0D+lWD7FzN2mGwmUiCmlcOEvKhbaia8 3VDUZd4vHoqx9lgNo89it2rM5/iNE/DrEJrWVApg= Received: from [IPv6:2001:470:1f05:1326:ba:f3eb:f1fe:6ea] (unknown [IPv6:2001:470:1f05:1326:ba:f3eb:f1fe:6ea]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 04C00216C3B; Tue, 2 Apr 2013 06:37:18 +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: <515A7C0C.6060703@sidn.nl> Date: Mon, 1 Apr 2013 23:37:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4E59FDE2-FD7D-4C83-99A3-ECABEF1553F3@isc.org> References: <515A7C0C.6060703@sidn.nl> To: Maarten Wullink X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] Nameserver ip version and usage of variants in domain object examples X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 06:37:29 -0000 How about: "ipAddresses":{ "v4":["192.0.2.1"], "v6":["2001:db8::123"] }, On Apr 1, 2013, at 11:34 PM, Maarten Wullink wrote: > Is it an option to change the nameserver object to also include the ip > version attribute like this? > > "ipAddresses" : > [ > {"2001:db8::123", 6}, > {"192.0.2.1", 4} > ], 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 maarten.wullink@sidn.nl Mon Apr 1 23:48: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 425FE21F9866 for ; Mon, 1 Apr 2013 23:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=-0.471, 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 r+uzSFy2dQyG for ; Mon, 1 Apr 2013 23:48:25 -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 6372E21F984A for ; Mon, 1 Apr 2013 23:48:25 -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=M8iyGun+bVgPgrRy8CHcqidPKwEDPDU5Z/fEtGRiinI=; b=uPGqf/McOLu+5ST28BhqFK7ZbxTW5s4am2IrGkLlYlYEmA3Q4txihf6Gh97e5UP92x473WNX46dR4tth/EMWIFlGoUvpRwZ2BtARauSJImEZ4WJvxNKSpYVbc1umoqz9NGuU/fliO99hUPecWRplnRZgiP3/QfOkVDgxw2PhOKU= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r326mNTW012619-r326mNTY012619 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 2 Apr 2013 08:48:23 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 08:48:23 +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; Tue, 2 Apr 2013 08:48:23 +0200 Message-ID: <515A7F36.20006@sidn.nl> Date: Tue, 2 Apr 2013 08:48:22 +0200 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Francisco Obispo References: <515A7C0C.6060703@sidn.nl> <4E59FDE2-FD7D-4C83-99A3-ECABEF1553F3@isc.org> In-Reply-To: <4E59FDE2-FD7D-4C83-99A3-ECABEF1553F3@isc.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] Cc: "weirds@ietf.org" Subject: Re: [weirds] Nameserver ip version and usage of variants in domain object examples X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 06:48:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/2013 08:37 AM, Francisco Obispo wrote: > How about: > > > "ipAddresses":{ "v4":["192.0.2.1"], "v6":["2001:db8::123"] }, > I have a slight preference for your solution, but the version identifier should be kept consistent with the one used in section 10 (ip address object) and should be "4" or "6". (or change section 10) > > > > On Apr 1, 2013, at 11:34 PM, Maarten Wullink > wrote: > >> Is it an option to change the nameserver object to also include >> the ip version attribute like this? >> >> "ipAddresses" : [ {"2001:db8::123", 6}, {"192.0.2.1", 4} ], > > Francisco Obispo Director of Applications and Services - ISC email: > fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP > KeyID = B38DB1BE > - -- 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) iQEcBAEBAgAGBQJRWn82AAoJEHZPQ3qFDFN1ORIH/jEhMpUaXr2w4+RSv9aXiNxJ 4CkTYWWMb004A4zxYIWdLBUuMgOkdesZZmBXq+cd1FDN6GTISi/zW52Io1Kcjw0x lX39jFsrG3I4vrEBC0K1TiTTUwzl2RMFNNFZv0nNms5dVFg66rH+uDSPyMizztxg Ed3VYCiwVbQ4yqqlQu54cuHptHpl3KBtKdeyvMfrwG5cbIC31WCkxxjyn2M8OzN2 4vBF0i5cqzgUkK2yYc9Yp4hVRjia8n6wgrsNz1mWPfqHVSPfkrk9h1NJiXEBxnKM kysSVwDXN5rsqsdYrJCquyYWrJwR4vn/aGbF/SPhxfXkDTC4YVoG2/4jwQiZQDc= =yzWe -----END PGP SIGNATURE----- From andy@arin.net Tue Apr 2 07:04: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 BC6FA21F8624 for ; Tue, 2 Apr 2013 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 E2IU8ERvgSDO for ; Tue, 2 Apr 2013 07:04:56 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9C21F85DF for ; Tue, 2 Apr 2013 07:04:56 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id F28B521364E; Tue, 2 Apr 2013 10:04:55 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 8A788213647; Tue, 2 Apr 2013 10:04:55 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 10:04:46 -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, 2 Apr 2013 10:04:54 -0400 From: Andy Newton To: Maarten Wullink , Francisco Obispo Thread-Topic: [weirds] Nameserver ip version and usage of variants in domain object examples Thread-Index: AQHOL2yQJdRb0WmhL0uOnEG5fOvPtpjCwFcAgAA26IA= Date: Tue, 2 Apr 2013 14:04:54 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8F1E@CHAXCH01.corp.arin.net> In-Reply-To: <515A7F36.20006@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E2F5E0F475DF0448ABE57A6B1CB04FA@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Nameserver ip version and usage of variants in domain object examples X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 14:04:56 -0000 On 4/2/13 2:48 AM, "Maarten Wullink" wrote: >On 04/02/2013 08:37 AM, Francisco Obispo wrote: >>How about: >>"ipAddresses":{ "v4":["192.0.2.1"], "v6":["2001:db8::123"] }, > >I have a slight preference for your solution, but the version >identifier should be kept consistent with the one used in section 10 >(ip address object) and should be "4" or "6". (or change section 10) I prefer Francisco's solution too. We can change the identifier for IP address object classes to "v4" and "v6". I don't think that is a big deal. -andy From pieter.vandepitte@dns.be Tue Apr 2 07:17: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 32ACB21F8A00 for ; Tue, 2 Apr 2013 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 a41FgsjVWx7C for ; Tue, 2 Apr 2013 07:17:05 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 271FE21F8908 for ; Tue, 2 Apr 2013 07:17:04 -0700 (PDT) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id D16964260010 for ; Tue, 2 Apr 2013 16:17:03 +0200 (CEST) Date: Tue, 2 Apr 2013 16:17:03 +0200 (CEST) From: Pieter Vandepitte To: weirds@ietf.org Message-ID: <1214210827.7549755.1364912223524.JavaMail.root@staff.dns.be> In-Reply-To: <20130329222305.9301.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7549754_1951168531.1364912223523" X-Originating-IP: [77.67.63.234] X-Mailer: Zimbra 7.2.0_GA_2681 (ZimbraWebClient - GC26 (Linux)/7.2.0_GA_2681) Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:17:06 -0000 ------=_Part_7549754_1951168531.1364912223523 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit A few short comments on my behalf: Please note that I don't want to offend anyone, but I just want to make my opinion clear... I fully agree: RFC 2616 indeed makes GET and HEAD mandatory and it is a bad idea to duplicate text, but: [1] very few standards are implemented correctly. Don't get me wrong: i would love to have every bit of code being fully compliant, but this is the reality. If we don't mention a thing on the HEAD method i don't think we can expect it will be implemented correctly. [2] everyone following the list is very smart and reads every single letter of an RFC (including links to others), but we cannot assume every developer will read all RFC's in the references section. Repeating will emphasise the importance of the HEAD method. [3] I'm working on an implementation here on Jetty and currently performing a HEAD (only implemented GET), results in a "HTTP/1.1 405 Request method 'HEAD' not supported" Other web apps will have similar behavior. So I would not state that "a lot of servers will probably support it for free anyway." I think if we don't mention it, it will never be implemented by most registries. [4] It's about the 'semantics' of the HEAD method. We don't really 'duplicate' text. It's more giving a meaning to the HEAD method [5] I think I didn't state the problem 100% clear. Domain Availability is not just [a] performing a lookup of a domain, [b] then just throw away all information and [c] return available or not. Domain availability has a very different access profile (unlimited, no content restriction) and usage profile ( > 40 times more queries per second) than WHOIS and so is implemented slightly different. It's not merely a "for free" feature by letting a web server strip off the contents [6] a side note on connection cost: 3205 bytes (GET) vs.208 bytes (HEAD) does make a difference under heavy traffic... On the other hand, if the focus of the working group is purely defining a replacement for WHOIS, then this is fine by me and I can understand the decision. I would not want to slow down any standardization process because of a tiny feature. Best regards, Pieter ----- Original Message ----- > From: "John Levine" > To: weirds@ietf.org > Sent: Friday, March 29, 2013 11:23:05 PM > Subject: Re: [weirds] Working Group Last Call: > draft-ietf-weirds-using-http > >> I agree. We should just say that HEAD should be supported. Now is > >> that a > >> SHOULD or a MUST. I think MUST given 2616's language. > > > >[Alexander Mayrhofer] > >I think it's a MUST. However, we might want to clarify it comes from > >the HTTP specs, rather than > >from the RDAP specs. Maybe something along the lines of : "GET and > >HEAD are REQUIRED methods in > >HTTP. Therefore, RDAP servers MUST implement at least those two > >methods". > Since RFC 2616 already makes GET and HEAD mandatory, the correct > thing > for us to say about that is nothing. It is rarely a good idea for one > standards document to restate bits of another document, since the two > statements never quite say the same thing. > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds ------=_Part_7549754_1951168531.1364912223523 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>
A f= ew short comments on my behalf:

Please note that I don't want to offend anyo= ne, but I just want to make my opinion clear...

I fully agree: RFC 2616 inde= ed makes GET and HEAD mandatory and it is a bad idea to duplicate text, but= :
<= br>
[1] very few standards are implemented correctly. Don't get me wrong: i wo= uld love to have every bit of code being fully compliant, but this is the r= eality. If we don't mention a thing on the HEAD method i don't think we can= expect it will be implemented correctly.
[2] everyone following the list is v= ery smart and reads every single letter of an RFC (including links to other= s), but we cannot assume every developer will read all RFC's in the referen= ces section. Repeating will emphasise the importance of the HEAD method.
[3] I= 'm working on an implementation here on Jetty and currently performing a HE= AD (only implemented GET), results in a "HTTP/1.1 405 Request method 'HEAD'= not supported" 
Other web apps will have similar behavior. So I would no= t state that "a lot of servers will probably support it for free anyway."
I th= ink if we don't mention it, it will never be implemented by most registries= .
[= 4] It's about the 'semantics' of the HEAD method. We don't really 'duplicat= e' text. It's more giving a meaning to the HEAD method 
[5] I think I did= n't state the problem 100% clear. Domain Availability is not just [a] perfo= rming a lookup of a domain, [b] then just throw away all information and [c= ] return available or not. Domain availability has a very different access = profile (unlimited, no content restriction) and usage profile ( > 40 tim= es more queries per second) than WHOIS and so is implemented slightly diffe= rent. It's not merely a "for free" feature by letting a web server strip of= f the contents
[6] a side note on connection cost: 3205 bytes (GET) vs.208 byt= es (HEAD) does make a difference under heavy traffic...

= On the other hand, i= f the focus of the working group is purely defining a replacement for WHOIS= , then this is fine by me and I can understand the decision. I would not wa= nt to slow down any standardization process because of a tiny feature. = ;
<= br>
Best regards,

Pieter


To: weirds@i= etf.org
Sent: Friday, March 29, 2013 11:23:05 PM
Subject: <= /b>Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http
>> I agree. We should just say that HEAD should be supported. Now i= s that a
>> SHOULD or a MUST. I think MUST given 2616's language.<= br>>
>[Alexander Mayrhofer]
>I think it's a MUST. However, = we might want to clarify it comes from the HTTP specs, rather than
>f= rom the RDAP specs. Maybe something along the lines of :  "GET and HEA= D are REQUIRED methods in
>HTTP. Therefore, RDAP servers MUST impleme= nt at least those two methods".

Since RFC 2616 already makes GET an= d HEAD mandatory, the correct thing
for us to say about that is nothing.=  It is rarely a good idea for one
standards document to restate bi= ts of another document, since the two
statements never quite say the sam= e thing.

R's,
John


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

------=_Part_7549754_1951168531.1364912223523-- From james.mitchell@ausregistry.com.au Tue Apr 2 08:00: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 5B69321F86AD for ; Tue, 2 Apr 2013 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUtO2PSvmIVo for ; Tue, 2 Apr 2013 08:00:09 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4521F8652 for ; Tue, 2 Apr 2013 08:00:08 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 03 Apr 2013 02:00:08 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 3 Apr 2013 02:00:03 +1100 From: James Mitchell To: Alexander Mayrhofer , Maarten Wullink , Pieter Vandepitte Date: Wed, 3 Apr 2013 02:00:04 +1100 Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: Ac4vssBSRkFwqTjZTl+rZEznQ1SQdw== Message-ID: In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F5E6@NICS-EXCH.sbg.nic.at> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:00:10 -0000 Alex, A domain name may be unavailable because: - the name is in use (HTTP 200) - the name is valid but has not been registered (HTTP 404 optionally with content) - the name is reserved/withheld from registration (HTTP 404 optionally with content?) - the name contains disallowed characters e.g. "one&two.example" or ".example" (HTTP 404 optionally with content?) - the name could not possibly be a domain name "<64 characters>.example" (HTTP 404 optionally with content?) - etc.. How does a client identify the valid unregistered domain name? If we want a standardised DAC over HTTP service then some content is required either in the using-http document through different response codes, or a WEIRDS DAC document. I think I'd prefer the latter. Regards, James On 30/03/13 12:03 AM, "Alexander Mayrhofer" wrote: >> > And I was thinking right away of something else: wouldn't it be a good >> > idea to introduce a HEAD method? A lot of / some registries currently >> > have some kind of Domain Availability Service which simply returns >> > whether the domain which is looked up, is still available (yes or no). >> > A "HEAD /domains/example.com" would e.g. >> > return a "200 OK" if the domain name exists, and a "404 NOT FOUND" >> > if the domain name is still available (i.e. the same result code as if >> > the client performed a GET) > >[Alexander Mayrhofer] >From the DNR perspective, i fully agree. We (.at) have a lightweight >availability check based on the "finger" protocol, and would definitely >need a similar lightweight method in WIERDS if we considered the protocol >for deployment.=20 > >From the WEIRDS/protocol perspectiv: > >RFC 2616 says that HEAD MUST be supported anyways. However, it also says >that (see section 9.4) > >"The metainformation contained > in the HTTP headers in response to a HEAD request SHOULD be identical > to the information sent in response to a GET request" > >which means that, for example if the GET response includes a >Content-Length header field, the respective HEAD response should also >include this header field. Which, in turn, means that the HEAD method >would also need to fully evaluate the query, fetch the data, and >calculate the response body, just because it needs to provide the header >filed - and this would contradict the purpose of HEAD resembling a >light-weight alternative to GET (at least on the server side). > >Of course, we could leave out the various problematic header fields in >the HEAD response, but this would stretch the purpose of SHOULD a bit. >Alternatively, we could strip the headers from both the GET and HEAD >responses - which probably doesn't make sense either. > >Practically, i would probably simply leave out the problematic headers in >the HEAD responses, and bend the HTTP specs, rather than losing the >advantage of the "lightweight" method. > >We can solve this in the document by simply saying that servers SHOULD >also support HEAD, and leave the decision whether or not to provide >GET-identical headers to the implementors. > >Alex > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Tue Apr 2 08:36: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 D83DE21F8CF4 for ; Tue, 2 Apr 2013 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 t+2zMza-BQQ2 for ; Tue, 2 Apr 2013 08:36:41 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0FC21F8C04 for ; Tue, 2 Apr 2013 08:36:41 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id D421D213647; Tue, 2 Apr 2013 11:36:40 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id E76BF213596; Tue, 2 Apr 2013 11:36:39 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 11:36:31 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 11:35:54 -0400 From: Andy Newton To: James Mitchell , Alexander Mayrhofer , Maarten Wullink , Pieter Vandepitte Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i77WAAgAAII4CAAM05AIAAJe4AgAZp0AD//8bSgA== Date: Tue, 2 Apr 2013 15:35:26 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8FCA@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <31442E9C0963824BAF9FBE58E4490927@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:36:42 -0000 On 4/2/13 11:00 AM, "James Mitchell" wrote: >Alex, > >A domain name may be unavailable because: >- the name is in use (HTTP 200) >- the name is valid but has not been registered (HTTP 404 optionally with >content) >- the name is reserved/withheld from registration (HTTP 404 optionally >with content?) >- the name contains disallowed characters e.g. "one&two.example" or >".example" (HTTP 404 optionally with content?) >- the name could not possibly be a domain name "<64 characters>.example" >(HTTP 404 optionally with content?) >- etc.. > >How does a client identify the valid unregistered domain name? If we want >a standardised DAC over HTTP service then some content is required either >in the using-http document through different response codes, or a WEIRDS >DAC document. I think I'd prefer the latter. > >Regards, >James James, This is very well said. I don't think this should go into using-http as that refers to RDAP. The semantics you have outlined are different enough that DAC is really a separate thing from RDAP. However it is very close both in protocol operation and in subject area, so I think it is reasonable that if a couple of people were to put this in I-D form we could seek it as a working group item even if we had to ask the IESG to modify the charter ever so slightly. It would seem a shame to spin up yet another working group just to handle DAC since it so closely related to RDAP. -andy From superuser@gmail.com Tue Apr 2 09:40: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 2AC0821F8CD2 for ; Tue, 2 Apr 2013 09:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx64yyz3ZMlx for ; Tue, 2 Apr 2013 09:40:13 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1121F8C83 for ; Tue, 2 Apr 2013 09:40:13 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so488298wer.40 for ; Tue, 02 Apr 2013 09:40: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=V+JvGkeIokzMb1XBQPQ3QD9rQagJPFyiYrVOMYfompY=; b=XnhhGT19ZbzS3DRfyHTPHNjScmtJUnNge3KoVwOZ+3OmQeClOS7Blw9F5OTVz/n00g dRu8FUGIh8Qi7QCOcq2ZbBkjLf8Cczs6TF5DLtN1OLTxaSRDIoUxJY1X9Kb4brzY/ww9 5inIVzaadayDGmlraF7W/DsvvXCbP1IoLc2+LKQwQJ6VJuE6uC3bNHEAyEt+SXtkNVci yE50P/YkYgFue7IoPOBYcI6HsMedQjiBSqYnhcuxi5rBObrqlqdUqquU07rIP7jTc5cd dbSVeD95c4GICdJ2ErT6/Q8c4ACudv/8uJ/4SjPu70V6f8dui8wp5j6JfKOIEI5mhOTl Ro+w== MIME-Version: 1.0 X-Received: by 10.180.89.243 with SMTP id br19mr10143735wib.5.1364920812457; Tue, 02 Apr 2013 09:40:12 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Tue, 2 Apr 2013 09:40:12 -0700 (PDT) Date: Tue, 2 Apr 2013 09:40:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba24d2c553c04d96364cd Subject: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Tue, 02 Apr 2013 16:40:14 -0000 --e89a8f3ba24d2c553c04d96364cd Content-Type: text/plain; charset=ISO-8859-1 Colleagues, We propose to adopt this draft as a WG item seeking Informational status. Since the content includes work worth recording, and also because the results of the inventory work have influenced some design choices made in other documents, we believe this is an appropriate action for the WG to take. We propose to leave the current author set unmodified. Please provide comments of support or objection, preferably by the end of next week. -MSK, WEIRDS co-chair --e89a8f3ba24d2c553c04d96364cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

We propose to adop= t this draft as a WG item seeking Informational status.=A0 Since the conten= t includes work worth recording, and also because the results of the invent= ory work have influenced some design choices made in other documents, we be= lieve this is an appropriate action for the WG to take.

We propose to leave the current author set unmodified.

Ple= ase provide comments of support or objection, preferably by the end of next= week.

-MSK, WEIRDS co-chair

--e89a8f3ba24d2c553c04d96364cd-- From shollenbeck@verisign.com Tue Apr 2 09:42:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E1921F8CD2 for ; Tue, 2 Apr 2013 09:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imp2xAOErvXJ for ; Tue, 2 Apr 2013 09:42:38 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9C32921F8C83 for ; Tue, 2 Apr 2013 09:42:36 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUVsKfLDNA9er37Bp7CkCfZSPO/IHUxeo@postini.com; Tue, 02 Apr 2013 09:42:37 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r32GgXnC012352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 12:42:33 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 2 Apr 2013 12:42:32 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-object-inventory Thread-Index: AQHOL8DBh4tT6ewFPkOnVsrh6boXG5jDInEw Date: Tue, 2 Apr 2013 16:42:31 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2434CEE5@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_831693C2CDA2E849A7D7A712B24E257F2434CEE5BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Tue, 02 Apr 2013 16:42:39 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2434CEE5BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It makes sense to refer to this document in the response draft. I'd like to= see it adopted. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, April 02, 2013 12:40 PM To: weirds@ietf.org Subject: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-object-inven= tory Colleagues, We propose to adopt this draft as a WG item seeking Informational status. = Since the content includes work worth recording, and also because the resul= ts of the inventory work have influenced some design choices made in other = documents, we believe this is an appropriate action for the WG to take. We propose to leave the current author set unmodified. Please provide comments of support or objection, preferably by the end of n= ext week. -MSK, WEIRDS co-chair --_000_831693C2CDA2E849A7D7A712B24E257F2434CEE5BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It makes sense to refer t= o this document in the response draft. I’d like to see it adopted.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, April 02, 2013 12:40 PM
To: weirds@ietf.org
Subject: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-objec= t-inventory

 

Colleagues,

We propose to adopt t= his draft as a WG item seeking Informational status.  Since the conten= t includes work worth recording, and also because the results of the invent= ory work have influenced some design choices made in other documents, we believe this is an appropriate action for the = WG to take.

We propose to leave the current author set unmodified.

Please provide commen= ts of support or objection, preferably by the end of next week.<= /p>

-MSK, WEIRDS co-chair=

--_000_831693C2CDA2E849A7D7A712B24E257F2434CEE5BRN1WNEXMBX01vc_-- From carlosm3011@gmail.com Tue Apr 2 09:44:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D567021F8CD2 for ; Tue, 2 Apr 2013 09:44:39 -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 cHIXvMRUVB-i for ; Tue, 2 Apr 2013 09:44:39 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF221F8C78 for ; Tue, 2 Apr 2013 09:44:39 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id ox1so752826veb.35 for ; Tue, 02 Apr 2013 09:44:38 -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=KFXkZ9F2OiAoHCWq9RLEIy+khFwS21gNVErL5Z36npc=; b=y83GhWoYsfMfjGLV8tZWxVvQdkATtqYC73DXufpk/qlzZaoIScFah3ahhV9hiJqOy8 L+unkzMJf9Tz6C5amRH6lXvK2LJHo6ph/EKBycoWEKyXm3lKWZtvxx+BtgYCe5FXGs/W kALAI2xVhllvEZXEk1+O79rsCDARfZHFx4rIc7DDyfPfW5HC7M+RaRIpTXpJhO4I1Kl0 J/uWaynVZJnfRmdigDqqmpYAcm1GBG6c8v714ZJe3zYokY6/fTof6LtvMA4hEc96J1Dl fLm8U5dEgv/Q5rE8KqElLfPVyapaNnBYYxMugl9jzOU+zYa8J7Y86SGLhF45aFgxiBNz UHbA== X-Received: by 10.52.23.18 with SMTP id i18mr11182715vdf.46.1364921078740; Tue, 02 Apr 2013 09:44:38 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:c150:a248:29df:a29a]) by mx.google.com with ESMTPS id s20sm2147668vdg.2.2013.04.02.09.44.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 09:44:37 -0700 (PDT) Message-ID: <515B0B05.1010401@gmail.com> Date: Tue, 02 Apr 2013 13:44:53 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-object-inventory 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, 02 Apr 2013 16:44:39 -0000 I support WG adoption of this draft. It provides a useful reference even when it might get quickly outdated. regards, ~Carlos On 4/2/13 1:40 PM, Murray S. Kucherawy wrote: > Colleagues, > > We propose to adopt this draft as a WG item seeking Informational > status. Since the content includes work worth recording, and also > because the results of the inventory work have influenced some design > choices made in other documents, we believe this is an appropriate > action for the WG to take. > > We propose to leave the current author set unmodified. > > Please provide comments of support or objection, preferably by the end > of next week. > > -MSK, WEIRDS co-chair > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From johnl@iecc.com Tue Apr 2 09:49: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 9063421F87B1 for ; Tue, 2 Apr 2013 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.942 X-Spam-Level: X-Spam-Status: No, score=-110.942 tagged_above=-999 required=5 tests=[AWL=0.257, 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 bxDHB38lFNdz for ; Tue, 2 Apr 2013 09:49: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 B07B821F86D3 for ; Tue, 2 Apr 2013 09:49:35 -0700 (PDT) Received: (qmail 91988 invoked from network); 2 Apr 2013 16:49:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 16:49:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515b0c1e.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=/rftR2DLMtQyCYSnpmm4WboHd9y+1QaFvIaDnKYhF6Y=; b=ITQjNE51Y61hp16WMAWIGXbvb679HLwFWW2ZC0xI8U6517IHU6lLWrkYsDPyAlDE44q+QAK4hHHkFgucTZMO5LbVXXwRcRFzJwoGPF1s3rb4panO9XmNoDaUeQBy/ir270z2pD2eLxUUkNLaVmZbXoGuliFYXleZIgcFM2OhfF8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515b0c1e.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=/rftR2DLMtQyCYSnpmm4WboHd9y+1QaFvIaDnKYhF6Y=; b=tfnSwIwT3T2b5qcflY14nRk0e7bMLgdndE3BObuI/1eDd7cRvl7odQzPzkmPvCJ9PQRzLb8OqupkAE7qQvWWe6bZbM6THwLq+XPw0Po4pfQvizXgPGn/MW8Ml7zUSNRL2Xo9vcn0C4ZKErbCEVm7Qei032mDBGPA523s+XxIxZc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 16:49:10 -0000 Message-ID: <20130402164910.53225.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2434CEE5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Tue, 02 Apr 2013 16:49:36 -0000 In article <831693C2CDA2E849A7D7A712B24E257F2434CEE5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >It makes sense to refer to this document in the response draft. I'd like to see it adopted. Agreed. Nice piece of work, worth preserving. From andy@arin.net Tue Apr 2 09:54:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5A21F8B1E for ; Tue, 2 Apr 2013 09:54:39 -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, HTML_MESSAGE=0.001, 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 nWFPTpObbMKq for ; Tue, 2 Apr 2013 09:54:39 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4057221F8B04 for ; Tue, 2 Apr 2013 09:54:39 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D7C951651FA; Tue, 2 Apr 2013 12:54:08 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 517441650AE; Tue, 2 Apr 2013 12:54:04 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 2 Apr 2013 12:53:42 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 12:53:51 -0400 From: Andy Newton To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-object-inventory Thread-Index: AQHOL8Km4JfzTCKcNkihE0SlutgoyQ== Date: Tue, 2 Apr 2013 16:53:49 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF9092@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [192.149.252.228] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF9092CHAXCH01corpari_" MIME-Version: 1.0 Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Tue, 02 Apr 2013 16:54:39 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF9092CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Murray S. Kucherawy" > Date: Tuesday, April 2, 2013 12:40 PM To: "weirds@ietf.org" > Subject: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-object-inven= tory Colleagues, We propose to adopt this draft as a WG item seeking Informational status. = Since the content includes work worth recording, and also because the resul= ts of the inventory work have influenced some design choices made in other = documents, we believe this is an appropriate action for the WG to take. We propose to leave the current author set unmodified. Please provide comments of support or objection, preferably by the end of n= ext week. -MSK, WEIRDS co-chair I support adoption as outlined here. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF9092CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <2A0957D59D050047B23E3314943EC461@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Tuesday, April 2, 2013 12:40 = PM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Call for adoption= : draft-zhou-weirds-dnrd-ap-object-inventory

Colleagues,

We propose to adopt this draft as a WG item seeking Informational status.&n= bsp; Since the content includes work worth recording, and also because the = results of the inventory work have influenced some design choices made in o= ther documents, we believe this is an appropriate action for the WG to take.

We propose to leave the current author set unmodified.

Please provide comments of support or objection, preferably by the end of n= ext week.

-MSK, WEIRDS co-chair

I support adoption as outlined here.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBF9092CHAXCH01corpari_-- From alexander.mayrhofer@nic.at Wed Apr 3 00:01: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 C2F8021F856C for ; Wed, 3 Apr 2013 00:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.13 X-Spam-Level: X-Spam-Status: No, score=-8.13 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A007YIjibqo for ; Wed, 3 Apr 2013 00:01:00 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id CB59321F8556 for ; Wed, 3 Apr 2013 00:00:58 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Wed, 3 Apr 2013 08:58:59 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Wed, 3 Apr 2013 09:00:46 +0200 From: Alexander Mayrhofer To: Andy Newton , James Mitchell , Maarten Wullink , Pieter Vandepitte Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwue5Zoxq1BWXk25CcORrCdypJi7mY8AgAAIIoCAAM05AIAAMovAgAZMcACAAAnhAIABIqPw Date: Wed, 3 Apr 2013 07:00:45 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07509830A50@NICS-EXCH.sbg.nic.at> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8FCA@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF8FCA@CHAXCH01.corp.arin.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 07:01:00 -0000 > >Alex, > > > >A domain name may be unavailable because: > >- the name is in use (HTTP 200) > >- the name is valid but has not been registered (HTTP 404 optionally > >with > >content) > >- the name is reserved/withheld from registration (HTTP 404 optionally > >with content?) > >- the name contains disallowed characters e.g. "one&two.example" or > >".example" (HTTP 404 optionally with content?) > >- the name could not possibly be a domain name "<64 > characters>.example" > >(HTTP 404 optionally with content?) [Alexander Mayrhofer]=20 Agreed. Essentially, the way we see our current WHOIS service is that it pr= ovides information about registered names. Nothing more. Particularly, it d= oes not perform any policy checks on the string that was queried for. It's = like the phone book - just because there's no entry for 123 in the phone bo= ok doesn't mean you can get that number. > >How does a client identify the valid unregistered domain name? If we > >want a standardised DAC over HTTP service then some content is required > >either in the using-http document through different response codes, or > >a WEIRDS DAC document. I think I'd prefer the latter. [Alexander Mayrhofer]=20 Agreed, again. DAC doesn't fit the "information directory" model very well = - the DAC should be a seperate document.=20 > This is very well said. I don't think this should go into using-http as t= hat refers > to RDAP. The semantics you have outlined are different enough that DAC is > really a separate thing from RDAP. However it is very close both in proto= col > operation and in subject area, so I think it is reasonable that if a coup= le of > people were to put this in I-D form we could seek it as a working group i= tem > even if we had to ask the IESG to modify the charter ever so slightly. It= would > seem a shame to spin up yet another working group just to handle DAC sinc= e > it so closely related to RDAP. [Alexander Mayrhofer]=20 Agreed, again. Resource concerns aside, i'm happy to collaborate with other= s to create a DAC draft, in case there's significant interest in that. Alex From pieter.vandepitte@dnsbelgium.be Wed Apr 3 00:02: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 DAC1B21F856E for ; Wed, 3 Apr 2013 00:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-0.390, 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 IrL4OVpklLRi for ; Wed, 3 Apr 2013 00:02:24 -0700 (PDT) Received: from nug.nucleus.be (nug.nucleus.be [77.73.96.109]) by ietfa.amsl.com (Postfix) with ESMTP id 33C3A21F856C for ; Wed, 3 Apr 2013 00:02:24 -0700 (PDT) Received: from lpieterv.dns.be (unknown [77.67.63.234]) by nug.nucleus.be (Postfix) with ESMTPSA id 7AE61426001A for ; Wed, 3 Apr 2013 09:02:22 +0200 (CEST) Message-ID: <515BD3FE.80604@dnsbelgium.be> Date: Wed, 03 Apr 2013 09:02:22 +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] jcard and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 07:02:25 -0000 Hi, does anybody know how an entity will look like with jcards? Or isn't it decided yet that we will go on with jcards? I think there are roughly 2 possibilities: either [1] we integrate RIR and DNR specific attributes as VCARD extensions or [2] we integrate jcard as a property of the entity. Are there other idea's? [1] will look like ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Simon Perreault"], ["n", {}, "text", ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]] ], ... ["x-weirds-handle", {}, "text", "XXXX"], ["x-weirds-port43", {}, "text", "whois.example.net"], ... ] ] [2] will look like { "handle" : "XXXX", "vcard" : ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Simon Perreault"], ["n", {}, "text", ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]] ], ... ] ] ], ... "port43" : "whois.example.net", } I would prefer [1] -- *Pieter Vandepitte* *Software Engineer* +32 16 29 89 27 *www.dnsbelgium.be* From andy@arin.net Wed Apr 3 02:43: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 C6CBE21F8548 for ; Wed, 3 Apr 2013 02:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqptvmM66imY for ; Wed, 3 Apr 2013 02:43:23 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id F148221F84CA for ; Wed, 3 Apr 2013 02:43:22 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 77B1F213664; Wed, 3 Apr 2013 05:43:15 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 3091F2135FF; Wed, 3 Apr 2013 05:43: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; Wed, 3 Apr 2013 05:43:01 -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, 3 Apr 2013 05:43:07 -0400 From: Andy Newton To: Pieter Vandepitte , "weirds@ietf.org" Thread-Topic: [weirds] jcard and entities Thread-Index: AQHOMDkPHLMq8P74dE+J4Nydnd5wUZjEPtWA Date: Wed, 3 Apr 2013 09:43:07 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF9412@CHAXCH01.corp.arin.net> In-Reply-To: <515BD3FE.80604@dnsbelgium.be> 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.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <531E05E152B9234DBCEE6E2456E3C802@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] jcard and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 09:43:24 -0000 On 4/3/13 3:02 AM, "Pieter Vandepitte" wrote: >Hi, > >does anybody know how an entity will look like with jcards? Or isn't >it decided yet that we will go on with jcards? [..snip..] > >[2] will look like > > { > "handle" : "XXXX", > "vcard" : > ["vcard", > [ > ["version", {}, "text", "4.0"], > ["fn", {}, "text", "Simon Perreault"], > ["n", > {}, > "text", > ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]] > ], > ... > ] > ] > ], > ... > > "port43" : "whois.example.net", > > } > This is the form proposed by Simon and being incorporated as we speak. See http://www.ietf.org/mail-archive/web/weirds/current/msg02153.html The reason for this is that RDAP has its own set of common data structures that are uses by many object classes including the entity object class. If we went with approach 1 then those structures would be different between entities and all other object classes in RDAP. I'm working on the new draft and it will be out as soon as possible. -andy From stpeter@stpeter.im Wed Apr 3 05:47: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 D7DB921F8D86 for ; Wed, 3 Apr 2013 05:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGOI8GmX61OQ for ; Wed, 3 Apr 2013 05:47:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EF77F21F8D63 for ; Wed, 3 Apr 2013 05:47:32 -0700 (PDT) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C8727406A8; Wed, 3 Apr 2013 06:57:15 -0600 (MDT) Message-ID: <515C24E2.1050705@stpeter.im> Date: Wed, 03 Apr 2013 06:47:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Pieter Vandepitte References: <515BD3FE.80604@dnsbelgium.be> In-Reply-To: <515BD3FE.80604@dnsbelgium.be> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] jcard and entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 12:47:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/3/13 1:02 AM, Pieter Vandepitte wrote: > Hi, > > does anybody know how an entity will look like with jcards? Or > isn't it decided yet that we will go on with jcards? As a reminder, I sure hope that folks here (especially the document editors and WG chairs) are paying attention to the work of the JCARDCAL WG: https://datatracker.ietf.org/wg/jcardcal/ The JCARDCAL WG is moving quite quickly, so if you have feedback please provide it on the jcardcal@ietf.org mailing list. Thanks! Peter (JCARDCAL WG co-chair) - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXCTiAAoJEOoGpJErxa2prWIP/RO6YpVwHqNnZuo9ZeEr2nod yswvEmBRGNCDid5ax4uCO0ECJq5zmFlERq1PYlRTGGCHp+VL6vtGmfzO57E9BXa4 IPkbVXSS9dwfGrweVas3vH9aludqmnagLyQ4cbIanz1B3mmAld9H2xSJVdiPJUEA j+9cykuyD5GdaG/XtqcdeKUvzNzDrVQb1xP7aFZsmmU3dfIWqnDvD70fyN2TlQc3 pyBUJO+D8jtkYvycgo2BABOlzI4cw4Y1iTuIMJmJvMwPfa/56Rx52VJEfSddKgtV thwf0lqu3mMLxQO7UomghlImEGUmqjGknmWOuAoNa6mbxmXvd/BcjnLDH92nIR/U b5fov7g0tTUW5KvJMOW/3fLJiqXgCo1/kgdAJPtf/KNwAold/0FvI1Trz8iMbC9R MXENAEdCdJWYx9KiB/v556RdZKfqBr/EZgsAKitJQt2enStuwKra45Pcwf4S/+Y5 2YUMlibeD5BAaTiSp57XH5yj98Y6qWotczpESuJkDiWEcwnTg2ytD/LcPikZDh3J mLW5/eyKL/KCgYpz1ORZnFdjjUkUWvxpUKFEym4a80sf5cnC9X9cjZoLsddf2/+b 4tX2nDEwJw+DVVNGJI3/IPSd6MLdQoBhO0blfc4+qxhpXTtn0qusOI1Ox2tEPSkM VeyuYVsEB+FzAWBHitaO =CJB5 -----END PGP SIGNATURE----- From aservin@lacnic.net Wed Apr 3 17:26: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 155D121F87B7 for ; Wed, 3 Apr 2013 17:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.525 X-Spam-Level: X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFrb004pX-wn for ; Wed, 3 Apr 2013 17:26:22 -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 7C95121F8758 for ; Wed, 3 Apr 2013 17:26:22 -0700 (PDT) Received: from [192.168.0.14] (02d8fd5d.bb.sky.com [2.216.253.93]) by mail.lacnic.net.uy (Postfix) with ESMTP id A9EFF308446 for ; Wed, 3 Apr 2013 21:26:08 -0300 (UYT) Message-ID: <515CC8A6.5010900@lacnic.net> Date: Thu, 04 Apr 2013 01:26:14 +0100 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: 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] Call for adoption: draft-zhou-weirds-dnrd-ap-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, 04 Apr 2013 00:26:23 -0000 Support. It is a very good reference to keep for the future. Also, when we (the RIRs) start working together on this (which eventually became weirds) we did a similar analysis and inventory. Ours was much simpler and we didn't write it down so formally, nevertheless if the WG wanted to add some of that work let me know and I will dig on my notes. Regards, as On 4/2/13 5:40 PM, Murray S. Kucherawy wrote: > Colleagues, > > We propose to adopt this draft as a WG item seeking Informational > status. Since the content includes work worth recording, and also > because the results of the inventory work have influenced some design > choices made in other documents, we believe this is an appropriate > action for the WG to take. > > We propose to leave the current author set unmodified. > > Please provide comments of support or objection, preferably by the end > of next week. > > -MSK, WEIRDS co-chair > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From maarten.wullink@sidn.nl Wed Apr 3 23:47: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 91F5B21F9494 for ; Wed, 3 Apr 2013 23:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=-0.314, 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 plulW5CyL7-C for ; Wed, 3 Apr 2013 23:47:50 -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 923E921F85ED for ; Wed, 3 Apr 2013 23:47:50 -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=0ZUy8ctMKwFwCBjBOLJ3isrx74yC6zbWg7n0T3euWps=; b=Ak4e9UlK6CT4U/dQgM+J0RgY8GMhsHjjReE/QNPm+1t5PfVipcURw0wLzghRer0/wt7onM955hq40AsHZP77qfnEo5X/TWHFwTjvnD2QgjwXf9fjyyVk09zhwUMoORSXIfBNDutsoLJPNaR/J+ZjdwQPPcRFfAX6MtnDV19nyfg= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r346ll9v017698-r346ll9x017698 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 4 Apr 2013 08:47:47 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 4 Apr 2013 08:47:47 +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, 4 Apr 2013 08:47:47 +0200 Message-ID: <515D2212.4070505@sidn.nl> Date: Thu, 4 Apr 2013 08:47:46 +0200 From: Maarten Wullink Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" 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] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 06:47:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know if this has been mentioned before but when looking through the references i noticed that the url for the CORS refererence is broken. it should be http://www.w3.org/TR/cors/ for the latest version or http://www.w3.org/TR/2013/CR-cors-20130129/ for the version referenced from the draft. On 03/27/2013 05:53 PM, Murray S. Kucherawy wrote: > Colleagues, > > We would like to initiate a two-week Working Group Last Call on > draft-ietf-weirds-http. A version 03 was just pushed to the > datatracker: > > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > > Last call will end Wednesday, April 10th. > > Please review and comment on the draft, even if it is only to say > on the record "I have reviewed this document thoroughly and it > looks good." We would like to have no fewer than five people > report that they have taken a look at the whole document and > reported their findings, and will be reticent to send it to the > IESG without that. We're also keen to hear from people that have > implemented the specification as to their views on clarity, > correctness, and completeness. > > Thanks, > > -MSK and Olaf, your co-chairs > > > > _______________________________________________ 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) iQEcBAEBAgAGBQJRXSISAAoJEHZPQ3qFDFN1R28IAOK4M0/JpEBp0Asm6K3vuXRE bH54cmCaUckPdKwznOt/bjXNiWyJWvx4hD64a777vuLX53l6JCzsiILjqWgVrQE+ if7NJcfsl+R7cTaGtLObTzNmnD3h/vXx5trdOBqYmWdz6p8XxQCVsFrk1oQ1JRN8 Ydzs0NxZw+Df7DVzYPJl85/oakLRjurz5N0xBoc/anhqnnv+1TfoPNbpAt0mFVfk S9EDtF7XLgsqWZo+iWRtq+lQpKEoohOaDwQ9QNlt7aiC7iyhc9AQtf2hZvM8V02V d60ojXrtlbzSyE5IJ3CidnxnkoRZ8rDfqVWoClS8Lu2GKqg3BIWPDkSUemJvTTY= =n51A -----END PGP SIGNATURE----- From andy@arin.net Thu Apr 4 02:27: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 EA13521F9622 for ; Thu, 4 Apr 2013 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.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 cDZY1TsmKjzC for ; Thu, 4 Apr 2013 02:27:09 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6CA21F9621 for ; Thu, 4 Apr 2013 02:27:09 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id F17E9213623; Thu, 4 Apr 2013 05:27:08 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 6BB422135AA; Thu, 4 Apr 2013 05:27:08 -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, 4 Apr 2013 05:26:47 -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, 4 Apr 2013 05:26:53 -0400 From: Andy Newton To: Maarten Wullink , "Murray S. Kucherawy" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5jF7ZcA///pYQA= Date: Thu, 4 Apr 2013 09:26:53 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBF9B2E@CHAXCH01.corp.arin.net> In-Reply-To: <515D2212.4070505@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [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] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 09:27:10 -0000 On 4/4/13 2:47 AM, "Maarten Wullink" wrote: >I don't know if this has been mentioned before but when looking >through the references i noticed that the url for the CORS refererence >is broken. > >it should be http://www.w3.org/TR/cors/ for the latest version or >http://www.w3.org/TR/2013/CR-cors-20130129/ for the version referenced >from the draft. Thanks Maarten. I'll fix that on the next respin. The ref in the bibxml3 library didn't go to the 2013 version so I had hand fabricated it and in the process substituted CR for WD. -andy From internet-drafts@ietf.org Thu Apr 4 05:23:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C32E21F8B5F; Thu, 4 Apr 2013 05:23:30 -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.101, 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 VWheGnzKFg6N; Thu, 4 Apr 2013 05:23:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B266621F8629; Thu, 4 Apr 2013 05:23:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130404122329.25681.31454.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 05:23:29 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 12:23:30 -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 : Security Services for the Registration Data Access Proto= col Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-02.txt Pages : 10 Date : 2013-04-04 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services, specific requirements for RDAP, and approaches to provide RDAP security services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-sec-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Thu Apr 4 05:25: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 A93AB21F8BA4 for ; Thu, 4 Apr 2013 05:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.351 X-Spam-Level: X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[AWL=1.248, 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 L7ST+vzGrkqC for ; Thu, 4 Apr 2013 05:25:31 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 087EB21F8B5F for ; Thu, 4 Apr 2013 05:25:31 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUV1xOlxd49wOleE1HYEdM67X/TGBmZVx@postini.com; Thu, 04 Apr 2013 05:25:31 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 r34CPRt9007156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Apr 2013 08:25:30 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 4 Apr 2013 08:25:26 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-02.txt Thread-Index: AQHOMS9EJbzwWfy/zEyNyc8dZXorwpjF/E1Q Date: Thu, 4 Apr 2013 12:25:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2434F275@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130404122329.25681.31454.idtracker@ietfa.amsl.com> In-Reply-To: <20130404122329.25681.31454.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 12:25:31 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Thursday, April 04, 2013 8:23 AM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. >=20 > Title : Security Services for the Registration Data > Access Protocol > Author(s) : Scott Hollenbeck > Ning Kong > Filename : draft-ietf-weirds-rdap-sec-02.txt > Pages : 10 > Date : 2013-04-04 >=20 This update captures comments received from Marc Blanchet and includes edit= s based on discussion in Orlando. Scott From zhoulinlin@cnnic.cn Sat Apr 6 18:08:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4921F87C5 for ; Sat, 6 Apr 2013 18:08:37 -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 19uUBZ++LxGr for ; Sat, 6 Apr 2013 18:08:37 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id B1D1521F86C9 for ; Sat, 6 Apr 2013 18:08:34 -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; Sun, 07 Apr 2013 09:08:25 +0800 From: "Linlin Zhou" To: Date: Sun, 7 Apr 2013 09:08:25 +0800 Message-ID: <007701ce332c$6858a2e0$3909e8a0$@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: Ac4v8aaoMubRn4BjRvuMch/W6/0IHgDOVFpA Content-Language: zh-cn Subject: [weirds] FW: I-D Action: draft-zhou-weirds-dnrd-ap-object-inventory-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 01:08:37 -0000 FYI. This version adds some statistics data in section 5.1. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, April 03, 2013 6:29 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-zhou-weirds-dnrd-ap-object-inventory-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Registration Data Access Protocol Object Inventory Analysis Author(s) : Linlin Zhou Ning Kong Sean Shen Steve Sheng Filename : draft-zhou-weirds-dnrd-ap-object-inventory-01.txt Pages : 18 Date : 2013-04-02 Abstract: WHOIS output elements from 124 TLDs were collected and analyzed. This document describes the statistical analysis process and result of WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of domain name data objects in WHOIS response. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhou-weirds-dnrd-ap-object-inventory There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhou-weirds-dnrd-ap-object-inventory-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-zhou-weirds-dnrd-ap-object-inventory- 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From marc.blanchet@viagenie.ca Sun Apr 7 00:29: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 38AE921F8D90 for ; Sun, 7 Apr 2013 00:29:44 -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 hbbe+gApr3MZ for ; Sun, 7 Apr 2013 00:29:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id D7E6821F8B11 for ; Sun, 7 Apr 2013 00:29:42 -0700 (PDT) Received: from [10.196.198.183] (28-193.icannmeeting.org [199.91.193.28]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9305241176; Sun, 7 Apr 2013 03:29:11 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: Date: Sun, 7 Apr 2013 15:29:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF32C8E-2D5C-4943-AEBD-2C10AB97240C@viagenie.ca> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Sun, 07 Apr 2013 07:29:44 -0000 yes. very useful background data that should be recorded permanently. Marc. Le 2013-04-03 =E0 00:40, Murray S. Kucherawy a = =E9crit : > Colleagues, >=20 > We propose to adopt this draft as a WG item seeking Informational = status. Since the content includes work worth recording, and also = because the results of the inventory work have influenced some design = choices made in other documents, we believe this is an appropriate = action for the WG to take. >=20 > We propose to leave the current author set unmodified. >=20 > Please provide comments of support or objection, preferably by the end = of next week. >=20 > -MSK, WEIRDS co-chair >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From zhoulinlin@cnnic.cn Sun Apr 7 02:45: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 ED0E321F8E36 for ; Sun, 7 Apr 2013 02:45:30 -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 f1S195ryToEi for ; Sun, 7 Apr 2013 02:45:30 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 73B2621F8D2A for ; Sun, 7 Apr 2013 02:45:28 -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; Sun, 07 Apr 2013 17:45:19 +0800 From: "Linlin Zhou" To: "'Arturo Servin'" , References: <515CC8A6.5010900@lacnic.net> In-Reply-To: <515CC8A6.5010900@lacnic.net> Date: Sun, 7 Apr 2013 17:45:20 +0800 Message-ID: <00e401ce3374$9e690a30$db3b1e90$@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: Ac4wyw8Xr7XzSXpoQFWWHDlGUHeGtgCYqi4Q Content-Language: zh-cn Subject: Re: [weirds] Call for adoption: draft-zhou-weirds-dnrd-ap-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: Sun, 07 Apr 2013 09:45:31 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Arturo Servin > Sent: Thursday, April 04, 2013 8:26 AM > To: weirds@ietf.org > Subject: Re: [weirds] Call for adoption: > draft-zhou-weirds-dnrd-ap-object-inventory > > > Support. > > It is a very good reference to keep for the future. > > Also, when we (the RIRs) start working together on this (which eventually > became weirds) we did a similar analysis and inventory. Ours was much simpler > and we didn't write it down so formally, nevertheless if the WG wanted to add > some of that work let me know and I will dig on my notes. > I think this is a good idea. I'd like see more information about it. > Regards, > as > > On 4/2/13 5:40 PM, Murray S. Kucherawy wrote: > > Colleagues, > > > > We propose to adopt this draft as a WG item seeking Informational > > status. Since the content includes work worth recording, and also > > because the results of the inventory work have influenced some design > > choices made in other documents, we believe this is an appropriate > > action for the WG to take. > > > > We propose to leave the current author set unmodified. > > > > Please provide comments of support or objection, preferably by the end > > of next week. > > > > -MSK, WEIRDS co-chair > > > > > > > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From bje@apnic.net Mon Apr 8 00:14: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 8EB8221F8EA5 for ; Mon, 8 Apr 2013 00:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.416 X-Spam-Level: ** X-Spam-Status: No, score=2.416 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 MkEMVShWf7kM for ; Mon, 8 Apr 2013 00:14:02 -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 E144521F8B61 for ; Mon, 8 Apr 2013 00:14:00 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 8 Apr 2013 17:12:06 +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, 8 Apr 2013 17:13:57 +1000 From: Byron Ellacott To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwudlplH1oWZ7keNypwMB09/dpi90p71gAAF0ICAAIGjAIAABpeAgAAOaoCAArRRgIAK18cA Date: Mon, 8 Apr 2013 07:13:57 +0000 Message-ID: In-Reply-To: <5159E255.9040507@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.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <0518DB66DA2B9B4B8B8985EF077A7792@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 07:14:03 -0000 Hi Ernie, On 2/04/13 5:39 AM, "Ernie Dainow" wrote: >Section 8.1 > Clients MAY use IRIs as they see fit, but MUST transform them to >URIs [RFC3986] > >RFC3986 does not address IRIs or URI/IRI transforms, the reference >should be RFC3987. The 3986 reference is for URIs. I will add a 3987 reference for IRIs (and the transform). Thanks, Byron From bje@apnic.net Mon Apr 8 00:26: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 4239721F8DEF for ; Mon, 8 Apr 2013 00:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.486 X-Spam-Level: * X-Spam-Status: No, score=1.486 tagged_above=-999 required=5 tests=[AWL=0.929, 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 67h2e38uFGII for ; Mon, 8 Apr 2013 00:26:13 -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 541BB21F8A66 for ; Mon, 8 Apr 2013 00:26:13 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 8 Apr 2013 17:26:10 +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, 8 Apr 2013 17:26:10 +1000 From: Byron Ellacott To: John R Levine , Andy Newton Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwudlplH1oWZ7keNypwMB09/dpi90p71gAAF0ICAA1ZmAIAAAWQAgArOXIA= Date: Mon, 8 Apr 2013 07:26:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CE753D29A35924ABB1F66852880449C@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 07:26:14 -0000 Hi John, On 2/04/13 6:24 AM, "John R Levine" wrote: >>> I agree that we should either say UTF-8 or nothing. This isn't a >>>policy >>> issue, it's an interop issue. >> >> Then it should say nothing. Our JSON response is UTF-8. > >I would have a minor preference to say that servers that return non-ASCII >results do so encoded as UTF-8, but it's not a big deal. > >Is there any reason not to specify UTF-8 for non-ASCII responses? Is >anyone we're aware of planning to use any other encoding? I've removed the portion of the text referring to non-ASCII data. The json-response draft mandates UTF-8, so I don't think the using-http draft needs to, does it? Byron From bje@apnic.net Mon Apr 8 00:27:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA721F902D for ; Mon, 8 Apr 2013 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=0.6, 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 CRakay-PXR39 for ; Mon, 8 Apr 2013 00:27:09 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id B83F021F8A66 for ; Mon, 8 Apr 2013 00:27:08 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 8 Apr 2013 17:27:04 +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, 8 Apr 2013 17:27:04 +1000 From: Byron Ellacott To: SM , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwudlplH1oWZ7keNypwMB09/dpi90p71gA4sNoA= Date: Mon, 8 Apr 2013 07:27:03 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.53] Content-Type: text/plain; charset="Windows-1252" Content-ID: <357A376E01BE254ABC884DD8C1ED99F4@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 07:27:10 -0000 Hi, On 30/03/13 4:44 PM, "SM" wrote: >At 09:53 27-03-2013, Murray S. Kucherawy wrote: >>We would like to initiate a two-week Working Group Last Call on >>draft-ietf-weirds-http. A version 03 was just pushed to the datatracker: > >The Abstract mentions that: > > "This document describes the usage of the Registration Data Access > Protocol (RDAP) using HTTP." > >The Introduction Section mentions that: > > "This document describes the usage of HTTP for Registration Data > Directory Services running on RESTful web servers." > >I guess that the Abstract needs to be updated. Does this work as an abstract? This document describes the RESTful usage of HTTP for the Registration Data Access Protocol (RDAP). >In the Introduction Section: > > "In designing these common usage patterns, this draft endeavours to > satisfy requirements for a Registration Data Access Protocol (RDAP)." > >As a nit, "draft". Now "document." >I read the Introduction Section and I did not find anything explicit >about the Registration Data Access Protocol. There is however an >example which tries to explain how this protocol works. Where is >this Registration Data Access Protocol specified? Appended to the first paragraph of the introduction: Together with other documents from the IETF WEIRDS working group, this document describes the Registration Data Access Protocol (RDAP). Does that answer the question? >In Section 2: > > "[SAC-051] describes a protocol profile of RDAP for Domain Name > Registries (DNRs), DNRD-AP." > >Please "expand on first use". -04 will have an expansion of DNRD-AP. > > "This document and others from the IETF WEIRDS working group describe > a single protocol, RDAP, for access to the data of both DNRs and > Regional Internet Registries (RIRs)." > >What does this have to do with terminology? Removed, as it's now covered in the introduction. > > "RIRs are also often referred to as number resource registries and > are responsible for the registration of IP address networks and > autonomous system numbers." > >What does this have to do with terminology? Removed. >In Section 3: > > "Third, HTTP offers a number of transport protocol mechanisms not > described further in this document. Operators are able to make use > of these mechanisms according to their local policy, including cache > control, authorization, compression, and redirection." > >Hmm, that does not sound like transport protocol mechanisms to me. Could you suggest alternate text in place of "transport protocol" ? > "HTTP also benefits from widespread investment in scalability, > reliability, and performance, and widespread programmer > understanding of client behaviours for RESTful web services, > reducing the cost to deploy Registration Data Directory > Services and clients." > >I heard that one before. :-) Section 3 starts with "query" and ends >with HTTP for the naive programmer argument. I suggest reordering >the design intent starting from the "top". Could you suggest text here? >In Section 4.1: > > "RDAP clients MUST include an Accept: header specifying application/ > rdap+json, application/json, or both. Servers receiving an RDAP > request MUST return an entity with Content-Type application/ > rdap+json." > >What are RDAP clients? I guess that the problem is that the draft >explains it by example (Section 1) instead of specifying it. Where should it be made explicit that RDAP clients are those adhering To the behaviours described in the draft? I could insert: =8A, that is, clients adhering to the behaviours described in this document, =8A =8A right there, but I'm not sure that's actually a sensible place to do so. >In Section 5: > > "While no standard HTTP response code is forbidden in usage, at a > minimum clients SHOULD understand the response codes described > in this section." > >Why is this a SHOULD? A client may have valid reasons in particular circumstances to ignore a particular response code, but servers shouldn't have to provide any additional service or support to clients that do so. >In Section 5.1: > > "If a server has the information requested by the client and wishes to > respond to the client with the information according to its policies, > it SHOULD encode the answer in the format most appropriate according > to the standard and defined rules for processing the HTTP Accept > header, and return that answer in the body of a 200 response." > >I can understand that this working group feels strongly about >policy. The question of whether the server is willing to provide the >information is irrelevant. If the server is providing the >information, it returns a body with a 200 response code. The >specification does not have to put policy in every place. Is there new text you'd like to suggest? >In Section 5.2: > > "If a server wishes to inform a client that the answer to a given > query can be found elsewhere, it SHOULD return either a 301 or a 307 > response code and an HTTP URL in the Location: header." > >I see two response codes in the above? I see a "SHOULD". I suggest >being clear or else it will lead to diverging implementations. The >above can be restated in terms of what the response code means. > > "A server SHOULD use a 301 response to inform the client of a > permanent move and a 307 response otherwise." > >This makes it two SHOULDs. Why can't that be explained with one SHOULD? Could you provide text that does explain it with one SHOULD? >In Section 5.3: > > "If a server wishes to respond that it has no information regarding > the query, it SHOULD return a 404 response code." > >Why is this a SHOULD? There may be valid circumstances in which a server responds with a different code. Perhaps a server might prefer a redirection response with a body indicating that while it has no information, the client might like to try a general redirection service instead. >In Section 5.4: > > "If a server receives a query which it cannot understand, it SHOULD > return a 400 response code." > >Why is this a SHOULD? By the way, on reading of the sentence only I >would say that the 400 response code is not appropriate. "Cannot understand" should be "cannot interpret as an RDAP query" or similar. The intent is that a malformed query be given a "Bad Request" response. >In Section 7.1: > > "In accordance with RFC5226, the IANA policy for assigning new values > shall be Specification Required: values and their meanings must be > documented in an RFC or in some other permanent and readily available > reference, in sufficient detail that interoperability between > independent implementations is possible." > >Note that this is IANA considerations. I suggest not calling it >"IANA policy". I suggest not restating what is in RFC 5226 as it may >end up being problematic in future (nothing to do with the working >group). Why is the policy "specification required"? What text would you suggest for this section instead? I believe there is a separate question raised by the chairs regarding the choice of policy. >draft-ietf-weirds-using-http-03 is well-written. My reading of it is >that it is under-specified. I suggest framing the draft in terms of >HTTP. It will give everyone what he or she wants while disguising >the draft as an IETF specification. :-) There isn't a Security >Considerations section in the draft. My hypothesis [1] is that a >draft intended to be published on the Standards Track to make it >there is very low if there isn't any consideration to security. There will be a Security Considerations section in the next version, using the text supplied by Jean-Philippe Dionne. Thanks for the feedback! Byron From internet-drafts@ietf.org Mon Apr 8 19:24: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 2307E21F849C; Mon, 8 Apr 2013 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 gtNGS0O-s30g; Mon, 8 Apr 2013 19:24:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F721F8484; Mon, 8 Apr 2013 19:24:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409022402.14693.40759.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 19:24:02 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:24:03 -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 : JSON Responses for the Registration Data Access Protocol= (RDAP) Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-json-response-03.txt Pages : 51 Date : 2013-04-08 Abstract: This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From andy@arin.net Mon Apr 8 19:28: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 D18C121F84AF for ; Mon, 8 Apr 2013 19:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C57R8M8cGqTG for ; Mon, 8 Apr 2013 19:28:58 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id CEC2821F8498 for ; Mon, 8 Apr 2013 19:28:57 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4640E2136B6; Mon, 8 Apr 2013 22:28:57 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 9C7F6213683 for ; Mon, 8 Apr 2013 22:28:56 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 8 Apr 2013 22:28:44 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 22:28:50 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-json-response-03.txt Thread-Index: AQHONMlZ/wUmqE9SVUySbYMDE85whJjNKlyA Date: Tue, 9 Apr 2013 02:28:49 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAE47@CHAXCH01.corp.arin.net> In-Reply-To: <20130409022402.14693.40759.idtracker@ietfa.amsl.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.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-json-response-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:28:58 -0000 All, There are a lot of changes in this version based on the discussion in the working group. Here is the change log: Added jCard verbiage and examples and deleted overlapping contact information and the appendix on postal addresses Removed the IANA considerations as they have been moved to another document Changed the remarks structure to be like notices Reordering and rewording some of the sections so they flow better Added note about object class "self" links Changed ipAddresses in nameserver object class to separate out v6 from v4 Changed IP network version identifier from integer to string to be more consistent with ipAddresses identifier in nameserver object classes Changed DNS names to LDH names and Unicode names Modified the definition of 'conjoined' variant relationship so it was circular Added 'proxy', 'private', 'redacted', and 'obscured' status values (most useful for entities). Added a privacy considerations section Added a security considerations section Added 'reseller' and 'sponsor' to the list of entity roles Added the 'events' common data structure Added 'asEventActor' to entities Added appendix on event modeling Removed the subclasses/superclassing between RIRs/DNRs for entity and domain object classes Change suggested status/relation/etc values to be case/spacing consistent Normalized some of the definitions of object class members Modifying the JSON signaling section to reference the guidance in draft-ietf-weirds-using-http Changed the text regarding the process of unknown JSON attributes -andy On 4/8/13 10:24 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Web Extensible Internet Registration >Data Service Working Group of the IETF. > > Title : JSON Responses for the Registration Data Access >Protocol (RDAP) > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-json-response-03.txt > Pages : 51 > Date : 2013-04-08 > >Abstract: > This document describes JSON data structures representing > registration information maintained by Regional Internet Registries > (RIRs) and Domain Name Registries (DNRs). These data structures are > used to form Registration Data Access Protocol (RDAP) query > responses. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds > From superuser@gmail.com Mon Apr 8 20:36: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 C7ED421F8F28 for ; Mon, 8 Apr 2013 20:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 xpgQl+XE4Sw1 for ; Mon, 8 Apr 2013 20:36:36 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F301521F8733 for ; Mon, 8 Apr 2013 20:36:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj8so3231662wib.7 for ; Mon, 08 Apr 2013 20:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=bzcg7iq6oeg0asKu9LPynbizO9ZHrZOdudtn9vRc/0k=; b=cYMYnLQCx+oS/aq89WJSVxv5IQSgSYlHpJsOqzLqLV5ZRa1/l5WGtPGpIoexgja5SC ChrCJa8Tb2cuBOUgURQBhovI4sqha0fvlKlESTpW2mcQllZ6cF1pi+6VoYFsG+UagmeN NH6NLbcdagr/Xs6qGslpJJjjfZ0+Jgj7MqhgDbEwJ2gV0H96XBbqlsh3b/T700kM2ePM t+BhXMHhndm4rjVit/HPbCm9FWehHSJE/btUo2SWQqmicSNM85jgvuCy/xUs8x8mVQyT Lpi/upVrNmNDS7AbfMhX265HDSglgxUhbQORe4qtXhAv6aYg/8AhI1fqvjGuAOljEAOA sKRA== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr16616579wiv.14.1365478595137; Mon, 08 Apr 2013 20:36:35 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 20:36:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 20:36:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d0438914d9c95e004d9e542ad Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:36:36 -0000 --f46d0438914d9c95e004d9e542ad Content-Type: text/plain; charset=ISO-8859-1 Reminder: This closes Wednesday. If you haven't done a review and submitted comments but plan to, please don't leave it until the last moment. So far I've seen quite a lot of review feedback, so we're going to be happy that it was a thorough WGLC. Gratitudes to everyone who has taken time to participate! What remains is to confirm that people are satisfied with the result. So, Andy et al, please post a revision based on the WGLC chatter as soon as possible after Wednesday so those that have weighed in have a chance to confirm their issues were addressed either on the list or in the document. Olaf will be shepherding this one and he'll take it from there. -MSK, WEIRDS co-chair On Wed, Mar 27, 2013 at 9:53 AM, Murray S. Kucherawy wrote: > Colleagues, > > We would like to initiate a two-week Working Group Last Call on > draft-ietf-weirds-http. A version 03 was just pushed to the datatracker: > > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ > > Last call will end Wednesday, April 10th. > > Please review and comment on the draft, even if it is only to say on the > record "I have reviewed this document thoroughly and it looks good." We > would like to have no fewer than five people report that they have taken a > look at the whole document and reported their findings, and will be > reticent to send it to the IESG without that. We're also keen to hear from > people that have implemented the specification as to their views on > clarity, correctness, and completeness. > > Thanks, > > -MSK and Olaf, your co-chairs > > --f46d0438914d9c95e004d9e542ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reminder: This closes Wednesday.=A0 If you = haven't done a review and submitted comments but plan to, please don= 9;t leave it until the last moment.

So far I've seen quite= a lot of review feedback, so we're going to be happy that it was a tho= rough WGLC.=A0 Gratitudes to everyone who has taken time to participate!
What remains is to confirm that people are satisfied with the result.= =A0 So, Andy et al, please post a revision based on the WGLC chatter as soo= n as possible after Wednesday so those that have weighed in have a chance t= o confirm their issues were addressed either on the list or in the document= .

Olaf will be shepherding this one and he'll take it from ther= e.

-MSK, WEIRDS co-chair
<= br>
On Wed, Mar 27, 2013 at 9:53 AM, Murray S= . Kucherawy <superuser@gmail.com> wrote:
Colleagues,
We would like to initiate a two-week Working Group Last Call on draft-iet= f-weirds-http.=A0 A version 03 was just pushed to the datatracker:

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

Last call will end Wednesday, April 10th.

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

Thanks,

-MSK and Olaf, your co-chairs


--f46d0438914d9c95e004d9e542ad-- From ajs@anvilwalrusden.com Mon Apr 8 22:52:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE42521F8FA5 for ; Mon, 8 Apr 2013 22:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tkuAkRG5ZTn for ; Mon, 8 Apr 2013 22:52:01 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7EF21F8FA4 for ; Mon, 8 Apr 2013 22:51:59 -0700 (PDT) Received: from mx1.yitter.info (li440-116.members.linode.com [50.116.54.116]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3A3558A031 for ; Tue, 9 Apr 2013 05:51:56 +0000 (UTC) Date: Tue, 9 Apr 2013 01:51:53 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130409055153.GG24624@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 05:52:01 -0000 On Wed, Mar 27, 2013 at 05:53:22PM +0100, Murray S. Kucherawy wrote > We would like to initiate a two-week Working Group Last Call on > draft-ietf-weirds-http. Dear colleagues, I have read this draft. By and large, I think it's in good shape. I include some comments here. These are made without reference to the other comments that have been made, but I have read those comments and mostly agree with them. Section 1. Why is the "should" in (4) not a 2119? When is it ok not to return 404? (Probably just say "it returns a 404 response" or else even "a 4xx response" in order not to be doing protocol in the intro.) Section 3. There are a few design criteria this document attempts to support. This is awkward. How about "attempts to meet"? It isn't clear to me how the third paragraph describes any criterion. How about, "Third, this protocol is intended to be able to make use of the range of mechanisms available for use with HTTP. HTTP offers a number. . ."? Section 4.1 This specification does not define the responses a server returns to a request with any other media types in the Accept: header, or with no Accept: header. It'd be nice to say why not. I think probably because this is designed as a machine-to-machine protocol, where the formatting for human consumption is supposed to be handled on the client side, right? Is that another criterion that ought to be in Section 3? It's odd that section 4 doesn't actually say how you send a query. Section 5 It is expected that usage of response codes and types for this application not defined here will be described in subsequent documents. Why is that an expectation? Presumably, if there is an expectation that such response codes will be used, we also have an expectation of how; why not add them now? Section 5.2 A server SHOULD use a 301 response to inform the client of a permanent move and a 307 response otherwise. Under what circumstances would it be acceptable not to do this? If none, this should be a MUST. I can't think of any such cases. The paragraph starting "In other words. . ." doesn't follow from the example immediately preceding. I think ditching the "In other words" would help. Also, the subsequent example is confusing, because it looks very like the path segment _is so_ modified. I had to re-read this twice to get it. Are references for "base" and "path segment" needed to clarify? Section 5.3 If a server wishes to respond that it has no information regarding the query, it SHOULD return a 404 response code. When could it do otherwise? I think this is MUST. Section 5.4 If a server receives a query which it cannot understand, it SHOULD return a 400 response code. What alternatives are there here? If none, this is MUST. Section 6 Are identifiers case sensitive? Also, why are the starting character rules SHOULD NOT? Certainly, SHOULD NOT on initial 0-9 and _ is inconsistent with the ABNF. Also, the ABNF has no indication that you shouldn't start with "xml". Section 8.2 I think I already saw agreement to ditch the hand-wavy bits about possible encodings and just require that things be Unicode. Is the "should be annotated" better spelled "SHOULD be annotated"? (In particular, it might be nice to say, "SHOULD be annotated with language identifiers whenever they are available. . . ", which gets around the obvious exception case of not having the tag available either because there wasn't one or because you couldn't do it.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Mon Apr 8 22:52: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 033F221F8FD7 for ; Mon, 8 Apr 2013 22:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5KUQ7Uo6qBTh for ; Mon, 8 Apr 2013 22:52:51 -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 411A021F8FC6 for ; Mon, 8 Apr 2013 22:52:51 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t57so5031875wey.18 for ; Mon, 08 Apr 2013 22:52:50 -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=MMEGdUfXw8SHixzsxJlL4foMLXSM7vj5YRf+sxkPJic=; b=DZxxs1AZmM4HEDfGWkUerkt7xWfWsAO0YeMNf739qZaqy+/lmSpucd0I7t1BXoeuIm fI1egBWG1jEWmu11zl74Js5uAJ/zkSOPWIhihWQck5Bl4CRQ42nsRR949P9mK0mxQvjv etHA0ok2+jNCmBblBxTgAFCOqOOi/1M1gpQK9miKFuM+lMd5GNm/qYeq0opGIf94XcpM FJcvWM6YfsxDDp3dUzNTDB/hnqFc2g82a8ZaSb4D0gZMBiI4k9Bn30V5qYh3SAs+2+pz FsQazXE0ytVAJ6hQk82PQEcNL7P+WdrFX3UfxrZCILM1S36KMP8m22qaE4b5zWzCOpR+ xUYg== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr14449455wjc.59.1365486770416; Mon, 08 Apr 2013 22:52:50 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 22:52:50 -0700 (PDT) Date: Mon, 8 Apr 2013 22:52:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1b942e570db04d9e72972 Subject: [weirds] Status of draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 05:52:52 -0000 --001a11c1b942e570db04d9e72972 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, As the WGLC on the Using HTTP draft winds down, I'd like people to start thinking about giving this draft a review as well. We have it on our charter as a milestone due this month. We won't start WGLC on this draft until we're done with the other one, but I wanted to put it in the back of your minds that this one is next, and it won't be long now. If you have the cycles available, early reviews would be most welcome. -MSK, WEIRDS co-chair --001a11c1b942e570db04d9e72972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

As the WGLC on the Using HTTP draf= t winds down, I'd like people to start thinking about giving this draft= a review as well.=A0 We have it on our charter as a milestone due this mon= th.=A0 We won't start WGLC on this draft until we're done with the = other one, but I wanted to put it in the back of your minds that this one i= s next, and it won't be long now.=A0 If you have the cycles available, = early reviews would be most welcome.

-MSK, WEIRDS co-chair

--001a11c1b942e570db04d9e72972-- From sm@resistor.net Tue Apr 9 02:48: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 B932E21F933B for ; Tue, 9 Apr 2013 02:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg2OGOug9f01 for ; Tue, 9 Apr 2013 02:47:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3621F91D6 for ; Tue, 9 Apr 2013 02:47:59 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r399lmAN020968; Tue, 9 Apr 2013 02:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365500873; bh=Nx406bHEtfE9Jt6wmWyY8rd9r4Slhi0+m5yOrS3vDD0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dCQ2F8vO9iubSKVfNAzEWJoSrkx7qmzWO7sAeZ/GBAziL2BhB97Z5zW11P1JMtfJ6 CLKugs0GTQ7yuF2XI8KRn3D5+IXI0g039qzN68DRoliun0c45OG/U9FdfK2SvGakCE bFKr1sNlsTe/eWTqRIT/UoGUsMSBNYkIPorxdA0A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1365500873; i=@resistor.net; bh=Nx406bHEtfE9Jt6wmWyY8rd9r4Slhi0+m5yOrS3vDD0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Wfjciz+pVb94B2b8BogpO+AgXxF8fTZGIqgcJUdNlcvrdzeBskWDD7Z6ZZ70O7fSM TmrYwWNU/+iCTQj/kNRfKsDx1/ZNzqgn1FsmUvxoj6u+H4oAtrqd9M6IlywsaYgFrt 7NMrwLLDYTc/jh7+Q5SHbwV5ua0E3gMpRWFWUV1A= Message-Id: <6.2.5.6.2.20130409010159.073ce158@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Apr 2013 01:51:26 -0700 To: Byron Ellacott From: SM In-Reply-To: References: <6.2.5.6.2.20130329193040.0a435c18@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:48:00 -0000 Hi Byron, At 00:27 08-04-2013, Byron Ellacott wrote: >Does this work as an abstract? > > This document describes the RESTful usage of HTTP for the > Registration Data Access Protocol (RDAP). Not really, the text is not aligned with the=20 description of the document given in the Introduction section. >Appended to the first paragraph of the introduction: > > Together with other documents from the IETF WEIRDS working group, > this document describes the Registration Data Access Protocol= (RDAP). After reading the above text I still do not know=20 what the Registration Data Access Protocol is or=20 where the protocol is specified. >Does that answer the question? No. :-) >Could you suggest alternate text in place of "transport protocol" ? It's easier to drop "transport protocol". >Could you suggest text here? It's difficult for me to suggest text as I did=20 not follow the discussion about design=20 intents. You could start with the third point,=20 then have the "First" text and then the "Second"=20 text. If you really want to document the design=20 intent you could explain why HTTP is being used=20 and how it fits within the constraints. >Where should it be made explicit that RDAP clients are those adhering >To the behaviours described in the draft? I could insert: > > =8A, that is, clients adhering to the behaviours described > in this document, =8A > >=8A right there, but I'm not sure that's actually a sensible place to >do so. This is a draft intended for the Standards=20 Track. Such documents are usually about=20 protocols which specify the exchange of commands=20 and responses between a client and a server. As=20 I mentioned previous, my guess is the draft=20 explains "RDAP" by example, hence causing the=20 problem where it is not that clear what a RDAP=20 client is. I guess that you might get away with=20 the above text or add text to explain the client and server approach. >A client may have valid reasons in particular circumstances to ignore >a particular response code, but servers shouldn't have to provide any >additional service or support to clients that do so. Let me ask it differently; could I be provided=20 with examples when the SHOULD does not have to be followed? >Is there new text you'd like to suggest? The text could be removed. >Could you provide text that does explain it with one SHOULD? I'll get back to you on this one. >There may be valid circumstances in which a server responds with a >different >code. Perhaps a server might prefer a redirection response with a body >indicating that while it has no information, the client might like to try >a general redirection service instead. Ok. >"Cannot understand" should be "cannot interpret as an RDAP query" or >similar. The intent is that a malformed query be given a "Bad Request" >response. The above sounds better. You could use it instead. >What text would you suggest for this section instead? I believe there is >a separate question raised by the chairs regarding the choice of policy. I'll leave it to others to suggest text first=20 as I have to catch up with other stuff. I'll do=20 a parse of the text after the end of the WGLC. BTW, my reply is short. Let me know if there are=20 any part which is unclear or which would benefit from an explanation. Regards, -sm=20 From andy@arin.net Tue Apr 9 03:14: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 8A2B921F93B2 for ; Tue, 9 Apr 2013 03:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J98YVlDaj6Hv for ; Tue, 9 Apr 2013 03:14:23 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id ED49421F93A6 for ; Tue, 9 Apr 2013 03:14:22 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id A94551650EF; Tue, 9 Apr 2013 06:14:18 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 31FD11650EB; Tue, 9 Apr 2013 06:14: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; Tue, 9 Apr 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; Tue, 9 Apr 2013 06:14:04 -0400 From: Andy Newton To: SM , Byron Ellacott Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHOKwufQGdqA1SD+02gDEqb/EAX/5i90qRegA5vQICAAanpAP//1AYA Date: Tue, 9 Apr 2013 10:14:03 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAF1A@CHAXCH01.corp.arin.net> In-Reply-To: <6.2.5.6.2.20130409010159.073ce158@resistor.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: [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] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 10:14:23 -0000 On 4/9/13 4:51 AM, "SM" wrote: >>Could you suggest alternate text in place of "transport protocol" ? > >It's easier to drop "transport protocol". I think more appropriate terminology is "transfer protocol" or even things a bit more descriptive such as "application transfer protocol" or "application data transfer protocol". >This is a draft intended for the Standards >Track. Such documents are usually about >protocols which specify the exchange of commands >and responses between a client and a server. As >I mentioned previous, my guess is the draft >explains "RDAP" by example, hence causing the >problem where it is not that clear what a RDAP >client is. I guess that you might get away with >the above text or add text to explain the client and server approach. There seems to be a theme in your comments which is a good observation. Since this is the first draft in the RDAP series, it might make sense to beef up the introduction to include a little history of the problem space, a description of what RDAP is and some foreshadowing of the documents to come in the series (the query doc, the JSON response doc, and the upcoming search work). Just a thought. -andy From sm@resistor.net Tue Apr 9 10:30: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 1489B21F93DC for ; Tue, 9 Apr 2013 10:30:32 -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 gedRqM8dVhsL for ; Tue, 9 Apr 2013 10:30:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5643A21F930C for ; Tue, 9 Apr 2013 10:30:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39HTteW027949; Tue, 9 Apr 2013 10:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365528600; bh=//8uYj60+Wc9cLx6KTQ0Km7LVKs52WeYYxcNh5WU1gU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r4R1mbPxO4lQrJPGcYNhtO6b7OnhdsXCqczZpk1H+wF3QvO/9D3qYUDUMzQbInsLx B3ZXnDDW78zBN7h99YiukDYzqwqbQyM9+aX4rry4v4ImoOPPivqo0c62HPWumIGfG4 FbxajfMyBOM4UxExSlti6FDUgqT7xpg1z0Jgzxfk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1365528600; i=@resistor.net; bh=//8uYj60+Wc9cLx6KTQ0Km7LVKs52WeYYxcNh5WU1gU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Y1q3w8WrmtWHkgMJMXEQpCZKC1+W905Z/14Askua0kWK7ILTU+AoKQ2AaZ/TCqXsV jlTSDLQ71djCRdn6SLFBsLygo0T1+0eJ7r1dIItUhnIdO2cq3doupYgSAHLWu5aq/N c80S2RFUPVvhUbxEa3sogb08Bjpuqrf51t02YvZk= Message-Id: <6.2.5.6.2.20130409095443.0be737b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Apr 2013 10:19:30 -0700 To: Andy Newton From: SM In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAF1A@CHAXCH01.corp.ari n.net> References: <6.2.5.6.2.20130409010159.073ce158@resistor.net> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAF1A@CHAXCH01.corp.arin.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:30:32 -0000 Hi Andy, At 03:14 09-04-2013, Andy Newton wrote: >I think more appropriate terminology is "transfer protocol" or even things >a bit more descriptive such as "application transfer protocol" or >"application data transfer protocol". I will defer to HTTP folks for the transfer protocol wording or else I will have to spend time determining whether the terminology is correct or not. >There seems to be a theme in your comments which is a good observation. Sorry for rehashing this. I was trying to provide an explanation. >Since this is the first draft in the RDAP series, it might make sense to >beef up the introduction to include a little history of the problem space, >a description of what RDAP is and some foreshadowing of the documents to >come in the series (the query doc, the JSON response doc, and the upcoming >search work). As a quick reaction, the above sounds like a good idea. Maybe the working group was trying to avoid a grand unified specification and, in doing so, is considering each draft listed in the charter as independent of each other. In future people reading these documents might not have sufficient context to understand how to implement the specifications. Regards, -sm From andy@arin.net Tue Apr 9 12:09:43 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683321F98B1 for ; Tue, 9 Apr 2013 12:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uoPIurtD7Nu for ; Tue, 9 Apr 2013 12:09:43 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id EAED521F98A8 for ; Tue, 9 Apr 2013 12:09:42 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 8C6E5213666; Tue, 9 Apr 2013 15:09:12 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 1063521364B; Tue, 9 Apr 2013 15:09:12 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 9 Apr 2013 15:09:02 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 15:09:11 -0400 From: Andy Newton To: SM Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-using-http Thread-Index: AQHONUwQCJbQpfnx9kOvu6qOvc0raZjOQNMA Date: Tue, 9 Apr 2013 19:09:10 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB294@CHAXCH01.corp.arin.net> In-Reply-To: <6.2.5.6.2.20130409095443.0be737b8@resistor.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.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] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:09:43 -0000 On 4/9/13 1:19 PM, "SM" wrote: >>Since this is the first draft in the RDAP series, it might make sense to >>beef up the introduction to include a little history of the problem >>space, >>a description of what RDAP is and some foreshadowing of the documents to >>come in the series (the query doc, the JSON response doc, and the >>upcoming >>search work). > >As a quick reaction, the above sounds like a good idea. Maybe the >working group was trying to avoid a grand unified specification and, >in doing so, is considering each draft listed in the charter as >independent of each other. In future people reading these documents >might not have sufficient context to understand how to implement the >specifications. At one point we had a requirements document, but I think the IESG nixed it. Absent that, this maybe the most appropriate place to this information. -andy From gavin.brown@centralnic.com Tue Apr 9 12:19: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 2006521F9867 for ; Tue, 9 Apr 2013 12:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 gVE0X4p1heFH for ; Tue, 9 Apr 2013 12:19:32 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2621F9845 for ; Tue, 9 Apr 2013 12:19:32 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id AD06F7204E8 for ; Tue, 9 Apr 2013 19:19:28 +0000 (UTC) Message-ID: <516469C0.4060904@centralnic.com> Date: Tue, 09 Apr 2013 20:19:28 +0100 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [weirds] Comments on draft-ietf-weirds-json-response-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:19:33 -0000 Hi all, The latest update to the json-response draft has introduced some significant changes -- and complexity -- to the format and contents of RDAP responses. As the developer of both client and server implementations of RDAP, I have some comments regarding this. 1. vCard I have no particular preference for vCard or any other format for address information. However I would like to note that the suggestion that vCard be used was prompted by my request that entity responses allowed for structured address data, so that address data held by DNRs is not represented in a lossy way. We now have a situation where vCard is used to represent address information -- at the cost of a more complex data model -- but address data is still a flat array of strings, so my original suggestion has still not been satisfied. 2. Events I can understand why the new event model has been added. It allows for more events to be represented than the previous model, which just supported timestamps for registration, expiration, and the last update. However, the new model is more complicated for both client and server implementers, the use of the free-form "eventAction" doesn't meet the goal of properly structured data, and also makes internationalisation harder. If this property is used, the values it can take should be enumerated. 3. Embedding The new draft allows entities to be embedded into events. Of course, events can also be embedded into entities. This allows for recursion. Instead of allowing full entities to be embedded into an event, the specification should recommend the use of an elided entity object containing just a handle and a link object. In fact, my preference would be for such elided objects to be used whenever one object is embedded inside another. G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From superuser@gmail.com Tue Apr 9 12:24: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 33C2D21F98A1 for ; Tue, 9 Apr 2013 12:24: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, 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 oIHH39xAabyQ for ; Tue, 9 Apr 2013 12:24:37 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D5ACB21F989A for ; Tue, 9 Apr 2013 12:24:36 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so5510571wey.25 for ; Tue, 09 Apr 2013 12:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=An2wQROAVKEVL3sW9cbAvvFv4ozhgjy5RTUePYJkPAM=; b=txpFuvuXPylLENK4L6xwRaFGmUQ4etFbpOK8RNBWRzihIkwAEsSoNYVKeYgzmlPuJy AkJTT8Qr5wvaf2mCZKOjVetRQStTqzh0oYns3/KyTiqaEABVOh9mjpWUkOXY83vIaRrD BqoiGCSr5+BvIqZfPDmr1ohOzCZHpnTwL/zIY89gOHeEox39UFZOGx5UAef+NWylkmOR z8IZ1gfRLNzBMT8Y+zot/+z339qixAKW1+zjSkoK2tr3g7pnFfLakx0QmjV1AEPqI9eX hWX4TGkOWrt2kQ7pjqeIHV8Yk2o8uSolv6YhPsb6XBIoouLioADuYc9yh6lD0chb88rc MT0Q== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr41024430wjb.17.1365535475979; Tue, 09 Apr 2013 12:24:35 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 9 Apr 2013 12:24:35 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB294@CHAXCH01.corp.arin.net> References: <6.2.5.6.2.20130409095443.0be737b8@resistor.net> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB294@CHAXCH01.corp.arin.net> Date: Tue, 9 Apr 2013 12:24:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=047d7b5d8cfff95e1304d9f280bb Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:24:38 -0000 --047d7b5d8cfff95e1304d9f280bb Content-Type: text/plain; charset=ISO-8859-1 I think we do still want a grand unified specification to the extent that doing so is practical. If this is to be considered the core framework specification and the rest builds upon it, then this is as good a place to enumerate requirements as any. But yes, our current plans don't include publication of a separate requirements document. -MSK On Tue, Apr 9, 2013 at 12:09 PM, Andy Newton wrote: > On 4/9/13 1:19 PM, "SM" wrote: > > >>Since this is the first draft in the RDAP series, it might make sense to > >>beef up the introduction to include a little history of the problem > >>space, > >>a description of what RDAP is and some foreshadowing of the documents to > >>come in the series (the query doc, the JSON response doc, and the > >>upcoming > >>search work). > > > >As a quick reaction, the above sounds like a good idea. Maybe the > >working group was trying to avoid a grand unified specification and, > >in doing so, is considering each draft listed in the charter as > >independent of each other. In future people reading these documents > >might not have sufficient context to understand how to implement the > >specifications. > > At one point we had a requirements document, but I think the IESG nixed > it. Absent that, this maybe the most appropriate place to this information. > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b5d8cfff95e1304d9f280bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think we do still want a grand unified specificatio= n to the extent that doing so is practical.=A0 If this is to be considered = the core framework specification and the rest builds upon it, then this is = as good a place to enumerate requirements as any.

But yes, our current plans don't include publication of a separate = requirements document.

-MSK


On Tue, Apr 9, 2013 at 12:09 PM, Andy = Newton <andy@arin.net> wrote:
On 4/9/13 1:19 PM, "S= M" <sm@resistor.net> wrot= e:

>>Since this is the first draft in the RDAP series, it might make sen= se to
>>beef up the introduction to include a little history of the problem=
>>space,
>>a description of what RDAP is and some foreshadowing of the documen= ts to
>>come in the series (the query doc, the JSON response doc, and the >>upcoming
>>search work).
>
>As a quick reaction, the above sounds like a good idea. =A0Maybe the >working group was trying to avoid a grand unified specification and, >in doing so, is considering each draft listed in the charter as
>independent of each other. =A0In future people reading these documents<= br> >might not have sufficient context to understand how to implement the >specifications.

At one point we had a requirements document, but I think the IESG nix= ed
it. Absent that, this maybe the most appropriate place to this information.=

-andy

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

--047d7b5d8cfff95e1304d9f280bb-- From andy@arin.net Tue Apr 9 13:00: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 B244521F97E7 for ; Tue, 9 Apr 2013 13:00:40 -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 OQjdI0Lb8mlL for ; Tue, 9 Apr 2013 13:00:40 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3A21F97DF for ; Tue, 9 Apr 2013 13:00:40 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id A78A3213671; Tue, 9 Apr 2013 16:00:39 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id EA9D321364C; Tue, 9 Apr 2013 16:00: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; Tue, 9 Apr 2013 16:00:16 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 16:00:25 -0400 From: Andy Newton To: Gavin Brown , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-03.txt Thread-Index: AQHONVctAW+zYZD5Fkm3Dy8MimqoYJjOTwyA Date: Tue, 9 Apr 2013 20:00:24 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB357@CHAXCH01.corp.arin.net> In-Reply-To: <516469C0.4060904@centralnic.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:00:40 -0000 Gavin, Thanks for looking at the latest document. My comments are in-line: On 4/9/13 3:19 PM, "Gavin Brown" wrote: >1. vCard > >I have no particular preference for vCard or any other format for >address information. However I would like to note that the suggestion >that vCard be used was prompted by my request that entity responses >allowed for structured address data, so that address data held by DNRs >is not represented in a lossy way. > >We now have a situation where vCard is used to represent address >information -- at the cost of a more complex data model -- but address >data is still a flat array of strings, so my original suggestion has >still not been satisfied. I think it is just a matter of providing examples that use structured addresses with jCard. Perhaps Scott and I should start thinking of an appendix which discusses the use of structured and unstructured addresses with jCard. But jCard can support both. >2. Events > >I can understand why the new event model has been added. It allows for >more events to be represented than the previous model, which just >supported timestamps for registration, expiration, and the last update. > >However, the new model is more complicated for both client and server >implementers, the use of the free-form "eventAction" doesn't meet the >goal of properly structured data, and also makes internationalisation >harder. If this property is used, the values it can take should be >enumerated. Like status, role relationships, and variant relationships, the suggested event actions are listed in an appendix (see Appendix A.2, page 40). I just noticed that xml2rfc left out the table of contents, so that is probably very easy to miss. Appendix C (page 46) discusses the event modeling. It might be that we want to create expert-review or first-come, first-serve IANA registries for all these values, not just the event actions. > >3. Embedding > >The new draft allows entities to be embedded into events. Of course, >events can also be embedded into entities. This allows for recursion. >Instead of allowing full entities to be embedded into an event, the >specification should recommend the use of an elided entity object >containing just a handle and a link object. In fact, my preference would >be for such elided objects to be used whenever one object is embedded >inside another. I agree that recursive entity embedding would be bad. And by that I mean entities that embed entities. However, I don't believe the new event model allows that. Certainly it could be that a domain embeds a name server that embeds an entity, but that would be true even with the old event model. -andy From superuser@gmail.com Tue Apr 9 23:26:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CDD21F83EF for ; Tue, 9 Apr 2013 23:26:39 -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.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0axjIcMzClIU for ; Tue, 9 Apr 2013 23:26:38 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6FF21F8B65 for ; Tue, 9 Apr 2013 23:26:33 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id y10so98550wgg.2 for ; Tue, 09 Apr 2013 23:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=avIqSCeB70EG6a8v/3oYbQgfM6Czaoko9RmOEU3Hg6s=; b=tXRumyfYsjSz/akDFtbLKjZ6msaE9TQboyqPoYGrNG13MsK2cOT5H5EUZQ0eL31GaY dlJueR4gL6U7hO/tMqUaoeXIDxTYtBPDdPjDw7IF8oQX8iZLgINHiWCgSPGZ6MaKE8hs CwaFY4RV7z78Q5MhsQv7zWXuYFfutrDQjXj4mT8NoXZNewB89di6Ol0NW25dJ0+XEleW rPWkg9C0ZZv5jE6JujgB//7IoNto20fQ6IJ+VgYtVCjCXrwPObmTjOcLLPHwf2BvooBv qdGM7/VGkh9jocxzq1hSSNxUMDvJG7PZvQhCjaLhR8OKvwsnKOsfyWj2xUiIgwyqLll8 eUtA== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr1006667wjb.17.1365575192731; Tue, 09 Apr 2013 23:26:32 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 9 Apr 2013 23:26:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 23:26:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d8cff46e83f04d9fbc0e3 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 06:26:39 -0000 --047d7b5d8cff46e83f04d9fbc0e3 Content-Type: text/plain; charset=ISO-8859-1 My own comments on this draft as an individual. Apologies if they repeat those of anyone else (and if so, please ignore accordingly); also, if there's an older thread with some of these answers that I've managed to forget about, please point me in the right direction. I've paid particular attention to the use of RFC2119 words here, since both of our ADs are sticklers for that kind of thing. Section 1: "HTTP" and "URL" should be expanded on first use in Section 1. Similarly, "Registration Data" and "Directory Service" should be defined in this context; i.e., registration of what? Does this refer to LDAP, which is also a directory service? s/should return/returns/ Section 2: Expand/define "RIRs" on first use. Can you refer to a definition of "autonomous system" someplace? I can't think of one off the top of my head, however. Section 3: "Should a result contain more than one result" -- Suggest changing the first one to "reply" or "response", or the second to "entity". s/may/can/, just to be safe. Suggest adding "encryption" to the list in the third paragraph. Section 4.1: s/header/header field/ (which we insist on in mail; not certain it's also common for web) Section 4.2: Under what circumstances might one deviate from this SHOULD? What are the possible consequences of doing so? Section 5: What does "SHOULD understand" mean here? Since earlier we're saying the complexity is imposed on servers, and the whole thing should be usable by clients pretty much as-is, I don't understand what existing clients are supposed to do with this SHOULD. Also, same question as above: Why might one deviate from this SHOULD, and what are the possible consequences? Section 5.1: Same question about this SHOULD. I think you could get away without the normative language at all and just say that if the server has the information, it constructs a success reply as per [HTTP], using a media type selected as per Section 4.1. Section 5.2: Same question about this SHOULD. In fact I think that one ought to be a MUST; the protocol is effectively broken if you don't do that. There's one instance of "url" that should be "URL". I suggest including the example in the last paragraph as an actual HTTP request and reply. Happy to help with the xml2rfc part if needed. Same question about this SHOULD. I think this one might also be a MUST. Section 5.3: Same question about this SHOULD. The MAY is fine. Section 5.4: Same question about this SHOULD. The MAY is fine. Section 5.5: I think the MAY should be a SHOULD, explaining that you might deviate if you don't want to reveal explicitly that rate limiting is the reason for the denial of a reply. The second SHOULD is probably fine; the consequences of a client not backing off when told to do so are kind of intuitive. Section 6: s/may/can/ This SHOULD is well explained; deviating from it has the consequences implied by the final paragraph. Section 7.1: s/as prefix/as a prefix/ See also my earlier remark about the "Intended usage:" definition. The example registration appears to have it right. Section 8.2: s/should/SHOULD/ or s/should/needs to/, depending on whether you want it to be normative. Does RFC2616 or RFC3986 give guidance about how to do what's described here? If not, a reference needs to be provided. Section 8.3: I think the SHOULD here is probably fine, as long as you just explain that failing to follow that guidance can produce a response that is effectively unusable by the client. Section 10: The references should be ordered. I think that's just a matter of adding "" in the meta-data before the section. Appendix A: I don't know what the issue being discussed here is. Can we add a paragraph at the top describing the problem? It sounds like an attack, but I don't know given the text here. -MSK --047d7b5d8cff46e83f04d9fbc0e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My own comments on this draft as an individ= ual.=A0 Apologies if they repeat those of anyone else (and if so, please ig= nore accordingly); also, if there's an older thread with some of these = answers that I've managed to forget about, please point me in the right= direction.=A0 I've paid particular attention to the use of RFC2119 wor= ds here, since both of our ADs are sticklers for that kind of thing.

Section 1:

"HTTP" and "URL"= should be expanded on first use in Section 1.

Similarly, "Regi= stration Data" and "Directory Service" should be defined in = this context; i.e., registration of what?=A0 Does this refer to LDAP, which= is also a directory service?

s/should return/returns/

Section 2:

Expand/de= fine "RIRs" on first use.

Can you refer to a def= inition of "autonomous system" someplace?=A0 I can't think of= one off the top of my head, however.

Section 3:

"Should a result contain m= ore than one result" -- Suggest changing the first one to "reply&= quot; or "response", or the second to "entity".

s/may/can/, just to be safe.

Suggest addin= g "encryption" to the list in the third paragraph.

<= div>Section 4.1:

s/header/header field/ (which we insist = on in mail; not certain it's also common for web)

Section 4.2:

Under what circumstances migh= t one deviate from this SHOULD?=A0 What are the possible consequences of do= ing so?

Section 5:

What does "SHOU= LD understand" mean here?=A0 Since earlier we're saying the comple= xity is imposed on servers, and the whole thing should be usable by clients= pretty much as-is, I don't understand what existing clients are suppos= ed to do with this SHOULD.=A0 Also, same question as above:=A0 Why might on= e deviate from this SHOULD, and what are the possible consequences?

Section 5.1:

Same question about this SHOU= LD.=A0 I think you could get away without the normative language at all and= just say that if the server has the information, it constructs a success r= eply as per <some section in> [HTTP], using a media type selected as = per Section 4.1.

Section 5.2:

Same question about this SHOULD.=A0 In f= act I think that one ought to be a MUST; the protocol is effectively broken= if you don't do that.

There's one instance of &q= uot;url" that should be "URL".

I suggest including the example in the last paragraph as an = actual HTTP request and reply.=A0 Happy to help with the xml2rfc part if ne= eded.

Same question about this SHOULD.=A0 I think this on= e might also be a MUST.

Section 5.3:

Same question about this SHOULD.=A0 The = MAY is fine.

Section 5.4:

Same question= about this SHOULD.=A0 The MAY is fine.

Section 5.5:
<= br> I think the MAY should be a SHOULD, explaining that you might deviate if yo= u don't want to reveal explicitly that rate limiting is the reason for = the denial of a reply.

The second SHOULD is probably fine= ; the consequences of a client not backing off when told to do so are kind = of intuitive.

Section 6:

s/may/can/

This SHOULD i= s well explained; deviating from it has the consequences implied by the fin= al paragraph.

Section 7.1:

s/as prefix/as a prefix= /

See also my earlier remark about the "Intended usage:&q= uot; definition.=A0 The example registration appears to have it right.
<= br>
Section 8.2:

s/should/SHOULD/ or s/should/n= eeds to/, depending on whether you want it to be normative.

Does RFC2616 or RFC3986 give guidance about how to do what&#= 39;s described here?=A0 If not, a reference needs to be provided.

Section 8.3:

I think the SHOULD here is probably fine, as l= ong as you just explain that failing to follow that guidance can produce a = response that is effectively unusable by the client.

Section 10:

The references shou= ld be ordered.=A0 I think that's just a matter of adding "<?rfc= sortrefs=3D"yes" ?>" in the meta-data before the <fro= nt> section.

Appendix A:

I don't know what the issue being dis= cussed here is.=A0 Can we add a paragraph at the top describing the problem= ?=A0 It sounds like an attack, but I don't know given the text here.
-MSK
--047d7b5d8cff46e83f04d9fbc0e3-- From superuser@gmail.com Tue Apr 9 23:32: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 F136921F8D05 for ; Tue, 9 Apr 2013 23:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqvZHpQJ3dsP for ; Tue, 9 Apr 2013 23:32:51 -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 E74AF21F8C3C for ; Tue, 9 Apr 2013 23:32:50 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so4444611wiw.14 for ; Tue, 09 Apr 2013 23:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2n4LsNvddQCe3CUwP65WwOlwhivqMItW8T5dKwwJ8Bo=; b=KOrT60Qornn6LHq0IhxR7e1IMmY4MzYtyClB02TYlX4UpExgn/AkG/d4SKSp1/qdCW Loz/mbQyzs73s+X3ZSMcvxhTrhN6rnU8hb9aRx9/l5pLNKxVh9jYlNNvyxG6Hi7oqjEd urTmsAOwTirPE3zTV09B83jrKF8evnwzUFFq0+NDLoBjGaOsTkHQvsOcxsQfO2ZiozgH MI1F8i38F2Jysu3GKsXbNZSN0sRPXQM8JZYkMEvQ3dfjJ2NtElw5ISrBB1q19aDRxLx3 pbVcmUijJHeAaDhVVrS1r7X/q16OlhOuikWYv1CRdXeHcHju4yZUXvmxJ1ogYbY0/Y8H 9Jpw== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr24118233wiv.14.1365575559158; Tue, 09 Apr 2013 23:32:39 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 9 Apr 2013 23:32:39 -0700 (PDT) In-Reply-To: <20130409055153.GG24624@mx1.yitter.info> References: <20130409055153.GG24624@mx1.yitter.info> Date: Tue, 9 Apr 2013 23:32:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0438914d1e243204d9fbd679 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 06:32:52 -0000 --f46d0438914d1e243204d9fbd679 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 8, 2013 at 10:51 PM, Andrew Sullivan wrote: > On Wed, Mar 27, 2013 at 05:53:22PM +0100, Murray S. Kucherawy wrote > > > We would like to initiate a two-week Working Group Last Call on > > draft-ietf-weirds-http. > > Dear colleagues, > > I have read this draft. By and large, I think it's in good shape. I > include some comments here. These are made without reference to the > other comments that have been made, but I have read those comments and > mostly agree with them. > If I may ressurect a joke from the Atlanta meeting: "I agree with everything Andrew just said." To elaborate on a couple of points: Section 4.1 > > This specification does not define the responses a server returns > to > a request with any other media types in the Accept: header, or with > no Accept: header. > > It'd be nice to say why not. I think probably because this is > designed as a machine-to-machine protocol, where the formatting > for human consumption is supposed to be handled on the client > side, right? Is that another criterion that ought to be in > Section 3? > > It's odd that section 4 doesn't actually say how you send a query. > It's described in vague terms in Section 1, but now that you mention it, including as an appendix or even its own section a complete query-reply sequence in literal HTTP and JSON might be useful. > Section 6 > > Are identifiers case sensitive? Also, why are the starting > character rules SHOULD NOT? Certainly, SHOULD NOT on initial 0-9 > and _ is inconsistent with the ABNF. Also, the ABNF has no > indication that you shouldn't start with "xml". > I thought the same thing, but didn't mention it myself because the prose before and after the ABNF further explain the restriction. I think rather than coming up with ABNF that disallows the xml prefix, you can add a comment within the ABNF re-stating the restriction. In my own documents I do this like: thing = (a / b / c) 1*DIGIT whatever ; the numeric part MUST fit in a 32-bit integer -MSK --f46d0438914d1e243204d9fbd679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2013 at 10:51 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Wed, Mar 27, 2013 at 05:53:22PM +0100, Mu= rray S. Kucherawy wrote

> We would like to initiate a two-week Working Group Last Call on
> draft-ietf-weirds-http.

Dear colleagues,

I have read this draft. =A0By and large, I think it's in good shape. = =A0I
include some comments here. =A0These are made without reference to the
other comments that have been made, but I have read those comments and
mostly agree with them.

If I may ressur= ect a joke from the Atlanta meeting: "I agree with everything Andrew j= ust said."=A0 To elaborate on a couple of points:

Section 4.1

=A0 =A0This specification does not define the responses a server returns to
=A0 =A0a request with any other media types in the Accept: header, or with<= br> =A0 =A0no Accept: header.

=A0 =A0 It'd be nice to say why not. =A0I think probably because = this is
=A0 =A0 designed as a machine-to-machine protocol, where the formatting
=A0 =A0 for human consumption is supposed to be handled on the client
=A0 =A0 side, right? =A0Is that another criterion that ought to be in
=A0 =A0 Section 3?

=A0 =A0 It's odd that section 4 doesn't actually say how you send a= query.

It's described in vague ter= ms in Section 1, but now that you mention it, including as an appendix or e= ven its own section a complete query-reply sequence in literal HTTP and JSO= N might be useful.

=A0
Section 6

=A0 =A0 Are identifiers case sensitive? =A0Also, why are the starting
=A0 =A0 character rules SHOULD NOT? =A0Certainly, SHOULD NOT on initial 0-9=
=A0 =A0 and _ is inconsistent with the ABNF. =A0Also, the ABNF has no
=A0 =A0 indication that you shouldn't start with "xml".

I thought the same thing, but didn't men= tion it myself because the prose before and after the ABNF further explain = the restriction.=A0 I think rather than coming up with ABNF that disallows = the xml prefix, you can add a comment within the ABNF re-stating the restri= ction.=A0 In my own documents I do this like:

thing =3D (a / b / c) 1*DIGIT whatever
=A0=A0= =A0=A0=A0 ; the numeric part MUST fit in a 32-bit integer

-MSK
--f46d0438914d1e243204d9fbd679-- From jean-philippe.dionne@viagenie.ca Wed Apr 10 09:53: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 7D5C521F8ECA for ; Wed, 10 Apr 2013 09:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HqPqmK4sLQPv for ; Wed, 10 Apr 2013 09:53:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id C72A321F8EAC for ; Wed, 10 Apr 2013 09:53:15 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 239AD403EE for ; Wed, 10 Apr 2013 12:52:45 -0400 (EDT) Message-ID: <516598DC.3070009@viagenie.ca> Date: Wed, 10 Apr 2013 12:52:44 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAE47@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFAE47@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:53:16 -0000 Hi, On 04/08/2013 10:28 PM, Andy Newton wrote: > Changed DNS names to LDH names and Unicode names Is the "ldhName" property mendatory and "unicodeName" optional? The unicode name, as it is defined in draft-ietf-weirds-json-response-03#section-4 , cannot represent a 100% ASCII domain name: Unicode names: Textual representations of DNS names were one or more of the labels are u-labels as described by [RFC5890]. Trailing periods are optional. and following into rfc5890#section-2.3.2.1 : A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). Regards Jean-Philippe From andy@arin.net Thu Apr 11 06:49: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 7BD6221F8C10 for ; Thu, 11 Apr 2013 06:49:40 -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 jl+BaBCznLeK for ; Thu, 11 Apr 2013 06: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 2E51821F8ADC for ; Thu, 11 Apr 2013 06:49:39 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id CEC7921365A; Thu, 11 Apr 2013 09:49:38 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 447812135FF; Thu, 11 Apr 2013 09:49: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, 11 Apr 2013 09:49:16 -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, 11 Apr 2013 09:49:31 -0400 From: Andy Newton To: Jean-Philippe Dionne , "weirds@ietf.org" Thread-Topic: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) Thread-Index: AQHONrtkOuc/zkYA3Eq8vSy3m20Qvg== Date: Thu, 11 Apr 2013 13:49:31 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFBC25@CHAXCH01.corp.arin.net> In-Reply-To: <516598DC.3070009@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <36A85365FB8EA04F983DE79B35751A87@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:49:40 -0000 Jean-Philippe, Thanks for the comments. My reply is in-line: On 4/10/13 12:52 PM, "Jean-Philippe Dionne" wrote: >Hi, > >On 04/08/2013 10:28 PM, Andy Newton wrote: >> Changed DNS names to LDH names and Unicode names > >Is the "ldhName" property mendatory and "unicodeName" optional? Good point. I would think that ldhName is a SHOULD with unicodeName OPTIONAL. >The unicode name, as it is defined in >draft-ietf-weirds-json-response-03#section-4 , cannot represent a 100% >ASCII domain name: > > Unicode names: Textual representations of DNS names were one or > more of the labels are u-labels as described by > [RFC5890]. Trailing periods are optional. > >and following into rfc5890#section-2.3.2.1 : > > A "U-label" is an IDNA-valid string of Unicode characters, in > Normalization Form C (NFC) and including at least one non-ASCII > character, expressed in a standard Unicode Encoding Form (such as > UTF-8). To represent 100% ASCII in unicodeName, our restriction could be changed to "where zero or more of the labels are u-labels=8A". But I don't understand. What's the point of populating unicodeName with a 100% ASCII domain name? -andy From jean-philippe.dionne@viagenie.ca Thu Apr 11 07:12: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 01A3E21F87E0 for ; Thu, 11 Apr 2013 07:12: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 lviAbBVH2E0M for ; Thu, 11 Apr 2013 07:12:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7362A21F87D5 for ; Thu, 11 Apr 2013 07:12:34 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C443B403ED; Thu, 11 Apr 2013 10:12:03 -0400 (EDT) Message-ID: <5166C4B3.4070101@viagenie.ca> Date: Thu, 11 Apr 2013 10:12:03 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFBC25@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFBC25@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:12:35 -0000 Hi, On 04/11/2013 09:49 AM, Andy Newton wrote: > To represent 100% ASCII in unicodeName, our restriction could be changed > to "where zero or more of the labels are u-labelsŠ". But I don't > understand. What's the point of populating unicodeName with a 100% ASCII > domain name? > The definition doesn't have to be changed. I just wanted to show that, according to the definitions, unicodeName couldn't be used in all situation and had to be OPTIONAL. Thanks Jean-Philippe From simon.perreault@viagenie.ca Thu Apr 11 07:17:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04C721F85C6 for ; Thu, 11 Apr 2013 07:17:14 -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 BPaIzwXLhmwh for ; Thu, 11 Apr 2013 07:17:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2E821F859A for ; Thu, 11 Apr 2013 07:17:14 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e4f1:5649:5ce3:8749]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B8409403ED for ; Thu, 11 Apr 2013 10:16:43 -0400 (EDT) Message-ID: <5166C619.2000307@viagenie.ca> Date: Thu, 11 Apr 2013 16:18:01 +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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFBC25@CHAXCH01.corp.arin.net> <5166C4B3.4070101@viagenie.ca> In-Reply-To: <5166C4B3.4070101@viagenie.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:17:14 -0000 Le 2013-04-11 16:12, Jean-Philippe Dionne a écrit : > Hi, > > On 04/11/2013 09:49 AM, Andy Newton wrote: >> To represent 100% ASCII in unicodeName, our restriction could be changed >> to "where zero or more of the labels are u-labelsŠ". But I don't >> understand. What's the point of populating unicodeName with a 100% ASCII >> domain name? >> > > The definition doesn't have to be changed. I just wanted to show that, > according to the definitions, unicodeName couldn't be used in all > situation and had to be OPTIONAL. OPTIONAL is incorrect. unicodeName MUST be present if the name has a u-label representation. But even for pure ASCII names I think unicodeName should be there. I don't want to sprinkle all my future scripts with "if unicodeName is present then use it, otherwise use ldhName". I just want to get to the Unicode representation, and I don't care if it's full ASCII or not. Simon From andy@arin.net Thu Apr 11 11:23:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DCA21F8C06 for ; Thu, 11 Apr 2013 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnSWCVWtigR8 for ; Thu, 11 Apr 2013 11:23:17 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4121F85BF for ; Thu, 11 Apr 2013 11:23:17 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id EECDE16529E; Thu, 11 Apr 2013 14:23:06 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 75CFA165299; Thu, 11 Apr 2013 14:23:04 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 11 Apr 2013 14:22:35 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 14:22:51 -0400 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) Thread-Index: AQHONrtkOuc/zkYA3Eq8vSy3m20QvpjRUquAgAABq4CAAAFbAA== Date: Thu, 11 Apr 2013 18:22:50 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> In-Reply-To: <5166C619.2000307@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <3DD6C8C7C3C8944A859760A5D796F927@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:23:19 -0000 On 4/11/13 10:18 AM, "Simon Perreault" wrote: >OPTIONAL is incorrect. unicodeName MUST be present if the name has a >u-label representation. Well, the MUST use unicodeName if they want to express the unicode version. But it is all up to registry police. Certainly use of unicodeName is RECOMMENDED if the domain name is an IDN. >But even for pure ASCII names I think unicodeName should be there. I >don't want to sprinkle all my future scripts with "if unicodeName is >present then use it, otherwise use ldhName". I just want to get to the >Unicode representation, and I don't care if it's full ASCII or not. Unfortunately, that is all up to the policy of the registry. -andy From simon.perreault@viagenie.ca Thu Apr 11 11:47: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 294AB21F84F5 for ; Thu, 11 Apr 2013 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 EbNhcJiFXSsv for ; Thu, 11 Apr 2013 11:47:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82621F81FF for ; Thu, 11 Apr 2013 11:47:09 -0700 (PDT) Received: from porto.nomis80.org (85-169-43-76.rev.numericable.fr [85.169.43.76]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4203B403ED; Thu, 11 Apr 2013 14:46:59 -0400 (EDT) Message-ID: <51670522.9000906@viagenie.ca> Date: Thu, 11 Apr 2013 20:46:58 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:47:10 -0000 Le 2013-04-11 20:22, Andy Newton a écrit : > On 4/11/13 10:18 AM, "Simon Perreault" wrote: > >> OPTIONAL is incorrect. unicodeName MUST be present if the name has a >> u-label representation. > > Well, the MUST use unicodeName if they want to express the unicode > version. But it is all up to registry police. Certainly use of unicodeName > is RECOMMENDED if the domain name is an IDN. > >> But even for pure ASCII names I think unicodeName should be there. I >> don't want to sprinkle all my future scripts with "if unicodeName is >> present then use it, otherwise use ldhName". I just want to get to the >> Unicode representation, and I don't care if it's full ASCII or not. > > Unfortunately, that is all up to the policy of the registry. I don't get why this is a policy issue. If it's not provided by the server, it can be computed by the client. Providing it is just being nice so that clients don't need to implement the complex IDNA machinery. Maybe I missed something... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dk@hostmaster.ua Thu Apr 11 12:13: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 71C1921F8F02 for ; Thu, 11 Apr 2013 12:13:09 -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 U7Q74l6-Ls2o for ; Thu, 11 Apr 2013 12:13:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id B879F21F8F00 for ; Thu, 11 Apr 2013 12:13:08 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0A8EA21000; Thu, 11 Apr 2013 15:13:08 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 11 Apr 2013 15:13:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=pn4Pp0sry/B0Qug9AUaEZvG4nlk=; b=aX 4JWKcAQ1Eg4I235fEkKlWgSgja0tBKcFPYL/I1VDFft8I1wL8pVaj0W9rlhIddZ4 MWwpMGfRNr5MXV29BHGFY50hNXm2SCLfGv6TM1w8O77WQmP8iBvPbefyFBBwyLxH Kiz9aUC3jxgLzyS+03OYjtrj7n+Old7s30erqMdFI= X-Sasl-enc: yQ3EtN8z8A/h7OlkytJHwnVz0zUR9TZ0RX0TNpxZZYpj 1365707587 Received: from [192.168.77.108] (unknown [93.74.55.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 3204D2000D1; Thu, 11 Apr 2013 15:13:07 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Dmitry Kohmanyuk In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> Date: Thu, 11 Apr 2013 22:13:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7FAEBE4B-12D1-4983-94DF-ABB740BACFC9@hostmaster.ua> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:13:09 -0000 On Apr 11, 2013, at 9:22 PM, Andy Newton wrote: > On 4/11/13 10:18 AM, "Simon Perreault" = wrote: >=20 >> OPTIONAL is incorrect. unicodeName MUST be present if the name has a >> u-label representation. >=20 > Well, the MUST use unicodeName if they want to express the unicode > version. But it is all up to registry police. Certainly use of = unicodeName > is RECOMMENDED if the domain name is an IDN. >=20 >> But even for pure ASCII names I think unicodeName should be there. I >> don't want to sprinkle all my future scripts with "if unicodeName is >> present then use it, otherwise use ldhName". I just want to get to = the >> Unicode representation, and I don't care if it's full ASCII or not. >=20 > Unfortunately, that is all up to the policy of the registry. if registry has IDN names, it has to provide their IDNA form (A-label) = as ldhName and possibly U-label (in unicodeName); if registry has only ASCII names, it should provide them as ldhName; = unicodeName can be used, or not. so ldhName field is MUST, and unicodeName is SHOULD? Some registries = (UA included) provide only A-labels in whois. Personally, if I would be writing a client I would use my own Unicode = conversion if needed - but i can see why somebody may want decoded name and encoded name fields. So the = rationale was to make it easier for clients? From edainow@afilias.info Fri Apr 12 10:12: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 DFA7221F8640 for ; Fri, 12 Apr 2013 10:12: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 3HgG-x+a5Wph for ; Fri, 12 Apr 2013 10:12:44 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50321F863C for ; Fri, 12 Apr 2013 10:12:44 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UQhWl-00067j-58 for weirds@ietf.org; Fri, 12 Apr 2013 17:12:43 +0000 Received: from mail-ie0-f197.google.com ([209.85.223.197]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UQhWl-0005WO-4p for weirds@ietf.org; Fri, 12 Apr 2013 17:12:43 +0000 Received: by mail-ie0-f197.google.com with SMTP id a11so16576948iee.4 for ; Fri, 12 Apr 2013 10:12:38 -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=jgVy2+S2ieghSMU9TX3DUs5faRBcbNsRoe69ar1yBtU=; b=jQRJ6x3vmkvl5jimgfgMKMaiCVGMZFlRk7RBR20HBc0Hh7Auv6vKGO+7aAAg/XnvPc RBpn5YFeFm8fAZ+JfjW2zn6jPwdIVJTJEhNEs3jX53rzRgojRUi7kddDzLE1hPXXcvQi WLPp80OxPiDVJiGHWYj0kLczYXTgbheZq8EWp7uvSQ9zRchS91uq3ZBg4YSFtp5LC8yM aGPtVzKKEwBsEB9MpSockTAx95z4WUNzmzQtzpoPkueZIL1R+e6p3PTjB8sXLqljzbve 0ukpaRtlKfwKdENmSZ1Lid+TDhln/iNFDKLDVm4edJPgG1YV7C2BJ2ChtKG0ZhLxCbIh FWHw== X-Received: by 10.50.153.198 with SMTP id vi6mr2292437igb.112.1365786758053; Fri, 12 Apr 2013 10:12:38 -0700 (PDT) X-Received: by 10.50.153.198 with SMTP id vi6mr2292431igb.112.1365786757923; Fri, 12 Apr 2013 10:12:37 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id qs4sm3765789igb.10.2013.04.12.10.12.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 10:12:34 -0700 (PDT) Message-ID: <5168407E.80303@afilias.info> Date: Fri, 12 Apr 2013 13:12:30 -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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB357@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFB357@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlIHieDUY43p/95z+GDHFuXiUjZd5j2QPQ79jdJN4gKh7QEI8LWENECvxBnGpk/t/SWKQwovrdV+XMdqGE6rIkm7+BPEu5zwpg0AFheowZUkYR+ujd5VhPdSEYpEpteYeUsVgmZ Cc: "weirds@ietf.org" , Gavin Brown Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-03.txt - vCard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 17:12:45 -0000 On 4/9/2013 4:00 PM, Andy Newton wrote: > Gavin, > > Thanks for looking at the latest document. My comments are in-line: > > On 4/9/13 3:19 PM, "Gavin Brown" wrote: > >> 1. vCard >> >> I have no particular preference for vCard or any other format for >> address information. However I would like to note that the suggestion >> that vCard be used was prompted by my request that entity responses >> allowed for structured address data, so that address data held by DNRs >> is not represented in a lossy way. >> >> We now have a situation where vCard is used to represent address >> information -- at the cost of a more complex data model -- but address >> data is still a flat array of strings, so my original suggestion has >> still not been satisfied. > I think it is just a matter of providing examples that use structured > addresses with jCard. Perhaps Scott and I should start thinking of an > appendix which discusses the use of structured and unstructured addresses > with jCard. But jCard can support both. > Many examples have vCard entries. I would prefer one section on vCard showing a few examples, and then just referring back to that section instead of repeating the same vCard in all examples as in the current draft. In discussions about remarks and notices, it was concluded that the server should not be doing formatting. The inclusion of the \n control character in the vCard examples is inconsistent with this principle. Instead of: [ "label", {}, "text", "123 Maple Ave\n", "Suite 90001\n", ... Can we not do: [ "label", {}, "text", ["123 Maple Ave", "Suite 90001", ...] -Ernie From edainow@afilias.info Fri Apr 12 10:34: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 8F90621F860A for ; Fri, 12 Apr 2013 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, 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 RpBB1+x+WfCn for ; Fri, 12 Apr 2013 10:34:16 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3921F85DA for ; Fri, 12 Apr 2013 10:34:13 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UQhrY-0008Bt-3q for weirds@ietf.org; Fri, 12 Apr 2013 17:34:12 +0000 Received: from mail-oa0-f72.google.com ([209.85.219.72]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UQhrY-0006dD-3Z for weirds@ietf.org; Fri, 12 Apr 2013 17:34:12 +0000 Received: by mail-oa0-f72.google.com with SMTP id j6so18080844oag.11 for ; Fri, 12 Apr 2013 10:34:06 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=sTiDnkYK0k8D7j0/+mc1l2RXc99+aQvho9hcoXcpKB4=; b=Emn/O+ZZj7bnRRkaecNSz9PSyZ1Donr+9WBRLnujqIK5eLkIdsLt3Rc3kEDDVfCmCj uFzUvqZ50Tk9OZmndLHYN+VnOMqT5lXAd2XBnCIl4HwB7h5chtp8rfCvQ4qYB48To72J K8QpCDymCxEUNvHgavsAcjl02MDNEQBEHEtLTyQhQd2KMTOkR5WG9dwDevQTumveNiel zyWG4iPCkbw/TBzTktaCt0MstpbEs4uX4ZbVsX/2MFn25AlYGX04uf8wx4KIxFPkwmeG NByqz5U/p0TdB6bJOV5M1mFU7zSq6YL4rLbJLjFAShpT5V7ym/aAK9UsiKLbxE53rUu/ ocgg== X-Received: by 10.50.73.65 with SMTP id j1mr2363377igv.49.1365788046398; Fri, 12 Apr 2013 10:34:06 -0700 (PDT) X-Received: by 10.50.73.65 with SMTP id j1mr2363373igv.49.1365788046272; Fri, 12 Apr 2013 10:34:06 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id hi4sm3897626igc.6.2013.04.12.10.34.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 10:34:04 -0700 (PDT) Message-ID: <51684588.8080307@afilias.info> Date: Fri, 12 Apr 2013 13:34:00 -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 References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC097@CHAXCH01.corp.arin.net> <7FAEBE4B-12D1-4983-94DF-ABB740BACFC9@hostmaster.ua> In-Reply-To: <7FAEBE4B-12D1-4983-94DF-ABB740BACFC9@hostmaster.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk0bHNEn+3x90TB7hPmAT8HJ41Ybha+2O+5LjEOs7/3ZCgdjC5ODSpJaO0PAFq+0SANZjvXPMekjr423LJFJlpBtAtSf8zSAUqNPIjFY/5C5tep4NV9tN6p3tp3zVd9+wXxACEy Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 17:34:16 -0000 On 4/11/2013 3:13 PM, Dmitry Kohmanyuk wrote: > On Apr 11, 2013, at 9:22 PM, Andy Newton wrote: > >> On 4/11/13 10:18 AM, "Simon Perreault" wrote: >> >>> OPTIONAL is incorrect. unicodeName MUST be present if the name has a >>> u-label representation. >> Well, the MUST use unicodeName if they want to express the unicode >> version. But it is all up to registry police. Certainly use of unicodeName >> is RECOMMENDED if the domain name is an IDN. >> >>> But even for pure ASCII names I think unicodeName should be there. I >>> don't want to sprinkle all my future scripts with "if unicodeName is >>> present then use it, otherwise use ldhName". I just want to get to the >>> Unicode representation, and I don't care if it's full ASCII or not. >> Unfortunately, that is all up to the policy of the registry. > > if registry has IDN names, it has to provide their IDNA form (A-label) as ldhName and possibly U-label (in unicodeName); > if registry has only ASCII names, it should provide them as ldhName; unicodeName can be used, or not. > > so ldhName field is MUST, and unicodeName is SHOULD? Some registries (UA included) provide only A-labels in whois. > > Personally, if I would be writing a client I would use my own Unicode conversion if needed - but i can see why > somebody may want decoded name and encoded name fields. So the rationale was to make it easier for clients? > > There was also discussion of including the "IDN table identifier" with unicode names. Has this been ruled out? http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html -Ernie From superuser@gmail.com Fri Apr 12 10:51: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 A83CC21F8976 for ; Fri, 12 Apr 2013 10:51:23 -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, 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 Lr9+QLiOVWcs for ; Fri, 12 Apr 2013 10:51: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 A39C721F8D4E for ; Fri, 12 Apr 2013 10:51:22 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so1843340wib.9 for ; Fri, 12 Apr 2013 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=qzce71lqhiFem9WkOtPToBur2fXphqf39I7oK+kjEuk=; b=yD6eH8lwmC7V0x/Oo/ko4Ptm+ff8jGP6vpD04Nn3wE3v8lqKT22yvwHgV0SbMPQtAH Et+AzeP0FhlDppsWD6ILJ5fSh+0L8iP6Fun/7lQl48OQyk0cHVFI/AnUAEuDC6A6yp9v b6v3VkLMwKukJI6U+Ehvhm4XTkvJ+92kzdqREPGBj3x/0fksNhznvK78sIENis8U46qk JJFEsvX/FYr9X0Mpj0MQgwxYLrNc8CASmDqEE5GCJvm/oDhizbOVgHQTLuR39oybrZnt 11NKBW5+kE8JzZc2yOhiaE81vd7n115gAqIcDgXO9b6lqAwSpSetzYuUpDZ0BOTdPgP0 x/kQ== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr19104858wjc.59.1365789081838; Fri, 12 Apr 2013 10:51:21 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 10:51:21 -0700 (PDT) Date: Fri, 12 Apr 2013 10:51:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1b9420fab6e04da2d8d5c Subject: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 17:51:24 -0000 --001a11c1b9420fab6e04da2d8d5c Content-Type: text/plain; charset=ISO-8859-1 Colleagues, This message begins a two-week Working Group Last Call on draft-ietf-weirds-rdap-sec. Version 02 is current in the tracker: https://datatracker.ietforg/doc/draft-ietf-weirds-rdap-sec Last call will end on Friday, April 26. Please review and comment on the draft, even if it is only to say on the record "I have reviewed this document thoroughly and it looks good." We would like to have no fewer than five people report that they have taken a look at the whole document and reported their findings, and will be reticent to send it to the IESG without that. We're also keen to hear from people that have implemented the specification as to their views on clarity, correctness, and completeness. I will be the document shepherd for this one. Thanks, -MSK and Olaf, your co-chairs --001a11c1b9420fab6e04da2d8d5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

This message begins a two-wee= k Working Group Last Call on draft-ietf-weirds-rdap-sec.=A0 Version 02 is c= urrent in the tracker:

https://datatracker.ietforg/doc/draft-ietf-= weirds-rdap-sec

Last call will end on Friday, April 26.

Please r= eview and comment on the draft, even if it is only to say=20 on the record "I have reviewed this document thoroughly and it looks= =20 good."=A0 We would like to have no fewer than five people report that = they have taken a look at the whole document and reported their findings,=20 and will be reticent to send it to the IESG without that.=A0 We're also= =20 keen to hear from people that have implemented the specification as to=20 their views on clarity, correctness, and completeness.

I will be the document shepherd for this one.

Thanks,

-MS= K and Olaf, your co-chairs

--001a11c1b9420fab6e04da2d8d5c-- From edainow@afilias.info Fri Apr 12 11:38:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3821F8D4E for ; Fri, 12 Apr 2013 11:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 lp9EMq1kAAZs for ; Fri, 12 Apr 2013 11:38:16 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6F21F854F for ; Fri, 12 Apr 2013 11:38:16 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UQirY-0005bf-4X for weirds@ietf.org; Fri, 12 Apr 2013 18:38:16 +0000 Received: from mail-oa0-f72.google.com ([209.85.219.72]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UQirY-0001qq-4H for weirds@ietf.org; Fri, 12 Apr 2013 18:38:16 +0000 Received: by mail-oa0-f72.google.com with SMTP id j6so18520006oag.11 for ; Fri, 12 Apr 2013 11:38:10 -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=mXQueqWkNWxKukZIXgLfrxZLQHX8keZLIscYiGDnG2g=; b=pOQARoSYy9YDfcplUUBkOt8npNs6qfSQ0ShQ5hOKj3H15vijlbja5wAmsCZt0bksN0 x0NCImuzZr7ktkWem/ZOgEllY8MhZUMPf9lP9EP5bIB+IVdasLPzsvucBkMjn4N8CiE0 gt62J4Mhg1QrKRbAqshhDo9IypEZSu5MsGZBBMjp4PTqKHoV4taPBA4a6vORdVXLQY2d QfM7TRDe/CTym48Fh0lM2IpOOA+x6dNAklGgVX1K2CYIJ8XIb8vHujdKmBLFgmfIOxkO qiCw4S3VsXiZyeXx+GLAZD/HrIb34uQlCAn9xjYoNRMxTs5e9kuxqQV77oENS44Dwlmj axRg== X-Received: by 10.43.9.68 with SMTP id ov4mr7162662icb.22.1365791890609; Fri, 12 Apr 2013 11:38:10 -0700 (PDT) X-Received: by 10.43.9.68 with SMTP id ov4mr7162659icb.22.1365791890502; Fri, 12 Apr 2013 11:38:10 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPS id ua6sm3823252igb.0.2013.04.12.11.38.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 11:38:09 -0700 (PDT) Message-ID: <5168548D.802@afilias.info> Date: Fri, 12 Apr 2013 14:38:05 -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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBE7CE0@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBE7CE0@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkAUL9RmfcljfyuRLyMXm/5fRYVOrM7rBJf0BRgbGpO60BFMQXwnK7JzY3Yg4q77QFlf94c4IDP915QWwNmu7ylMKDF3HhWNF27irbPimkTki53uBLHmXZbMCcDFk06/fcXC7i3 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, 12 Apr 2013 18:38:17 -0000 On 1/31/2013 11:35 AM, Andy Newton wrote: > On 1/31/13 11:26 AM, "Warren Kumari" wrote: > >> Fine -- so a "should" or a "recommend" or a "pretty please do this"Š >> >> I don't really care how, but encouraging implementations to support it >> would be goodŠ > That works for me. If somebody would be willing to flesh out an outline or > some points that implementers might want to put in this help, I would > imagine that would go a long way to providing the proper context for > implementers to understand why providing this information is such a good > idea. > > -andy > > A help link may be useful for providing detailed information about a particular object but not for providing overall help. Suppose a client uses a redirection service and successfully retrieves data for many DNS names, but hits an authentication failure with a particular name. The user now has the redirected url to the correct server, so they append "help" to the path and get the documentation, which should provide requirements and instructions for authentication. To support this, a standard path segment for "help" should be added to the rdap-query spec. Here is some proposed wording. An RDAP user, whether an end user or a developer of a client application, may need to know a number of technical details. The response to "help" should display in a browser and provide basic documentation that a user needs to successfully use the service. Note that in some cases, it may be more useful to provide detailed documentation for a particular object by using a link in that object rather than in the general help. Following is some of the general information that should be provided. - What objects the server supports, for example domains for what TLDs - Description of any extensions - custom path segments and JSON values. - Whether authentication is required or not and how to get authentication credentials. - Which optional parts of the spec are not supported (for example, what Search options). - 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. - Names of a few objects that exist, so that a client can do some basic tests. - How to get technical support for problems or unanswered questions (for example, including a comment submission form on the Help page). -Ernie From andy@arin.net Fri Apr 12 12:16: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 133DF21F8E5F for ; Fri, 12 Apr 2013 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=3.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 lzfpo6q5gvR0 for ; Fri, 12 Apr 2013 12:16:46 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF121F8E5A for ; Fri, 12 Apr 2013 12:16:46 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 24365165393; Fri, 12 Apr 2013 15:16:16 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id A4007165390; Fri, 12 Apr 2013 15:16:15 -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, 12 Apr 2013 15:15:55 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 12 Apr 2013 15:16:15 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-03.txt - vCard Thread-Index: AQHON6D3o7/AIJEamE2nh1Nwt9DBKZjS9R8A Date: Fri, 12 Apr 2013 19:16:14 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC579@CHAXCH01.corp.arin.net> In-Reply-To: <5168407E.80303@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: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DAEE8D701EC8C458F49BC78038A4E58@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , Gavin Brown Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-03.txt - vCard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 19:16:47 -0000 On 4/12/13 1:12 PM, "Ernie Dainow" wrote: >In discussions about remarks and notices, it was concluded that the >server should not be doing formatting. The inclusion of the \n control >character in the vCard examples is inconsistent with this principle. > >Instead of: > [ "label", {}, "text", "123 Maple Ave\n", > "Suite 90001\n", > ... >Can we not do: > [ "label", {}, "text", ["123 Maple Ave", "Suite 90001", ...] Ernie, I think the \n is the unstructured jCard. Honestly, I don't know enough about jCard to tell you if the examples shouldn't have \n in them, though I certainly understand your point. -andy From andy@arin.net Fri Apr 12 12:47: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 6EFBC21F8314 for ; Fri, 12 Apr 2013 12:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 atS8mDZudx8g for ; Fri, 12 Apr 2013 12:47:31 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8521F8266 for ; Fri, 12 Apr 2013 12:47:31 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 6C55B2135A6; Fri, 12 Apr 2013 15:47:31 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 7B1C821360D; Fri, 12 Apr 2013 15:47:11 -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, 12 Apr 2013 15:46:51 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 12 Apr 2013 15:46:07 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) Thread-Index: AQHONrtkOuc/zkYA3Eq8vSy3m20QvpjRUquAgAABq4CAAAFbAIAAURcAgAF2pQD//+HVAA== Date: Fri, 12 Apr 2013 19:46:05 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC5B0@CHAXCH01.corp.arin.net> In-Reply-To: <51684588.8080307@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: [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] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 19:47:32 -0000 On 4/12/13 1:34 PM, "Ernie Dainow" wrote: >There was also discussion of including the "IDN table identifier" with >unicode names. Has this been ruled out? >http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html > > This was an oversight. Though looking over that draft it isn't apparent to me which tables identifiers are being referenced. Is there more specific information? -andy From edainow@afilias.info Fri Apr 12 13:15: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 BDD4521F8E87 for ; Fri, 12 Apr 2013 13:15:58 -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 KYUcNMYL7TNk for ; Fri, 12 Apr 2013 13:15:58 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C823421F8E7E for ; Fri, 12 Apr 2013 13:15:57 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UQkO4-0008Bp-5s for weirds@ietf.org; Fri, 12 Apr 2013 20:15:56 +0000 Received: from mail-la0-f72.google.com ([209.85.215.72]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UQkO4-0008ES-5L for weirds@ietf.org; Fri, 12 Apr 2013 20:15:56 +0000 Received: by mail-la0-f72.google.com with SMTP id fr10so3929773lab.11 for ; Fri, 12 Apr 2013 13:15:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=d6H42VSwItZ01ynyv+htAO4hmMT8ZW74uiGeLbKeLJc=; b=DdNnHVzdBOSWVDxZaHbvAsMF4k+YkyhfcuJVOfy7EJbSHWfictvWR2frGfr2j53kP8 cY+iVbmNlNjp/tv7ve9ivWpSY1gaTjkP9dy0peJoO2J0cUjHMwRjthuvhTunfI8uJ6Ck KCzJjjvZfU8fR3LaRRw0POh9+whmDYq79o+P1LPxdGvXHKKwsE7YGiV8JpXC5afbYeAW BBAMyquInaKnmHecY1yLJHTMdzw9uxeoNdytqv440g3fR/EzjX89Ww6qf9F6ossUEVqB ZfABaxz5Wx2R7BFrW5K9uSNgt//cfo6/b5omImF+rk9IUb/OBvilu918JE4DkgARBMuc eG/g== X-Received: by 10.112.136.33 with SMTP id px1mr6049013lbb.95.1365797750322; Fri, 12 Apr 2013 13:15:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.136.33 with SMTP id px1mr6049007lbb.95.1365797750087; Fri, 12 Apr 2013 13:15:50 -0700 (PDT) Received: by 10.112.23.41 with HTTP; Fri, 12 Apr 2013 13:15:49 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC5B0@CHAXCH01.corp.arin.net> References: <51684588.8080307@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC5B0@CHAXCH01.corp.arin.net> Date: Fri, 12 Apr 2013 16:15:49 -0400 Message-ID: From: Ernie Dainow To: Andy Newton Content-Type: multipart/alternative; boundary=089e0115fc4ebab12304da2f91c0 X-Gm-Message-State: ALoCoQljaB68uRIu5+TRMsEJkdVT+aNpZFD+JrR7axJPrgzh1tUjvHN60/dNXco2lvkWvNRr0Jv0T+UGhJ69TYGwtgnBWQZkXIjwzxWeoE6XrQjm4AvHmt2pPsdRkKmoDLoq/fCYj8A+ Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 20:15:58 -0000 --089e0115fc4ebab12304da2f91c0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 12, 2013 at 3:46 PM, Andy Newton wrote: > On 4/12/13 1:34 PM, "Ernie Dainow" wrote: > > >There was also discussion of including the "IDN table identifier" with > >unicode names. Has this been ruled out? > >http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html > > > > > > This was an oversight. Though looking over that draft it isn't apparent to > me which tables identifiers are being referenced. Is there more specific > information? > > -andy > > http://www.iana.org/domains/idn-tables -Ernie --089e0115fc4ebab12304da2f91c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 12, 2013 at 3:46 PM, Andy Ne= wton <andy@arin.net> wrote:
On 4/12/13 1:34 PM, "Ernie Dainow" <edainow@afilias.info> wrote:

>There was also discussion of including the "IDN table identifier&q= uot; with
>unicode names. Has this been ruled out?
>http://www.ietf.org/mail-archive/web/weirds/curren= t/msg02391.html
>
>

This was an oversight. Though looking over that draft it isn't ap= parent to
me which tables identifiers are being referenced. Is there more specific information?

-andy



=
-Ernie
--089e0115fc4ebab12304da2f91c0-- From dk@hostmaster.ua Fri Apr 12 13:55: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 A58E721F8F01 for ; Fri, 12 Apr 2013 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buF+HXg3vKff for ; Fri, 12 Apr 2013 13:55:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id E58CB21F8EC1 for ; Fri, 12 Apr 2013 13:55:05 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4AD9D2054D; Fri, 12 Apr 2013 16:55:03 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 12 Apr 2013 16:55:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=/8z W+zlVI6oVKY7MfdS0mC8CBKk=; b=Rl4txtCVbgRINyRX08MlxC2nqvB/bqJGJbU 26+lr7m2GgkRkJZ+MdLatNdH8iS+ZBiKVoTgaUr0i+TaNu3fqmhe1WvQ8v+aP57+ 7ccEcc2bqEg+eK6E1PmCZUDFIHQhYpKoVlTjFwz5CqHIsGFb7/6Kg4IkHhpHb22s zdti0uFE= X-Sasl-enc: /pVIIbyIWWoDrba5ulKuhQiiXWMj+EMiTpbx/kjhRXkn 1365800102 Received: from [192.168.77.108] (unknown [93.74.55.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 5A7E3C80003; Fri, 12 Apr 2013 16:55:02 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9DF4882A-3D5E-4CB5-8979-BA25BB4634E6" From: Dmitry Kohmanyuk In-Reply-To: Date: Fri, 12 Apr 2013 23:55:01 +0300 Message-Id: <0DDB0C80-51B8-4D8A-A7FB-78FA0B5769AB@hostmaster.ua> References: <51684588.8080307@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC5B0@CHAXCH01.corp.arin.net> To: Ernie Dainow X-Mailer: Apple Mail (2.1503) Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 20:55:35 -0000 --Apple-Mail=_9DF4882A-3D5E-4CB5-8979-BA25BB4634E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 12, 2013, at 11:15 PM, Ernie Dainow wrote: > On Fri, Apr 12, 2013 at 3:46 PM, Andy Newton wrote: > On 4/12/13 1:34 PM, "Ernie Dainow" wrote: >=20 > >There was also discussion of including the "IDN table identifier" = with > >unicode names. Has this been ruled out? > >http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html > > > > this refers to=20 http://tools.ietf.org/html/draft-obispo-epp-idn-02 which was recently updated (April 5th) - but that draft has no reference = to IDN table repository=20 ("provided by (EPP) server" identifier is mentioned, only.) >=20 > This was an oversight. Though looking over that draft it isn't = apparent to > me which tables identifiers are being referenced. Is there more = specific > information? >=20 > -andy >=20 >=20 > http://www.iana.org/domains/idn-tables >=20 those tables are not very usable as machine-readable registry - as their = format is usually free-formed text. a (working draft) document was written by Kim Davies a while ago to = offer XML format for them,=20 but have not been adopted by IANA yet. I don't have reference to it on = hand. also, multiple table versions may exist - but only last one is = referenced from this page. also, URLs are constructed (usually) using triple of IDNA-converted TLD = names, language, and version identifiers -=20 for example, = http://www.iana.org/domains/idn-tables/tables/xn--90a3ac_cyrl_1.1.html - = but sometimes=20 convention is a bit different, e.g. = http://www.iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html=20 for Serbian names in PL - here, it looks like "sr-pl" is used = instead of just sr as language tag. -- dk@= --Apple-Mail=_9DF4882A-3D5E-4CB5-8979-BA25BB4634E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 edainow@afilias.info> = wrote:
On Fri, Apr 12, 2013 at 3:46 PM, Andy Newton <andy@arin.net> wrote:
On 4/12/13 1:34 PM, "Ernie Dainow" <edainow@afilias.info> = wrote:

>There was also discussion of including the "IDN table identifier" = with
>unicode names. Has this been ruled out?
>http://www.ietf.org/mail-archive/web/weirds/current/msg0= 2391.html
>
>

this = refers to 


which = was recently updated (April 5th) - but that draft has no reference to = IDN table repository 
 ("provided by (EPP) server" = identifier is mentioned, only.)


This was an oversight. Though looking over that draft it isn't = apparent to
me which tables identifiers are being referenced. Is there more = specific
information?

-andy




those = tables are not very usable as machine-readable registry - as their = format is usually free-formed text.

a (working = draft) document was written by Kim Davies a while ago to offer XML = format for them, 
but have not been adopted by IANA yet. =  I don't have reference to it on = hand.

also, multiple table versions may exist - = but only last one is referenced from this = page.

also, URLs are constructed (usually) = using triple of IDNA-converted TLD names, language, and version = identifiers - 
  convention is a bit = different, e.g. h= ttp://www.iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html 
     for Serbian names in PL - here, it looks = like "sr-pl" is used instead of just sr as language = tag.

-- dk@
= --Apple-Mail=_9DF4882A-3D5E-4CB5-8979-BA25BB4634E6-- From edainow@afilias.info Fri Apr 12 14:25: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 D18CA21F8E8F for ; Fri, 12 Apr 2013 14:25:09 -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 WKJB0tIF025d for ; Fri, 12 Apr 2013 14:25:09 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DD96E21F8C55 for ; Fri, 12 Apr 2013 14:25:08 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UQlT2-0004pA-4J for weirds@ietf.org; Fri, 12 Apr 2013 21:25:08 +0000 Received: from mail-wi0-f197.google.com ([209.85.212.197]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UQlT2-000344-3V for weirds@ietf.org; Fri, 12 Apr 2013 21:25:08 +0000 Received: by mail-wi0-f197.google.com with SMTP id hn17so17818wib.4 for ; Fri, 12 Apr 2013 14:25:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=AQ/5nuDDQhNWOmcE0ry7HnPI+WMmjnubMQVrJXkh2Vw=; b=S49tKwyhSWLDmla6wpWlf/9fbpstWRwMFQrkTGCwWDgrW4B+zZmOV1rA0dJ6zJ6bTe qshKb3RLSHH8g/osDTOoH+c080prhm2p1SRDdVtdfhWEWiEpR1aPOF7c7YYbx2G3MdTv JsQbNJc2Js4YWln5SRZ7q8KcVBgkf8yX8Q44QtTv8w+ijxOrcTNJrK5Cheo1JzMFbrkQ a0iDlDLnAxcif2paDWF+grYjT6pUdvjHON3gdTdWQgs6453MQJIlpo6jSVPW0gEVOBHD pd7JJk1JAD+K00DRcDIWu36s4Tt/4gAzkVOVd95U5cjHnCVjwyTSX14DXZSMzGtvte3d lu3Q== X-Received: by 10.152.26.166 with SMTP id m6mr4465948lag.4.1365801901952; Fri, 12 Apr 2013 14:25:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.26.166 with SMTP id m6mr4465942lag.4.1365801901742; Fri, 12 Apr 2013 14:25:01 -0700 (PDT) Received: by 10.112.23.41 with HTTP; Fri, 12 Apr 2013 14:25:01 -0700 (PDT) In-Reply-To: <0DDB0C80-51B8-4D8A-A7FB-78FA0B5769AB@hostmaster.ua> References: <51684588.8080307@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC5B0@CHAXCH01.corp.arin.net> <0DDB0C80-51B8-4D8A-A7FB-78FA0B5769AB@hostmaster.ua> Date: Fri, 12 Apr 2013 17:25:01 -0400 Message-ID: From: Ernie Dainow To: Dmitry Kohmanyuk Content-Type: multipart/alternative; boundary=089e0160a6f42ff40104da3089dd X-Gm-Message-State: ALoCoQkEc8mJ+Qcr0xKPTvZXzyNcfrfZxikbII5cfDmPLU43r7oOdv8fxDQMSXd+ollutYiWb0osUoa7CzF46AFPWNDDi5YIflVuIPPAIqEGAqM6E9g6NDhzfoXEes97QsclRHUJhU4q Cc: "weirds@ietf.org" Subject: Re: [weirds] draft-ietf-weirds-json-response-03 (LDH names and Unicode names) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:25:09 -0000 --089e0160a6f42ff40104da3089dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 12, 2013 at 4:55 PM, Dmitry Kohmanyuk wrote: > > On Apr 12, 2013, at 11:15 PM, Ernie Dainow wrote: > > On Fri, Apr 12, 2013 at 3:46 PM, Andy Newton wrote: > >> On 4/12/13 1:34 PM, "Ernie Dainow" wrote: >> >> >There was also discussion of including the "IDN table identifier" with >> >unicode names. Has this been ruled out? >> >http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html >> > >> > >> > > this refers to > > http://tools.ietf.org/html/draft-obispo-epp-idn-02 > > which was recently updated (April 5th) - but that draft has no reference > to IDN table repository > ("provided by (EPP) server" identifier is mentioned, only.) > > >> This was an oversight. Though looking over that draft it isn't apparent to >> me which tables identifiers are being referenced. Is there more specific >> information? >> >> -andy >> >> > http://www.iana.org/domains/idn-tables > > > those tables are not very usable as machine-readable registry - as their > format is usually free-formed text. > > a (working draft) document was written by Kim Davies a while ago to offer > XML format for them, > but have not been adopted by IANA yet. I don't have reference to it on > hand. > > also, multiple table versions may exist - but only last one is referenced > from this page. > > also, URLs are constructed (usually) using triple of IDNA-converted TLD > names, language, and version identifiers - > for example, > http://www.iana.org/domains/idn-tables/tables/xn--90a3ac_cyrl_1.1.html - > but sometimes > convention is a bit different, e.g. > http://www.iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html > for Serbian names in PL - here, it looks like "sr-pl" is used instead > of just sr as language tag. > > -- dk@ > I would expect RDAP to return only the name of the table, like ".ASIA Japanese", and optionally a url link. I think most clients/users want to know primarily the language of the IDN, and only secondarily the full table of code points. -Ernie --089e0160a6f42ff40104da3089dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 12, 2013 at 4:55 PM, Dmitry = Kohmanyuk <dk@hostmaster.ua> wrote:

On Apr = 12, 2013, at 11:15 PM, Ernie Dainow <edainow@afilias.info> wrote:

On Fri, Apr 12, 2013 at 3:46 PM, Andy Newton <andy@arin.net> wr= ote:
On 4/12/13 1:34 PM, "Ernie Dainow" <edainow@afilias.info> wrote:
>There was also discussion of including the "IDN table identifier&q= uot; with
>unicode names. Has this been ruled out?
>http://www.ietf.org/mail-archive/web/weirds/curren= t/msg02391.html
>
>

thi= s refers to=A0


which was recently updated (April 5th) - but that draft= has no reference to IDN table repository=A0
=A0("provided b= y (EPP) server" identifier is mentioned, only.)


This was an oversight. Though looking over that draft it isn't ap= parent to
me which tables identifiers are being referenced. Is there more specific information?

-andy




those tables are = not very usable as machine-readable registry - as their format is usually f= ree-formed text.

a (working draft) document was written by Kim Davies a = while=A0ago to offer XML format for them,=A0
but have not been ad= opted by IANA yet. =A0I don't have reference to it on hand.
<= br>
also, multiple table versions may exist - but only last one is r= eferenced from this page.

also, URLs are construct= ed (usually) using triple of IDNA-converted TLD names, language, and versio= n identifiers -=A0
<= div>=A0 convention is a bit different, e.g.=A0http://www= .iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html=A0
=A0 =A0 =A0for Serbian names in PL - here, it looks like "sr-pl&q= uot; is used instead of just sr as language tag.

-- dk@

I would expect RDAP to return only the name of the tabl= e, like =A0".ASIA Japanese", and optionally a url link. I think m= ost clients/users want to know primarily the language of the IDN, and only = secondarily the full table of code points.

-Ernie

--089e0160a6f42ff40104da3089dd-- From andy@arin.net Sat Apr 13 08:45: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 4287121F86C3 for ; Sat, 13 Apr 2013 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRdTw3yONO+q for ; Sat, 13 Apr 2013 08:45:56 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id BAC4321F8618 for ; Sat, 13 Apr 2013 08:45:56 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 6A3B0213671; Sat, 13 Apr 2013 11:45:56 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 098EF213669; Sat, 13 Apr 2013 11:45:56 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 13 Apr 2013 11:45:20 -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; Sat, 13 Apr 2013 11:45:42 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] help Thread-Index: AQHN/yVXgFevBTQie06p/bwbzsClcJhivVeAgADQSQCAAF5jgP//r9gAgABZOwD//66qgIBv+sCAgAEfGoA= Date: Sat, 13 Apr 2013 15:45:42 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC70C@CHAXCH01.corp.arin.net> In-Reply-To: <5168548D.802@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: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B18708B49971140AF1E347CBA6CCE4C@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: Sat, 13 Apr 2013 15:45:57 -0000 On 4/12/13 2:38 PM, "Ernie Dainow" wrote: >To support this, a standard path segment for "help" should be added to >the rdap-query spec. Here is some proposed wording. This capability is already available using either the "help" or "about" link relation in the "links" array which can go inside the "notices" array. -andy From simon.perreault@viagenie.ca Sat Apr 13 09:12:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA9921F884A for ; Sat, 13 Apr 2013 09:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCQnX7Y5vW-h for ; Sat, 13 Apr 2013 09:12:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5C221F8825 for ; Sat, 13 Apr 2013 09:12:13 -0700 (PDT) Received: from porto.nomis80.org (85-169-43-76.rev.numericable.fr [85.169.43.76]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 42512403C5 for ; Sat, 13 Apr 2013 12:11:40 -0400 (EDT) Message-ID: <516983BB.5060107@viagenie.ca> Date: Sat, 13 Apr 2013 18:11:39 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC579@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC579@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-03.txt - vCard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 16:12:15 -0000 Le 2013-04-12 21:16, Andy Newton a écrit : >> Instead of: >> [ "label", {}, "text", "123 Maple Ave\n", >> "Suite 90001\n", >> ... >> Can we not do: >> [ "label", {}, "text", ["123 Maple Ave", "Suite 90001", ...] > > I think the \n is the unstructured jCard. Honestly, I don't know enough > about jCard to tell you if the examples shouldn't have \n in them, though > I certainly understand your point. In this particular case, with the label property, the embedded \n is correct. An array would not be. That's because the value of the label property is defined as a single text value in vCard (RFC 6350). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Sun Apr 14 20:39: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 32B7F21F8DA6; Sun, 14 Apr 2013 20:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, 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 BrajWaVZUkEh; Sun, 14 Apr 2013 20:39:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84D21F8A1B; Sun, 14 Apr 2013 20:39:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415033958.16674.45387.idtracker@ietfa.amsl.com> Date: Sun, 14 Apr 2013 20:39:58 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-object-inventory-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 03:39:59 -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 : Domain Name Registration Data Access Protocol Object Inv= entory Analysis Author(s) : Linlin Zhou Ning Kong Sean Shen Filename : draft-ietf-weirds-object-inventory-00.txt Pages : 18 Date : 2013-04-14 Abstract: WHOIS output elements from 124 TLDs were collected and analyzed. This document describes the statistical analysis process and result of WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of domain name data objects in WHOIS response. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-object-inventory-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhoulinlin@cnnic.cn Sun Apr 14 22:02:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE84C21F8EE1 for ; Sun, 14 Apr 2013 22:02:01 -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=[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 RxppKJtr9gY8 for ; Sun, 14 Apr 2013 22:02:00 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 6755A21F8521 for ; Sun, 14 Apr 2013 22:01:55 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 15 Apr 2013 13:01:46 +0800 From: "Linlin Zhou" To: Date: Mon, 15 Apr 2013 13:01:46 +0800 Message-ID: <002b01ce3996$549b13d0$fdd13b70$@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: Ac45iwW/cEmRaXfiQn65fXvvOCWbWwACqEew Content-Language: zh-cn Subject: [weirds] FW: I-D Action: draft-ietf-weirds-object-inventory-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 05:02:02 -0000 The inventory draft is adopted as WG document. More comments are appreciated. -----Original Message----- From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, April 15, 2013 11:40 AM To: i-d-announce@ietf.org Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-object-inventory-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF. Title : Domain Name Registration Data Access Protocol Object Inventory Analysis Author(s) : Linlin Zhou Ning Kong Sean Shen Steve Sheng Filename : draft-ietf-weirds-object-inventory-00.txt Pages : 18 Date : 2013-04-14 Abstract: WHOIS output elements from 124 TLDs were collected and analyzed. This document describes the statistical analysis process and result of WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of domain name data objects in WHOIS response. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-object-inventory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-object-inventory-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds From edainow@afilias.info Mon Apr 15 08:11: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 2023B21F905B for ; Mon, 15 Apr 2013 08:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 9pCo6C1ddqLK for ; Mon, 15 Apr 2013 08:11:34 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 556ED21F9027 for ; Mon, 15 Apr 2013 08:11: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.69) (envelope-from ) id 1URl49-0001gm-5U for weirds@ietf.org; Mon, 15 Apr 2013 15:11:33 +0000 Received: from mail-bk0-f71.google.com ([209.85.214.71]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1URl49-0005ij-4w for weirds@ietf.org; Mon, 15 Apr 2013 15:11:33 +0000 Received: by mail-bk0-f71.google.com with SMTP id jc3so6244143bkc.10 for ; Mon, 15 Apr 2013 08:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UW+Z83q991cEAmbKDjX4RuoGEzW/p6F8P7AsQb4Ta74=; b=XUqD39OQhyxEqD2bNZNoD6CNV33TEskMNJpRabN63dyxCyZoxj3krMFH6lwzB+Rm8+ HJViRwA8EDALMwSFIlGQGkB//j5/3tknbAYlwwRnY2NS9PX91l5vEPsacyOiqu3Pstrn Mgj1qqNZqondzL/mVVOL4pByejXMCknRMmjGbnSBRZP2CtnLKWzTaGWIrawLiv1cRR59 DGYJcFqyBP0/7AYSxwv4u8OsXNImTzWxflrfvXiVxnhnQRpNDvfypcZrp5Fb30GVaWws jeqHh0UfcGmf7vZoWW7OGMTlql+u7xINVirL+J2OKVKeQpM4XpAR+a2w4kiUCPHqmRni JUqg== X-Received: by 10.112.198.227 with SMTP id jf3mr10570406lbc.69.1366038687300; Mon, 15 Apr 2013 08:11:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.198.227 with SMTP id jf3mr10570401lbc.69.1366038687167; Mon, 15 Apr 2013 08:11:27 -0700 (PDT) Received: by 10.112.23.41 with HTTP; Mon, 15 Apr 2013 08:11:27 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC70C@CHAXCH01.corp.arin.net> References: <5168548D.802@afilias.info> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFC70C@CHAXCH01.corp.arin.net> Date: Mon, 15 Apr 2013 11:11:27 -0400 Message-ID: From: Ernie Dainow To: Andy Newton Content-Type: multipart/alternative; boundary=001a11c34ab6b2c5e204da67aa44 X-Gm-Message-State: ALoCoQkOyHcp5W4KzSH9FiMqK/OWce3tPtBNIx7aSb6pXh48KqUv8v7DasREflvLD8LWmaPYWS/AMYXJPliEKMSeQ2csPfo9xO49BlHZPeI0CTKbM1IKi1J1mrJb9ehQctSaIDz3s9yC 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, 15 Apr 2013 15:11:35 -0000 --001a11c34ab6b2c5e204da67aa44 Content-Type: text/plain; charset=ISO-8859-1 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. -Ernie On Sat, Apr 13, 2013 at 11:45 AM, Andy Newton wrote: > On 4/12/13 2:38 PM, "Ernie Dainow" wrote: > > >To support this, a standard path segment for "help" should be added to > >the rdap-query spec. Here is some proposed wording. > > This capability is already available using either the "help" or "about" > link relation in the "links" array which can go inside the "notices" array. > > -andy > > --001a11c34ab6b2c5e204da67aa44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are several cases where the user may not get a JSON response and so d= oes not receive the notices array or anything else. For example, after HTTP= =A0Unauthorized or=A0Not Found. A standard way to get help independently of= looking for a link somewhere in a JSON response makes things a lot easier.=

-Ernie


On Sat, = Apr 13, 2013 at 11:45 AM, Andy Newton <andy@arin.net> wrote:
=
On 4/12/13 2:38 PM, "Ernie Dainow" <edainow@afilias.info> wrote:
>To support this, a standard path segment for "help" should be= added to
>the rdap-query spec. Here is some proposed wording.

This capability is already available using either the "help"= ; or "about"
link relation in the "links" array which can go inside the "= notices" array.

-andy


--001a11c34ab6b2c5e204da67aa44-- From andy@arin.net Mon Apr 15 10:40:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5821F9667 for ; Mon, 15 Apr 2013 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rHsSiPX7BRj1 for ; Mon, 15 Apr 2013 10:40:18 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCA21F9664 for ; Mon, 15 Apr 2013 10:40:17 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E1A791650DE; Mon, 15 Apr 2013 13:39:46 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 574D9164E1B; Mon, 15 Apr 2013 13:39:46 -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; Mon, 15 Apr 2013 13:39:39 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.209]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 13:39:45 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] help Thread-Index: AQHN/yVXgFevBTQie06p/bwbzsClcJhivVeAgADQSQCAAF5jgP//r9gAgABZOwD//66qgIBv+sCAgAEfGoCAA14pgP//5l2A Date: Mon, 15 Apr 2013 17:39:44 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43@CHAXCH01.corp.arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43CHAXCH01corpari_" 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: Mon, 15 Apr 2013 17:40:18 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 d= oes not receive the notices array or anything else. For example, after HTTP= Unauthorized or Not Found. A standard way to get help independently of loo= king 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 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: Ernie Dainow <edainow@afilias.info>
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 Unauthorized or Not Found. A standard way to get help indep= endently 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
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFCA43CHAXCH01corpari_-- From bje@apnic.net Mon Apr 15 22:08: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 F1A3421F95DF for ; Mon, 15 Apr 2013 22:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZCpPvPcnf1R for ; Mon, 15 Apr 2013 22:08:19 -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 2FCF621F95DC for ; Mon, 15 Apr 2013 22:08:15 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Tue, 16 Apr 2013 15:08:05 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802:90fc:97c2:1a5f:d67d) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 16 Apr 2013 15:08:05 +1000 Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA2.org.apnic.net ([fe80::c75:3639:c2fb:c053%15]) with mapi id 14.01.0438.000; Tue, 16 Apr 2013 15:08:05 +1000 From: Byron Ellacott To: "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHON6ZdFciRv1qN60uinCE+IB8fqZjYUXAA Date: Tue, 16 Apr 2013 05:08:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.89] Content-Type: multipart/alternative; boundary="_000_CD93171120BB0bjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:08:20 -0000 --_000_CD93171120BB0bjeapnicnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello WG, "I have reviewed this document thoroughly and it looks good." - The introduction does not refer to I-D.ietf-weirds-using-http, and perha= ps should. - In 3.1.1, the [To be discussed: =85] note should be removed. - 3.3 could reference -using=96http on the use of 429 response codes, or v= ice versa. - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. These are minor points that should not stop this document from progressing.= Thanks to the authors for their work! Byron From: "Murray S. Kucherawy" > Date: Saturday, 13 April 2013 3:51 AM To: "weirds@ietf.org" > Subject: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Colleagues, This message begins a two-week Working Group Last Call on draft-ietf-weirds= -rdap-sec. Version 02 is current in the tracker: https://datatracker.ietforg/doc/draft-ietf-weirds-rdap-sec Last call will end on Friday, April 26. Please review and comment on the draft, even if it is only to say on the re= cord "I have reviewed this document thoroughly and it looks good." We woul= d like to have no fewer than five people report that they have taken a look= at the whole document and reported their findings, and will be reticent to= send it to the IESG without that. We're also keen to hear from people tha= t have implemented the specification as to their views on clarity, correctn= ess, and completeness. I will be the document shepherd for this one. Thanks, -MSK and Olaf, your co-chairs --_000_CD93171120BB0bjeapnicnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello WG,

"I have reviewed this document thoroughly and it looks good."= ;

 - The introduction does not refer to I-D.ietf-weirds-using-http,= and perhaps should.
 - In 3.1.1, the [To be discussed: =85] note should be removed.
 - 3.3 could reference -using=96http on the use of 429 response c= odes, or vice versa.
 - 5 refers to RDAP as an "HTML-based protocol."  = I believe the intent is to note that RDAP is expected to be used in an HTML= presentation context at least some of the time, but the wording is not qui= te right there, I think.

These are minor points that should not stop this document from progres= sing.  Thanks to the authors for their work!

  Byron

From: "Murray S. Kucherawy&quo= t; <superuser@gmail.com> Date: Saturday, 13 April 2013 3:51 = AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Working Group Las= t Call: draft-ietf-weirds-rdap-sec

Colleagues,

This message begins a two-week Working Group Last Call on draft-ietf-weirds= -rdap-sec.  Version 02 is current in the tracker:

http= s://datatracker.ietforg/doc/draft-ietf-weirds-rdap-sec

Last call will end on Friday, April 26.

Please review and comment on the draft, even if it is only to say on t= he record "I have reviewed this document thoroughly and it looks good.= "  We would like to have no fewer than five people report that th= ey have taken a look at the whole document and reported their findings, and will be reticent to send it to the IESG witho= ut that.  We're also keen to hear from people that have implemented th= e specification as to their views on clarity, correctness, and completeness= .

I will be the document shepherd for this one.

Thanks,

-MSK and Olaf, your co-chairs

 --_000_CD93171120BB0bjeapnicnet_-- From shollenbeck@verisign.com Tue Apr 16 10:12: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 A212321F9719 for ; Tue, 16 Apr 2013 10:12:29 -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=[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 Dbi0CYRbKKY7 for ; Tue, 16 Apr 2013 10:12:28 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFF721F9702 for ; Tue, 16 Apr 2013 10:12:26 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUW2GeRIJUMZDMOQXC5ZL8kYZzYAjPg44@postini.com; Tue, 16 Apr 2013 10:12:28 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 r3GHCMon013306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 13:12:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 13:12:21 -0400 From: "Hollenbeck, Scott" To: Byron Ellacott , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHON6ZdFciRv1qN60uinCE+IB8fqZjYUXAAgADHaxA= Date: Tue, 16 Apr 2013 17:12:21 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243595CB@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_831693C2CDA2E849A7D7A712B24E257F243595CBBRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:12:29 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F243595CBBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, Byron. Comments below. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Byron Ellacott Sent: Tuesday, April 16, 2013 1:08 AM To: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Hello WG, "I have reviewed this document thoroughly and it looks good." - The introduction does not refer to I-D.ietf-weirds-using-http, and perha= ps should. > Perhaps. I don't have a problem with adding it. - In 3.1.1, the [To be discussed: ...] note should be removed. > Yes, thanks for catching that. - 3.3 could reference -using-http on the use of 429 response codes, or vic= e versa. > We already have a normative reference to RFC 6585. -using-http includes t= he same reference. I think we're good as long as the documents are consiste= nt. - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. > s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open= to suggestions. Scott --_000_831693C2CDA2E849A7D7A712B24E257F243595CBBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Byron. Comments b= elow.

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Hello WG,=

 

"I have reviewed this = document thoroughly and it looks good."

 

 - The introduction do= es not refer to I-D.ietf-weirds-using-http, and perhaps should.<= /span>

 

> Perhaps. I don’t have a problem= with adding it.

 

 - In 3.1.1, the [To b= e discussed: …] note should be removed.

 

> Yes,= thanks for catching that.

 

 - 3.3 could reference= -using–http on the use of 429 response codes, or vice versa.

 

> We already have a normative reference= to RFC 6585. –using-http includes the same reference. I think weR= 17;re good as long as the documents are consistent.

 

 - 5 refers to RDAP as= an "HTML-based protocol."  I believe the intent is to note = that RDAP is expected to be used in an HTML presentation context at least s= ome of the time, but the wording is not quite right there, I think.=

 

> s/As an HTML-based protocol/As a prot= ocol using HTTP transport/? I’m open to  suggestions.=

 <= /p>

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F243595CBBRN1WNEXMBX01vc_-- From internet-drafts@ietf.org Tue Apr 16 17:31: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 A225121F977C; Tue, 16 Apr 2013 17:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 hoKPfmDZzZbZ; Tue, 16 Apr 2013 17:31:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4138921F9697; Tue, 16 Apr 2013 17:31:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 17:31:49 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:31:49 -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-04.txt Pages : 12 Date : 2013-04-16 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bje@apnic.net Tue Apr 16 17:37: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 4310521F8D02 for ; Tue, 16 Apr 2013 17:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=0.001, 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 8Daj6t+IgwEA for ; Tue, 16 Apr 2013 17:37:54 -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 8F5F421F8E6A for ; Tue, 16 Apr 2013 17:37:52 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Wed, 17 Apr 2013 10:35:13 +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; Wed, 17 Apr 2013 10:37:23 +1000 From: Byron Ellacott To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt Thread-Index: AQHOOwL7KDrVfi6RG0CugPjfiNcQnJjZkWoA Date: Wed, 17 Apr 2013 00:37:22 +0000 Message-ID: In-Reply-To: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EACA6A057D0FF40955950032D82DB20@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:37:55 -0000 Many thanks to everyone for the rich WGLC feedback. Here's the change list from the draft: * Revised introduction and abstract. * Added negative responses other than 404. * Added security considerations. * Added and corrected references: CORS, RFC3912, RFC3987, RFC5890. * Expanded on first use several acronyms. * Updated 2119 language. Byron On 17/04/13 10:31 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Web Extensible Internet Registration >Data Service Working Group of the IETF. > > Title : HTTP usage in the Registration Data Access Protocol >(RDAP) > Author(s) : Andrew Lee Newton > Byron J. Ellacott > Ning Kong > Filename : draft-ietf-weirds-using-http-04.txt > Pages : 12 > Date : 2013-04-16 > >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-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From bje@apnic.net Tue Apr 16 18:23: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 8C29C21F969D for ; Tue, 16 Apr 2013 18:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQjw0BDjjEaN for ; Tue, 16 Apr 2013 18:23:24 -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 72C3221F96C4 for ; Tue, 16 Apr 2013 18:23:23 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 17 Apr 2013 11:23:19 +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; Wed, 17 Apr 2013 11:23:19 +1000 From: Byron Ellacott To: "Hollenbeck, Scott" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHON6ZdFciRv1qN60uinCE+IB8fqZjYUXAAgADHaxCAAIwdAA== Date: Wed, 17 Apr 2013 01:23:18 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243595CB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.197] Content-Type: multipart/alternative; boundary="_000_CD94362620D0Ebjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 01:23:24 -0000 --_000_CD94362620D0Ebjeapnicnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Scott, From: , Scott > Date: Wednesday, 17 April 2013 3:12 AM To: Byron Ellacott >, "weirds@ietf.org<= mailto:weirds@ietf.org>" > Subject: RE: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. > s/As an HTML-based protocol/As a protocol using HTTP transport/? I=92m op= en to suggestions. How about: "As a protocol likely to be used by services with an HTML presen= tation layer RDAP is susceptible=85" ? Byron --_000_CD94362620D0Ebjeapnicnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <163175A70AF721468FC38F362B9A11C2@apnic.net> Content-Transfer-Encoding: quoted-printable
Hi Scott,

From: <Hollenbeck>, Scott <= ;shollenbeck@verisign.com&g= t;
Date: Wednesday, 17 April 2013 3:12= AM
To: Byron Ellacott <bje@apnic.net>, "weirds@ietf.org" <= weirds@ietf.org>
Subject: RE: [weirds] Working Group= Last Call: draft-ietf-weirds-rdap-sec


 - 5 refers to RDAP as an "HTML-based protocol.= "  I believe the intent is to note that RDAP is expected to be us= ed in an HTML presentation context at least some of the time, but the wording is not quite right there, I think.

 

> s/As an HTML-based protocol/As a protocol usin= g HTTP transport/? I=92m open to  suggestions.

How about: "As a protocol likely to be used by = services with an HTML presentation layer RDAP is susceptible=85" ?

  Byron
--_000_CD94362620D0Ebjeapnicnet_-- From superuser@gmail.com Tue Apr 16 20:10: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 5C5BF21F9729 for ; Tue, 16 Apr 2013 20:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 e5yUKq6h1OOg for ; Tue, 16 Apr 2013 20:10:12 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3605C21F972A for ; Tue, 16 Apr 2013 20:10:12 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so594348wie.12 for ; Tue, 16 Apr 2013 20:10:11 -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=iX963Kjr5Zk2gKlaMJFOxtUhWtSLOZRPZGPWPPndMec=; b=QfJr69ntTm9pWZ1F5n2nyn3/tRJj3I/cOyaE54+7Y8tYIsPolkze3rvH/Et5goQuaG +2zijCepGynLonpG0J7C+B6I6y3SUA8YaISrnYc+rSDayfOKELGiVWiH/aPcIz6uv5sz 9GE1fhGxHVuJNvLdJveCqohDfUJ0lNeVCbqAScOgxRpDo/Y6eIIc9wWpqcF7WdrgmCjq 5fTMenhz9UTZ548E0hNHfFOfvgvJHfNKlgg7optWxapxKzpcbUhQ+igb6Mb4FqZDxXiP wFa2lcDg9b5LMSqdISP+tkHjKAdxNK0USWI1ljfm7AUl9RnCk342wGljDxRnyf7+rcQS Uydg== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr7655842wix.20.1366168211416; Tue, 16 Apr 2013 20:10:11 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 16 Apr 2013 20:10:11 -0700 (PDT) In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 20:10:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Byron Ellacott Content-Type: multipart/alternative; boundary=f46d04182538f1eec404da85d27a Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 03:10:13 -0000 --f46d04182538f1eec404da85d27a Content-Type: text/plain; charset=ISO-8859-1 Nice work, everyone! A few things remain in -04: 1) "Appendix Appendix B" in Section 4.2. 2) The "Intended usage" thing in Section 8.1 is still weird. 3) The SHOULD in Section 5 seems vague to me. (a) What does it mean to "understand" it, exactly? (b) When would one deviate from the normative statement and what impact might it have on interoperability? These can be fixed during/after IETF LC, so just tuck them away for later; no need to do a -05 first unless you feel like it. -MSK, participatorially On Tue, Apr 16, 2013 at 5:37 PM, Byron Ellacott wrote: > Many thanks to everyone for the rich WGLC feedback. Here's the change > list from the draft: > > * Revised introduction and abstract. > * Added negative responses other than 404. > * Added security considerations. > * Added and corrected references: CORS, RFC3912, RFC3987, RFC5890. > * Expanded on first use several acronyms. > * Updated 2119 language. > > Byron > > > On 17/04/13 10:31 AM, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Web Extensible Internet Registration > >Data Service Working Group of the IETF. > > > > Title : HTTP usage in the Registration Data Access > Protocol > >(RDAP) > > Author(s) : Andrew Lee Newton > > Byron J. Ellacott > > Ning Kong > > Filename : draft-ietf-weirds-using-http-04.txt > > Pages : 12 > > Date : 2013-04-16 > > > >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-04 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-using-http-04 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >weirds mailing list > >weirds@ietf.org > >https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --f46d04182538f1eec404da85d27a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nice work, everyone!

A few thin= gs remain in -04:

1) "Appendix Appendix B" in Sectio= n 4.2.

2) The "Intended usage" thing in Section 8.1 = is still weird.

3) The SHOULD in Section 5 seems vague to me.=A0 (a) What do= es it mean to "understand" it, exactly?=A0 (b) When would one dev= iate from the normative statement and what impact might it have on interope= rability?

These can be fixed during/after IETF LC, so just tuck them away f= or later; no need to do a -05 first unless you feel like it.

-= MSK, participatorially




On Tue, Apr 16, 2013 at 5:37 PM, Byron E= llacott <bje@apnic.net> wrote:
Many thanks to everyone for the rich WGLC feedback. =A0Here's the chang= e
list from the draft:

=A0* =A0Revised introduction and abstract.
=A0* =A0Added negative responses other than 404.
=A0* =A0Added security considerations.
=A0* =A0Added and corrected references: CORS, RFC3912, RFC3987, RFC5890. =A0* =A0Expanded on first use several acronyms.
=A0* =A0Updated 2119 language.

=A0 Byron


On 17/04/13 10:31 AM, "int= ernet-drafts@ietf.org"
<inte= rnet-drafts@ietf.org> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Web Extensible Internet Registration<= br> >Data Service Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP usage in the Registration= Data Access Protocol
>(RDAP)
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andrew Lee Newton
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Byron J. Ellacott > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ning Kong
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-weirds-using-http-04.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-16
>
>Abstract:
> =A0 This document is one of a collection that together describe the > =A0 Registration Data Access Protocol (RDAP). =A0It describes how RDAP= is
> =A0 transported using the Hypertext Transfer Protocol (HTTP).
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-weirds-usi= ng-http
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-weirds-using-http-0= 4
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-wei= rds-using-http-04
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>weirds mailing list
>weirds@ietf.org
>https://www.ietf.org/mailman/listinfo/weirds

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

--f46d04182538f1eec404da85d27a-- From johnl@iecc.com Wed Apr 17 03:19: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 98F3C21F86E4 for ; Wed, 17 Apr 2013 03:19:21 -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 LVW0J5alC8zT for ; Wed, 17 Apr 2013 03:19:21 -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 C1F1721F86D8 for ; Wed, 17 Apr 2013 03:19:20 -0700 (PDT) Received: (qmail 16096 invoked from network); 17 Apr 2013 10:20:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2013 10:20:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516e7727.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=5AddnVPFQW5k/REV4E0t6b8NnuSptgaYiniYfzGf6N0=; b=kKB94thXplXVl5DD/9K8Foq78+m0B877sWW1qk10NuV+aiaLtJyh6sRy33fFek0dy74Qrdm3fFklM5mj7sfVNJAz6OXv/gaBlVDyfxIUnIN2bRZF/P+sMSuzXpOr3jWpjw0fy8xu8ikJGRT5rWePTlfkddRrWmxIpwYrdwKM8aI= 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=516e7727.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=5AddnVPFQW5k/REV4E0t6b8NnuSptgaYiniYfzGf6N0=; b=pncXUk4MH09mTMb7Tp4CBgTnpjdUXY5ZNJ1DrOpKytb+3dDB9AGf19EAM38IGuAr8YdM9WIyAPeqmi5yQSapNuht+rjv1g5oHtQFYQQN0p7uvDscU0VNfWkJgb+1F7TDOxsaGFIxIGrO13xZwYGEf/MefoD7lzz/wnVbReHTJ4o= Date: 17 Apr 2013 10:18:56 -0000 Message-ID: <20130417101856.3326.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 10:19:21 -0000 > - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is to note that RDAP is >expected to be used in an HTML presentation context ... No, it's just a typo for HTTP-based protocol. RDAP involves no HTML at all. It includes HTTP requests and responses that contain JSON. It is possible to make RDAP-like queries that return HTML, if the queries don't have the appropriate Accept:, but those are outside the scope of RDAP. From johnl@iecc.com Wed Apr 17 03:31: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 57FF821F8E5D for ; Wed, 17 Apr 2013 03:31:02 -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 YJuD6lFE3oTM for ; Wed, 17 Apr 2013 03:31:01 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8953B21F8AE8 for ; Wed, 17 Apr 2013 03:31:01 -0700 (PDT) Received: (qmail 18854 invoked from network); 17 Apr 2013 10:32:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2013 10:32:34 -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=516e79e4.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=k4DiXLJ4pxr6oNyMsF4Ep9lbSpj/edB9k3xWDVBHHe8=; b=ld5wO/UtiYs4DviIgxT0m2EaVX5apl5jTnJYwovrA7FFa4280ABOSmPB9KjEO9i1ODYFQyQtDpxBhxPikHaO/BGTrKbl4is7aOHuijzCHJTDNQ/4yNz+IFidXPQokg7/Wkrr4yMaOdJBiXxhEYyUY2NviW4zBMfjXqL+5k6ZNsE= 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=516e79e4.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=k4DiXLJ4pxr6oNyMsF4Ep9lbSpj/edB9k3xWDVBHHe8=; b=fk70Psb1z88oiLcbggly69H+7v+rU5dJO1Wj0t9qWb4tmK7+b02wgIsqhrSsmF84H6CWbF0E2YhLwwRPwg35/8A/x6ubg27sjqEv5571IbiK+51C3qUn4FmUIPvR3CnfPI3uqJhCg3LME2yOAhFOGCjv6nKWgk0T/G8zy5nl0y0= Date: 17 Apr 2013 10:30:38 -0000 Message-ID: <20130417103038.3429.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 10:31:02 -0000 >How about: "As a protocol likely to be used by services with an HTML presentation layer RDAP is >susceptible…" ? Please, no. There is no HTML presentation layer or any other HTML in RDAP. It is 100% JSON all the time. You don't need HTML for injection attacks: http://rdap.example/domain/foo.com%22%3bdrop%20table%20domains%3b From shollenbeck@verisign.com Wed Apr 17 03:56: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 C299C21F8C30 for ; Wed, 17 Apr 2013 03:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8azJ2pNxYBPt for ; Wed, 17 Apr 2013 03:56:52 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id D30A921F8C08 for ; Wed, 17 Apr 2013 03:56:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUW5/8outo/y0FCxqnL9eVCvn5QwAZeSO@postini.com; Wed, 17 Apr 2013 03:56:52 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 r3HAul9s018490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 06:56:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 06:56:46 -0400 From: "Hollenbeck, Scott" To: Byron Ellacott , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHON6ZdFciRv1qN60uinCE+IB8fqZjYUXAAgADHaxCAAIwdAIAAn/fA Date: Wed, 17 Apr 2013 10:56:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24359BA8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243595CB@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_831693C2CDA2E849A7D7A712B24E257F24359BA8BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 10:56:53 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24359BA8BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Byron Ellacott [mailto:bje@apnic.net] Sent: Tuesday, April 16, 2013 9:23 PM To: Hollenbeck, Scott; weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Hi Scott, From: , Scott > Date: Wednesday, 17 April 2013 3:12 AM To: Byron Ellacott >, "weirds@ietf.org<= mailto:weirds@ietf.org>" > Subject: RE: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. > s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open= to suggestions. How about: "As a protocol likely to be used by services with an HTML presen= tation layer RDAP is susceptible..." ? I don't know. I think the risk is more closely associated with HTTP transpo= rt than HTML presentation. Scott --_000_831693C2CDA2E849A7D7A712B24E257F24359BA8BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Byron El= lacott [mailto:bje@apnic.net]
Sent: Tuesday, April 16, 2013 9:23 PM
To: Hollenbeck, Scott; weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Hi Scott,=

 

From: <Hollenbeck>, Scott <shollenbeck@verisign.com>
Date: Wednesday, 17 April 2013 3:12 AM
To: Byron Ellacott <bje@apnic.ne= t>, "weirds@ietf.org&quo= t; <weirds@ietf.org>
Subject: RE: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

 =

 - 5 refers to RDAP as= an "HTML-based protocol."  I believe the intent is to note = that RDAP is expected to be used in an HTML presentation context at least s= ome of the time, but the wording is not quite right there, I think.

 <= o:p>

> s/As an HTML-based protocol/As a prot= ocol using HTTP transport/? I’m open to  suggestions.

 

How about: "As a pr= otocol likely to be used by services with an HTML presentation layer RDAP i= s susceptible…" ?

 <= /p>

I don’t know. I think the risk is mo= re closely associated with HTTP transport than HTML presentation.


Scott

--_000_831693C2CDA2E849A7D7A712B24E257F24359BA8BRN1WNEXMBX01vc_-- From shollenbeck@verisign.com Wed Apr 17 03:59:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112521F88BF for ; Wed, 17 Apr 2013 03:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.751, 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 FcNo6md4MTju for ; Wed, 17 Apr 2013 03:59:55 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7221F88B9 for ; Wed, 17 Apr 2013 03:59:53 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUW6ApHX5tK/ZZ7OpRWb8AS7MTB+FCt5S@postini.com; Wed, 17 Apr 2013 03:59:55 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 r3HAxlxo027859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 06:59:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 06:59:46 -0400 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHOO1T3FciRv1qN60uinCE+IB8fqZjaPlIw Date: Wed, 17 Apr 2013 10:59:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24359BD1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130417101856.3326.qmail@joyce.lan> In-Reply-To: <20130417101856.3326.qmail@joyce.lan> 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] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 10:59:57 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John Levine > Sent: Wednesday, April 17, 2013 6:19 AM > To: weirds@ietf.org > Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap- > sec >=20 > > - 5 refers to RDAP as an "HTML-based protocol." I believe the intent > is to note that RDAP is > >expected to be used in an HTML presentation context ... >=20 > No, it's just a typo for HTTP-based protocol. >=20 > RDAP involves no HTML at all. It includes HTTP requests and responses > that contain JSON. Yes, that's correct. It should be "HTTP". Scott From shollenbeck@verisign.com Wed Apr 17 06:19: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 5396821F8E73 for ; Wed, 17 Apr 2013 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 t7F+z-pt3A0N for ; Wed, 17 Apr 2013 06:19:49 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8965B21F8E6E for ; Wed, 17 Apr 2013 06:19:48 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUW6hdC/PHXln2CHJti5MWWzxKYk5fFHc@postini.com; Wed, 17 Apr 2013 06:19:48 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 r3HDJifM032221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 09:19:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 09:19:44 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHON6ZdFciRv1qN60uinCE+IB8fqZjYUXAAgADHaxCAAVLfsA== Date: Wed, 17 Apr 2013 13:19:43 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24359E74@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243595CB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F243595CB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F24359E74BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:19:51 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24359E74BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While looking at the text in the Introduction section to address Byron's co= mment below I decided that I'd rather eliminate the references to the docum= ents. The list will become incomplete if the core set changes (such as by a= dding a "search" document). Instead, I'd like to replace this text: "The Registration Data Access Protocol (RDAP) core is specified in two docu= ments: "Registration Data Access Protocol Lookup Format" [I-D.ietf-weirds-r= dap-query] and "JSON Responses for the Registration Data Access Protocol (R= DAP)" [I-D.ietf-weirds-json-response]. One goal of RDAP is to provide secu= rity services that do not exist in the WHOIS [RFC3912] protocol, including = authentication, authorization, availability, data confidentiality, and data= integrity. This document describes each of these security services from the perspectiv= e of RDAP requirements and applicability. Where applicable, informational = references to requirements for a WHOIS replacement service [RFC3707] are no= ted." with this: "One goal of the Registration Data Access Protocol (RDAP) is to provide sec= urity services that do not exist in the WHOIS [RFC3912] protocol, including= authentication, authorization, availability, data confidentiality, and dat= a integrity. This document describes how each of these services is applica= ble to RDAP and specifies requirements and approaches to provide the servic= es. Where applicable, informational references to requirements for a WHOIS= replacement service [RFC3707] are noted." Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Hollenbeck, Scott Sent: Tuesday, April 16, 2013 1:12 PM To: Byron Ellacott; weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thanks for the feedback, Byron. Comments below. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Byron Ellacott Sent: Tuesday, April 16, 2013 1:08 AM To: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Hello WG, "I have reviewed this document thoroughly and it looks good." - The introduction does not refer to I-D.ietf-weirds-using-http, and perha= ps should. > Perhaps. I don't have a problem with adding it. - In 3.1.1, the [To be discussed: ...] note should be removed. > Yes, thanks for catching that. - 3.3 could reference -using-http on the use of 429 response codes, or vic= e versa. > We already have a normative reference to RFC 6585. -using-http includes t= he same reference. I think we're good as long as the documents are consiste= nt. - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. > s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open= to suggestions. Scott --_000_831693C2CDA2E849A7D7A712B24E257F24359E74BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While looking at the text in the Introduct= ion section to address Byron’s comment below I decided that I’d= rather eliminate the references to the documents. The list will become incomplete if the core set changes (such as by adding a “search̶= 1; document). Instead, I’d like to replace this text:

 

“The Registration Data Access Protoc= ol (RDAP) core is specified in two documents: "Registration Data Acces= s Protocol Lookup Format" [I-D.ietf-weirds-rdap-query] and "JSON = Responses for the Registration Data Access Protocol (RDAP)" [I-D.ietf-weirds-js= on-response].  One goal of RDAP is to provide security services that d= o not exist in the WHOIS [RFC3912] protocol, including authentication, auth= orization, availability, data confidentiality, and data integrity.

 

This document describes each of these secu= rity services from the perspective of RDAP requirements and applicability.&= nbsp; Where applicable, informational references to requirements for a WHOIS replacement service [RFC3707] are noted.”

 

with this:

 

“One goal of the Registration Data A= ccess Protocol (RDAP) is to provide security services that do not exist in = the WHOIS [RFC3912] protocol, including authentication, authorization, availability, data confidentiality, and data integrity.  This documen= t describes how each of these services is applicable to RDAP and specifies = requirements and approaches to provide the services.  Where applicable= , informational references to requirements for a WHOIS replacement service [RFC3707] are noted.”

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 16, 2013 1:12 PM
To: Byron Ellacott; weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Thanks for the feedback, Byron. Comments b= elow.

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Hello WG,=

 

"I have reviewed this = document thoroughly and it looks good."

 

 - The introduction do= es not refer to I-D.ietf-weirds-using-http, and perhaps should.<= /span>

 

> Perhaps. I don’t have a problem= with adding it.

 

 - In 3.1.1, the [To b= e discussed: …] note should be removed.

 

> Yes,= thanks for catching that.

 

 - 3.3 could reference= -using–http on the use of 429 response codes, or vice versa.

 

> We already have a normative reference= to RFC 6585. –using-http includes the same reference. I think weR= 17;re good as long as the documents are consistent.

 

 - 5 refers to RDAP as= an "HTML-based protocol."  I believe the intent is to note = that RDAP is expected to be used in an HTML presentation context at least s= ome of the time, but the wording is not quite right there, I think.=

 

> s/As an HTML-based protocol/As a prot= ocol using HTTP transport/? I’m open to  suggestions.=

 <= /p>

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F24359E74BRN1WNEXMBX01vc_-- From carlosm3011@gmail.com Wed Apr 17 09:38: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 0E05C21F85CB for ; Wed, 17 Apr 2013 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXmsVZqg8K2P for ; Wed, 17 Apr 2013 09:37:59 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F05F21F867B for ; Wed, 17 Apr 2013 09:37:59 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id 25so285268yhr.9 for ; Wed, 17 Apr 2013 09:37:58 -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 :subject:content-type:content-transfer-encoding; bh=9lw5umwMLrStTusOm1W8RGA7+lkXJUvqaXxmLQq/LkI=; b=zd7tQ4QmU3Xxz47OXx/3DAWlUO1QUPhIDssfNl+ECAYXdEkg6CN5u4QckJqMdbayx7 V2g2IKC65BLXGMEJgUkFoG/CueWLWNg757SDpI87sr7CHmgirDaxJ86YD4j+Xa7xuQBv R/Cew4/8EWfJBSq+Pge7SWtbFpZXfkX2OK+zqsSXEs2Mq3fY1xGhfMZtF9kAbmOdL79x /2z2K3KIIo8bKp8wgsHDb9I97DIy4ypqs6iWr52GJYsDpOmrENqPeFi3j51UvyBduP+t YoHjO+3L8PqG0ldvNz+pBDwfAV9UG142Xe4hZXWCbhBpbNrXHsZLVvyrZLTC94WBISQZ o20w== X-Received: by 10.236.134.16 with SMTP id r16mr4467288yhi.112.1366216678833; Wed, 17 Apr 2013 09:37:58 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:b8a7:c573:3e5d:b8a5]) by mx.google.com with ESMTPS id i67sm10585959yhq.25.2013.04.17.09.37.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 09:37:57 -0700 (PDT) Message-ID: <516ECFE1.4090609@gmail.com> Date: Wed, 17 Apr 2013 13:37:53 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [weirds] LACNIC implementation of rate limiting and API keys X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 16:38:00 -0000 Guys, first of all apologies for the delay. As we promised in Orlando, here are some notes related to our implementation of rate limits and API keys. I also ask the workgroup whether you believe this topic should be addressed in any of the current drafts, in a new draft, or if it should be left up to implementers. thanks, ~Carlos ======================= LACNIC Restful WHOIS Rate Limit Implementation Dario Gomez Gerardo Rada Arturo Servin Carlos Martinez Rate limiting is used to control the rate on which requests to the rdap service are served. Traffic that is less or equal to the specified rate of requests is served. Instead, if the request rate exceeds a threshold, the request produces an error (currently HTTP code 403). The rdap service that we are operating only allows clients to make a limited number of requests. This policy affects the service in different ways. Our policy for the beta rdap service is: o 100 queries every 5 minutes o 1000 queries every 60 minutes By default, the LACNIC’s RDAP server checks the number of queries for the IP (v4 or v6) address that originated the incoming request. If that IP address exceeds the rate, the application returns a HTTP 403 error code with the message “rate limit exceeded for IP: xxx.xxx.xxx.xxx”. To implement our rate limiting solution, we need to save the requests status or log the requests for each incoming IP address. Our solution stores IP addresses and timestamps for every requests received in a database table. When a new request is received, we check the counts for previous request saved on the data table and verify it according with the configured policies. As the requests log data table can grow a lot we implemented a clean up mechanism where every 24 hours every record older than 24 hours is purged. Some users of our WHOIS service require higher limits. Currently our port 43 service implements whitelisting for some cases, but other users are forced to curb their request stream in order to comply with the current rate limits. For the RDAP service we decided to take advantage of the more modern nature of the protocol and introduced the possibility of using API keys in order to provide differentiated services to users with different requirements. The API key subsystem allows us to define different query limits for each key. API keys may be also source-IP-limited, only allowing a given range of source addresses to use a given key. In order to make use of an API key an “apkikey” parameter is added to request URL, as in the following example: http://rdap.labs.lacnic.net/rdap/entity/AIL?apikey=1234 Currently API keys are to be requested manually by interested parties. From superuser@gmail.com Wed Apr 17 11:06: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 0DB1621E8050 for ; Wed, 17 Apr 2013 11:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 5Mtg4W2KKDpc for ; Wed, 17 Apr 2013 11:06:47 -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 6F84B21E8048 for ; Wed, 17 Apr 2013 11:06:46 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hq17so1848479wib.11 for ; Wed, 17 Apr 2013 11:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MN0ESDLyYd4CRUkOhnDsYiiqv4oZHdgriVOybh9rqg4=; b=gJEsAIsTh7VBr7vOHwRcfYDqE8yNvyXWVALpIM/CHjRQdQqg0yQTotHjSpVc7D9VT9 fZtLGv1h8g8GuIgMHQdqUNxZWdftOPTJ9k35T2H+7PG/W2nxjDLoWvCjnydHzqH29ktv Q9Lpcvdp2N0kotYfAWbodYfQ1kHAl+l84jwSlYjCQTLnnjNzK9T/I7NadHg8eqvtmJOD ybjnZyDCInlORuUTfVneUJNMnMNAaov2m+OSeEwatPqEyA6n5IWNLTMb6GItq4F2oDzs 34dhRWcDc1s/CMHopkqnfDwmWwrFuIYXBegGd77+8L9Cu3EAAn3VnS0oWBToFhPicPfl 6aPA== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr27971232wib.32.1366222005601; Wed, 17 Apr 2013 11:06:45 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 17 Apr 2013 11:06:45 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24359E74@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243595CB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F24359E74@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 17 Apr 2013 11:06:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=f46d044306aa540b1604da9259f6 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:06:48 -0000 --f46d044306aa540b1604da9259f6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I see what you're getting at, though it does seem odd to talk about RDAP without a reference document explaining what exactly that is. I recommend leaving the references in. If we add search document(s) or something else to the core set, this can be fixed during IETF LC or via RFC Editor notes during IESG Evaluation. Or, at a minimum, referencing a subset of core documents is better than referencing none. -MSK, document shepherd hat this time On Wed, Apr 17, 2013 at 6:19 AM, Hollenbeck, Scott wrote: > While looking at the text in the Introduction section to address Byron= =92s > comment below I decided that I=92d rather eliminate the references to the > documents. The list will become incomplete if the core set changes (such = as > by adding a =93search=94 document). Instead, I=92d like to replace this t= ext:*** > * > > ** ** > > =93The Registration Data Access Protocol (RDAP) core is specified in two > documents: "Registration Data Access Protocol Lookup Format" > [I-D.ietf-weirds-rdap-query] and "JSON Responses for the Registration Dat= a > Access Protocol (RDAP)" [I-D.ietf-weirds-json-response]. One goal of RDA= P > is to provide security services that do not exist in the WHOIS [RFC3912] > protocol, including authentication, authorization, availability, data > confidentiality, and data integrity.**** > > ** ** > > This document describes each of these security services from the > perspective of RDAP requirements and applicability. Where applicable, > informational references to requirements for a WHOIS replacement service > [RFC3707] are noted.=94**** > > ** ** > > with this:**** > > ** ** > > =93One goal of the Registration Data Access Protocol (RDAP) is to provide > security services that do not exist in the WHOIS [RFC3912] protocol, > including authentication, authorization, availability, data > confidentiality, and data integrity. This document describes how each of > these services is applicable to RDAP and specifies requirements and > approaches to provide the services. Where applicable, informational > references to requirements for a WHOIS replacement service [RFC3707] are > noted.=94**** > > ** ** > > Scott**** > > ** ** > > *From:* weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > Behalf Of *Hollenbeck, Scott > *Sent:* Tuesday, April 16, 2013 1:12 PM > *To:* Byron Ellacott; weirds@ietf.org > > *Subject:* Re: [weirds] Working Group Last Call: > draft-ietf-weirds-rdap-sec**** > > ** ** > > Thanks for the feedback, Byron. Comments below.**** > > ** ** > > Scott**** > > ** ** > > *From:* weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > Behalf Of *Byron Ellacott > *Sent:* Tuesday, April 16, 2013 1:08 AM > *To:* weirds@ietf.org > *Subject:* Re: [weirds] Working Group Last Call: > draft-ietf-weirds-rdap-sec**** > > ** ** > > Hello WG,**** > > ** ** > > "I have reviewed this document thoroughly and it looks good."**** > > ** ** > > - The introduction does not refer to I-D.ietf-weirds-using-http, and > perhaps should.**** > > ** ** > > > Perhaps. I don=92t have a problem with adding it.**** > > ** ** > > - In 3.1.1, the [To be discussed: =85] note should be removed.**** > > ** ** > > > Yes, thanks for catching that.**** > > ** ** > > - 3.3 could reference -using=96http on the use of 429 response codes, or > vice versa.**** > > ** ** > > > We already have a normative reference to RFC 6585. =96using-http includ= es > the same reference. I think we=92re good as long as the documents are > consistent.**** > > ** ** > > - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is > to note that RDAP is expected to be used in an HTML presentation context = at > least some of the time, but the wording is not quite right there, I think= . > **** > > ** ** > > > s/As an HTML-based protocol/As a protocol using HTTP transport/? I=92m > open to suggestions.**** > > ** ** > > Scott**** > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --f46d044306aa540b1604da9259f6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I see what you're getting at, though it does seem= odd to talk about RDAP without a reference document explaining what exactl= y that is.

I recommend leaving the references in.=A0 If we add searc= h document(s) or something else to the core set, this can be fixed during I= ETF LC or via RFC Editor notes during IESG Evaluation.=A0 Or, at a minimum,= referencing a subset of core documents is better than referencing none.
-MSK, document shepherd hat this time


On Wed, Apr 17, 2013= at 6:19 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

While looking at the text in the Introduct= ion section to address Byron=92s comment below I decided that I=92d rather = eliminate the references to the documents. The list will become incomplete if the core set changes (such as by adding a =93search=94 docum= ent). Instead, I=92d like to replace this text:

=A0

=93The Registration Data Access Protocol (= RDAP) core is specified in two documents: "Registration Data Access Pr= otocol Lookup Format" [I-D.ietf-weirds-rdap-query] and "JSON Resp= onses for the Registration Data Access Protocol (RDAP)" [I-D.ietf-weirds-js= on-response].=A0 One goal of RDAP is to provide security services that do n= ot exist in the WHOIS [RFC3912] protocol, including authentication, authori= zation, availability, data confidentiality, and data integrity.

=A0

This document describes each of these secu= rity services from the perspective of RDAP requirements and applicability.= =A0 Where applicable, informational references to requirements for a WHOIS replacement service [RFC3707] are noted.=94

=A0

with this:

=A0

=93One goal of the Registration Data Acces= s Protocol (RDAP) is to provide security services that do not exist in the = WHOIS [RFC3912] protocol, including authentication, authorization, availability, data confidentiality, and data integrity.=A0 This document d= escribes how each of these services is applicable to RDAP and specifies req= uirements and approaches to provide the services.=A0 Where applicable, info= rmational references to requirements for a WHOIS replacement service [RFC3707] are noted.=94

=A0

Scott

=A0

From: weirds-bounces@ietf.o= rg [mailto:weirds-bounces@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 16, 2013 1:12 PM
To: Byron Ellacott; weirds@ietf.org


Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

=A0

Thanks for the feedback, Byron. Comments b= elow.

=A0

Scott

=A0

From: weirds-bounces@ietf.o= rg [mailto:weirds-bounces@ietf.org] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: weirds@ietf= .org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

=A0

Hello WG,

=A0

"I have reviewed this document tho= roughly and it looks good."

=A0

=A0- The introduction does not refer to= I-D.ietf-weirds-using-http, and perhaps should.

=A0

> Perhaps. I don=92t have a problem wit= h adding it.

=A0

=A0- In 3.1.1, the [To be discussed: = =85] note should be removed.

=A0

> Yes, thanks for catching that.<= u>

=A0

=A0- 3.3 could reference -using=96http = on the use of 429 response codes, or vice versa.

=A0

> We already have a normative reference= to RFC 6585. =96using-http includes the same reference. I think we=92re go= od as long as the documents are consistent.

=A0

=A0- 5 refers to RDAP as an "HTML-= based protocol." =A0I believe the intent is to note that RDAP is expec= ted to be used in an HTML presentation context at least some of the time, but the wording is not quite right there, I think.<= /u>

=A0

> s/As an HTML-based protocol/As a prot= ocol using HTTP transport/? I=92m open to=A0 suggestions.

=A0<= /p>

Scott


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


--f46d044306aa540b1604da9259f6-- From jean-philippe.dionne@viagenie.ca Wed Apr 17 11:07:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B811421E8051 for ; Wed, 17 Apr 2013 11:07:14 -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 kkc3s3Dnu6qs for ; Wed, 17 Apr 2013 11:07:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4126A21E804B for ; Wed, 17 Apr 2013 11:07:14 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AC3DE40401 for ; Wed, 17 Apr 2013 14:06:43 -0400 (EDT) Message-ID: <516EE4B3.4020201@viagenie.ca> Date: Wed, 17 Apr 2013 14:06:43 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: weirds@ietf.org References: <516ECFE1.4090609@gmail.com> In-Reply-To: <516ECFE1.4090609@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] LACNIC implementation of rate limiting and API keys X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 18:07:14 -0000 On 04/17/2013 12:37 PM, Carlos M. Martinez wrote: > I also ask the workgroup whether you believe this topic should be > addressed in any of the current drafts, in a new draft, or if it should > be left up to implementers. Hi Carlos, Thank you for sharing this info. I am curious to know if you have considered using the http authentication mechanism (or other mechanism suggested by draft-ietf-weirds-rdap-sec) instead of the "?apikey=1234" inside the url? Thanks Jean-Philippe From shollenbeck@verisign.com Wed Apr 17 11:15: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 851D121E805F for ; Wed, 17 Apr 2013 11:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.375, 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 irwl3Wjd+0O2 for ; Wed, 17 Apr 2013 11:15:41 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0D43421E8048 for ; Wed, 17 Apr 2013 11:15:40 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUW7my0v7XfMU2FkkBMcxcM0/BfETwyAb@postini.com; Wed, 17 Apr 2013 11:15:41 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 r3HIFarF010509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Apr 2013 14:15:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 17 Apr 2013 14:15:36 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHOO5ZUrZikOo63d0m/zlGHgxJ+qpjatiiw Date: Wed, 17 Apr 2013 18:15:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2435A40E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F243595CB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F24359E74@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_831693C2CDA2E849A7D7A712B24E257F2435A40EBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:15:44 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F2435A40EBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > it does seem odd to talk about RDAP without a reference document explaini= ng what exactly that is. This document will get stuck in a queue until the references can be resolve= d, but I see your point. I'll keep 'em in. Scott From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Wednesday, April 17, 2013 2:07 PM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec I see what you're getting at, though it does seem odd to talk about RDAP wi= thout a reference document explaining what exactly that is. I recommend leaving the references in. If we add search document(s) or som= ething else to the core set, this can be fixed during IETF LC or via RFC Ed= itor notes during IESG Evaluation. Or, at a minimum, referencing a subset = of core documents is better than referencing none. -MSK, document shepherd hat this time On Wed, Apr 17, 2013 at 6:19 AM, Hollenbeck, Scott > wrote: While looking at the text in the Introduction section to address Byron's co= mment below I decided that I'd rather eliminate the references to the docum= ents. The list will become incomplete if the core set changes (such as by a= dding a "search" document). Instead, I'd like to replace this text: "The Registration Data Access Protocol (RDAP) core is specified in two docu= ments: "Registration Data Access Protocol Lookup Format" [I-D.ietf-weirds-r= dap-query] and "JSON Responses for the Registration Data Access Protocol (R= DAP)" [I-D.ietf-weirds-json-response]. One goal of RDAP is to provide secu= rity services that do not exist in the WHOIS [RFC3912] protocol, including = authentication, authorization, availability, data confidentiality, and data= integrity. This document describes each of these security services from the perspectiv= e of RDAP requirements and applicability. Where applicable, informational = references to requirements for a WHOIS replacement service [RFC3707] are no= ted." with this: "One goal of the Registration Data Access Protocol (RDAP) is to provide sec= urity services that do not exist in the WHOIS [RFC3912] protocol, including= authentication, authorization, availability, data confidentiality, and dat= a integrity. This document describes how each of these services is applica= ble to RDAP and specifies requirements and approaches to provide the servic= es. Where applicable, informational references to requirements for a WHOIS= replacement service [RFC3707] are noted." Scott From: weirds-bounces@ietf.org [mailto:weird= s-bounces@ietf.org] On Behalf Of Hollenbeck= , Scott Sent: Tuesday, April 16, 2013 1:12 PM To: Byron Ellacott; weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thanks for the feedback, Byron. Comments below. Scott From: weirds-bounces@ietf.org [mailto:weird= s-bounces@ietf.org] On Behalf Of Byron Ella= cott Sent: Tuesday, April 16, 2013 1:08 AM To: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Hello WG, "I have reviewed this document thoroughly and it looks good." - The introduction does not refer to I-D.ietf-weirds-using-http, and perha= ps should. > Perhaps. I don't have a problem with adding it. - In 3.1.1, the [To be discussed: ...] note should be removed. > Yes, thanks for catching that. - 3.3 could reference -using-http on the use of 429 response codes, or vic= e versa. > We already have a normative reference to RFC 6585. -using-http includes t= he same reference. I think we're good as long as the documents are consiste= nt. - 5 refers to RDAP as an "HTML-based protocol." I believe the intent is t= o note that RDAP is expected to be used in an HTML presentation context at = least some of the time, but the wording is not quite right there, I think. > s/As an HTML-based protocol/As a protocol using HTTP transport/? I'm open= to suggestions. Scott _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds --_000_831693C2CDA2E849A7D7A712B24E257F2435A40EBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> it does seem odd to talk about RDAP without a reference document = explaining what exactly that is.

 

This document will get stuck in a queue un= til the references can be resolved, but I see your point. I’ll keep &= #8216;em in.

 

Scott

 

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Wednesday, April 17, 2013 2:07 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

I see what you're get= ting at, though it does seem odd to talk about RDAP without a reference doc= ument explaining what exactly that is.

I recommend leaving the references in.  If we add search document(s) o= r something else to the core set, this can be fixed during IETF LC or via R= FC Editor notes during IESG Evaluation.  Or, at a minimum, referencing= a subset of core documents is better than referencing none.

-MSK, document shepherd hat this time

 

On Wed, Apr 17, 2013 at 6:19 AM, Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

While looking at the text in the Introduction section to= address Byron’s comment below I decided that I’d rather elimin= ate the references to the documents. The list will become incomplete if the co= re set changes (such as by adding a “search” document). Instead= , I’d like to replace this text:

 

“The Registration Data Access Protocol (RDAP) core= is specified in two documents: "Registration Data Access Protocol Lookup Format" [I-D.ietf-weirds-rdap-query] and "JSON Responses = for the Registration Data Access Protocol (RDAP)" [I-D.ietf-weirds-jso= n-response].  One goal of RDAP is to provide security services that do= not exist in the WHOIS [RFC3912] protocol, including authentication, authorization, availability, data confidentiality, and dat= a integrity.

 

This document describes each of these security services = from the perspective of RDAP requirements and applicability.  Where applicable, informational references to requirements for a WHOIS rep= lacement service [RFC3707] are noted.”

 

with this:

 

“One goal of the Registration Data Access Protocol= (RDAP) is to provide security services that do not exist in the WHOIS [RFC3912] protocol, including authentication, authorization, availab= ility, data confidentiality, and data integrity.  This document descri= bes how each of these services is applicable to RDAP and specifies requirem= ents and approaches to provide the services.  Where applicable, informational references to requirements for a WHOIS rep= lacement service [RFC3707] are noted.”

 

Scott

 

From: weirds-bounces= @ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 16, 2013 1:12 PM
To: Byron Ellacott; weirds@ietf.org


Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Thanks for the feedback, Byron. Comments below.

 

Scott

 

From: weirds-bounces= @ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Byron Ellacott
Sent: Tuesday, April 16, 2013 1:08 AM
To: weirds@ietf= .org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Hello WG,

 

"I have reviewed this document thoroughly and it= looks good."

 

 - The introduction does not refer to I-D.ietf-w= eirds-using-http, and perhaps should.

 

> Perhaps. I don’t have a problem with adding i= t.

 

 - In 3.1.1, the [To be discussed: …] note= should be removed.

 

> Yes, thanks for catching that.

 

 - 3.3 could reference -using–http on the = use of 429 response codes, or vice versa.

 

> We already have a normative reference to RFC 6585. = –using-http includes the same reference. I think we’re good as long as the documents are consistent.

 

 - 5 refers to RDAP as an "HTML-based proto= col."  I believe the intent is to note that RDAP is expected to b= e used in an HTML presentation context at least some of the time, but the wording= is not quite right there, I think.

 

> s/As an HTML-based protocol/As a protocol using HTT= P transport/? I’m open to  suggestions.

 

Scott


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

 

--_000_831693C2CDA2E849A7D7A712B24E257F2435A40EBRN1WNEXMBX01vc_-- From carlosm3011@gmail.com Wed Apr 17 11:54:17 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52821E8085 for ; Wed, 17 Apr 2013 11:54:17 -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 GZOmkdb6D8dx for ; Wed, 17 Apr 2013 11:54:16 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC221E8063 for ; Wed, 17 Apr 2013 11:54:16 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so1091607qeb.6 for ; Wed, 17 Apr 2013 11:54:15 -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=x7I43S8Gzx7IDRuFDnQBk+ne7wxu0KAr+K/qVG/NQoA=; b=rmAqQ5xE/Jvlh8quAfB1Y3lNi5j54n9/ViZJ2xbYO6QtxClO+H60Nddt42wL/I783/ MQltSkWdZ+ASapehIYYoNKuhpE5l2YLuQu9MIiPtyf7j/pcs9vaVaYFObOiqpYi2x5P8 trvOXSkZZ6muMkJskn0aSnT033qSMoZ5WrsEOad9f/2HCqosZC8zbUfh26VUIbpFh2kt RIa6P8iUic43E4fx5R05fEykq7D4mggp9K1MP1Nout9DuRsQz+C7UF3r1O3AP2ZgVul4 bO1yBCEGnjeVUX4U4tFrxQK8+kNCSgMSyDEwY8JvzAK03v9fkoGeLZoEEhGpLM5Sv4q3 pzew== X-Received: by 10.229.167.131 with SMTP id q3mr459382qcy.133.1366224855855; Wed, 17 Apr 2013 11:54:15 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:29e3:7398:b044:fdc8]) by mx.google.com with ESMTPS id bt19sm9670690qab.0.2013.04.17.11.54.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 11:54:14 -0700 (PDT) Message-ID: <516EEFD2.1080000@gmail.com> Date: Wed, 17 Apr 2013 15:54:10 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jean-Philippe Dionne References: <516ECFE1.4090609@gmail.com> <516EE4B3.4020201@viagenie.ca> In-Reply-To: <516EE4B3.4020201@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] LACNIC implementation of rate limiting and API keys X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 18:54:17 -0000 Hello Jean-Philippe, Our implementation somewhat predates draft-xx-rdap-sec. The apikey + source-ip restriction is more similar and feels familiar when compared to our current operational procedures for port 43 WHOIS. Also this is why we currently return a 403 instead of a 429. Personally (and this is just my opinion), embedding the apikey in the URL lends itself more easily for casual users (simple bash scripts or event just browser access as it is bookmarkable) That said, we do plan to support draft-xxx-rdap-sec as well, probably using the same API key as username / password with auth-basic / auth-digest, although we haven't made a design decision just yet. We also plan to start sending 429s instead of 403s and to send Retry-After hints so well-behaved clients can, well, behave themselves :D Warm regards, ~Carlos On 4/17/13 3:06 PM, Jean-Philippe Dionne wrote: > On 04/17/2013 12:37 PM, Carlos M. Martinez wrote: >> I also ask the workgroup whether you believe this topic should be >> addressed in any of the current drafts, in a new draft, or if it should >> be left up to implementers. > > Hi Carlos, > > Thank you for sharing this info. > > I am curious to know if you have considered using the http > authentication mechanism (or other mechanism suggested by > draft-ietf-weirds-rdap-sec) instead of the "?apikey=1234" inside the url? > > Thanks > Jean-Philippe > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Thu Apr 18 05:01: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 84EE921F8D29 for ; Thu, 18 Apr 2013 05:01:02 -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 XcGMv1bnD9MB for ; Thu, 18 Apr 2013 05:01:01 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 24BB821F8C10 for ; Thu, 18 Apr 2013 05:01:01 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C8B832136C3; Thu, 18 Apr 2013 08:01:00 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id CFA27213666; Thu, 18 Apr 2013 08:00: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; Thu, 18 Apr 2013 08:00:42 -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, 18 Apr 2013 08:00:58 -0400 From: Andy Newton To: "carlos@lacnic.net" , Jean-Philippe Dionne Thread-Topic: api keys in rdap-sec ( was Re: [weirds] LACNIC implementation of rate limiting and API keys ) Thread-Index: AQHOPCxjURle14NLy02NRzfWq6fHEQ== Date: Thu, 18 Apr 2013 12:00:58 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> In-Reply-To: <516EEFD2.1080000@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.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <517FC4342E77964E90AF291C01ADC014@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 12:01:02 -0000 On 4/17/13 2:54 PM, "Carlos M. Martinez" wrote: >That said, we do plan to support draft-xxx-rdap-sec as well, probably >using the same API key as username / password with auth-basic / >auth-digest, although we haven't made a design decision just yet. We >also plan to start sending 429s instead of 403s and to send Retry-After >hints so well-behaved clients can, well, behave themselves :D We have api keys for our templates and restful provisioning system, and we are considering their use with our Whois restful system (not RDAP, the one we currently have). I think draft-ietf-weirds-rdap-sec should mention api keys and define a manner in which they are used. Api keys are quite common in restful web services. The above suggestion of using them with auth-basic,digest looks workable. -andy From kranjbar@ripe.net Thu Apr 18 05:13: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 7168421F87B7 for ; Thu, 18 Apr 2013 05:13:41 -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 9ce9GOHT7X-U for ; Thu, 18 Apr 2013 05:13:41 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE521F8783 for ; Thu, 18 Apr 2013 05:13:40 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1USnib-0002Uz-Or; Thu, 18 Apr 2013 14:13:38 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-243.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1USnib-0000Qv-Mf; Thu, 18 Apr 2013 14:13:37 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B3E29C2-E5C4-4580-9A66-3E891B3029EE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kaveh Ranjbar In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> Date: Thu, 18 Apr 2013 14:13:37 +0200 Message-Id: <4F6267CA-DD0B-4A9A-9138-42FBC9467909@ripe.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> To: Andy Newton X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130418 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5bbc0534425b410de6d067b3eb5d11c640 Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 12:13:41 -0000 --Apple-Mail=_8B3E29C2-E5C4-4580-9A66-3E891B3029EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 18, 2013, at 2:00 PM, Andy Newton wrote: > I think draft-ietf-weirds-rdap-sec should mention api keys and define = a > manner in which they are used. Api keys are quite common in restful = web > services. +1 > The above suggestion of using them with auth-basic,digest looks = workable. How are we going to (nicely) translate an API key to a = [username:realm:password] combination?=20 In my opinion, these two mechanisms represent two distinct scenarios: in = case of an API key, you obtain it after going through an auth. process = which will generate a key for you based on your credential privileges or = services level VS in case of username, password those privileges or = service level restrictions are tied to the account itself. All the best, Kaveh.= --Apple-Mail=_8B3E29C2-E5C4-4580-9A66-3E891B3029EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii andy@arin.net> wrote:

I think = draft-ietf-weirds-rdap-sec should mention api keys and define = a
manner in which they are used. Api = keys are quite common in restful web
services.
, "weirds@ietf.org" Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 13:27:29 -0000 --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805CHAXCH01corpari_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Kaveh Ranjbar > Date: Thursday, April 18, 2013 8:13 AM To: Andrew Newton > Cc: Carlos Martinez >, Jean-Phi= lippe Dionne >, "weirds@ietf.org" > Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation = of rate limiting and API keys ) How are we going to (nicely) translate an API key to a [username:realm:pass= word] combination? In my opinion, these two mechanisms represent two distinct scenarios: in ca= se of an API key, you obtain it after going through an auth. process which = will generate a key for you based on your credential privileges or services= level VS in case of username, password those privileges or service level r= estrictions are tied to the account itself. Just theorizing, but we could have the username as "apikey" and the passwor= d as the actual api key. Api keys are handy, but I've never liked the idea that they surface in URIs= as parameters. -andy --_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805CHAXCH01corpari_ Content-Type: text/html; charset="us-ascii" Content-ID: <7FD12880A2E5424BB03BCD58F62E31AF@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Kaveh Ranjbar <kranjbar@ripe.net>
Date: Thursday, April 18, 2013 8:13= AM
To: Andrew Newton <andy@arin.net>
Cc: Carlos Martinez <carlos@lacnic.net>, Jean-Philippe Dionne &= lt;jean-philippe.dionne= @viagenie.ca>, "weirds@ietf.= org" <weirds@ietf.org>
Subject: Re: [weirds] api keys in r= dap-sec ( was Re: LACNIC implementation of rate limiting and API keys )

How are we going to (nicely) translate an API key to a [username:realm= :password] combination? 

In my opinion, these two mechanisms represent two distinct scenarios: = in case of an API key, you obtain it after going through an auth. process w= hich will generate a key for you based on your credential privileges or ser= vices level VS in case of username, password those privileges or service level restrictions are tied to the ac= count itself.

Just theorizing, but we could have the username as "apikey" = and the password as the actual api key.

Api keys are handy, but I've never liked the idea that they surface in= URIs as parameters.

-andy
--_000_62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805CHAXCH01corpari_-- From shollenbeck@verisign.com Thu Apr 18 07:29: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 D9FB021F8F0D for ; Thu, 18 Apr 2013 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 9UL709YVgPOs for ; Thu, 18 Apr 2013 07:29:36 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id A264521F8E6B for ; Thu, 18 Apr 2013 07:29:30 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUXADSmRHKzk0kR6xpHH6GX/QqebJobuE@postini.com; Thu, 18 Apr 2013 07:29:36 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 r3IETPAN029336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 10:29: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, 18 Apr 2013 10:29:24 -0400 From: "Hollenbeck, Scott" To: Andy Newton , "carlos@lacnic.net" , Jean-Philippe Dionne Thread-Topic: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) Thread-Index: AQHOPCxjURle14NLy02NRzfWq6fHEZjcCcUA Date: Thu, 18 Apr 2013 14:29:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24366F3A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <516EEFD2.1080000@gmail.com> <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 14:29:37 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Andy Newton > Sent: Thursday, April 18, 2013 8:01 AM > To: carlos@lacnic.net; Jean-Philippe Dionne > Cc: weirds@ietf.org > Subject: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation > of rate limiting and API keys ) >=20 > On 4/17/13 2:54 PM, "Carlos M. Martinez" wrote: >=20 > >That said, we do plan to support draft-xxx-rdap-sec as well, probably > >using the same API key as username / password with auth-basic / > >auth-digest, although we haven't made a design decision just yet. We > >also plan to start sending 429s instead of 403s and to send Retry- > After > >hints so well-behaved clients can, well, behave themselves :D >=20 > We have api keys for our templates and restful provisioning system, and > we > are considering their use with our Whois restful system (not RDAP, the > one > we currently have). >=20 > I think draft-ietf-weirds-rdap-sec should mention api keys and define a > manner in which they are used. Api keys are quite common in restful web > services. >=20 > The above suggestion of using them with auth-basic,digest looks > workable. Please send text. Scott From carlosm3011@gmail.com Thu Apr 18 08:56:46 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172421F8FDF for ; Thu, 18 Apr 2013 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 MGSeKw9Cm09o for ; Thu, 18 Apr 2013 08:56:44 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 110EA21F8FD6 for ; Thu, 18 Apr 2013 08:56:41 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so2658360vcb.19 for ; Thu, 18 Apr 2013 08:56:41 -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=BAQwIZ6dyOJMsTYrOPkxmHWUyLAkVu4katTmQMEzYts=; b=t6tiWI+mb/+O/4JcTHw5OxpdekMF7ThiRmDJ8iDvMX+HgxbFjZNZyM2/3TjARzwRkt 6VSaPRwC3gAoA00KlYHA0T6Jpk4W76F19o7ARrXVrkrng1wU6efyRB9KhPCk17oJVdCe L+GFrcg9SBlZ7GpZJmziuCvdw54EL4xp9MGlcHdFNQkhspM316gAUXW9X9RU10OAAVer eoMkSBW/pYk7jwW+E8Ozocf30YGe8iqelB0I8StSJFk/pP6naJpyPsFzx9b6+BWaWkPd Z1IiL91Dm7xR8N6I25aeewTpM0freh2ssylPceRMJ00l+5dVaQ7GjFI5HEnZVHcmbCbu Xaog== X-Received: by 10.52.178.161 with SMTP id cz1mr7252641vdc.7.1366300601568; Thu, 18 Apr 2013 08:56:41 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:61b4:49b4:c10d:1585]) by mx.google.com with ESMTPS id tf2sm10044452veb.8.2013.04.18.08.56.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:56:40 -0700 (PDT) Message-ID: <517017B7.4080103@gmail.com> Date: Thu, 18 Apr 2013 12:56:39 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 15:56:46 -0000 I was thinking along that lines, too: Username: rdapclient Realm: apikey Password: 0ath1s1smy4p1ke1 What I like about having apikeys in the URLs is the 'bookmarkability' (!) they provide. However, I'm not religious about it either. Other possibility would be a custom header, something along the lines of: X-RDAP-APIKey: 0ath1s1smy4p1ke1 Warm regards, ~Carlos On 4/18/13 10:27 AM, Andy Newton wrote: > From: Kaveh Ranjbar > > Date: Thursday, April 18, 2013 8:13 AM > To: Andrew Newton > > Cc: Carlos Martinez >, > Jean-Philippe Dionne >, "weirds@ietf.org > " > > Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC > implementation of rate limiting and API keys ) > > How are we going to (nicely) translate an API key to a > [username:realm:password] combination? > > In my opinion, these two mechanisms represent two distinct > scenarios: in case of an API key, you obtain it after going through > an auth. process which will generate a key for you based on your > credential privileges or services level VS in case of username, > password those privileges or service level restrictions are tied to > the account itself. > > > Just theorizing, but we could have the username as "apikey" and the > password as the actual api key. > > Api keys are handy, but I've never liked the idea that they surface in > URIs as parameters. > > -andy > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From simon.perreault@viagenie.ca Thu Apr 18 09:02: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 BE42A21F9005 for ; Thu, 18 Apr 2013 09:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UXoE9Jkw0Hly for ; Thu, 18 Apr 2013 09:02:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A13DF21F8FFC for ; Thu, 18 Apr 2013 09:02:27 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 519A640401 for ; Thu, 18 Apr 2013 12:02:23 -0400 (EDT) Message-ID: <5170190F.1050902@viagenie.ca> Date: Thu, 18 Apr 2013 18:02:23 +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: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> <517017B7.4080103@gmail.com> In-Reply-To: <517017B7.4080103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 16:02:42 -0000 Le 2013-04-18 17:56, Carlos M. Martinez a écrit : > I was thinking along that lines, too: > > Username: rdapclient > Realm: apikey > Password: 0ath1s1smy4p1ke1 Note that you can't get to the plain-text password if you use an auth scheme like digest. Simon From carlosm3011@gmail.com Thu Apr 18 09:06: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 B849E21F9033 for ; Thu, 18 Apr 2013 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 DX3HWU06+31c for ; Thu, 18 Apr 2013 09:06:16 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 149EE21F8FFC for ; Thu, 18 Apr 2013 09:06:15 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id a11so1813283qen.23 for ; Thu, 18 Apr 2013 09:06:15 -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=aXHFjdVzge+7Uceo+b7/uLIp6AqjZhqPVi/SwZdSa8s=; b=sPR4th2CcGGR8cHotAROqaAXe/Es2pMnLMGGkQRrblCTREvhcdPbXGz2RNY00Op0Gl gTov5JLNb6sjQm6bfalGA3EOp0hzo+N5w1GwftczVZb7Fvw3ndBYCX+7F5Xl463z/0Fa 2XcyDm7S3SySf1LVfur+VzMZcRki51uO5FcSvpQUxGFYqK6rLFdm1ohSw+fi+XpOwHvG T5YbQv0PVcYp+2zWjsjWGp9XhpKYkLgNF6JfeY2IkiHDRM9IKm229pKhc0qXfffn4jOr HlUK6UDSvDeRGLK2o5OoTI7J5aO5akl7u6wEUk7hiYsvf+h5S/IIvyXUwtY4taATZqzp bvBA== X-Received: by 10.49.14.102 with SMTP id o6mr12493161qec.5.1366301175583; Thu, 18 Apr 2013 09:06:15 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:61b4:49b4:c10d:1585]) by mx.google.com with ESMTPS id kn10sm12787534qeb.8.2013.04.18.09.06.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 09:06:14 -0700 (PDT) Message-ID: <517019F4.2010200@gmail.com> Date: Thu, 18 Apr 2013 13:06:12 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Simon Perreault References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> <517017B7.4080103@gmail.com> <5170190F.1050902@viagenie.ca> In-Reply-To: <5170190F.1050902@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: weirds@ietf.org Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:06:16 -0000 Of course. But you can store both api keys and their corresponding digests in your DB. Or we may decide to only spec plain-text for realm apikey. I don't have strong views on the subject... as Woody Allen put it 'Whatever Works' :D ~C. On 4/18/13 1:02 PM, Simon Perreault wrote: > Le 2013-04-18 17:56, Carlos M. Martinez a écrit : >> I was thinking along that lines, too: >> >> Username: rdapclient >> Realm: apikey >> Password: 0ath1s1smy4p1ke1 > > Note that you can't get to the plain-text password if you use an auth > scheme like digest. > > Simon > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Thu Apr 18 09:11:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23F521F90CC for ; Thu, 18 Apr 2013 09:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 IB3yf15lSZAw for ; Thu, 18 Apr 2013 09:11:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 398E921F90C5 for ; Thu, 18 Apr 2013 09:11:15 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C3D2D40401; Thu, 18 Apr 2013 12:10:43 -0400 (EDT) Message-ID: <51701B04.1080004@viagenie.ca> Date: Thu, 18 Apr 2013 18:10:44 +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: carlos@lacnic.net References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> <517017B7.4080103@gmail.com> <5170190F.1050902@viagenie.ca> <517019F4.2010200@gmail.com> In-Reply-To: <517019F4.2010200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: weirds@ietf.org Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 16:11:15 -0000 Le 2013-04-18 18:06, Carlos M. Martinez a écrit : > Of course. But you can store both api keys and their corresponding > digests in your DB. Or we may decide to only spec plain-text for realm > apikey. If it's not important to get to the plain-text apikey, then I don't understand the technical difference between an apikey and a password. Could anyone explain like I'm a four year old? Thanks, Simon From jean-philippe.dionne@viagenie.ca Thu Apr 18 09:16: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 6726621F8E4C for ; Thu, 18 Apr 2013 09:16:36 -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 sjqKOK5vsd8s for ; Thu, 18 Apr 2013 09:16:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BCE1521F8BC7 for ; Thu, 18 Apr 2013 09:16:35 -0700 (PDT) Received: from sekkai.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2299C40401; Thu, 18 Apr 2013 12:16:35 -0400 (EDT) Message-ID: <51701C62.2090108@viagenie.ca> Date: Thu, 18 Apr 2013 12:16:34 -0400 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD7A2@CHAXCH01.corp.arin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 16:16:36 -0000 On 04/18/2013 08:00 AM, Andy Newton wrote: > On 4/17/13 2:54 PM, "Carlos M. Martinez" wrote: > >> That said, we do plan to support draft-xxx-rdap-sec as well, probably >> using the same API key as username / password with auth-basic / >> auth-digest, although we haven't made a design decision just yet. We >> also plan to start sending 429s instead of 403s and to send Retry-After >> hints so well-behaved clients can, well, behave themselves :D > > We have api keys for our templates and restful provisioning system, and we > are considering their use with our Whois restful system (not RDAP, the one > we currently have). > > I think draft-ietf-weirds-rdap-sec should mention api keys and define a > manner in which they are used. Api keys are quite common in restful web > services. > > The above suggestion of using them with auth-basic,digest looks workable. > Hi, I am wondering what is be the relation of authentication with the redirection mechanism. What happens when a client is redirected to a server that has a different authentication method or different authentication realm? I guess the client should maintain a list of credentials classified per realm, server name and authentication method. Jean-Philippe From carlosm3011@gmail.com Thu Apr 18 09:23:55 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B349221F9003 for ; Thu, 18 Apr 2013 09:23:55 -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 jU940XQOPP-E for ; Thu, 18 Apr 2013 09:23:55 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8F21F8FE8 for ; Thu, 18 Apr 2013 09:23:55 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id 1so1849550qec.38 for ; Thu, 18 Apr 2013 09:23:54 -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=K8Z3g8uJiwDX55/lJGqt7fm4pdM0f/4Nys+VjOkyMq4=; b=JfAnATpnsxk9cJyrrxYUUs4COoLlb4Pu9S4y7ICHMNuM6yGYLDA9Tsa5yVy8Pti37R +ydlx7grce0WZxnB0XZv/fSTRyrqd0wiW2dubJj9orORo3GSqApLclhNB3BUzbH8sqAy HlgkQQ7WTRn0aCULDaRVxcqDZ9QUugz7EfsnSwSlUhjH5wb6r9MrC8CRgcj+19xe0Tl6 A1YCrTHVvgZ8nfX+eyUMst7BPhh4YSItOSnfZ1d8S8bBHUWO5jnFMiIhxDZ8MQ0ofH4U bXQoW0AmgWVAt9jCZXG0xrgjgtSNWYdzXGCB2M+z+a7S15iqmb0pvNBYkNiALd5tahV4 VMug== X-Received: by 10.229.25.7 with SMTP id x7mr4018921qcb.138.1366302234500; Thu, 18 Apr 2013 09:23:54 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.70]) by mx.google.com with ESMTPS id ei3sm13712272qab.10.2013.04.18.09.23.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 09:23:53 -0700 (PDT) Message-ID: <51701E17.9080202@gmail.com> Date: Thu, 18 Apr 2013 13:23:51 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Simon Perreault References: <62D9228640AC7F49B2DD9ED0C9CE60E58BBFD805@CHAXCH01.corp.arin.net> <517017B7.4080103@gmail.com> <5170190F.1050902@viagenie.ca> <517019F4.2010200@gmail.com> <51701B04.1080004@viagenie.ca> In-Reply-To: <51701B04.1080004@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: carlos@lacnic.net, weirds@ietf.org Subject: Re: [weirds] api keys in rdap-sec ( was Re: LACNIC implementation of rate limiting and API keys ) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:23:55 -0000 It's the same idea, the semantics is different. An username/password set (supposedly) proves identity. An API key is just a token for some sort of contract between client and server. In this case, a contract for a given rate limiting policy. It is not intended to prove identity. Regards, ~Carlos On 4/18/13 1:10 PM, Simon Perreault wrote: > Le 2013-04-18 18:06, Carlos M. Martinez a écrit : >> Of course. But you can store both api keys and their corresponding >> digests in your DB. Or we may decide to only spec plain-text for realm >> apikey. > > If it's not important to get to the plain-text apikey, then I don't > understand the technical difference between an apikey and a password. > > Could anyone explain like I'm a four year old? > > Thanks, > Simon From superuser@gmail.com Sat Apr 20 11:33:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1621F91C4 for ; Sat, 20 Apr 2013 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 nHgf-PXd2xWa for ; Sat, 20 Apr 2013 11:33:12 -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 9CE6321F91BB for ; Sat, 20 Apr 2013 11:33:11 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t57so4739029wey.18 for ; Sat, 20 Apr 2013 11:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=zwFkrRx6yL7fkp0qsRSTGwZR5uTUrFapsLxIUmPrnwk=; b=j1sVl/1pwuZeeLEWy4V3uP6YlKTdCF/UzoT1vB1LBbqq8VkvHIxKNhVMhNczzrKBxp HaHf4qroOSRX0ZK+bEejhcISk0Gl6FwVWwkvYbZN9PeLQARD41iST/mcRbddYFrhDloM qAMtEw1vrJwFST5OsVea+1/TmwYwJBQoNfun95Nc0/hBoZ8W4jsmcfrmnWz5UyGetgem KqH3GFDzWWHyP5qRwS9Wxt/FcmB1ZWd5BEfW+WzfVzAGDMymaINg14jjNPFlGfVlT7IS 7YFT/c+PFk9G4rp4UuB8Ifib+9KYxj8Pdr8JBL0af/b8Gd7khkn4M1HQTzZOp2/ZmBOA LvRw== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr36814392wjb.15.1366482450423; Sat, 20 Apr 2013 11:27:30 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sat, 20 Apr 2013 11:27:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 20 Apr 2013 11:27:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=089e010d85740ca64904dacefd11 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 18:33:12 -0000 --089e010d85740ca64904dacefd11 Content-Type: text/plain; charset=ISO-8859-1 Reviewing as document shepherd: Overall, this is in good shape. Thanks to the editors for a job well done. What's below can be discussed on the list if anyone disagrees with any of these points; rough consensus prevails. Section 3 contains the first of many instances of a nit: The "RFC4949 [RFC4949]" thing seems awkward. Can we drop the first one? (Same for various other instances of the same thing throughout.) Section 3.4's reference to HTTP over TLS is a more useful syntax to me. Section 3.1, the use of RFC2119 language around requirements was something I'd not seen before. I checked with Barry and he said it was proper, so I'm not asking for any changes, but I just wanted to note that it might be questioned during other evaluation phases. Section 3.1, the APPROACH part, is the first indication that RDAP is built upon HTTP, but it is indicated only if you follow the reference to RFC2617. I suggest either saying this explicitly in the prose here, or adding a reference to our "using-http" draft in the Introduction section. Section 3.1.1, the paragraph on OpenID points out that it's decentralized twice. Suggest striking the second one. Also in that paragraph there's a TBD item; has this been resolved? Section 3.3, I don't think we can use RECOMMENDED in this way. Suggest replacing it with "advised". > Section 3.3, change "header" to "header field". In Section 3.4, the first requirement avoids naming HTTP specifically while the other two do. I think it's fine to admit up front that we're going with HTTP as the main transport mechanism (see above), so maybe that first requirement can be dropped. In Section 3.5, I think the point about data accuracy needs more emphasis given how it's appeared in other contexts (e.g., ICANN). It doesn't need to be here; maybe a new section after Section 3, or a paragraph in Security Considerations, would be a good place to talk about this for a sentence or three. Also in Section 3.5, isn't the first OPTION redundant to the second REQUIREMENT? Same with the second OPTION and the third REQUIREMENT. In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (maybe a new subsection), or we should pick a non-normative expression if we want to leave it there. In Section 5, I suggest that we also remind readers (and a single sentence should do it) that any vulnerabilities with respect to HTTP, HTTP AUTH, HTTP over TLS, etc., also affect RDAP clients and servers. -MSK --089e010d85740ca64904dacefd11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewing as document shephe= rd:

Overall, this is in good shape.=A0 Thanks to the edit= ors for a job well done.=A0 What's below can be discussed on the list i= f anyone disagrees with any of these points; rough consensus prevails.

Section 3 contains the first of many instances of a nit:

<= /div>The "RFC4949 [RFC4949]" thing seems awkward.=A0 Can we drop = the first one?=A0 (Same for various other instances of the same thing throu= ghout.)=A0 Section 3.4's reference to HTTP over TLS is a more useful sy= ntax to me.

Section 3.1, the use of RFC2119 language around requirements was = something I'd not seen before.=A0 I checked with Barry and he said it w= as proper, so I'm not asking for any changes, but I just wanted to note= that it might be questioned during other evaluation phases.

Section 3.1, the APPROACH part, is the first indication that RDAP= is built upon HTTP, but it is indicated only if you follow the reference t= o RFC2617.=A0 I suggest either saying this explicitly in the prose here, or= adding a reference to our "using-http" draft in the Introduction= section.

Section 3.1.1, the paragraph on OpenID points out that it's d= ecentralized twice.=A0 Suggest striking the second one.=A0 Also in that par= agraph there's a TBD item; has this been resolved?

Section= 3.3, I don't think we can use RECOMMENDED in this way.=A0 Suggest repl= acing it with "advised".

Section 3.3, change= "header" to "header field".

In Section 3.4, the first requirement avoids naming HTTP spec= ifically while the other two do.=A0 I think it's fine to admit up front= that we're going with HTTP as the main transport mechanism (see above)= , so maybe that first requirement can be dropped.

In Section 3.5, I think the point abou= t data accuracy needs more emphasis given how it's appeared in other co= ntexts (e.g., ICANN).=A0 It doesn't need to be here; maybe a new sectio= n after Section 3, or a paragraph in Security Considerations, would be a go= od place to talk about this for a sentence or three.

Also = in Section 3.5, isn't the first OPTION redundant to the second REQUIREM= ENT?=A0 Same with the second OPTION and the third REQUIREMENT.

In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (maybe = a new subsection), or we should pick a non-normative expression if we want = to leave it there.

In Section 5, I = suggest that we also remind readers (and a single sentence should do it) th= at any vulnerabilities with respect to HTTP, HTTP AUTH, HTTP over TLS, etc.= , also affect RDAP clients and servers.

-MSK
--089e010d85740ca64904dacefd11-- From shollenbeck@verisign.com Mon Apr 22 05:34: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 44E1821F8F6C for ; Mon, 22 Apr 2013 05:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq3dd6wPUjge for ; Mon, 22 Apr 2013 05:34:52 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7790321F8F17 for ; Mon, 22 Apr 2013 05:34:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUXUuajJuv3ga15RgcixxC1DU5PW4CtZP@postini.com; Mon, 22 Apr 2013 05:34:51 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 r3MCYktm014776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 08:34:46 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 22 Apr 2013 08:34:46 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHOPfWGsuM2cUeRnECY8g22/kEri5jiJ7EQ Date: Mon, 22 Apr 2013 12:34:45 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F24379B93@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_831693C2CDA2E849A7D7A712B24E257F24379B93BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:34:55 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F24379B93BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the comments Murray. More below. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Saturday, April 20, 2013 2:28 PM To: weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Reviewing as document shepherd: Overall, this is in good shape. Thanks to the editors for a job well done.= What's below can be discussed on the list if anyone disagrees with any of= these points; rough consensus prevails. Section 3 contains the first of many instances of a nit: The "RFC4949 [RFC4949]" thing seems awkward. Can we drop the first one? (= Same for various other instances of the same thing throughout.) Section 3.= 4's reference to HTTP over TLS is a more useful syntax to me. > I always try to write using complete sentences that don't include the cit= ation for needed references. Something like "blah blah as specified in [RFC= XXXX]." isn't a complete sentence, though it's commonly used in many RFCs. = I can make changes to use document titles as appropriate. Section 3.1, the use of RFC2119 language around requirements was something = I'd not seen before. I checked with Barry and he said it was proper, so I'= m not asking for any changes, but I just wanted to note that it might be qu= estioned during other evaluation phases. > It's an old debate. Section 3.1, the APPROACH part, is the first indication that RDAP is built = upon HTTP, but it is indicated only if you follow the reference to RFC2617.= I suggest either saying this explicitly in the prose here, or adding a re= ference to our "using-http" draft in the Introduction section. > I'm adding the reference to the introduction. Section 3.1.1, the paragraph on OpenID points out that it's decentralized t= wice. Suggest striking the second one. Also in that paragraph there's a T= BD item; has this been resolved? > I'll remove the second one, and yes, the TBD is being removed because the= most recent version addresses the question. Section 3.3, I don't think we can use RECOMMENDED in this way. Suggest rep= lacing it with "advised". > OK. Section 3.3, change "header" to "header field". > OK. In Section 3.4, the first requirement avoids naming HTTP specifically while= the other two do. I think it's fine to admit up front that we're going wi= th HTTP as the main transport mechanism (see above), so maybe that first re= quirement can be dropped. > The purpose of the first requirement is to describe a need to protect pla= intext credentials while in transit. It's not really about HTTP. I think it= needs to stay, but if the purpose isn't clear can you suggest text to make= it so? In Section 3.5, I think the point about data accuracy needs more emphasis g= iven how it's appeared in other contexts (e.g., ICANN). It doesn't need to= be here; maybe a new section after Section 3, or a paragraph in Security C= onsiderations, would be a good place to talk about this for a sentence or t= hree. > I'll move it to the Security Considerations section, but I do think the I= CANN focus has nothing to do with the protocol's security services. They're= talking about data values being "truthful". That's not something we can gu= arantee. Also in Section 3.5, isn't the first OPTION redundant to the second REQUIRE= MENT? Same with the second OPTION and the third REQUIREMENT. > Maybe they're not well ordered. The intention in the first case is to say= "RDAP MAY include message integrity checks, and if it does, they MUST be f= ully specified...". Same basic flow for the second option and third require= ment, but I agree that this last set doesn't flow very well. Either the req= uirement or the option can probably be removed. Which would you suggest? In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (maybe = a new subsection), or we should pick a non-normative expression if we want = to leave it there. > Given "Non-repudiation services were also considered and ultimately rejec= ted due to a lack of requirements", I don't like the idea of adding another= section to 3. I'll remove the normative text. In Section 5, I suggest that we also remind readers (and a single sentence = should do it) that any vulnerabilities with respect to HTTP, HTTP AUTH, HTT= P over TLS, etc., also affect RDAP clients and servers. > Agreed. --_000_831693C2CDA2E849A7D7A712B24E257F24379B93BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the comments Murray. More below= .

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Saturday, April 20, 2013 2:28 PM
To: weirds@ietf.org
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rda= p-sec

 

Reviewing as document= shepherd:

Overall, this is in g= ood shape.  Thanks to the editors for a job well done.  What's be= low can be discussed on the list if anyone disagrees with any of these poin= ts; rough consensus prevails.

Section 3 contains th= e first of many instances of a nit:

The "RFC4949 [RF= C4949]" thing seems awkward.  Can we drop the first one?  (S= ame for various other instances of the same thing throughout.)  Sectio= n 3.4's reference to HTTP over TLS is a more useful syntax to me.

> I alwa= ys try to write using complete sentences that don’t include the citat= ion for needed references. Something like “blah blah as specified in [RFCXXXX].” isn’t a complete sentence, though it’s commo= nly used in many RFCs. I can make changes to use document titles as appropr= iate.

Section 3.1, the use = of RFC2119 language around requirements was something I'd not seen before.&= nbsp; I checked with Barry and he said it was proper, so I'm not asking for= any changes, but I just wanted to note that it might be questioned during other evaluation phases.

> ItR= 17;s an old debate.

Section 3.1, the APPR= OACH part, is the first indication that RDAP is built upon HTTP, but it is = indicated only if you follow the reference to RFC2617.  I suggest eith= er saying this explicitly in the prose here, or adding a reference to our "using-http" draft in the Introduct= ion section.

> I̵= 7;m adding the reference to the introduction.

Section 3.1.1, the pa= ragraph on OpenID points out that it's decentralized twice.  Suggest s= triking the second one.  Also in that paragraph there's a TBD item; ha= s this been resolved?

> I̵= 7;ll remove the second one, and yes, the TBD is being removed because the m= ost recent version addresses the question.

Section 3.3, I don't think we can use RECOMMENDED in= this way.  Suggest replacing it with "advised".<= /p>

 

> OK.

 

Section 3.3, change &= quot;header" to "header field".

> OK.

In Section 3.4, the f= irst requirement avoids naming HTTP specifically while the other two do.&nb= sp; I think it's fine to admit up front that we're going with HTTP as the m= ain transport mechanism (see above), so maybe that first requirement can be dropped.

> The pu= rpose of the first requirement is to describe a need to protect plaintext c= redentials while in transit. It’s not really about HTTP. I think it needs to stay, but if the purpose isn’t clear can you suggest tex= t to make it so?

In Section 3.5, I think the point about data accurac= y needs more emphasis given how it's appeared in other contexts (e.g., ICAN= N).  It doesn't need to be here; maybe a new section after Section 3, = or a paragraph in Security Considerations, would be a good place to talk about this for a sentence or three.

 

> I’ll move it to the Security Co= nsiderations section, but I do think the ICANN focus has nothing to do with= the protocol’s security services. They’re talking about data v= alues being “truthful”. That’s not something we can guarantee.=

 

Also in Section 3.5, = isn't the first OPTION redundant to the second REQUIREMENT?  Same with= the second OPTION and the third REQUIREMENT.

> Maybe = they’re not well ordered. The intention in the first case is to say &= #8220;RDAP MAY include message integrity checks, and if it does, they MUST be fully specified…”. Same basic flow for the second option an= d third requirement, but I agree that this last set doesn’t flow very= well. Either the requirement or the option can probably be removed. Which = would you suggest?

In Section 5, I belie= ve the MUST NOT belongs somewhere in Section 3 (maybe a new subsection), or= we should pick a non-normative expression if we want to leave it there.

> Given = “Non-repudiation services were also considered and ultimately rejecte= d due to a lack of requirements”, I don’t like the idea of addi= ng another section to 3. I’ll remove the normative text.

In Section 5, I sugge= st that we also remind readers (and a single sentence should do it) that an= y vulnerabilities with respect to HTTP, HTTP AUTH, HTTP over TLS, etc., als= o affect RDAP clients and servers.

> Agreed= .

--_000_831693C2CDA2E849A7D7A712B24E257F24379B93BRN1WNEXMBX01vc_-- From superuser@gmail.com Mon Apr 22 13:10: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 8330321E80D8 for ; Mon, 22 Apr 2013 13:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 ZHapTP6F2Taz for ; Mon, 22 Apr 2013 13:10:07 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D69F21E80D5 for ; Mon, 22 Apr 2013 13:10:07 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1206972wgh.14 for ; Mon, 22 Apr 2013 13:10:06 -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=Lcz14Ezhh1xVtf0Gi2MAcZcebn1Mnln3TcsYL570QSc=; b=e7lkuqhZI7JiH7yDJ/VSfqdbl/z3PwiF67enY49MopLimZK8voymivUH/kNwGIfZyL NjXKPiombjx+zrUBTVOu1IoBYnb1AeAFYroZO68JSXw/IPnmdpk6Oy7g4HE/yQPAlrCz RPwFO4h5SLHuzbNZudW+4Cn6HN/fqP/KXhp0LuLbveCpOjsXRFrL3xWEwtAxYiBtWPw3 Mjm2Qelza+mSALL3UJfVhGUAlQvtuXAQgDQaDtJZTOal63nBtfGAy28BPHsw9q33I9M/ 4dtMU1hDDl32sNdiCKbKsopkkg3yfLDLxO7fllYBv8b6smZZY6GyRG1fbYtt26RAp962 a7+Q== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr33251594wix.14.1366661406395; Mon, 22 Apr 2013 13:10:06 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 22 Apr 2013 13:10:06 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F24379B93@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F24379B93@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 22 Apr 2013 13:10:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=f46d043c062ea815d504daf8a7ee Cc: "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:10:08 -0000 --f46d043c062ea815d504daf8a7ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Apr 22, 2013 at 5:34 AM, Hollenbeck, Scott wrote: > > I always try to write using complete sentences that don=92t include th= e > citation for needed references. Something like =93blah blah as specified = in > [RFCXXXX].=94 isn=92t a complete sentence, though it=92s commonly used in= many > RFCs. I can make changes to use document titles as appropriate. > Thanks. I agree that I'm mostly expressing a personal preference on that one, now that you mention it. > **** > In Section 3.4, the first requirement avoids naming HTTP specifically > while the other two do. I think it's fine to admit up front that we're > going with HTTP as the main transport mechanism (see above), so maybe tha= t > first requirement can be dropped. > > > The purpose of the first requirement is to describe a need to protect > plaintext credentials while in transit. It=92s not really about HTTP. I t= hink > it needs to stay, but if the purpose isn=92t clear can you suggest text t= o > make it so? > Yeah, I see your point. Let's try this on for size, and if you don't like it, just let it go as-is: Try dropping "HTTP" from the second requirement, and ending the third with "...confidentiality methods that may be defined later." > **** > > In Section 3.5, I think the point about data accuracy needs more emphasis > given how it's appeared in other contexts (e.g., ICANN). It doesn't need > to be here; maybe a new section after Section 3, or a paragraph in Securi= ty > Considerations, would be a good place to talk about this for a sentence o= r > three.**** > > ** ** > > > I=92ll move it to the Security Considerations section, but I do think t= he > ICANN focus has nothing to do with the protocol=92s security services. > They=92re talking about data values being =93truthful=94. That=92s not so= mething we > can guarantee. > Totally agree. I think I'm trying to head off the idea that some ICANN reader might look at this and say we forgot about or misunderstood the "truthful" issue; I'd rather we say it's simply not possible for this protocol (or, quite possibly, any protocol) to make positive assertions about the truth of the data, and such things shouldn't be inferred by clients or implementers. (Stephen Colbert's voice keeps coming to me when I type that word.) > **** > > ** ** > > Also in Section 3.5, isn't the first OPTION redundant to the second > REQUIREMENT? Same with the second OPTION and the third REQUIREMENT.**** > > > Maybe they=92re not well ordered. The intention in the first case is to > say =93RDAP MAY include message integrity checks, and if it does, they MU= ST > be fully specified=85=94. Same basic flow for the second option and third > requirement, but I agree that this last set doesn=92t flow very well. Eit= her > the requirement or the option can probably be removed. Which would you > suggest? > Personally, I would remove the options. To me they don't add anything; saying RDAP or a layer below it MUST provide those facilities (even if they're optional at those layers) seems adequate to me. But since you see what I'm getting at, I'll leave it to your discretion. > **** > > In Section 5, I believe the MUST NOT belongs somewhere in Section 3 (mayb= e > a new subsection), or we should pick a non-normative expression if we wan= t > to leave it there.**** > > > Given =93Non-repudiation services were also considered and ultimately > rejected due to a lack of requirements=94, I don=92t like the idea of add= ing > another section to 3. I=92ll remove the normative text. > WFM. Thanks! -MSK --f46d043c062ea815d504daf8a7ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2013 at 5:34 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

> = I always try to write using complete sentences that don=92t include the cit= ation for needed references. Something like =93blah blah as specified in [RFCXXXX].=94 isn=92t a complete sentence, though it=92s commonly used in = many RFCs. I can make changes to use document titles as appropriate.=

Thank= s.=A0 I agree that I'm mostly expressing a personal preference on that = one, now that you mention it.

In Section 3.4, the first requirement avoids naming HTTP specifically= while the other two do.=A0 I think it's fine to admit up front that we= 're going with HTTP as the main transport mechanism (see above), so may= be that first requirement can be dropped.

> = The purpose of the first requirement is to describe a need to protect plain= text credentials while in transit. It=92s not really about HTTP. I think it needs to stay, but if the purpose isn=92t clear can you suggest text to= make it so?

Yeah, I see your point.=A0 Let&= #39;s try this on for size, and if you don't like it, just let it go as= -is:

Try dropping "HTTP" from the second requirement, a= nd ending the third with "...confidentiality methods that may be defin= ed later."
=A0

In Section 3.5, I think the point about data accurac= y needs more emphasis given how it's appeared in other contexts (e.g., = ICANN).=A0 It doesn't need to be here; maybe a new section after Sectio= n 3, or a paragraph in Security Considerations, would be a good place to talk about this for a sentence or three.

=A0

> I=92ll move it to the Security = Considerations section, but I do think the ICANN focus has nothing to do wi= th the protocol=92s security services. They=92re talking about data values being =93truthful=94. That=92s not something we can guarantee.

<= /div>

Totally agree.=A0 I think I'm trying= to head off the idea that some ICANN reader might look at this and say we = forgot about or misunderstood the "truthful" issue; I'd rathe= r we say it's simply not possible for this protocol (or, quite possibly= , any protocol) to make positive assertions about the truth of the data, an= d such things shouldn't be inferred by clients or implementers.

(Stephen Colbert's voice keeps coming to me when I type = that word.)
=A0

=A0

Also in Section 3.5, = isn't the first OPTION redundant to the second REQUIREMENT?=A0 Same wit= h the second OPTION and the third REQUIREMENT.

> = Maybe they=92re not well ordered. The intention in the first case is to say= =93RDAP MAY include message integrity checks, and if it does, they MUST be fully specified=85=94. Same basic flow for the second option and third = requirement, but I agree that this last set doesn=92t flow very well. Eithe= r the requirement or the option can probably be removed. Which would you su= ggest?

Personally, I would remove the options.=A0 To me they = don't add anything; saying RDAP or a layer below it MUST provide those = facilities (even if they're optional at those layers) seems adequate to= me.=A0 But since you see what I'm getting at, I'll leave it to you= r discretion.

In Section 5, I belie= ve the MUST NOT belongs somewhere in Section 3 (maybe a new subsection), or= we should pick a non-normative expression if we want to leave it there.=

> = Given =93Non-repudiation services were also considered and ultimately rejec= ted due to a lack of requirements=94, I don=92t like the idea of adding ano= ther section to 3. I=92ll remove the normative text.

=
WFM.

Thanks!

-MSK
--f46d043c062ea815d504daf8a7ee-- From olaf@NLnetLabs.nl Tue Apr 23 07:28: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 3007421F96D6 for ; Tue, 23 Apr 2013 07:28:53 -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 lWBgLhMfLD84 for ; Tue, 23 Apr 2013 07:28:51 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F1821F96DD for ; Tue, 23 Apr 2013 07:28:50 -0700 (PDT) Received: from [192.168.1.13] ([80.77.148.146]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.6/8.14.4) with ESMTP id r3NES2IJ011643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 16:28:03 +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 r3NES2IJ011643 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1366727288; bh=KB5rit/eY3d68nhG/FsPzdgthYtt5DLQ/nKeOyZRWMI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gR19yiMZ31wNbcPDGarEuwdcFqpMHFHZGeOEGhPJ4/JJXcWJtPsb4fwkd0zMqFjVb 2+VShxCiDfYhlJBO7ZdX7gohpE/Nx42dzO+bw/qkkCPcA//AnwrGx6C//fTKi7B8yx yeUABsxWCc3Ip/m4zmLyvmbRvmV4AoYx/Be8MhdY= Content-Type: multipart/mixed; boundary="Apple-Mail=_4853E21E-B2C4-4A98-87FF-2BCE7C90F1A0" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: Date: Tue, 23 Apr 2013 16:28:01 +0200 Message-Id: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> To: Andy Newton , Ning Kong , Byron Ellacott X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Tue, 23 Apr 2013 16:28:07 +0200 (CEST) Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:28:53 -0000 --Apple-Mail=_4853E21E-B2C4-4A98-87FF-2BCE7C90F1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 17, 2013, at 5:10 AM, Murray S. Kucherawy = wrote: > Nice work, everyone! >=20 > A few things remain in -04: >=20 > 1) "Appendix Appendix B" in Section 4.2. >=20 > 2) The "Intended usage" thing in Section 8.1 is still weird. >=20 > 3) The SHOULD in Section 5 seems vague to me. (a) What does it mean = to "understand" it, exactly? (b) When would one deviate from the = normative statement and what impact might it have on interoperability? >=20 > These can be fixed during/after IETF LC, so just tuck them away for = later; no need to do a -05 first unless you feel like it. >=20 > -MSK, participatorially >=20 Folk, I am doing the shepherd write-up and I need some input: 1. ID-NITS there are some warnings in the idnits that I need to make sure I = understand. http://www.ietf.org/tools/idnits/idnits There is no split in Normative and Informative References. I believe it = might be wise to introduce shuch split if we ever want to bump this = beast to Internet Standard maturity (without the split all references = are treated as normative and that actually makes RFC4627 a downref and = make idnits throw an error.) Without this split there are a few things in the write-up that I cannot = answer in a satisfying way. 2. Media Type http://tools.ietf.org/html/rfc4288#section-5.1 calls for community = review by sending a mail to ietf-types@iana.org Has that happened? (A quick search in the archive did not return a hit.) = (Am I understanding the RFC4288 requirement correctly) 3. IANA consideration The text reads: The following is a preliminary template for an RDAP extension registration: That begs the question: how to make this the production template? Do you = need coordination with IANA? A first version of the writeup is attached. There are some places where = I've put [Follow-up] as an indication that action is needed pending the = above. --Olaf --Apple-Mail=_4853E21E-B2C4-4A98-87FF-2BCE7C90F1A0 Content-Disposition: attachment; filename=draft-ietf-weirds-using-http-shepherd.txt Content-Type: text/plain; x-unix-mode=0444; name="draft-ietf-weirds-using-http-shepherd.txt" Content-Transfer-Encoding: quoted-printable Shepherd writeup for draft-ietf-weirds-using-http-04.txt Shepherd: Olaf Kolkman $Id: draft-ietf-weirds-using-http-shepherd.txt,v 1.2 2013/04/23 14:26:40 = olaf Exp $ = --------------------------------------------------------------------------= ------ (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This intended to be Standards Track RFC, it is the normative specification on how to use a Registration Data Access Protocol on top of HTTP, hence Standards Track. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: [=46rom the Introduction, the Abstract is a bit denser, but OK IMHO] This document describes the usage of HTTP for Registration Data Directory Services. The goal of this document is to tie together usage patterns of HTTP into a common profile applicable to the various types of Directory Services serving Registration Data using RESTful practices. By giving the various Directory Services common behavior, a single client is better able to retrieve data from Directory Services adhering to this behavior. Working Group Summary: During the development of the working group there has been a good amount of review by multiple wg participants. There are no issues arrived on the rough side of consensus and the document as a whole is well carried by consensus. This document is not contentious, but in the spirit of putting all cards on the table: there is one point where it touches on an issue that seems to be potentially create more discussion in the future and that is the encapsulation format of the reply. The working is clearly going for JSON although there are some that argue that XML might be better suited for some deployments. This specification does allow, just like the charter, a possiblilty for alternative reply encapsulations. In other words, I do not see any problems for this document. Document Quality: During the previous IETF there has been a demo of 4 implementations. There have been explicit statements by others that they believe the RFC is of sufficient detail to implement against. There is no indication this document underspecifies aspects. There has not been a MIB, Media Type, DNS, or Sucurity expert review (at least not with those explicit hats) Personnel: Chairs: Murray Kuchewary and Olaf Kolkman Shepherd: Olaf Kolkman AD: Pete Resnick (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed version 03 and version 04 in detail. There are a few editorial nits that are at the level of RFC-Editor edits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document has an internationalisation section (section 9). I know that some of the folk in the working group have a background in Internationalisation issues and have reviewed the document. That said the document identifies the issues only to be addressed in future document that specify the rules for replies. I am not an HTTP expert myself but I do not think that the specification touched areas that are beyond the HTTP knowledge within the working group. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? I have contacted all authors and they confirmed that there were no disclosures that needed to be filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures (reviewed Tue Apr 23 13:30 UTC 2013) (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG Consensus is solid and carried by the whole group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) I have not heard discontent about this document. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. [FOLLOW UP] *** lack separate sections for Informative/Normative (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The specification registers the "application/rdap+json" media type. (section 8.2) [FOLLOW UP] (13) Have all references within this document been identified as either normative or informative? [NO, SEE 11] (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? [FOLLOW UP] (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. [FOLLOW UP] (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, this document will obsolete nor update other documents. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). [FOLLOW UP] (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no such registries. Only 'Specification Required' (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is one trivial ABNF specification in the document. It has been checked using http://www.anfdata.cz/bnfparser2/ ---------------RESULT--------------- name =3D ALPHA *( ALPHA / DIGIT / "_" ) [1] passed --Apple-Mail=_4853E21E-B2C4-4A98-87FF-2BCE7C90F1A0-- From superuser@gmail.com Tue Apr 23 13:04: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 E558021F93E1 for ; Tue, 23 Apr 2013 13:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 dvkER3yCP7t6 for ; Tue, 23 Apr 2013 13:04:52 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 196F921F93CC for ; Tue, 23 Apr 2013 13:04:51 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so1294601wie.0 for ; Tue, 23 Apr 2013 13:04:51 -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=/ENM3aibKAD2Pv1CIoANCBPPW80hSYAOnfqZCIHfflg=; b=oOiQrj3pO1QZqjIL/2PdmMcsBIz0NhM+XoF60wh4K3o1PuC164ziPHgIN8hKVklOsk 6ZD0uTYDLKubO2wzUPdgTffGgkd7PujCDtIMiHhyLzwbUCYiy27PIX7t6U/y4+SLnry0 QaSR1IQwcNIcQOsFJlg43wgjOXdo3ODlxE+4STIUS0MF3OMRjifzmv9KOeZ/uLb0yezL iUC2MaAqbrijg4vRkEIq7LJs8VvzRErUlAckKlPwLlZNnU2xCcCk3rOTiZlAq91nLjc+ 8d6BIP/vBHyadKgRmAIyOjlctxNbSbpfOot2hNRxHv64++EsEa5wyDCiUe1eJTWLuT6G b69g== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr606781wib.20.1366747491210; Tue, 23 Apr 2013 13:04:51 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 13:04:51 -0700 (PDT) Date: Tue, 23 Apr 2013 13:04:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c094eb61c2304db0cb224 Subject: [weirds] draft-ietf-weirds-rdap-sec and draft-ietf-weirds-using-http IPR declarations X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 23 Apr 2013 20:04:53 -0000 --f46d043c094eb61c2304db0cb224 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, The above drafts are either nearing the end of Working Group Last Call or have already completed it. We are being encouraged to be more proactive in confirming with our communities that there are no outstanding IPR declarations about documents being progressed as working group items before advancing them. You should all by now be familiar with the provisions of BCP 78 and 79. If you are not, please do go read up on them. If you have any knowledge of claims of intellectual property restrictions about any of the content in these two drafts, please post them either to the chairs (weirds-chairs@tools.ietf.org) or to the list as soon as possible. The authors, in particular, need to let the document shepherds know explicitly that they have no knowledge of anything outstanding before we can process them for publication. Thanks, -MSK, WEIRDS co-chair --f46d043c094eb61c2304db0cb224 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

The above drafts ar= e either nearing the end of Working Group Last Call or have already complet= ed it.

We are being encouraged to be more proactive in confirming wi= th our communities that there are no outstanding IPR declarations about doc= uments being progressed as working group items before advancing them.

You should all by now be familiar with the provisions of BC= P 78 and 79.=A0 If you are not, please do go read up on them.

= If you have any knowledge of claims of intellectual property restrictions a= bout any of the content in these two drafts, please post them either to the= chairs (weirds-chairs@tool= s.ietf.org) or to the list as soon as possible.=A0 The authors, in part= icular, need to let the document shepherds know explicitly that they have n= o knowledge of anything outstanding before we can process them for publicat= ion.

Thanks,

-MSK, WEIRDS co-chair

--f46d043c094eb61c2304db0cb224-- From peter@denic.de Wed Apr 24 01:57: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 C952821F8FA4 for ; Wed, 24 Apr 2013 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Mvs3uK1F1xzd for ; Wed, 24 Apr 2013 01:57:56 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3514121F8F58 for ; Wed, 24 Apr 2013 01:57:55 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1UUvWU-00054R-7k; Wed, 24 Apr 2013 10:57:54 +0200 Received: from localhost by x27.adm.denic.de with local id 1UUvWU-0002ku-2k; Wed, 24 Apr 2013 10:57:54 +0200 Date: Wed, 24 Apr 2013 10:57:54 +0200 From: Peter Koch To: IETF WEIRDS WG Message-ID: <20130424085754.GJ1402@x28.adm.denic.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 08:57:56 -0000 On Fri, Apr 12, 2013 at 10:51:21AM -0700, Murray S. Kucherawy wrote: > Please review and comment on the draft, even if it is only to say on the I have read the document and I do not believe it is ready to be sent to the IESG. Assuming the "Intended status: Standards Track" reflects current intentions, I fail to recognize the protocol specifications in the draft. While section two refers to RFC 2119 wording, the draft relies upon "REQUIREMENT", "OPTION" and "APPROACH" or even "POSSIBLE APPROACH". The first two frame mandatory or optional requirements (so they address properties of the protocol rather than the implementation, in which case the normative language semantics are shifted). The latter I am not sure how to interpret. What nature is an "APPROACH" compared to a suggestion (noting well the ambiguity of strength in that word, too). Who is the addressee for this? Is it the implementer or the operator? On specific security "services": o "3.3 availability" is clearly operational guidance rather than a protocol spec o "3.4 data confidentiality" mentions data but mostly talks about protecting the credentials (avoid clear text passwords). Is it intended to cover both? o "3.5 data integrity" states requirements (again: protocol or ops?), but then concludes with TLS "MAY" "if the policy of the server operator requires message integrity" to end with a normative language requirement for the protocol: "RDAP MUST NOT preclude support for this feature in the future". I'd not know how to evaluate an specification/implementation/service against this. -Peter From shollenbeck@verisign.com Wed Apr 24 04:35: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 A154521F8F08 for ; Wed, 24 Apr 2013 04:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.501, 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 Npv-BbOaAdPr for ; Wed, 24 Apr 2013 04:35:01 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7682321F8F12 for ; Wed, 24 Apr 2013 04:34:58 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUXfDYswkrTNP6L+HGiDh8OnZxWwXQ8la@postini.com; Wed, 24 Apr 2013 04:35:00 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r3OBYta0008169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Apr 2013 07:34:55 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 24 Apr 2013 07:34:54 -0400 From: "Hollenbeck, Scott" To: Peter Koch , IETF WEIRDS WG Thread-Topic: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec Thread-Index: AQHOQMnOsuM2cUeRnECY8g22/kEri5jlNHxg Date: Wed, 24 Apr 2013 11:34:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130424085754.GJ1402@x28.adm.denic.de> In-Reply-To: <20130424085754.GJ1402@x28.adm.denic.de> 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] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 11:35:02 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Peter Koch > Sent: Wednesday, April 24, 2013 4:58 AM > To: IETF WEIRDS WG > Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap- > sec >=20 > On Fri, Apr 12, 2013 at 10:51:21AM -0700, Murray S. Kucherawy wrote: >=20 > > Please review and comment on the draft, even if it is only to say on > the >=20 > I have read the document and I do not believe it is ready to be sent to > the IESG. >=20 > Assuming the "Intended status: Standards Track" reflects current > intentions, > I fail to recognize the protocol specifications in the draft. While > section two > refers to RFC 2119 wording, the draft relies upon "REQUIREMENT", > "OPTION" > and "APPROACH" or even "POSSIBLE APPROACH". The first two frame > mandatory or > optional requirements (so they address properties of the protocol > rather than the > implementation, in which case the normative language semantics are > shifted). > The latter I am not sure how to interpret. What nature is an "APPROACH" > compared > to a suggestion (noting well the ambiguity of strength in that word, > too). > Who is the addressee for this? Is it the implementer or the operator? I'll leave the intended status and protocol vs. ops meta questions for Murr= ay and Olaf. No, the draft does not rely upon "REQUIREMENT", "OPTION", and "APPROACH". T= hose words have no normative meaning. If that's somehow confusing I can use= "Requirement", "Option", and "Approach" (modulo elimination of some of the= se as discussed in a thread to address Murray's comments). I used upper cas= e only to emphasize those areas of text. The "approach" text is intended to describe a way to meet the requirement. = The guidance presented is intended for both implementers and operators as a= ppropriate. > On specific security "services": >=20 > o "3.3 availability" is clearly operational guidance rather than a > protocol spec True. Operational guidance is often included in protocol specifications. > o "3.4 data confidentiality" mentions data but mostly talks about > protecting > the credentials (avoid clear text passwords). Is it intended to > cover both? It's intended to address all known requirements for "data confidentiality" = as defined in RFC 4949. The only requirement I could identify is the one to= protect credentials, which qualify as "data". > o "3.5 data integrity" states requirements (again: protocol or ops?), > but then > concludes with TLS "MAY" "if the policy of the server operator > requires message > integrity" to end with a normative language requirement for the > protocol: > "RDAP MUST NOT preclude support for this feature in the future". I'd > not know > how to evaluate an specification/implementation/service against this. Agreed, "MUST NOT preclude support for this feature in the future" isn't so= mething that can be addressed by an implementer. It's a requirement for spe= cification writers. How such guidance is provided is another question I'll = defer to Murray and Olaf. Scott From sm@resistor.net Wed Apr 24 07:12: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 3754621F931E for ; Wed, 24 Apr 2013 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtKAUPippKfz for ; Wed, 24 Apr 2013 07:12:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEBE21F930C for ; Wed, 24 Apr 2013 07:12:18 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OECDxt028854; Wed, 24 Apr 2013 07:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366812738; bh=id9czXp43wBbq93Uu/tchUBuMB7iBQou2u9xy+cn058=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Md/KkVldjBEtKYqbA18cKN59v7Wbajs0bhNLcOMtDybXtFP9liMeH4YGtyos4S/NZ sjWgxYSzoSnmQqnqiSncO3i5CDIps0MsQrVY/PryKM7L8glFmq+TSDmZl8Ar2QcHil lPVcPABR/vlQThypu98uZ9o575INd5cgpkOOIE8I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366812738; i=@resistor.net; bh=id9czXp43wBbq93Uu/tchUBuMB7iBQou2u9xy+cn058=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FnuLtqbR8/q95hOT76IP0qRUpF2miYTHT9NUBfV+YyqcZcLch6IL0AZn6DJRIi7C/ vdX9+Qf1g7ysiJlIcBpJVYzBO+2k8lDJ7YmxzGgKhtIzhlihrR3eraRYJ64dpiePkt PksUNHkZ482iNj524jrn4DHQrQaA1BfjC4HECNTM= Message-Id: <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 07:10:11 -0700 To: Olaf Kolkman From: SM In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:12:19 -0000 Hi Olaf, At 07:28 23-04-2013, Olaf Kolkman wrote: >2. Media Type > >http://tools.ietf.org/html/rfc4288#section-5.1 calls for community >review by sending a mail to ietf-types@iana.org >Has that happened? (A quick search in the archive did not return a >hit.) (Am I understanding the RFC4288 requirement correctly) See RFC 6838 for the registration procedure. Regards, -sm From edainow@afilias.info Wed Apr 24 10:06:23 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1699D21F9604 for ; Wed, 24 Apr 2013 10:06:23 -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 aNVKO2qYXAtG for ; Wed, 24 Apr 2013 10:06:22 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 855FA21F9413 for ; Wed, 24 Apr 2013 10:06:22 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UV39B-0006sf-5B for weirds@ietf.org; Wed, 24 Apr 2013 17:06:21 +0000 Received: from mail-oa0-f70.google.com ([209.85.219.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UV39B-0002HW-4u for weirds@ietf.org; Wed, 24 Apr 2013 17:06:21 +0000 Received: by mail-oa0-f70.google.com with SMTP id n9so12583597oag.5 for ; Wed, 24 Apr 2013 10:06:16 -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=Jz5QWFNXInngLuJ598wV+Ei1AQIa1y14ZHjCVRePseA=; b=pc9IB6vdujvlpSHbUrI9qu6eQ2u6UEe5zHSbx5jKXNjQ6lxJKB2RcRasuyncYGPB6e 5Th9DYnG9k6TPptXVD7b2SBl1ZbyHA/+YsnwagwYhtAZfck8z11fmSplhQrcXIA0nSGZ EvxlRrewCBn47e7tmbEf10dbpUCaHWfmoWq+ICzXb3I4fyz1QXLGCKVvTlP2YgX2wp8J wBf02XdyZ4YeKKNW0ivLhjomjDtVkL6I9lymfkQIQ42KV12JKHl/4MeI1QgXCabSXLPt RtBSQCJEoJwBxrkZIgtn3LLphifrrP/pmCRnv2xBsdIM12b+LSyhxBqip6JT3ac/LVjJ VU6Q== X-Received: by 10.60.42.104 with SMTP id n8mr14770696oel.94.1366823175969; Wed, 24 Apr 2013 10:06:15 -0700 (PDT) X-Received: by 10.60.42.104 with SMTP id n8mr14770693oel.94.1366823175897; Wed, 24 Apr 2013 10:06:15 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id n1sm1469958obc.10.2013.04.24.10.06.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 10:06:14 -0700 (PDT) Message-ID: <517810FF.9080406@afilias.info> Date: Wed, 24 Apr 2013 13:06:07 -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: "Hollenbeck, Scott" References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlAU/NnOSjfxAla67oLrbVsPwzYMHNB+hryYJ1XCnU/6HmnF6cyYrm2tdOH10ObivUyorwIjSyJ17hh4LNblndsY27KEfbow5il5BMKZ0rE86I/704zb7J+aMH2EOhuXZxNUcJf Cc: Peter Koch , IETF WEIRDS WG Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 17:06:23 -0000 On 4/24/2013 7:34 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Peter Koch >> Sent: Wednesday, April 24, 2013 4:58 AM >> To: IETF WEIRDS WG >> Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap- >> sec >> >> ... >> o "3.4 data confidentiality" mentions data but mostly talks about >> protecting >> the credentials (avoid clear text passwords). Is it intended to >> cover both? > It's intended to address all known requirements for "data confidentiality" as defined in RFC 4949. The only requirement I could identify is the one to protect credentials, which qualify as "data". > Some of the response data may be confidential. Isn't this the main reason for using authentication, for special classes of users such as law enforcement? Any non-public data that requires authentication should only be returned with protection for confidentiality. -Ernie From peter@denic.de Wed Apr 24 10:19: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 A082D21F9684 for ; Wed, 24 Apr 2013 10:19: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 cwljiwvMAhFN for ; Wed, 24 Apr 2013 10:19:03 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id CE17321F9680 for ; Wed, 24 Apr 2013 10:19:02 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1UV3LS-0000Zy-0U; Wed, 24 Apr 2013 19:19:02 +0200 Received: from localhost by x27.adm.denic.de with local id 1UV3LR-0003dV-TG; Wed, 24 Apr 2013 19:19:01 +0200 Date: Wed, 24 Apr 2013 19:19:01 +0200 From: Peter Koch To: IETF WEIRDS WG Message-ID: <20130424171901.GP1402@x28.adm.denic.de> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 17:19:03 -0000 Scott, thanks for your instant reply. On Wed, Apr 24, 2013 at 11:34:53AM +0000, Hollenbeck, Scott wrote: > > Who is the addressee for this? Is it the implementer or the operator? > > I'll leave the intended status and protocol vs. ops meta questions for Murray and Olaf. fair enough. > No, the draft does not rely upon "REQUIREMENT", "OPTION", and "APPROACH". Those words have no normative meaning. If that's somehow confusing I can use "Requirement", "Option", and "Approach" (modulo elimination of some of these as discussed in a thread to address Murray's comments). I used upper case only to emphasize those areas of text. At least that would eliminate my confusion regarding the normative (or not so) nature of those terms. > The "approach" text is intended to describe a way to meet the requirement. The guidance presented is intended for both implementers and operators as appropriate. This, however, I believe would benefit from an introduction in section 2. That said, and recognizing your first response above, I have a hard time seeing this in standards track. > > o "3.3 availability" is clearly operational guidance rather than a > > protocol spec > > True. Operational guidance is often included in protocol specifications. That is correct, but the use of normative language could be reduced a bit. ``A thorough reading of RFC 4732 [RFC4732] is RECOMMENDED'' is one such case. By the way, RFC 4732 is Informational and (rightfully, given the above) classified as normative reference. That's a downref. > > o "3.4 data confidentiality" mentions data but mostly talks about > > protecting > > the credentials (avoid clear text passwords). Is it intended to > > cover both? > > It's intended to address all known requirements for "data confidentiality" as defined in RFC 4949. The only requirement I could identify is the one to protect credentials, which qualify as "data". Agreed, in an abstract sense. What I was trying to highlight is that the "RDAP" distinguishes between credentials and data (objects) and that the document might benefit from a more explicit explanation which of those (or even both) is covered. -Peter From superuser@gmail.com Wed Apr 24 10:48: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 6809921F9080 for ; Wed, 24 Apr 2013 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 xVhE5zJlYLUv for ; Wed, 24 Apr 2013 10:48:35 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA021F8FA4 for ; Wed, 24 Apr 2013 10:48:34 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k13so941458wgh.31 for ; Wed, 24 Apr 2013 10:48:29 -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=GWkk4lCtb+BzYFnBfYp7sTd4oreRRv9HJ4AeIYVjC6c=; b=LukKfJI+KqcXksCo5gbIgjNiyxnIyvd00gn2C7hxq47LQ9uw0CdkKXOZWLPERPtfl3 ce4s8+oIXbnyt297BG/EErVmk/xJ9ULsmwW9xRSvzKa/jSXtV6tssbqe4fGKGhhJEa87 oa7MlvtUIK8DXnAqKFCa3wWoLLrpxFwVXiaX6EAShb6Si+hjEWMbvQhGKYEy90a/m2Bf FNXoGjNUZdcSNtogfM1bFRPgyp+yb9odahGME01We0jnkcgf7zGaWIJcAD1apLfLpwmR 0H/RxQclwm+28Lj2gU86DkApk9ygEjDINFTKm1Hh/y5XuIkf+4IF0gXRj5UXUnAHmTd4 kvuA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr70409877wjb.15.1366825709763; Wed, 24 Apr 2013 10:48:29 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 10:48:29 -0700 (PDT) In-Reply-To: <20130424171901.GP1402@x28.adm.denic.de> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> Date: Wed, 24 Apr 2013 10:48:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Peter Koch Content-Type: multipart/alternative; boundary=089e010d8574e6825804db1ee812 Cc: IETF WEIRDS WG Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 17:48:36 -0000 --089e010d8574e6825804db1ee812 Content-Type: text/plain; charset=ISO-8859-1 Hey Peter, On Wed, Apr 24, 2013 at 10:19 AM, Peter Koch wrote: > On Wed, Apr 24, 2013 at 11:34:53AM +0000, Hollenbeck, Scott wrote: > > > > Who is the addressee for this? Is it the implementer or the operator? > > > > I'll leave the intended status and protocol vs. ops meta questions for > Murray and Olaf. > > fair enough. > I'm consulting with our ADs on this question now. I'll get back to the WG with the result of that inquiry. > > > o "3.3 availability" is clearly operational guidance rather than a > > > protocol spec > > > > True. Operational guidance is often included in protocol specifications. > > That is correct, but the use of normative language could be reduced a bit. > ``A thorough reading of RFC 4732 [RFC4732] is RECOMMENDED'' is one such > case. > By the way, RFC 4732 is Informational and (rightfully, given the above) > classified as normative reference. That's a downref. > Yes. The shepherd writeup already calls out this downref, as required. -MSK --089e010d8574e6825804db1ee812 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Peter,

On Wed, Apr 24, 2013 at 10:19 AM, Peter = Koch <pk@denic.de> wrote:
On Wed, Apr 24, 2013 at 11:34:53AM +0000, Ho= llenbeck, Scott wrote:

> > Who is the addressee for this? Is it the implementer or the opera= tor?
>
> I'll leave the intended status and protocol vs. ops meta questions= for Murray and Olaf.

fair enough.

I'm consulting w= ith our ADs on this question now.=A0 I'll get back to the WG with the r= esult of that inquiry.
=A0
> > o "3.3 availability" is clearly opera= tional guidance rather than a
> > protocol spec
>
> True. Operational guidance is often included in protocol specification= s.

That is correct, but the use of normative language could be reduced a= bit.
``A thorough reading of RFC 4732 [RFC4732] is RECOMMENDED'' is one = such case.
By the way, RFC 4732 is Informational and (rightfully, given the above)
classified as normative reference. =A0That's a downref.

Yes.=A0 The shepherd writeup already calls out this do= wnref, as required.
=A0
-MSK

--089e010d8574e6825804db1ee812-- From superuser@gmail.com Wed Apr 24 12:16: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 49E6A21F937D for ; Wed, 24 Apr 2013 12:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 KB7qPlUnIJdQ for ; Wed, 24 Apr 2013 12:16:41 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4000621F9376 for ; Wed, 24 Apr 2013 12:16:41 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1019343wgh.14 for ; Wed, 24 Apr 2013 12:16:40 -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=ZB/cfDqeQTDTP908e/HK7VtszZrW7a9jPmwuoVA3r80=; b=qQROGrRP4D5hQT8Vxs/uQbt4Ja9Mxjw2oQG+AFOPLRq/XSF3DK+DK/kP4GJ1nE0y4v LVbL33ocZ85mazSjICT9CtdZovMj/h9sQ/ky+yO0KGbKKQRgcKBN1M7JVJ5nRkSJxoKO Q/YAhQh0RrMQnoQ7xySobHvX1601IZeq87v4bkxYL5O5KdNhPQH1gtlwc5lAJIxf6btk 9MlzdnwHldgiy6Mxi0IV2dovadKwcMXK3evxHcDUHsDVXU8YVPvUhjFJc2/ubJfPi30i RvCZKWoGFVJ44XER4FWb6+o2lNaqwC+EhbnhEwe9VGRmntmt+C/YElZvsDf9dL5ha8wj 4xmw== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr47464248wix.14.1366831000407; Wed, 24 Apr 2013 12:16:40 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 12:16:39 -0700 (PDT) In-Reply-To: References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> Date: Wed, 24 Apr 2013 12:16:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Peter Koch Content-Type: multipart/alternative; boundary=f46d043c062e3f572404db2024e2 Cc: IETF WEIRDS WG Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 19:16:42 -0000 --f46d043c062e3f572404db2024e2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 10:48 AM, Murray S. Kucherawy wrote: > > I'll leave the intended status and protocol vs. ops meta questions for >> Murray and Olaf. >> >> fair enough. >> > > I'm consulting with our ADs on this question now. I'll get back to the WG > with the result of that inquiry. > I talked to Pete about this. He thinks this work qualifies as an Applicability Statement since it explains how to achieve certain capabilities when using RDAP that are important to RDAP clients and servers but are not inherent parts of RDAP. Accordingly, Proposed Standard is the correct status to request. However, he did highlight that there's a bit of work we need to do here to clarify some of the messages the document is giving. For example, as Peter Koch pointed out, the APPROACH stuff was a little confusing to the eye for people that haven't been tracking it all along, and he asked some questions about our use of MUST in conjunction with them. Pete suggests a few things: a) add to Section 2 definitions of how REQUIREMENT, APPROACH and POSSIBLE APPROACH are used in later sections; I took them to mean "Given these requirements, here's one or more ways to achieve them", so some prose to that effect would suffice b) saying "REQUIREMENT: RDAP MUST include an authentication framework", for example, is technically incorrect because the authentication framework is clearly part of HTTP and not part of RDAP, so we should be similarly clear that the requirement is on the chosen transport mechanism, not on RDAP itself c) REQUIREMENT and MUST appear to be redundant d) APPROACH and MUST appear to conflict I note that all of this is stylistic stuff; the procedural and substantive content issues all seem to be in order. -MSK --f46d043c062e3f572404db2024e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 10:48 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
=
> I'll leave the intended status and protocol vs. ops meta questions= for Murray and Olaf.

fair enough.

I'm consul= ting with our ADs on this question now.=A0 I'll get back to the WG with= the result of that inquiry.

I talked to Pete about this.=A0 He thinks this work qualifie= s as an Applicability Statement since it explains how to achieve certain ca= pabilities when using RDAP that are important to RDAP clients and servers b= ut are not inherent parts of RDAP.=A0 Accordingly, Proposed Standard is the= correct status to request.

However, he did highlight that there's a bit of work we = need to do here to clarify some of the messages the document is giving.=A0 = For example, as Peter Koch pointed out, the APPROACH stuff was a little con= fusing to the eye for people that haven't been tracking it all along, a= nd he asked some questions about our use of MUST in conjunction with them.= =A0 Pete suggests a few things:

a) add to Section 2 definitions of how REQUIREMENT, APPROACH= and POSSIBLE APPROACH are used in later sections; I took them to mean &quo= t;Given these requirements, here's one or more ways to achieve them&quo= t;, so some prose to that effect would suffice

b) saying "REQUIREMENT: RDAP MUST include an authentica= tion framework", for example, is technically incorrect because the aut= hentication framework is clearly part of HTTP and not part of RDAP, so we s= hould be similarly clear that the requirement is on the chosen transport me= chanism, not on RDAP itself

c) REQUIREMENT and MUST appear to be redundant

d) APP= ROACH and MUST appear to conflict

I note that = all of this is stylistic stuff; the procedural and substantive content issu= es all seem to be in order.

-MSK

--f46d043c062e3f572404db2024e2-- From sm@resistor.net Wed Apr 24 23:27: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 4E49A21F9367 for ; Wed, 24 Apr 2013 23:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+fg0aRQQAeH for ; Wed, 24 Apr 2013 23:27:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB95F21F9350 for ; Wed, 24 Apr 2013 23:27:54 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P6RiI5027493; Wed, 24 Apr 2013 23:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366871269; bh=gLlHR5KuYHvGctqy6st/0Pxe1juLfN1pT9VCupqrS7s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ycl8nS6HpxnnFAKMokScvKGv2JXGLmkh+FKuuLKGETbYMIVWI4RvY2QrS+QAsayUG nf/aM8Xd9hKzaeP5jvLXSdwpQVypencTBofQMxp4DVxj1AQDYc0X6041Fok92RB/HS ByEVkZNmqeSVz9GM+OmS/SUVg0SN3QXxNh0e3Rco= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366871269; i=@resistor.net; bh=gLlHR5KuYHvGctqy6st/0Pxe1juLfN1pT9VCupqrS7s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2FhdQA22YQ/Mlc0GZJdsg31mC/NFQsY6/57B6zdsHrR61ATp3SmVjDgKWSJxD5V4X Qh2+feUVHPsIsJvJF6NoVsNrLaoMyBsRX0i74AyEDhVIERSXbo5/YckhmDKB/9vuOX ugB4XqeXYixQpvzlNIotC+qmOgIOI4zG66PuzVzM= Message-Id: <6.2.5.6.2.20130424225820.0a56fe50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 23:25:55 -0700 To: weirds@ietf.org From: SM In-Reply-To: <20130424085754.GJ1402@x28.adm.denic.de> References: <20130424085754.GJ1402@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 06:27:55 -0000 At 01:57 24-04-2013, Peter Koch wrote: >I have read the document and I do not believe it is ready to be sent >to the IESG. I read draft-ietf-weirds-rdap-sec. It's highly unusual as an intended Proposed Standard. The draft looks like a RFP instead of a specification for the Standards Track. I might be asked why it should not be on the Standards Track. Well, there is a missing normative reference to RFC 6919. :-) Regards, -sm From olaf@NLnetLabs.nl Thu Apr 25 00:22: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 B814C21F93B7 for ; Thu, 25 Apr 2013 00:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58mxqqIErGqc for ; Thu, 25 Apr 2013 00:22:53 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFFB21F93B4 for ; Thu, 25 Apr 2013 00:22:52 -0700 (PDT) Received: from [192.168.178.34] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r3P7Mjfd057847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 09:22:47 +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 r3P7Mjfd057847 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1366874571; bh=WMYmRZGgz/gnh1HPtjVpYyDdkNg1H1JDjCM8hEAa9Zo=; h=From:Subject:Date:References:To:In-Reply-To; b=nAAcZ+jU7yDiTs9ky4wJ8rJmH9j+/4JOnTAOEMRpoGIJn0JbHXZvw0JmGuYMFhR3W Ns3F6eqfPzuZ8i/P/2rKDb2P8eyXyji3nAxOEzHmDTeQgc68z9SUmMjT3gd84O1t/7 ZtZgPnN0wh1uZlArNWzG+vDf35BFYrxvUMp8KRLo= From: Olaf Kolkman Content-Type: multipart/alternative; boundary="Apple-Mail=_D9E51F2B-3C5A-4F59-9C8B-376922BFB7AE" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Thu, 25 Apr 2013 09:22:45 +0200 References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> To: SM , "weirds@ietf.org Group" In-Reply-To: <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 25 Apr 2013 09:22:47 +0200 (CEST) Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 07:22:53 -0000 --Apple-Mail=_D9E51F2B-3C5A-4F59-9C8B-376922BFB7AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2013, at 4:10 PM, SM wrote: > At 07:28 23-04-2013, Olaf Kolkman wrote: >> 2. Media Type >>=20 >> http://tools.ietf.org/html/rfc4288#section-5.1 calls for community = review by sending a mail to ietf-types@iana.org >> Has that happened? (A quick search in the archive did not return a = hit.) (Am I understanding the RFC4288 requirement correctly) >=20 > See RFC 6838 for the registration procedure. Yep.. that reads: "Notice of a potential media type registration in the standards tre = SHOULD be sent to the media-types@iana.org mailing list for review." So the question still stands albeit with a different maillists address: = Has that happened? Can the editors confirm that they have _not_ done so, = because then I will send a mail to the mailinglist, I do not think that = will block forward progress because that review can take place while the = IESG is processing the doc. --Olaf --Apple-Mail=_D9E51F2B-3C5A-4F59-9C8B-376922BFB7AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sm@resistor.net> wrote:

At 07:28 23-04-2013, Olaf = Kolkman wrote:
http://tools.ietf.= org/html/rfc4288#section-5.1 calls for community review = by sending a mail to ietf-types@iana.org
Has that = happened? (A quick search in the archive did not return a hit.) (Am I = understanding the RFC4288 requirement correctly)

Notice of a potential media type = registration in the standards tre SHOULD be sent to the media-types@iana.org mailing = list for review."

So the question still = stands albeit with a different maillists address: Has that = happened? Can the editors confirm that they have _not_ done so, = because then I will send a mail to the mailinglist, I do not think that = will block forward progress because that review can take place while the = IESG is processing the = doc.


--Olaf

= --Apple-Mail=_D9E51F2B-3C5A-4F59-9C8B-376922BFB7AE-- From peter@denic.de Thu Apr 25 00:36:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6508721F93A3 for ; Thu, 25 Apr 2013 00:36: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 B4+vDJTWmd4Y for ; Thu, 25 Apr 2013 00:36:52 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id C981C21F91D9 for ; Thu, 25 Apr 2013 00:36:51 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1UVGja-0006Qv-Qd; Thu, 25 Apr 2013 09:36:50 +0200 Received: from localhost by x27.adm.denic.de with local id 1UVGja-0003MG-NI; Thu, 25 Apr 2013 09:36:50 +0200 Date: Thu, 25 Apr 2013 09:36:50 +0200 From: Peter Koch To: IETF WEIRDS WG Message-ID: <20130425073650.GS1402@x28.adm.denic.de> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 07:36:52 -0000 On Wed, Apr 24, 2013 at 12:16:39PM -0700, Murray S. Kucherawy wrote: > I talked to Pete about this. He thinks this work qualifies as an > Applicability Statement since it explains how to achieve certain > capabilities when using RDAP that are important to RDAP clients and servers > but are not inherent parts of RDAP. Accordingly, Proposed Standard is the > correct status to request. I truly admire Pete for opening this rarely explored path. Even as an AS (as per RFC 2026, 3.2) the document needs more work. There is a mix of requirements for the protocol itself (not appropriate for an AS), requirements for implementers and guidance to operators, some of which lacks clarity or strength that I'd at least expect in an AS. > a) add to Section 2 definitions of how REQUIREMENT, APPROACH and POSSIBLE > APPROACH are used in later sections; I took them to mean "Given these > requirements, here's one or more ways to achieve them", so some prose to > that effect would suffice agree with the former, not necessarily with the latter. > I note that all of this is stylistic stuff; the procedural and substantive > content issues all seem to be in order. The strength and normative-ness of the statements expressed isn't a matter of style. I have serious concerns regarding the clarity of the specification (or, say applicability statement) when it comes to either compliance or interoperability issues. What I expect is protocol, what I think I'm seeing is a product or service description. -Peter From sm@resistor.net Thu Apr 25 00: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 B798221F8618 for ; Thu, 25 Apr 2013 00:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18DG+wfBt3bj for ; Thu, 25 Apr 2013 00:54:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53D21F847B for ; Thu, 25 Apr 2013 00:54:11 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P7s5O5011141; Thu, 25 Apr 2013 00:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366876450; bh=j3mdfvme3Ds5kTPJWxsrgdUJWNjcodnYYKJCdZ4tGtM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nP+G3NIGfFiK0GSr4czU1SwoX8H/7bgEx42UVfKfAKJwNkSOMxvKMc8kc9l6ODA25 w9xbcPTKctlUAOIxpKo28FrU7BGTZ9QspXNvDLG1X9KRnAygTcMXVroLO6VLFBcHq5 l9gc+vvN6oHh8lP4Gq4xaL89S2+EiEe7rlq9e1Yw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366876450; i=@resistor.net; bh=j3mdfvme3Ds5kTPJWxsrgdUJWNjcodnYYKJCdZ4tGtM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pUDVPS7/fRsEvY7eXOFR02IUb2sHG6lsvK9eqP1SjyeIjEUIT2nuRKNKLUKGdZSKg HRUE7SfYzY/60b0W8Hj5dptMgnrK0bM6VV1Ugs71qJDKPjNU3loeiUO/r1Kgnd3sFa uBWmby4FBeVivNSVGsFAZ3xBQCrVkPQjkXQWzMt8= Message-Id: <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 00:49:40 -0700 To: Olaf Kolkman From: SM In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 07:54:11 -0000 Hi Olaf, At 00:22 25-04-2013, Olaf Kolkman wrote: >So the question still stands albeit with a different maillists >address: Has that happened? Can the editors confirm that they have >_not_ done so, because then I will send That has not happened. BTW, the "Security considerations: n/a" might be a problem. Regards, -sm From olaf@NLnetLabs.nl Thu Apr 25 01:01: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 C969A21F93EF for ; Thu, 25 Apr 2013 01:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK9LQgjivEJd for ; Thu, 25 Apr 2013 01:01:32 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA51F21F93D8 for ; Thu, 25 Apr 2013 01:01:31 -0700 (PDT) Received: from [192.168.178.34] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r3P81ROH035440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 10:01:28 +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 r3P81ROH035440 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1366876890; bh=E3ApmLtBMCEnYzR2+vnqiSE+qFIkttXHX11N9+icoIg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Xv/8xDny9jx9W6/BlMZ4TGm7Zvrdo1L9/sVI+1BCt/NG6xhJfbkNU7Cxjzk1V43xc 6Y7+BbsJPnOji0aMT4hNoL5o4SSLP4jIAU25kQtJRt7MLJO774cO59J8DEeOti3SvG m5OLMW3uLi+n5hw5OvJCatiQ/1iED8OTz2z36jQA= Content-Type: multipart/alternative; boundary="Apple-Mail=_693E8D8C-CBB7-4693-BFA3-77A00E226469" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> Date: Thu, 25 Apr 2013 10:01:25 +0200 Message-Id: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> To: SM X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 25 Apr 2013 10:01:29 +0200 (CEST) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 08:01:32 -0000 --Apple-Mail=_693E8D8C-CBB7-4693-BFA3-77A00E226469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 25, 2013, at 9:49 AM, SM wrote: > That has not happened. BTW, the "Security considerations: n/a" might = be a problem. Are you looking at version 04? I think this is a reasonable security consideration? 7. Security Considerations This document does not pose strong security requirements to the RDAP protocol. However, it does not restrict against the use of security mechanisms offered by the HTTP protocol. This document made recommendations for server implementations against denial-of-service (Section 5.5) and interoperability with existing security mechanism in HTTP clients (Section 5.6). Additional security considerations to the RDAP protocol will be covered in future RFCs documenting specific security mechanisms and schemes. --Apple-Mail=_693E8D8C-CBB7-4693-BFA3-77A00E226469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sm@resistor.net> wrote:

That has not happened. =  BTW, the "Security considerations: n/a" might be a = problem.
Are you looking at version = 04?

I think this is a reasonable security = consideration?

7.  Security =
Considerations


   This document does not pose strong security requirements to the RDAP
   protocol.  However, it does not restrict against the use of security
   mechanisms offered by the HTTP protocol.

   This document made recommendations for server implementations against
   denial-of-service (Section 5.5) and interoperability with existing
   security mechanism in HTTP clients (Section 5.6).

   Additional security considerations to the RDAP protocol will be
   covered in future RFCs documenting specific security mechanisms and
   schemes.

= --Apple-Mail=_693E8D8C-CBB7-4693-BFA3-77A00E226469-- From sm@resistor.net Thu Apr 25 02:00: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 A755621F86DE for ; Thu, 25 Apr 2013 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 3-o-QzQsRoDU for ; Thu, 25 Apr 2013 02:00:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF90721F8613 for ; Thu, 25 Apr 2013 02:00:56 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P90krZ011865; Thu, 25 Apr 2013 02:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366880455; bh=971O9xfIB6UH/Z13ch/L/a0LDo3RkMuHdxOP+XKMPvc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vdzL4Lsjr9QpyP55La17MFEAbgio/g8OXs33rYw087F1meUDTSZmTqaMYxmqAzg7c Zbwyq7qJiVK3sWnvMiHUrv+qOWMLfo4jFO4MJK2zWi/niHGF+AaEpE52JDCDACIp1J TErKWQJsdIEXIs1kbuq7dFYnxxwZcEtL8MgZ1r9g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366880455; i=@resistor.net; bh=971O9xfIB6UH/Z13ch/L/a0LDo3RkMuHdxOP+XKMPvc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dFYAPmbxRbGlAjr2U7D4u+A78v2jHt9daYtngYw6DvabnjdVl2hOVGSnCzhFKW3Fd fhmTE+OWsulOJufkAjV075QpZ0nuxdkvraSE7TF9Kc2xn0xSwIwLBgxPBWg3KTPknt sOpN1DudcvGC3ceuXyKTUJjRa8KFIVbtCfyKOhKI= Message-Id: <6.2.5.6.2.20130425014632.0b9aef70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 01:57:22 -0700 To: Olaf Kolkman From: SM In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 09:00:57 -0000 Hi Olaf, At 01:01 25-04-2013, Olaf Kolkman wrote: >Are you looking at version 04? Yes. >I think this is a reasonable security consideration? With all due respect, no. Here is the request: "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 suggest looking at each of the above fields and see whether the entries are according to the guidance from the relevant RFC. BTW, the references should be split. Regards, -sm From sm@resistor.net Thu Apr 25 02:00: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 BB66321F8613 for ; Thu, 25 Apr 2013 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKUkvMjuq7WQ for ; Thu, 25 Apr 2013 02:00:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF92421F8D2E for ; Thu, 25 Apr 2013 02:00:56 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P90krX011865; Thu, 25 Apr 2013 02:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366880451; bh=NTqPtokqWd4kRb2MShgPnKDK55kWywwtJAoCk84Tjw0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uM8rE1sk+SwsaurKKCiMrZm5pmtsu7NRsNG9mStWyfid7b4NVyZluUxdiUXdH/c7+ /QJARfN6/RVyij/tagGyqtwvLGH8cJt1bkwod75J/My6/mYdAo+NtUITqkoMRSj0wp t6lT9DMn8ceUfxfbmmG8Fqs9S1lWi7CCLIkgsI1E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366880451; i=@resistor.net; bh=NTqPtokqWd4kRb2MShgPnKDK55kWywwtJAoCk84Tjw0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PVaQn75LIyvfoamj6jqPxyAtS3hkD3XeuVUruL/NaCCuakRGV59zLh/T1E59q2uHg FyxGAsvwvkudZtvRkc48peEyRzqTq17uB/w+xU6pNKJnM6MrZvHPrhONtgzM/yvJcG tW7mn/QDM+6M128d0K2hx/tLVIT0Wm83of6O9Vek= Message-Id: <6.2.5.6.2.20130425005421.0a77fef0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 01:35:03 -0700 To: weirds@ietf.org From: SM In-Reply-To: <20130425073650.GS1402@x28.adm.denic.de> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> <20130425073650.GS1402@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 09:00:57 -0000 At 00:36 25-04-2013, Peter Koch wrote: >The strength and normative-ness of the statements expressed isn't a matter >of style. I have serious concerns regarding the clarity of the specification Agreed. 'If the "basic" scheme is used another protocol (such as HTTP Over TLS [RFC2818]) MUST be used to protect the client's credentials from disclosure while in transit (see Section 3.4).' I do not understand this requirement as it basically says that I can pick another protocol (which is unspecified) and things should work fine. "The data confidentiality methods used by RDAP MUST be fully specified and available to existing HTTP clients and servers." The IETF is asking some external entity to specify data confidentiality methods for HTTP clients and servers. It sounds like the IETF is incompetent when it comes to producing specifications for HTTP servers and clients. draft-ietf-weirds-rdap-sec-02 is severely under-specified. Regards, -sm From superuser@gmail.com Thu Apr 25 07:10:18 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0821F8F28 for ; Thu, 25 Apr 2013 07:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7H2PWQ3e2Vsf for ; Thu, 25 Apr 2013 07:10:17 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8495C21F8F01 for ; Thu, 25 Apr 2013 07:10:17 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t57so738183wey.30 for ; Thu, 25 Apr 2013 07:10:16 -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=VrpelFVNTM0xAzp0P8Beyz22DsgpXZ2dyEvq9fSS4YQ=; b=IuDEGp5Iq03qFFiwRhehpvUkGU4ez/ZrMSgSxv0SEG5/VDDi0lmvYHHi2ggqaW3r1O DqyVqe4U9/HRkFgzS+oVeF/j/I2IKY16HRdAqsRRyarVzFmkBt4pIUcLTI8n69hTLXYh pvqKJ+CtFcbJ2ElUbms9DtLE4sIvM9le1gGIZi5yqudsdh87Cm+UVvTVhATMD3wtR3ST jNGWYBIkiEu2xeE/iuxZzSb3Vog/hKpmS2eQ41Qg3qjAljtY/S4M8c2y1yRLA/dLdBcW fHHXU9WZLjp4aSyO84hie6NptjqeEiUO/GsWTvint5mZBv89jHLTHIEFDxGb8prUd7mv dADA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr76098689wjb.15.1366899015500; Thu, 25 Apr 2013 07:10:15 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 07:10:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130425005421.0a77fef0@resistor.net> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> <20130425073650.GS1402@x28.adm.denic.de> <6.2.5.6.2.20130425005421.0a77fef0@resistor.net> Date: Thu, 25 Apr 2013 07:10:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=089e010d8574434ad304db2ffac0 Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 14:10:18 -0000 --089e010d8574434ad304db2ffac0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 1:35 AM, SM wrote: > 'If the "basic" scheme is used another protocol (such as > HTTP Over TLS [RFC2818]) MUST be used to protect the client's > credentials from disclosure while in transit (see Section 3.4).' > > I do not understand this requirement as it basically says that I can pick > another protocol (which is unspecified) and things should work fine. > "basic" doesn't protect credentials from being snooped. If that's important, you have to add another layer that does. Is that an incorrect thing to say? > "The data confidentiality methods used by RDAP MUST be fully specified > and available to existing HTTP clients and servers." > > The IETF is asking some external entity to specify data confidentiality > methods for HTTP clients and servers. It sounds like the IETF is > incompetent when it comes to producing specifications for HTTP servers and > clients. > That's not what this says to me. I read it as: RDAP is built atop existing data confidentiality methods rooted in HTTP. Is that inappropriate? Would you care to propose alternative text or some other solution? -MSK --089e010d8574434ad304db2ffac0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 1:35 AM, SM <= sm@resistor.net>= ; wrote:
=A0 'If the "basic" scheme is used another protocol (such as<= br> =A0 =A0HTTP Over TLS [RFC2818]) MUST be used to protect the client's =A0 =A0credentials from disclosure while in transit (see Section 3.4).'=

I do not understand this requirement as it basically says that I can pick a= nother protocol (which is unspecified) and things should work fine.

"basic" doesn't protect credenti= als from being snooped.=A0 If that's important, you have to add another= layer that does.=A0 Is that an incorrect thing to say?
=A0
=A0 "The data confidentiality methods used by RDAP MUST be fully speci= fied
=A0 =A0and available to existing HTTP clients and servers."

The IETF is asking some external entity to specify data confidentiality met= hods for HTTP clients and servers. =A0It sounds like the IETF is incompeten= t when it comes to producing specifications for HTTP servers and clients.

That's not what this says to me.=A0 I = read it as: RDAP is built atop existing data confidentiality methods rooted= in HTTP.=A0 Is that inappropriate?

Would you care to pro= pose alternative text or some other solution?

-MSK
--089e010d8574434ad304db2ffac0-- From sm@resistor.net Thu Apr 25 07:35:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1A21F8F1F for ; Thu, 25 Apr 2013 07:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTrXei4hXylE for ; Thu, 25 Apr 2013 07:35:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A382E21F8EBE for ; Thu, 25 Apr 2013 07:35:14 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3PEZ0Q6018392; Thu, 25 Apr 2013 07:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366900505; bh=eoA8pCDIJIm9WwzWxCjM9+fhMyls+divi8H1nsBmsMA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MQjUXL3NUK8CJf2xGrakgdvVSc4n/UzaMgOzqfCXJki6acEtLqgFPE4R7KKfYY8kW Xk5p3ohq3KR92Tq+1vdBWE4hlWcqI1xQs937WMUcZm+7rkSVPFlLGByT8KauXED3OC +LYoQQeo8EFwMEinNe7uqUm9xM6H6QStreMNET9g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1366900505; i=@resistor.net; bh=eoA8pCDIJIm9WwzWxCjM9+fhMyls+divi8H1nsBmsMA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kg1f9VR0RIHGXORgEXmKMRr43NE2NR8DsShvKbpOncpJdK+nRRORRz3dxVJpwkYCi L/Tt08GB/KISggf5NCs9/SGu6FBedIelLGyP4hkcAMmM9pHDQg10wo3GD4RyWrLvc7 fcckdhAP12r3idYeG78ol5gMrztzhghxwnv+z17Y= Message-Id: <6.2.5.6.2.20130425071851.0be8b170@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 07:32:22 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> <20130425073650.GS1402@x28.adm.denic.de> <6.2.5.6.2.20130425005421.0a77fef0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch , weirds@ietf.org Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 14:35:15 -0000 Hi Murray, At 07:10 25-04-2013, Murray S. Kucherawy wrote: >"basic" doesn't protect credentials from being snooped. If that's >important, you have to add another layer that does. Is that an >incorrect thing to say? There is a MUST" in the sentence. There is usually be a good reason for having that key word. If it is not important it does not make sense to have that key word. >That's not what this says to me. I read it as: RDAP is built atop >existing data confidentiality methods rooted in HTTP. Is that inappropriate? There is also a "MUST" in the sentence. What's inappropriate in my opinion is the usage of "MUST". I read the usage of the "MUST" as: The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement. >Would you care to propose alternative text or some other solution? I suggest publishing the document as Informational as the intended status is not important to the working group. Regards, -sm From superuser@gmail.com Thu Apr 25 08:26: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 6F14921F8E6C for ; Thu, 25 Apr 2013 08:26: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, 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 LmMXfXX07kbs for ; Thu, 25 Apr 2013 08:26:11 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4934721F8D8E for ; Thu, 25 Apr 2013 08:26:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so3548844wiv.13 for ; Thu, 25 Apr 2013 08:26:08 -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=AE6qUZ2MvQXqjsW8dKLBu/tT9WrVpGwKr82t2wSoI+I=; b=H/i76J+veWnIxSdatGIBvGXjX3GaPSAt0m7HaxclmjBvxt+6+rYCavjP6eHzLaWqAz rrvLn+9k6hdAVRtAbb/7CXr1Wss9sI2IDPkU7/pNObeUHrslV67JxMIsKnvCP/EVmgtU RqCgZBTGHEV0UkHe5C2Q9wyiob6BOf3mDZwVA9TQHYV+W0czWrFTolDKBja1E32kUrZT I1Uq0qj9YCK+qfV0cpf2j5xpqhKK/AJB+/7jBUaUjrkStnHp/+fs6USzxRjZsxNN8lSY kQyASAvAPP6lrfFMVMimecbZylsIkYmHUUm4m7htVyCmTRH0XskxfduMXO61oIKQwfKt rNDA== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr34816994wib.32.1366903568468; Thu, 25 Apr 2013 08:26:08 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 08:26:08 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130425071851.0be8b170@resistor.net> References: <20130424085754.GJ1402@x28.adm.denic.de> <831693C2CDA2E849A7D7A712B24E257F2437B140@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130424171901.GP1402@x28.adm.denic.de> <20130425073650.GS1402@x28.adm.denic.de> <6.2.5.6.2.20130425005421.0a77fef0@resistor.net> <6.2.5.6.2.20130425071851.0be8b170@resistor.net> Date: Thu, 25 Apr 2013 08:26:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=f46d044306aaa4114b04db3109e6 Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-rdap-sec X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 15:26:17 -0000 --f46d044306aaa4114b04db3109e6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 7:32 AM, SM wrote: > At 07:10 25-04-2013, Murray S. Kucherawy wrote: > >> "basic" doesn't protect credentials from being snooped. If that's >> important, you have to add another layer that does. Is that an incorrect >> thing to say? >> > > There is a MUST" in the sentence. There is usually be a good reason for > having that key word. If it is not important it does not make sense to > have that key word. I've consulted with two ADs on this question and neither objected to this use. Use of RFC2119 language to describe requirements is typical in applicability statements as a way of describing what one needs to do to provide some capability that's not part of the core specification. RFC6647, for example, describes ways to apply SMTP to perform greylisting; there's normative language in there that describes the way to create a capability but not enact a protocol. > > > That's not what this says to me. I read it as: RDAP is built atop >> existing data confidentiality methods rooted in HTTP. Is that >> inappropriate? >> > > There is also a "MUST" in the sentence. What's inappropriate in my > opinion is the usage of "MUST". I read the usage of the "MUST" as: > > The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate > requirements that are needed to meet formal review criteria (e.g., > mandatory-to-implement security mechanisms), when these mechanisms > are too inconvenient for implementers to actually implement. I don't think that's a fair characterization. -MSK --f46d044306aaa4114b04db3109e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 7:32 AM, SM <= sm@resistor.net>= ; wrote:
At 07:10 25-04-2013, Murray S. Kucherawy wrote:
"basic" doesn't protect credentials from being snooped. =A0If= that's important, you have to add another layer that does. =A0Is that = an incorrect thing to say?

There is a MUST" in the sentence. =A0There is usually be a good reason= for having that key word. =A0If it is not important it does not make sense= to have that key word.

I've consulted = with two ADs on this question and neither objected to this use.=A0 Use of R= FC2119 language to describe requirements is typical in applicability statem= ents as a way of describing what one needs to do to provide some capability= that's not part of the core specification.=A0 RFC6647, for example, de= scribes ways to apply SMTP to perform greylisting; there's normative la= nguage in there that describes the way to create a capability but not enact= a protocol.
=A0


That's not what this says to me. =A0I read it as: RDAP is built atop ex= isting data confidentiality methods rooted in HTTP. =A0Is that inappropriat= e?

There is also a "MUST" in the sentence. =A0What's inappropria= te in my opinion is the usage of "MUST". =A0I read the usage of t= he "MUST" as:

=A0 =A0The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to i= ndicate
=A0 =A0requirements that are needed to meet formal review criteria (e.g., =A0 =A0mandatory-to-implement security mechanisms), when these mechanisms =A0 =A0are too inconvenient for implementers to actually implement.

I don't think that's a fair characterizati= on.

-MSK
--f46d044306aaa4114b04db3109e6-- From bje@apnic.net Thu Apr 25 17:24: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 BEF3B21F9707 for ; Thu, 25 Apr 2013 17:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+rvgD+zV+UF for ; Thu, 25 Apr 2013 17:24:38 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id A8F8D21F96DE for ; Thu, 25 Apr 2013 17:24:33 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 26 Apr 2013 10:24:30 +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; Fri, 26 Apr 2013 10:24:29 +1000 From: Byron Ellacott To: Olaf Kolkman , "weirds@ietf.org Group" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt Thread-Index: AQHOOwL7KDrVfi6RG0CugPjfiNcQnJjZkWoA//+DEYCACitfgIABjVqAgAEgf4CAAcUWgA== Date: Fri, 26 Apr 2013 00:24:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.198] Content-Type: multipart/alternative; boundary="_000_CDA005FD21922bjeapnicnet_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 00:24:38 -0000 --_000_CDA005FD21922bjeapnicnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Olaf, From: Olaf Kolkman > Date: Thursday, 25 April 2013 5:22 PM To: SM >, "weirds@ietf.org Group" > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt "Notice of a potential media type registration in the standards tre SHOULD = be sent to the media-types@iana.org mailing li= st for review." So the question still stands albeit with a different maillists address: Has= that happened? Can the editors confirm that they have _not_ done so, becau= se then I will send a mail to the mailinglist, I do not think that will blo= ck forward progress because that review can take place while the IESG is pr= ocessing the doc. I have not sent mail to IANA regarding the media type registration; I am sp= eaking only for myself, and not the other two editors. Byron --_000_CDA005FD21922bjeapnicnet_ Content-Type: text/html; charset="us-ascii" Content-ID: <954A7A0C73A2D149990600A24CBF7F02@apnic.net> Content-Transfer-Encoding: quoted-printable
Hi Olaf,

From: Olaf Kolkman <olaf@NLnetLabs.= nl>
Date: Thursday, 25 April 2013 5:22 = PM
To: SM <sm@resistor.net>, "weirds@ietf.org Group" <we= irds@ietf.org>
Subject: Re: [weirds] I-D Action: d= raft-ietf-weirds-using-http-04.txt

"Notice of a potential me= dia type registration in the standards tre SHOULD be sent to the media-types@iana.org mailing li= st for review."

So the question still stands albeit with a different maillists address= : Has that happened? Can the editors confirm that they have _not_= done so, because then I will send a mail to the mailinglist, I do not thin= k that will block forward progress because that review can take place while the IESG is processing the doc.

I have not sent mail to IANA regarding the media type registration; I = am speaking only for myself, and not the other two editors.

  Byron

--_000_CDA005FD21922bjeapnicnet_-- From bje@apnic.net Thu Apr 25 18:16:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F349E21F96D8 for ; Thu, 25 Apr 2013 18:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=0.001, 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 zZzV+is3a3gj for ; Thu, 25 Apr 2013 18:16:00 -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 D4B9E21F96B6 for ; Thu, 25 Apr 2013 18:15:59 -0700 (PDT) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 26 Apr 2013 11:12:34 +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; Fri, 26 Apr 2013 11:15:56 +1000 From: Byron Ellacott To: Olaf Kolkman , Andy Newton , Ning Kong Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt Thread-Index: AQHOOwL7KDrVfi6RG0CugPjfiNcQnJjZkWoA//+DEYCACitfgIAEgU6A Date: Fri, 26 Apr 2013 01:15:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BBFC66ABC52294EAD8C3F6049A1F68E@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 01:16:01 -0000 Hi all, On 24/04/13 12:28 AM, "Olaf Kolkman" wrote: > >On Apr 17, 2013, at 5:10 AM, Murray S. Kucherawy >wrote: > >> Nice work, everyone! >>=20 >> A few things remain in -04: >>=20 >> 1) "Appendix Appendix B" in Section 4.2. >>=20 >> 2) The "Intended usage" thing in Section 8.1 is still weird. >>=20 >> 3) The SHOULD in Section 5 seems vague to me. (a) What does it mean to >>"understand" it, exactly? (b) When would one deviate from the normative >>statement and what impact might it have on interoperability? >>=20 >> These can be fixed during/after IETF LC, so just tuck them away for >>later; no need to do a -05 first unless you feel like it. >>=20 >> -MSK, participatorially >>=20 > > >Folk, > >I am doing the shepherd write-up and I need some input: > >1. ID-NITS >there are some warnings in the idnits that I need to make sure I >understand. >http://www.ietf.org/tools/idnits/idnits > >There is no split in Normative and Informative References. I believe it >might be wise to introduce shuch split if we ever want to bump this beast >to Internet Standard maturity (without the split all references are >treated as normative and that actually makes RFC4627 a downref and make >idnits throw an error.) > >Without this split there are a few things in the write-up that I cannot >answer in a satisfying way. As a first pass at this split: Normative: RFC 2119 RFC 2616 [HTTP] RFC 3986 [URI] RFC 3987 [IRI] RFC 6585 [HTTP-response, 429] W3C.CR-cors-20130129 [Access-Control-Allow-Origin header] Informative: SAC-051 [Origin of "RDAP" terminology] RFC 4627 [JSON media type; Informational] RFC 3912 [WHOIS specification] RFC 5234 [ABNF] RFC 5890 [IDNA-2008] How does that look? Byron From hammondjohnson@hushmail.com Sat Apr 27 14:08: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 D623A21F9940 for ; Sat, 27 Apr 2013 14:08: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 NrBKw96d0ePD for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5823B21F991F for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id B33B931108 for ; Sat, 27 Apr 2013 17:55:35 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:55:35 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7649DE6736; Sat, 27 Apr 2013 17:55:35 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:55:35 -0400 To: weirds@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427175535.7649DE6736@smtp.hushmail.com> Subject: [weirds] Biggest Fake Conference in Computer Science X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:08:06 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From olaf@NLnetLabs.nl Mon Apr 29 08:21: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 B68B721F9DF9 for ; Mon, 29 Apr 2013 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxObqZ5O9BMp for ; Mon, 29 Apr 2013 08:21: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 4805E21F9DF8 for ; Mon, 29 Apr 2013 08:21:00 -0700 (PDT) Received: from dhcp-163.nlnetlabs.nl (dhcp-163.nlnetlabs.nl [213.154.224.163]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r3TFKpDm036315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Apr 2013 17:20:53 +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 r3TFKpDm036315 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1367248858; bh=hvHJ7kHd7hM1Phk+hAb/YDjKB2p1sq3gLw5kIIZTagk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cYjL0gp50N73boCCUASXlDxU8e2XjcD+jJLN3woDBxzc+te+1dLhcAblije0aF3Km BDo7zFRRljnEsO3KlOi1y6Bkv5ecjjVabYcU7D3A+lRCKQqmF6/t99FxUpCEkxMT9j MzFsP6t8rJ5KnsvYK89C1v0gNfYmj2zSHvkaHzuU= Content-Type: multipart/alternative; boundary="Apple-Mail=_54CB66AE-942E-469D-ACCD-0308A3CD9B48" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olaf Kolkman In-Reply-To: Date: Mon, 29 Apr 2013 17:20:51 +0200 Message-Id: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> To: "weirds@ietf.org Group" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Mon, 29 Apr 2013 17:20:57 +0200 (CEST) Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.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, 29 Apr 2013 15:21:04 -0000 --Apple-Mail=_54CB66AE-942E-469D-ACCD-0308A3CD9B48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The message below was the last in this thread (it is just there for = context, to demonstrate we are in limbo, and this is a top post). The status is that we need to suppply the media-type template for review = to the media-types list.=20 SM raised some concern that the media type template is underspecified = (he probably has a point) and he wanted to write some text. The template = needs a few references to the document before it can be submitted. If SM = doesn't get around it it is probably wiser for the document editors to = take a stab and spin the document. formalities formalities. --Olaf On Apr 25, 2013, at 10:01 AM, Olaf Kolkman wrote: >=20 > On Apr 25, 2013, at 9:49 AM, SM wrote: >=20 >> That has not happened. BTW, the "Security considerations: n/a" might = be a problem. > Are you looking at version 04? >=20 > I think this is a reasonable security consideration? >=20 > 7. Security Considerations >=20 > This document does not pose strong security requirements to the = RDAP > protocol. However, it does not restrict against the use of = security > mechanisms offered by the HTTP protocol. >=20 > This document made recommendations for server implementations = against > denial-of-service (Section 5.5) and interoperability with existing > security mechanism in HTTP clients (Section 5.6). >=20 > Additional security considerations to the RDAP protocol will be > covered in future RFCs documenting specific security mechanisms and > schemes. >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_54CB66AE-942E-469D-ACCD-0308A3CD9B48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii olaf@NLnetLabs.nl>= wrote:
sm@resistor.net> wrote:

That has not happened. =  BTW, the "Security considerations: n/a" might be a = problem.
Are you looking at version = 04?

I think this is a reasonable security = consideration?

7.  Security =
Considerations


   This document does not pose strong security requirements to the RDAP
   protocol.  However, it does not restrict against the use of security
   mechanisms offered by the HTTP protocol.

   This document made recommendations for server implementations against
   denial-of-service (Section 5.5) and interoperability with existing
   security mechanism in HTTP clients (Section 5.6).

   Additional security considerations to the RDAP protocol will be
   covered in future RFCs documenting specific security mechanisms and
   schemes.
=

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

= --Apple-Mail=_54CB66AE-942E-469D-ACCD-0308A3CD9B48-- From sm@resistor.net Mon Apr 29 11:48:08 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9721F9A95 for ; Mon, 29 Apr 2013 11:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Qpo9T7cPO8bm for ; Mon, 29 Apr 2013 11:48:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0D721F9A6F for ; Mon, 29 Apr 2013 11:48:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3TIm1ig012694; Mon, 29 Apr 2013 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367261286; bh=S5HCVeo5yXg3rnFLvW1Ma3/lLM99/on1K87UIPHjI4E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KoKa17fnZd14u2MTTgaMc7XZYWlJIIQnU87GdebJmkII0q1VoWc8m3EG0tcRoIRxO u44j+9gYkTzCLMNq+AmUGfEP0tfN7Gz2+sF4nECBPS0WiYTjRCQCQtLMyS33+ycMNe /hlE0iHKR/lRvEjkxbfRjoCVJVOu7pfMzFH6+JH4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1367261286; i=@resistor.net; bh=S5HCVeo5yXg3rnFLvW1Ma3/lLM99/on1K87UIPHjI4E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QmRU7NtjTwCdvwDKrFxI9xWb4v4Eo17hffzdY3Pevp7JjoWHOFDkOYJpeCjU2BtSq uRosz3w5EZnzrpX9EYaVhg38jGEk9VxcgZIVvl2qtQklTih6hnjQo6SO+dtaJiNuS0 bRrpKmSeRcd5kel4C2y3kkkXjffSxtTpqBjU4Q28= Message-Id: <6.2.5.6.2.20130429104654.0e74ca38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 10:53:14 -0700 To: Olaf Kolkman From: SM In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.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, 29 Apr 2013 18:48:08 -0000 Hi Olaf, At 08:20 29-04-2013, Olaf Kolkman wrote: >SM raised some concern that the media type template is >underspecified (he probably has a point) and he wanted to write some >text. The template needs a few references to the document before it >can be submitted. If SM doesn't get around it it is probably wiser >for the document editors to take a stab and spin the document. I did not forget. I am busy with some working group work (you may have seen the thread). If the document editors can take a stab at the text I'll review it. I can also "send text" but it's unlikely that I may be able to do it within the next few days. Regards, -sm From internet-drafts@ietf.org Mon Apr 29 12:37: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 5EDA921F9A5C; Mon, 29 Apr 2013 12:37:23 -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 f1NGUC3q9Su3; Mon, 29 Apr 2013 12:37:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB36521F9A81; Mon, 29 Apr 2013 12:37:22 -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.p4 Message-ID: <20130429193722.13995.64143.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 12:37:22 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:37:23 -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 : Security Services for the Registration Data Access Proto= col Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-03.txt Pages : 9 Date : 2013-04-29 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-sec-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Mon Apr 29 12:43: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 33AB121F9B8F for ; Mon, 29 Apr 2013 12:43: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 LY34zspGMEZO for ; Mon, 29 Apr 2013 12:43:44 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABD121F9AF0 for ; Mon, 29 Apr 2013 12:43:44 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUX7NaPE18xJXx0lgvzwBVYjmXu8FZFFH@postini.com; Mon, 29 Apr 2013 12:43:44 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 r3TJhXqK002169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Apr 2013 15:43:35 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 29 Apr 2013 15:43:32 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-03.txt Thread-Index: AQHORRECumjTNQi6QU6IX55loZW3T5jtmHlQ Date: Mon, 29 Apr 2013 19:43:31 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F2437DA79@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130429193722.13995.64143.idtracker@ietfa.amsl.com> In-Reply-To: <20130429193722.13995.64143.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-03.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:43:50 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, April 29, 2013 3:37 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-03.txt This version was produced to address comments received during WG last call.= The most significant difference is that the upper case (but not 2119-norma= tive) words REQUIREMENT, OPTION, and APPROACH have been removed to eliminat= e any possible mis-understanding of their use, and the text that used those= words has been re-written. Scott From superuser@gmail.com Mon Apr 29 14:48: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 0105F21F9B7C for ; Mon, 29 Apr 2013 14:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 8zxUKa1MiKWn for ; Mon, 29 Apr 2013 14:48:12 -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 7473121F9B63 for ; Mon, 29 Apr 2013 14:48:07 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so4163547wgh.30 for ; Mon, 29 Apr 2013 14:48:06 -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=bmtExBHSWOuSvTQNYG4YlCxeuOGOUu1Q+DkanpjN4l4=; b=rsYlJAs6nAQPuJvVF7wSr9YvCgtb/GuEiYSKApwvEGlBF5Vf46W9DBsNNkBInwuNIH 00PklHz9Fo3jU3UG2mO68Rp73yxakbji5eRlsBZcBHxsrv5Ki8wkayy6+alWg94yKk9J 7e2ITLoM9m9HbruCUcCk45o2UmuN/+iNTG6qgIGn7BSwNoWZP+2IqEXE1CyY60L2O+cI aIsvBtF9fns4ARiFuaqdQSAyyuycsQ/YgTabHxNHnniPsRfebdObuDz4tt9Y9kdFbdzl ERACgPZvDFHO3Q8L9nxkcZVVebWR5Te9eg8JswARvqcVi4bhZ+CmpXZR6/CvhfxeFKUu 3Uew== MIME-Version: 1.0 X-Received: by 10.180.92.193 with SMTP id co1mr329573wib.20.1367272086602; Mon, 29 Apr 2013 14:48:06 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 14:48:06 -0700 (PDT) In-Reply-To: References: <20130417003149.22078.69197.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130424070810.0bcc0d70@resistor.net> <6.2.5.6.2.20130425004109.0b8b3630@resistor.net> Date: Mon, 29 Apr 2013 14:48:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Olaf Kolkman Content-Type: multipart/alternative; boundary=f46d0435c02c0888dd04db86d783 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.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, 29 Apr 2013 21:48:13 -0000 --f46d0435c02c0888dd04db86d783 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 8:20 AM, Olaf Kolkman wrote: > The message below was the last in this thread (it is just there for > context, to demonstrate we are in limbo, and this is a top post). > > The status is that we need to suppply the media-type template for review > to the media-types list. > > SM raised some concern that the media type template is underspecified (he > probably has a point) and he wanted to write some text. The template needs > a few references to the document before it can be submitted. If SM doesn't > get around it it is probably wiser for the document editors to take a stab > and spin the document. > > formalities formalities. > > --Olaf > > > > > On Apr 25, 2013, at 10:01 AM, Olaf Kolkman wrote: > > > On Apr 25, 2013, at 9:49 AM, SM wrote: > > That has not happened. BTW, the "Security considerations: n/a" might be a > problem. > > Are you looking at version 04? > > I think this is a reasonable security consideration? > > 7 . Security Considerations > > This document does not pose strong security requirements to the RDAP > protocol. However, it does not restrict against the use of security > mechanisms offered by the HTTP protocol. > > This document made recommendations for server implementations against > denial-of-service (Section 5.5 ) and interoperability with existing > security mechanism in HTTP clients (Section 5.6 ). > > Additional security considerations to the RDAP protocol will be > covered in future RFCs documenting specific security mechanisms and > schemes. > > Olaf's the shepherd for this one, so speaking only as myself here, I think this is fine. I also think it's safe to add the reference to the rdap-sec document since it looks like these two are going to go to the IESG at approximately the same time. That puts a little more "meat" in this section as it thus points to something more concrete. To the question of media type registration, RFC6838 says early review by emailing to IANA is "strongly encouraged". I suggest the authors send the registration request to media-types@iana.org now, give them the context and ask for review of it so that the result can be included in Olaf's writeup. -MSK, participatin' --f46d0435c02c0888dd04db86d783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 8:20 AM, Olaf Kolkman <olaf@nlnet= labs.nl> wrote:
The mess= age below was the last in this thread (it is just there for context, to dem= onstrate we are in limbo, and this is a top post).

The status is that we need to suppply the media-type templat= e for review to the media-types list.=A0

SM raised= some concern that the media type template is underspecified (he probably h= as a point) and he wanted to write some text. The template needs a few refe= rences to the document before it can be submitted. If SM doesn't get ar= ound it it is probably wiser for the document editors to take a stab and sp= in the document.

formalities formalities.

--Olaf

<= br>


= On Apr 25, 2013, at 10:01 AM, Olaf Kolkman <olaf@NLnetLabs.nl> wrote:


On Apr 25, 2013, at 9:49 AM, SM <= ;sm@resistor.net&g= t; wrote:

That has not happened. =A0BTW, the "Security consideration= s: n/a" might be a problem.
Are you looking at version 04?

I think this is a r= easonable security consideration?


7.  Security Considerations


   This document does not pose strong security requirements to the RDAP
   protocol.  However, it does not restrict against the use of security
   mechanisms offered by the HTTP protocol.

   This document made recommendations for server implementations against
   denial-of-service (Section 5.5) and intero=
perability with existing
   security mechanism in HTTP clients (Section 5.=
6).

   Additional security considerations to the RDAP protocol will be
   covered in future RFCs documenting specific security mechanisms and
   schemes.
Olaf's the shepherd for this one, so speaking only as my= self here, I think this is fine.=A0 I also think it's safe to add the r= eference to the rdap-sec document since it looks like these two are going t= o go to the IESG at approximately the same time.=A0 That puts a little more= "meat" in this section as it thus points to something more concr= ete.

To the question of media type registration, RFC6838 says ear= ly review by emailing to IANA is "strongly encouraged".=A0 I sugg= est the authors send the registration request to media-types@iana.org now, give them the context and ask f= or review of it so that the result can be included in Olaf's writeup.

-MSK, participatin'
--f46d0435c02c0888dd04db86d783-- From superuser@gmail.com Mon Apr 29 20:09: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 A2BD121F9BF1 for ; Mon, 29 Apr 2013 20:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 urQW79siZuMI for ; Mon, 29 Apr 2013 20:09:24 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0380221F9BDF for ; Mon, 29 Apr 2013 20:09:23 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z53so46294wey.15 for ; Mon, 29 Apr 2013 20:09:23 -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=OAjehUhZMzlQg1w8B02+AtUYDrvfsTljo18i/kgAQqg=; b=TiOBBKaYRpMPq++63Lv6ivQFI9vMKDWdhQLcaJ0M1tvtnrQpXpSu7GWLWjxKh8+maZ jvjxf90P6OBRDLpRQzpGtAKsP5Zp91Ip12WcNg7rkFbDO9HGOjrkkog+NePjeVTixyce qhbatA66g1D/O0a6QxIHxo3WJoy1by4Pcm76K3u04PyZOno6+yPCYDfx+FeMQeU9corU XDPZKQu9Gk+c69GyV0uRBs3tMqX9s69cJnfyB+puAXumUh5ZeAmtx52yp/v8ClckbDCy XHFi4UBDVgB49TThzLjhojzgzvXjMRV2wHY+D9GKyHBmnZhQdSGLGYwSCuKZyuS9NhqW 8x6g== MIME-Version: 1.0 X-Received: by 10.194.59.208 with SMTP id b16mr17361514wjr.15.1367291363180; Mon, 29 Apr 2013 20:09:23 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 20:09:23 -0700 (PDT) Date: Mon, 29 Apr 2013 20:09:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86de3201c72f04db8b54f7 Subject: [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: Tue, 30 Apr 2013 03:09:24 -0000 --047d7b86de3201c72f04db8b54f7 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b86de3201c72f04db8b54f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi there,

Now that we have adopted the above d= raft as a WG document, we need to add it to our charter with a projected mi= lestone.=A0 Could someone suggest a month by which we could reasonably comm= it to being done with it?

-MSK
--047d7b86de3201c72f04db8b54f7-- From andy@arin.net Tue Apr 30 07:24: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 AF5E121F99A2 for ; Tue, 30 Apr 2013 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JPm59T-Qolx for ; Tue, 30 Apr 2013 07:24:18 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id 46B8221F997D for ; Tue, 30 Apr 2013 07:24:18 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id DA26216517D; Tue, 30 Apr 2013 10:23:47 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 4008116519B; Tue, 30 Apr 2013 10:23:43 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 30 Apr 2013 10:23:33 -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, 30 Apr 2013 10:23:42 -0400 From: Andy Newton To: SM , Olaf Kolkman Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt Thread-Index: AQHOOwL9uWmYpy0P/UWF31nW0XkF1JjZ1HoAgAAqs4CACitfgIABjVmAgAEgf4CAAAeFAIAAA0mAgAAPogCAB/PGgA== Date: Tue, 30 Apr 2013 14:23:42 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E58BC00D66@CHAXCH01.corp.arin.net> In-Reply-To: <6.2.5.6.2.20130425014632.0b9aef70@resistor.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.34.130] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6A7C5F3D16FC9F45BA7F7CF6E7002349@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 14:24:29 -0000 Just taking a stab at this=8A On 4/25/13 4:57 AM, "SM" wrote: >"This specification registers the "application/rdap+json" media type. > > Type name: application > > Subtype name: rdap+json > > Required parameters: n/a > > Encoding considerations: n/a "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: n/a I'm not convinced a reference to the rdap-sec draft is needed as this is specifically about the media, which is just JSON. So I think this will suffice: "See the Security Considerations specified in Section 6 of RFC 4627." > > Interoperability considerations: n/a Here we may need a forward reference to draft-ietf-weirds-json-response. > > Published specification: [[ this document ]] > > Applications that use this media type: RDAP > > Additional information: n/a And here we may want to reference the WEIRDS working group. > > 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" What do people think? -andy From superuser@gmail.com Tue Apr 30 10:59: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 6E27521F9C58 for ; Tue, 30 Apr 2013 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.176, 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 QpPJa5q6CO52 for ; Tue, 30 Apr 2013 10:59:21 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD7921F9C6C for ; Tue, 30 Apr 2013 10:59:19 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so720803wgh.23 for ; Tue, 30 Apr 2013 10:59:18 -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=4foNoJ+flekNZR01qHb59uMqOrnn0M4B5/S90e9brT4=; b=WsZp4BreHfoRM71IELHJhIxFlx+4Jrx0882A5LwpVS7tCTppxrr2ngGUWqbXVqhl5a P5IfuZwNp50OciBDDKTw1gGpbxQrQUwir8JLyGcQ0Rflj6KJXsYBDRQhDvD1l15JV2f2 G5U6yY14ktoKLiVfe1UcfadYE+Bb/U4HodNnr2ZIYrTuIYw4934F5Boj+D6e1hV5Xj6l tOYgUA86/mgvXgvSSK4yrVXWZ4KEWJRGopeVLYP9pVQaMH6F6ohvqBUOGKuuJ8aSAUIu T0GYZGhJ2P+63v6bfvzcCjy+xuBnKHhO+/e1joAR9H/BsmQzheQfLoNG4s/KG1XW1MLE V4lg== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr19527601wjb.17.1367344758499; Tue, 30 Apr 2013 10:59:18 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 30 Apr 2013 10:59:18 -0700 (PDT) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E58BC00D66@CHAXCH01.corp.arin.net> References: <6.2.5.6.2.20130425014632.0b9aef70@resistor.net> <62D9228640AC7F49B2DD9ED0C9CE60E58BC00D66@CHAXCH01.corp.arin.net> Date: Tue, 30 Apr 2013 10:59:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andy Newton Content-Type: multipart/alternative; boundary=047d7b5d8cff9dadcd04db97c222 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-using-http-04.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 17:59:22 -0000 --047d7b5d8cff9dadcd04db97c222 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think you could send the template as you have it in the draft, and request guidance on exactly this set of points in the same message. Mention up front that this is document has ended WGLC but has not started IETF LC yet, so that the reviewer knows where we are in the process. -MSK On Tue, Apr 30, 2013 at 7:23 AM, Andy Newton wrote: > Just taking a stab at this=C5=A0 > > > On 4/25/13 4:57 AM, "SM" wrote: > > >"This specification registers the "application/rdap+json" media type. > > > > Type name: application > > > > Subtype name: rdap+json > > > > Required parameters: n/a > > > > Encoding considerations: n/a > > "The media described by this media-type is JSON. JSON supports Unicode. A= t > a minimum, all servers offering this media must support be capable of > serving it using UTF-8 encoding." > > > > > Security considerations: n/a > > I'm not convinced a reference to the rdap-sec draft is needed as this is > specifically about the media, which is just JSON. So I think this will > suffice: > > "See the Security Considerations specified in Section 6 of RFC 4627." > > > > > Interoperability considerations: n/a > > Here we may need a forward reference to draft-ietf-weirds-json-response. > > > > > Published specification: [[ this document ]] > > > > Applications that use this media type: RDAP > > > > Additional information: n/a > > And here we may want to reference the WEIRDS working group. > > > > > 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" > > > What do people think? > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b5d8cff9dadcd04db97c222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you could send the template as you have it in= the draft, and request guidance on exactly this set of points in the same = message.=C2=A0 Mention up front that this is document has ended WGLC but ha= s not started IETF LC yet, so that the reviewer knows where we are in the p= rocess.

-MSK


On Tue, Apr 30, 2013 at 7:23 AM, Andy Newton &= lt;andy@arin.net>= wrote:
Just taking a stab at this=C5=A0


On 4/25/13 4:57 AM, "SM" <s= m@resistor.net> wrote:

>"This specification registers the "application/rdap+json"= ; media type.
>
> =C2=A0 =C2=A0 =C2=A0 Type name: application
>
> =C2=A0 =C2=A0 =C2=A0 Subtype name: rdap+json
>
> =C2=A0 =C2=A0 =C2=A0 Required parameters: n/a
>
> =C2=A0 =C2=A0 =C2=A0 Encoding considerations: n/a

"The media described by this media-type is JSON. JSON supports U= nicode. At
a minimum, all servers offering this media must support be capable of
serving it using UTF-8 encoding."

>
> =C2=A0 =C2=A0 =C2=A0 Security considerations: n/a

I'm not convinced a reference to the rdap-sec draft is needed as this i= s
specifically about the media, which is just JSON. So I think this will
suffice:

"See the Security Considerations specified in Section 6 of RFC 4627.&q= uot;

>
> =C2=A0 =C2=A0 =C2=A0 Interoperability considerations: n/a

Here we may need a forward reference to draft-ietf-weirds-json-response.

>
> =C2=A0 =C2=A0 =C2=A0 Published specification: [[ this document ]]
>
> =C2=A0 =C2=A0 =C2=A0 Applications that use this media type: RDAP
>
> =C2=A0 =C2=A0 =C2=A0 Additional information: n/a

And here we may want to reference the WEIRDS working group.

>
> =C2=A0 =C2=A0 =C2=A0 Person & email address to contact for further= information: Andy
> =C2=A0 =C2=A0 =C2=A0 Newton <andy@hx= r.us>
>
> =C2=A0 =C2=A0 =C2=A0 Intended usage: COMMON
>
> =C2=A0 =C2=A0 =C2=A0 Restrictions on usage: none
>
> =C2=A0 =C2=A0 =C2=A0 Author: Andy Newton
>
> =C2=A0 =C2=A0 =C2=A0 Change controller: IETF
>
> =C2=A0 =C2=A0 =C2=A0 Provisional Registration: Yes"


What do people think?

-andy

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

--047d7b5d8cff9dadcd04db97c222--