IETF Logo Mail Archive

Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query

Andy Newton <andy@arin.net> Tue, 21 October 2014 23:42 UTC

Return-Path: <andy@arin.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D111A8839; Tue, 21 Oct 2014 16:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1vfg49o6qov; Tue, 21 Oct 2014 16:42:53 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5641A8843; Tue, 21 Oct 2014 16:42:49 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id D62B61651D2; Tue, 21 Oct 2014 19:42:48 -0400 (EDT)
Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 471F01651BE; Tue, 21 Oct 2014 19:42:48 -0400 (EDT)
Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 21 Oct 2014 19:45:24 -0400
Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Tue, 21 Oct 2014 19:42:47 -0400
From: Andy Newton <andy@arin.net>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, Sarah Banks <sbanks@encrypted.net>, "<ops-dir@ietf.org>" <ops-dir@ietf.org>, "draft-ietf-weirds-rdap-query.all@tools.ietf.org" <draft-ietf-weirds-rdap-query.all@tools.ietf.org>
Thread-Topic: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query
Thread-Index: AQHP7NBs2/V2colaR06q1vYLArlwrJw6uqOAgAB9JwA=
Date: Tue, 21 Oct 2014 23:42:46 +0000
Message-ID: <D06C6632.30F1B%andy@arin.net>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F494EFB20@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.7.130812
x-originating-ip: [192.149.252.96]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9058092C0CD238448D989AF508283E71@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sWpqg49HStCR80gks03z3XZNVNc
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] OPS-DIR Review of draft-ietf-weirds-rdap-query
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 23:42:55 -0000

On 10/21/14, 8:14 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

>>	Overall, I found the document very easy to read through, walking
>> through the problem it's trying to solve, addressing each add section
>> by section, with discussion points for each, and examples for each,
>> too. One minor (personal) nit, is the requirement that WHOIS servers
>> that don't or can't respond to a request SHOULD return a 501 error
>> (RFC7231). In trying to provide some structure, it'd be nice to know
>> explicitly that the server has/had an issue responding to the request.
>> If the server chooses not to return a 501 in the event of an error,
>> then what?
>
>Would anyone in the WG object to this being a MUST? That would address
>the ambiguity.

Well, servers that cannot respond to a request (501 - Not Implemented) and
wish to convey that information MUST use a 501. So..

OLD

  If a server receives a query that it cannot process because it is
  not implemented it SHOULD return an HTTP 501
  [RFC7231 <http://tools.ietf.org/html/rfc7231>] error.

NEW

  A server MUST return an HTTP 501 (Not Implemented) [RFC7231] to
  inform a client of unsupported queries.

-andy

v2.23.0 | Report a Bug | By Email