From internet-drafts@ietf.org Mon Dec 3 07:11:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8DC21F8319; Mon, 3 Dec 2012 07:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ridX4+jIpk8U; Mon, 3 Dec 2012 07:11:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC7321F87E7; Mon, 3 Dec 2012 07:10:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203151041.24797.3970.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 07:10:41 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:11:12 -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-01.txt Pages : 50 Date : 2012-12-03 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ed.lewis@neustar.biz Mon Dec 3 07:44:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA08221F8651 for ; Mon, 3 Dec 2012 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.325 X-Spam-Level: X-Spam-Status: No, score=-100.325 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91JuS8gkTanz for ; Mon, 3 Dec 2012 07:44:27 -0800 (PST) Received: from eastrmfepo101.cox.net (eastrmfepo101.cox.net [68.230.241.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3145521F85B1 for ; Mon, 3 Dec 2012 07:44:27 -0800 (PST) Received: from eastrmimpo110 ([68.230.241.223]) by eastrmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121203154424.LVLE10627.eastrmfepo101.cox.net@eastrmimpo110> for ; Mon, 3 Dec 2012 10:44:24 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo110 with cox id X3kP1k00a3cuADQ013kP7d; Mon, 03 Dec 2012 10:44:24 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.50BCC8D8.006F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=N5Wr5hBB c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=RARgB1Ut8ocA:10 a=hGBaWAWWAAAA:8 a=7Ce6JUiEEagA:10 a=Kl_4QgAaA15N0QQaiigA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=_W_S_7VecoQA:10 a=M89YZVzd82e-cG_K:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_449624B5-04AD-458A-B0AA-DC3426614BC0" From: Edward Lewis In-Reply-To: <20121130234803.72618.qmail@joyce.lan> Date: Mon, 3 Dec 2012 10:44:23 -0500 Message-Id: References: <20121130234803.72618.qmail@joyce.lan> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:44:27 -0000 --Apple-Mail=_449624B5-04AD-458A-B0AA-DC3426614BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 30, 2012, at 18:48, John Levine wrote: > Agreed. Given the limited interest shown by the names community here > (just Ed and Scott as far as I can tell), it makes sense to go ahead > with the numbers stuff. I'm puzzled by this statement. What is meant by "go ahead with the = numbers stuff" in the sense that "names" is holding it back or wants = something different? Why I'm puzzled: There isn't a distinct "names community" that is separate from a = "numbers community." There are about a dozen organizations that do both = (i.e., the NIRs and IANA, hence ICANN). There seems to be an assumption that "just because the IETF is working = on it, people are paying attention and posting." In some cases, = observers choose not to be active in the IETF and just see where the = chips fall. For them, it's hard to see the signal above the noise while = there are other issues to watch. That makes gauging interest (as = limited) hard to agree with. What is significant, in the architectural sense, about the protocol = under development that is specific to "names" or to "numbers?" = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_449624B5-04AD-458A-B0AA-DC3426614BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Agreed.=  Given the limited interest shown by the names community = here
(just Ed and Scott as far as I can tell), it makes sense to go = ahead
with the numbers = stuff.

I'm puzzled by = this statement.  What is meant by "go ahead with the numbers stuff" = in the sense that "names" is holding it back or wants something = different?  Why I'm puzzled:

There isn't a = distinct "names community" that is separate from a "numbers community." =  There are about a dozen organizations that do both (i.e., the NIRs = and IANA, hence ICANN).

There seems to be an = assumption that "just because the IETF is working on it, people are = paying attention and posting."  In some cases, observers choose not = to be active in the IETF and just see where the chips fall.  For = them, it's hard to see the signal above the noise while there are other = issues to watch.  That makes gauging interest (as limited) hard to = agree with.

What is significant, in = the architectural sense, about the protocol under development that is = specific to "names" or to "numbers?"

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

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

= --Apple-Mail=_449624B5-04AD-458A-B0AA-DC3426614BC0-- From ed.lewis@neustar.biz Mon Dec 3 09:35:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666F621F87E7 for ; Mon, 3 Dec 2012 09:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.412 X-Spam-Level: X-Spam-Status: No, score=-100.412 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEjW4NXYXMag for ; Mon, 3 Dec 2012 09:34:55 -0800 (PST) Received: from eastrmfepo101.cox.net (eastrmfepo101.cox.net [68.230.241.213]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9421F885A for ; Mon, 3 Dec 2012 09:34:54 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121203173454.YHVG10627.eastrmfepo101.cox.net@eastrmimpo209> for ; Mon, 3 Dec 2012 12:34:54 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id X5at1k00y3cuADQ015atgs; Mon, 03 Dec 2012 12:34:54 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.50BCE2BE.0089,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=kY7TxDJo3HsA:10 a=hGBaWAWWAAAA:8 a=sNSOnmC59AUA:10 a=48vgC7mUAAAA:8 a=1xOtXSlrRIqjJUIR6bAA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=brtt2W4ED1Ptw4yH:21 a=9g7qGwwkwT9HYp9D:21 a=WgYpzYxjnkIInfH5gBUA:9 a=_W_S_7VecoQA:10 a=Yi7EZXFfvJugcjFX:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9EDA0ED7-376D-4C73-AAC4-58167298ECFD" From: Edward Lewis In-Reply-To: <20121203151041.24797.3970.idtracker@ietfa.amsl.com> Date: Mon, 3 Dec 2012 12:34:53 -0500 Message-Id: References: <20121203151041.24797.3970.idtracker@ietfa.amsl.com> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-json-response-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:35:11 -0000 --Apple-Mail=_9EDA0ED7-376D-4C73-AAC4-58167298ECFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments on: On Dec 3, 2012, at 10:10, = wrote: > Title : JSON Responses for the Registration Data = Access Protocol (RDAP) > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-json-response-01.txt > Pages : 50 > Date : 2012-12-03 Item #1 Middle of second paragraph, Introduction: Where overlap exists between RIR and DNR response object classes, the RIR object classes are a proper subset of the DNR object classes. This reads funny. "Where overlap exists" implies that there are items = that don't overlap, hence one set is not a proper subset of the other = when you cosider all of the RIR object classes. (LIke saying "of the positive integers from -10 to 10, those are a = proper subset of the integers from 1 to 20.") I get that for a domain name registry like .int won't have IP address = range objects, it's just that the wording is quite, well, funny. Item #2 Last paragraph of the Introduction: Object classes defined in this document do not represent the full range of data that any registry may wish to publish. Section 4.2 defines a JSON extension mechanism that maybe used by registries to insert registry specific data values. The heuristic in me is that "statements ought to be positive with = exceptions being negative." I think what should be here is this: Object classes defined in the document represent a minimal set of what a = compliant client/server MUST understand to function correctly, however = some deployments may want to include additional object classes to suit = individual needs. Anticipating this need for extension, Section 4.2 of = this document defines a mechanism for extending the JSON (objects) that = are described in this document. Adjust as necessary. Or why am I reading this wrong? Item #3 One of my pet peeves is that there are too many ways (in WhoIs) to call = a specific value. In the definition of 'handle' the situation is = exemplified. 'handle': D...The data type names 'registryId', 'roid', 'nic-handle', 'registrationNo', etc... are terms often synonymous with this data type. In this document, the term 'handle' is used. The term exposed to users by clients is a presentation issue beyond the scope of this document. I included that because the text handles the problem I have neatly but = leaves me one open question. Will the term "handle" be the one used in-band, consistently, throughout = the protocol. I am fine with the presentation to the view changing to = what ever string is desired (registryID, roid, etc.) but "on the wire" = between server and client, I hope that the string is fixed to "handle" = (or any single value). Not a comment, a question...will handle be consistently used? Item #4=20 This is just a point, not an action item for the editors. In section 9.2, variants...this could just as easily be used by RIRs to = tie together all the /24's (say) for a address range (like a /20). Item #5 This is a question, I don't have a specific place to tag this to the = document. For a domain name or IP address domain name, what if I wanted to = designate an abuse contact, as opposed to a registrant contact? The document does have 'entities' like this: "entities" : [ ... ] but I don't see how to tag one as the abuse contact. Along these lines, I'd like to be able to easily (meaning via parser), = give an IP address and get back the abuse contact. Is that a reasonable = goal? = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_9EDA0ED7-376D-4C73-AAC4-58167298ECFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii internet-drafts@ietf.org> = <internet-drafts@ietf.org> = wrote:
Title =           : JSON = Responses for the Registration Data Access Protocol (RDAP)
Author(s) =       : Andrew Lee Newton
=             &n= bsp;           &nbs= p;Scott Hollenbeck
Filename =        : = draft-ietf-weirds-json-response-01.txt
Pages =           : = 50
= Date =            : = 2012-12-03

Item = #1

Middle of second paragraph, = Introduction:

Where =
overlap exists between RIR and DNR response object classes, the
RIR object classes are a proper subset of the DNR object =
classes.

This reads funny.  "Where overlap = exists" implies that there are items that don't overlap, hence one set = is not a proper subset of the other when you cosider all of the RIR = object classes.

(LIke saying "of the positive = integers from -10 to 10, those are a proper subset of the integers from = 1 to 20.")

I get that for a domain name = registry like .int won't have IP address range objects, it's just that = the wording is quite, well, funny.

Item = #2

Last paragraph of the = Introduction:

Object =
classes defined in this document do not represent the full
range of data that any registry may wish to publish.  Section 4.2
defines a JSON extension mechanism that maybe used by registries to
insert registry specific data values.

The = heuristic in me is that "statements ought to be positive with exceptions = being negative."

I think what should be here is = this:

Object classes defined in the document = represent a minimal set of what a compliant client/server MUST = understand to function correctly, however some deployments may want to = include additional object classes to suit individual needs. =  Anticipating this need for extension, Section 4.2 of this document = defines a mechanism for extending the JSON (objects) that are described = in this document.

Adjust as necessary. =  Or why am I reading this wrong?

Item = #3

One of my pet peeves is that there are too = many ways (in WhoIs) to call a specific value.  In the definition = of 'handle' the situation is exemplified.

   'handle':   D...The data type names =
'registryId', 'roid',
      'nic-handle', 'registrationNo', etc... are terms often synonymous
      with this data type.  In this document, the term 'handle' is used.
      The term exposed to users by clients is a presentation issue
      beyond the scope of this document.

I included that because the text handles = the problem I have neatly but leaves me one open = question.

Will the term "handle" be the one = used in-band, consistently, throughout the protocol.  I am fine = with the presentation to the view changing to what ever string is = desired (registryID, roid, etc.) but "on the wire" between server and = client, I hope that the string is fixed to "handle" (or any single = value).

Not a comment, a question...will handle = be consistently used?

Item = #4 

This is just a point, not an action = item for the editors.

In section 9.2, = variants...this could just as easily be used by RIRs to tie together all = the /24's (say) for a address range (like a = /20).

Item #5

This is = a question, I don't have a specific place to tag this to the = document.

For a domain name or IP address = domain name, what if I wanted to designate an abuse contact, as opposed = to a registrant contact?

The document does have = 'entities' like this:

     =
"entities" :
     [
       ...
     ]

but I don't see how to tag one as the = abuse contact.

Along these lines, I'd like to = be able to easily (meaning via parser), give an IP address and get back = the abuse contact.  Is that a reasonable = goal?


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

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

= --Apple-Mail=_9EDA0ED7-376D-4C73-AAC4-58167298ECFD-- From andy@arin.net Mon Dec 3 10:12:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D094D21F890B for ; Mon, 3 Dec 2012 10:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVp2NE7jlctu for ; Mon, 3 Dec 2012 10:12:15 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id E3DF321F890A for ; Mon, 3 Dec 2012 10:12:14 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 8EE7B213645; Mon, 3 Dec 2012 13:12:14 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 920FD2135A6; Mon, 3 Dec 2012 13:12:13 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 3 Dec 2012 13:11:56 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.60]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 13:12:01 -0500 From: Andy Newton To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-json-response-01.txt Thread-Index: AQHN0Wh06a+YEPJ2Gkep7IoTmBHOqZgHqgKA//+2iwA= Date: Mon, 3 Dec 2012 18:11:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <39C7BE0DC56BBF4EB159B558B2849E60@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-json-response-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:12:15 -0000 Ed, Replies inline... From: Edward Lewis >Item #1 > >Middle of second paragraph, Introduction: > >Where overlap exists between RIR and DNR response object classes, the >RIR object classes are a proper subset of the DNR object classes. >This reads funny. "Where overlap exists" implies that there are items >that don't overlap, hence one set is not a proper subset of the other >when you cosider all of the RIR object classes. > >(LIke saying "of the positive integers from -10 to 10, those are a proper >subset of the integers from 1 to 20.") > >I get that for a domain name registry like .int won't have IP address >range objects, it's just that the wording is quite, well, funny. What can I say? I'm a funny guy! I'll work on the wording so it is less confusing. > >Item #2 > >Last paragraph of the Introduction: > >Object classes defined in this document do not represent the full >range of data that any registry may wish to publish. Section 4.2 >> >defines a JSON extension mechanism that maybe used by registries to >insert registry specific data values. > >The heuristic in me is that "statements ought to be positive with >exceptions being negative." > >I think what should be here is this: > >Object classes defined in the document represent a minimal set of what a >compliant client/server MUST understand to function correctly, however >some deployments may want to include additional object classes to suit >individual needs. Anticipating this > need for extension, Section 4.2 of this document defines a mechanism for >extending the JSON (objects) that are described in this document. > >Adjust as necessary. Or why am I reading this wrong? I like that wording. Thanks! > >Item #3 > >One of my pet peeves is that there are too many ways (in WhoIs) to call a >specific value. In the definition of 'handle' the situation is >exemplified. > > 'handle': D...The data type names 'registryId', 'roid', > 'nic-handle', 'registrationNo', etc... are terms often synonymous > with this data type. In this document, the term 'handle' is used. > The term exposed to users by clients is a presentation issue > beyond the scope of this document. > > >I included that because the text handles the problem I have neatly but >leaves me one open question. > >Will the term "handle" be the one used in-band, consistently, throughout >the protocol. I am fine with the presentation to the view changing to >what ever string is desired (registryID, roid, etc.) but "on the wire" >between server and client, I hope that > the string is fixed to "handle" (or any single value). > >Not a comment, a question...will handle be consistently used? I've tried to make the protocol be consistent with "handle". If you find a place where it is not, let me know. So yes, the intent is to be consistent. > >Item #4=20 > >This is just a point, not an action item for the editors. > >In section 9.2, variants...this could just as easily be used by RIRs to >tie together all the /24's (say) for a address range (like a /20). The could be, but that seems like overloading the structure. Variants are intended for IDNs. Repurposing them for reverse DNS boundary collections seems wrong. And clients would have to know to treat variants for reverse DNS differently than for forward DNS based on the TLD. I'm getting a bad smell from that. I'd prefer a separate structure. Also, I'm not sure of the use case in general. > >Item #5 > >This is a question, I don't have a specific place to tag this to the >document. > >For a domain name or IP address domain name, what if I wanted to >designate an abuse contact, as opposed to a registrant contact? > >The document does have 'entities' like this: > > "entities" : > [ > ... > ] > > >but I don't see how to tag one as the abuse contact. Each entity object has a "roles" array of strings. That signifies the relationship for the entity to the containing object. "abuse" is listed in Appendix A.2, so putting "abuse" in the "roles" array would do what you are after. > >Along these lines, I'd like to be able to easily (meaning via parser), >give an IP address and get back the abuse contact. Is that a reasonable >goal? Yes, that is a reasonable goal. Issue a query for http://example.com/ip/192.0.2.0 In the result, look at each entity object in the "entities" array. The abuse contacts are any entity object that has "abuse" listed in its "roles" array. -andy From johnl@iecc.com Mon Dec 3 10:35:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB721F8940 for ; Mon, 3 Dec 2012 10:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.92 X-Spam-Level: X-Spam-Status: No, score=-105.92 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmxWkFSvCdGj for ; Mon, 3 Dec 2012 10:35:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39E21F8938 for ; Mon, 3 Dec 2012 10:35:12 -0800 (PST) Received: (qmail 42830 invoked from network); 3 Dec 2012 18:35:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Dec 2012 18:35:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50bcf0d9.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=efkJ9Hwy3NChObgK+4jEdV9R3a1aPDBmZwqUfeQfyYI=; b=nKeitrVHjwYzBsjtGKCUZBNILFlJ0hj06NWoSqw+YoXgraGuMbsXTYr9k516UbPbSBvxvS5h2aaVsc+5T0ooBGUW5D0gUMlBIN4xPnvuNq7XZvd05YyiB2FYSr8IonhqSz/AP9y9Pg+5fiRWbCXmQpV93yWgGHhXITgz0bnU7PI= 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=50bcf0d9.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=efkJ9Hwy3NChObgK+4jEdV9R3a1aPDBmZwqUfeQfyYI=; b=w+NbN4OefXSrElqWfS/fSKI6rYFtzYGriMpsxCk+FR7yZSk5Z63YSY3ZUoJfvmXfkYHVHuuiekS/MNtH4AkhJvzQsSfMEKkBoLssST7jAe+YM3f0D9EkpY0n4TrxGMshTOUjlhXJhIDTJiq2HGv7Ps8PTaxvlNKgCiZlpekRSZA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Dec 2012 18:34:43 -0000 Message-ID: <20121203183443.52163.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 Cc: ed.lewis@neustar.biz Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:35:20 -0000 > What is significant, in the architectural sense, about the protocol > under development that is specific to "names" or to "numbers?" Andy and Scott's draft has a small fixed set of query terms. They look to me to be adequate for RIR queries, but I would be pretty amazed if people thought that set were also adequate for DNR queries if WEIRDS is supposed to be a replacement for the current WHOIS. I think it'd be fine just to note that finishing the query terms for names is TBD, and do it later, but I want everyone to be clear that's what we're doing. Back when we were chartering this group, a bunch of people popped up and said it was very very very important to do the names and numbers at the same time, but now we're back to doing numbers first, which was the plan in the first place. From shollenbeck@verisign.com Mon Dec 3 10:38:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840C121F88A2 for ; Mon, 3 Dec 2012 10:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc-RghwoVWYg for ; Mon, 3 Dec 2012 10:38:20 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9C21F8443 for ; Mon, 3 Dec 2012 10:38:16 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKULzxl/BUKEozcal7ePcy9cObuZJxyjhj@postini.com; Mon, 03 Dec 2012 10:38:17 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qB3IcCQT001415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 13:38:12 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 13:38:11 -0500 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... Thread-Index: AQHN0W0Wphug0Xmi1EWey9PdQyVBt5gHurCA//+s1+A= Date: Mon, 3 Dec 2012 18:38:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B8CBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121203183443.52163.qmail@joyce.lan> In-Reply-To: <20121203183443.52163.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] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:38:31 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John Levine > Sent: Monday, December 03, 2012 1:35 PM > To: weirds@ietf.org > Cc: ed.lewis@neustar.biz > Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft- > ietf-... >=20 > > What is significant, in the architectural sense, about the protocol > > under development that is specific to "names" or to "numbers?" >=20 > Andy and Scott's draft has a small fixed set of query terms. They look > to me to be adequate for RIR queries, but I would be pretty amazed if > people thought that set were also adequate for DNR queries if WEIRDS is > supposed to be a replacement for the current WHOIS. Could you please provide some sample queries for which the documented set o= f path segments is inadequate? Scott From sm@resistor.net Mon Dec 3 10:39:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8221F8917 for ; Mon, 3 Dec 2012 10:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3TLJHhoOYlO for ; Mon, 3 Dec 2012 10:39:11 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAAC21F877B for ; Mon, 3 Dec 2012 10:39:11 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB3Id3gT022895 for ; Mon, 3 Dec 2012 10:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354559950; bh=KWa8jxadpe3BtIC0EmD5W84YJULHCfY1WsmHIxCExTg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=pcnqTWCuJS6OyZcNQ08jJAl+Se9igNWV5L7HN+GkuwcPunWrOrAvcI/63PIsPof6s b6ln7+oMYbDokRB5ATJC6sk6x7fpmBrB/Fdqmvkq2ZsOPg2ahannHAovOmDZfNpHMC WWmbIiGv/bmxYgoTWNzfVvCGxLI7Xva7GJPKte+U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1354559950; i=@resistor.net; bh=KWa8jxadpe3BtIC0EmD5W84YJULHCfY1WsmHIxCExTg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=LC+SjMUPx8hA9/jM02+bPhmNjZDjMNu4YO3yLHGQkhu9RGBBBJAQO1g/DkLDTsxLw Z1ZhIWsgnhACw4PcfM1R3N9n/KhWIX0qBZYr+6w/kIg1ARAGziEflerczeFPu3bzpC WqKv6Qu+x96yBE91CUNCwDVhbtnJtLkOVu5V40oY= Message-Id: <6.2.5.6.2.20121203100555.09a29730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Dec 2012 10:13:40 -0800 To: weirds@ietf.org From: SM In-Reply-To: References: <20121130234803.72618.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:39:12 -0000 At 07:44 03-12-2012, Edward Lewis wrote: >There isn't a distinct "names community" that is separate from a >"numbers community." There are about a dozen organizations that do >both (i.e., the NIRs and IANA, hence ICANN). How many individuals affiliated with IANA have reviewed the drafts? How many individuals affiliated with ICANN have reviewed the drafts? How many individuals affiliated with NIRs have reviewed the drafts? >There seems to be an assumption that "just because the IETF is >working on it, people are The IETF is not working on it. The editors of the drafts are working on it. People who have posted reviews to this mailing list are working on it. Regards, -sm From johnl@iecc.com Mon Dec 3 11:26:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8673F21F85C8 for ; Mon, 3 Dec 2012 11:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.018 X-Spam-Level: X-Spam-Status: No, score=-106.018 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id linjdJ0UWj9I for ; Mon, 3 Dec 2012 11:26:09 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6B21F8596 for ; Mon, 3 Dec 2012 11:26:08 -0800 (PST) Received: (qmail 54167 invoked from network); 3 Dec 2012 19:26:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Dec 2012 19:26:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50bcfcd0.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=iVbcLuGivFkZ8ncYfcbVyFfgwlmUJtWaT0dhisEMYqg=; b=aZnRC3LwYAfa2PF7o00cD+Vp6g8xBGF/tURbjofT5KzYbaN2FDXjkoHiMBVlOgfvVgVTmWE09HOvskwulyf8tz1y8srg8/LAQVjLvbu46BF3Q+7scg6Y1Q3LkL3SfQYwP8VvuPgcpYGC/wgOMX0cVabjAPfLraW6akU4Zmq5y2s= 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=50bcfcd0.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=iVbcLuGivFkZ8ncYfcbVyFfgwlmUJtWaT0dhisEMYqg=; b=pq7NFzFV0q7s0fsTvxfe7WVMnr1yB9Tv0wzUmomyr2IugUzunE2ncj9I8MJbhVIgS0rZzUxiTDYqOUh83qNQDCBxg1MqoebwVJbJC8B9qzx3E1bRyvdcD/LdmbQKOCeh76f+hW1cYzjVig0OIc2Zx4aNx/q8XoKXuEouH/WS/nY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Dec 2012 19:25:46 -0000 Message-ID: <20121203192546.54034.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B8CBE@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] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:26:10 -0000 >Could you please provide some sample queries for which the documented set of path segments is inadequate? The GTLD whois servers are all supposed do lookup by registrar name. (In a surprising number of cases, they don't work, but that's a separate issue.) Many GTLD servers offer limited wildcard matches, e.g. this lookup in .info. It's in the registry agreement, and in this case actually works: $ whois -h whois.afilias.info abc_ [ boilerplate snipped ] Domain ID:D47075535-LRMS Domain Name:ABC1.INFO Domain ID:D16905835-LRMS Domain Name:ABC2.INFO Domain ID:D32985814-LRMS Domain Name:ABC3.INFO Domain ID:D44983756-LRMS Domain Name:ABC5.INFO Domain ID:D44962928-LRMS Domain Name:ABC6.INFO Domain ID:D45421294-LRMS Domain Name:ABC7.INFO Domain ID:D46542896-LRMS Domain Name:ABC8.INFO Domain ID:D33995697-LRMS Domain Name:ABC9.INFO Domain ID:D2559623-LRMS Domain Name:ABCA.INFO Domain ID:D2453377-LRMS Domain Name:ABCB.INFO Domain ID:D46782033-LRMS Domain Name:ABCC.INFO Domain ID:D6407606-LRMS Domain Name:ABCD.INFO Domain ID:D43597920-LRMS Domain Name:ABCE.INFO Domain ID:D45826247-LRMS Domain Name:ABCF.INFO Domain ID:D35280565-LRMS Domain Name:ABCG.INFO Domain ID:D48050819-LRMS Domain Name:ABCH.INFO Domain ID:D34010045-LRMS Domain Name:ABCI.INFO Domain ID:D13490035-LRMS Domain Name:ABCL.INFO Domain ID:D48037921-LRMS Domain Name:ABCM.INFO Domain ID:D48031914-LRMS Domain Name:ABCN.INFO Domain ID:D48492420-LRMS Domain Name:ABCO.INFO Domain ID:D11452138-LRMS Domain Name:ABCP.INFO Domain ID:D45954821-LRMS Domain Name:ABCQ.INFO Domain ID:D37889783-LRMS Domain Name:ABCS.INFO Domain ID:D1331443-LRMS Domain Name:ABCT.INFO Domain ID:D8012479-LRMS Domain Name:ABCU.INFO Domain ID:D44864187-LRMS Domain Name:ABCV.INFO Domain ID:D11989005-LRMS Domain Name:ABCW.INFO Domain ID:D46495772-LRMS Domain Name:ABCX.INFO Domain ID:D47434319-LRMS Domain Name:ABCY.INFO From ed.lewis@neustar.biz Mon Dec 3 11:26:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF69421F86CE for ; Mon, 3 Dec 2012 11:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.484 X-Spam-Level: X-Spam-Status: No, score=-100.484 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeCWGjEFKCcn for ; Mon, 3 Dec 2012 11:26:46 -0800 (PST) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by ietfa.amsl.com (Postfix) with ESMTP id C58D321F86A5 for ; Mon, 3 Dec 2012 11:26:45 -0800 (PST) Received: from eastrmimpo305 ([68.230.241.237]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121203192645.YNWN18834.eastrmfepo102.cox.net@eastrmimpo305> for ; Mon, 3 Dec 2012 14:26:45 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo305 with cox id X7Sk1k00P3cuADQ017SkPD; Mon, 03 Dec 2012 14:26:45 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020206.50BCFCF5.008A,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=QvDcLCOd c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=RARgB1Ut8ocA:10 a=hGBaWAWWAAAA:8 a=7Ce6JUiEEagA:10 a=51nx_XhkgN-10vaiVNoA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=qQfcVs95nwDcYVZ-:21 a=-07JisKUsDXTOIjG:21 a=NFTBWUKGf2uF3NExXBMA:9 a=_W_S_7VecoQA:10 a=dn9P8-40Wiv1zLz1:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_CA911FC4-0200-4F50-B0E5-AE5C63924D2C" From: Edward Lewis In-Reply-To: <6.2.5.6.2.20121203100555.09a29730@resistor.net> Date: Mon, 3 Dec 2012 14:26:44 -0500 Message-Id: References: <20121130234803.72618.qmail@joyce.lan> <6.2.5.6.2.20121203100555.09a29730@resistor.net> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:26:46 -0000 --Apple-Mail=_CA911FC4-0200-4F50-B0E5-AE5C63924D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 3, 2012, at 13:13, SM wrote: > At 07:44 03-12-2012, Edward Lewis wrote: >> There isn't a distinct "names community" that is separate from a = "numbers community." There are about a dozen organizations that do both = (i.e., the NIRs and IANA, hence ICANN). >=20 > How many individuals affiliated with IANA have reviewed the drafts? >=20 > How many individuals affiliated with ICANN have reviewed the drafts? >=20 > How many individuals affiliated with NIRs have reviewed the drafts? >=20 I have tried to get input from NIRs, but my attempt to contact one = particular person hasn't been successful. There is a rat hole discussion that could happen here. First, the IETF = shies away from recognizing people having affiliations. The IETF = doesn't have members, no voting mechanism before approving a document. = The IETF relies on consensus being volunteered from participants. That = leaves open the possibility that the result can be highly biased "the = wrong way" - in the sense that the entirety of the problem was = underestimated or represented just a fraction of the operator = communitys' concerns. The best the IETF can do is try to beat the = bushes to get as much input as it can, not sit back and expect = volunteers to come calling. A lesson from the PROVREG WG and EPP. EPP was first published around = 2003 and eventually elevated to full standard by 2009. The elevation = followed the full IETF process. However, the operator community, which = pretty much came of age around 2004-2005 (estimates vary) was unaware of = the IETF's mailing list for EPP. So in 2009 there was a lot of = skepticism in the operator community over the elevation of EPP to full = standard when it seemed that the protocol had so many flaws. Between October 2009 and May 2010 a few things happened (the bookend = dates here correspond to CENTR Tech meetings). The operator community = and the PROVREG mail list were introduced to each other. It seems that = while those on the PROVREG list were aware of the state of the art of = registration, those who came on later never heard of the list (because = there was no IETF WG to gateway them in). After this happened, the = angst over the protocol subsided and issues were worked out ceasing the = desire to replace EPP with something different. I'm keeping this short = - the point is that there really needs to be an effort from the IETF = outwards to make sure that what gets into IETF documents is relevant, = and not rely on reviews trickling in on time. And, returning to where my comments began, the operator community in = this case is not so neatly divided between names and numbers. Perhaps = in some sense is seems that way because the number of numbers people on = the list is disproportionately higher than names people (if you are to = count the number of RIRs as 5 registries and the domain names as having = around 300). NIRs though...they expand the RIR's 5 number registries by = about double that. I dunno, this is a rat hole. I expect as much though as we are talking = about splitting input into "names" and "numbers" - attaching = affiliations when the process does not recognize that. >> There seems to be an assumption that "just because the IETF is = working on it, people are >=20 > The IETF is not working on it. The editors of the drafts are working = on it. People who have posted reviews to this mailing list are working = on it. In the sense that the IETF is anyone participating on a mail list or = document or face to face meeting, yes, the "IETF is working on it." = I've seen other organizations refer to things the "IETF is working on" = in that vein. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_CA911FC4-0200-4F50-B0E5-AE5C63924D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
At = 07:44 03-12-2012, Edward Lewis wrote:
There = isn't a distinct "names community" that is separate from a "numbers = community."  There are about a dozen organizations that do both = (i.e., the NIRs and IANA, hence ICANN).

How many = individuals affiliated with IANA have reviewed the drafts?

How = many individuals affiliated with ICANN have reviewed the = drafts?

How many individuals affiliated with NIRs have reviewed = the drafts?


I have tried = to get input from NIRs, but my attempt to contact one particular person = hasn't been successful.

There is a rat hole = discussion that could happen here.  First, the IETF shies away from = recognizing people having affiliations.  The IETF doesn't have = members, no voting mechanism before approving a document.  The IETF = relies on consensus being volunteered from participants.  That = leaves open the possibility that the result can be highly biased "the = wrong way" - in the sense that the entirety of the problem was = underestimated or represented just a fraction of the operator = communitys' concerns.  The best the IETF can do is try to beat the = bushes to get as much input as it can, not sit back and expect = volunteers to come calling.

A lesson from the = PROVREG WG and EPP.  EPP was first published around 2003 and = eventually elevated to full standard by 2009.  The elevation = followed the full IETF process.  However, the operator community, = which pretty much came of age around 2004-2005 (estimates vary) was = unaware of the IETF's mailing list for EPP.  So in 2009 there was a = lot of skepticism in the operator community over the elevation of EPP to = full standard when it seemed that the protocol had so many = flaws.

Between October 2009 and May 2010 a few = things happened (the bookend dates here correspond to CENTR Tech = meetings).  The operator community and the PROVREG mail list were = introduced to each other.  It seems that while those on the PROVREG = list were aware of the state of the art of registration, those who came = on later never heard of the list (because there was no IETF WG to = gateway them in).  After this happened, the angst over the protocol = subsided and issues were worked out ceasing the desire to replace EPP = with something different.  I'm keeping this short - the point is = that there really needs to be an effort from the IETF outwards to make = sure that what gets into IETF documents is relevant, and not rely on = reviews trickling in on time.

And, returning to = where my comments began, the operator community in this case is not so = neatly divided between names and numbers.  Perhaps in some sense is = seems that way because the number of numbers people on the list is = disproportionately higher than names people (if you are to count the = number of RIRs as 5 registries and the domain names as having around = 300).  NIRs though...they expand the RIR's 5 number registries by = about double that.

I dunno, this is a rat hole. =  I expect as much though as we are talking about splitting input = into "names" and "numbers" - attaching affiliations when the process = does not recognize that.

There seems to be an = assumption that "just because the IETF is working on it, people = are

The IETF is not working on it.  The editors = of the drafts are working on it.  People who have posted reviews to = this mailing list are working on = it.

In the sense that the = IETF is anyone participating on a mail list or document or face to face = meeting, yes, the "IETF is working on it."  I've seen other = organizations refer to things the "IETF is working on" in that = vein.

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

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

= --Apple-Mail=_CA911FC4-0200-4F50-B0E5-AE5C63924D2C-- From shollenbeck@verisign.com Mon Dec 3 11:41:55 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E1121F87F1 for ; Mon, 3 Dec 2012 11:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC8oIjNkvGtl for ; Mon, 3 Dec 2012 11:41:55 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E421F8704 for ; Mon, 3 Dec 2012 11:41:52 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUL0Af47cNb5sc4HYiUUEtXKDmhtzZ26v@postini.com; Mon, 03 Dec 2012 11:41:54 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qB3Jfm5q003551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 14:41:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 14:41:48 -0500 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... Thread-Index: AQHN0W0Wphug0Xmi1EWey9PdQyVBt5gHurCA//+s1+CAAGFtAP//rRNA Date: Mon, 3 Dec 2012 19:41:47 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B8D7A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6B8CBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20121203192546.54034.qmail@joyce.lan> In-Reply-To: <20121203192546.54034.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:41:55 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAyOjI2 IFBNDQo+IFRvOiB3ZWlyZHNAaWV0Zi5vcmcNCj4gQ2M6IEhvbGxlbmJlY2ssIFNjb3R0DQo+IFN1 YmplY3Q6IFJlOiBbd2VpcmRzXSByZXF1aXJlbWVudHMvc3VjY2VzcyB3YXMgLSBSZTogSS1EIEFj dGlvbjogZHJhZnQtDQo+IGlldGYtLi4uDQo+IA0KPiA+Q291bGQgeW91IHBsZWFzZSBwcm92aWRl IHNvbWUgc2FtcGxlIHF1ZXJpZXMgZm9yIHdoaWNoIHRoZSBkb2N1bWVudGVkDQo+IHNldCBvZiBw YXRoIHNlZ21lbnRzIGlzIGluYWRlcXVhdGU/DQo+IA0KPiBUaGUgR1RMRCB3aG9pcyBzZXJ2ZXJz IGFyZSBhbGwgc3VwcG9zZWQgZG8gbG9va3VwIGJ5IHJlZ2lzdHJhciBuYW1lLg0KPiAoSW4gYSBz dXJwcmlzaW5nIG51bWJlciBvZiBjYXNlcywgdGhleSBkb24ndCB3b3JrLCBidXQgdGhhdCdzIGEN Cj4gc2VwYXJhdGUgaXNzdWUuKQ0KDQpIbW0sIHllcywgdGhhdCdzIGEgbGVnYWN5IHVzZSBjYXNl LiBJdCBtYXkgYmUgb25lIHdlIGNhbiBhY2NvbW1vZGF0ZSBpbiB0aGUgY29udGV4dCBvZiBzZWFy Y2hlcyAoc2VlIGJlbG93KSBhbmQgc3RyaW5nIHBhdHRlcm4gbWF0Y2hpbmcuDQoNCj4gTWFueSBH VExEIHNlcnZlcnMgb2ZmZXIgbGltaXRlZCB3aWxkY2FyZCBtYXRjaGVzLCBlLmcuIHRoaXMgbG9v a3VwIGluDQo+IC5pbmZvLiAgSXQncyBpbiB0aGUgcmVnaXN0cnkgYWdyZWVtZW50LCBhbmQgaW4g dGhpcyBjYXNlIGFjdHVhbGx5DQo+IHdvcmtzOg0KPiANCj4gJCB3aG9pcyAtaCB3aG9pcy5hZmls aWFzLmluZm8gYWJjXw0KPiBbIGJvaWxlcnBsYXRlIHNuaXBwZWQgXQ0KDQpUaGF0J3MgYSBzZWFy Y2ggZGVzaWduZWQgdG8gcmV0dXJuIGEgbXVsdGktZWxlbWVudCByZXNwb25zZS4gV2UgbWFkZSBh IGNvbnNjaW91cyBkZWNpc2lvbiBhcyBhIGdyb3VwIHRvIGRlZmVyIHNlYXJjaCBwcm9jZXNzaW5n LCBidXQgaW4gYW4gaW50ZXJlc3RpbmcgdHdpc3Qgb2YgZmF0ZSBBbmR5IGFuZCBJIGhhdmUgYmVl biB0YWxraW5nIGFib3V0IGl0IG9mZi1saXN0IHRvZGF5LiBJIGFncmVlIHRoYXQgd2UgaGF2ZSB0 byBmaW5kIGEgd2F5IHRvIHNwZWNpZnkgc2VhcmNoIGZ1bmN0aW9uYWxpdHkgZm9yIHRoZSBwcm90 b2NvbCB0byBiZSBmdWxseSB1c2VmdWwgLSBhbmQgbm90IGp1c3QgZm9yIG5hbWVzLiBJIGRvbid0 IHlldCBrbm93IGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBzZWFyY2ggc3ludGF4IGFuZCBzZW1h bnRpY3MgdG8gdGhlIGV4aXN0aW5nIHF1ZXJ5IGFuZCByZXNwb25zZSBkcmFmdHMgb3IgaWYgdGhl eSBiZWxvbmcgaW4gdGhlaXIgb3duIGRvY3VtZW50KHMpLg0KDQpTY290dA0K From ed.lewis@neustar.biz Mon Dec 3 12:24:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8F21F8905 for ; Mon, 3 Dec 2012 12:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.544 X-Spam-Level: X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4ybV6DG8Nai for ; Mon, 3 Dec 2012 12:24:35 -0800 (PST) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF321F8904 for ; Mon, 3 Dec 2012 12:24:35 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121203202432.ZCRB6475.eastrmfepo202.cox.net@eastrmimpo209> for ; Mon, 3 Dec 2012 15:24:32 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id X8QY1k0093cuADQ018QYlW; Mon, 03 Dec 2012 15:24:32 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50BD0A80.010F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=ObnZeHdtUS0A:10 a=hGBaWAWWAAAA:8 a=75IHtLjT8_sA:10 a=EIGv1buV8x4DtAHDD58A:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=fhfWcLrrBvoDmxmU-jYA:9 a=_W_S_7VecoQA:10 a=byH9CJhMRzICHAdj:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C62FB01-5D12-4EF7-B241-C3F5C0D568BF" From: Edward Lewis In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B8D7A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 3 Dec 2012 15:24:32 -0500 Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D6B8CBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20121203192546.54034.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F0D6B8D7A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [weirds] search was Re:requirements/success was ... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Dec 2012 20:24:36 -0000 --Apple-Mail=_6C62FB01-5D12-4EF7-B241-C3F5C0D568BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 3, 2012, at 14:41, Hollenbeck, Scott wrote: > That's a search designed to return a multi-element response. We made a = conscious decision as a group to defer search processing, but in an = interesting twist of fate Andy and I have been talking about it off-list = today. I agree that we have to find a way to specify search = functionality for the protocol to be fully useful - and not just for = names. I don't yet know if it makes sense to add search syntax and = semantics to the existing query and response drafts or if they belong in = their own document(s). In trying to decide for myself, I figured that the problem needs better = definition. E.g., where do we draw the line between searching and bulk retrieval. = For example ... "/ip/*" Is the intent that I can ask for 5 specific objects in one URL and get = back the 5 responses? Is the intent that I can ask for all the objects in a lexical range = (abc*.se or 127.0.*)? Is the intent that I can ask for all object matching a regular = expression (127.[0-9].6.[^.]+)? Is the intent that I can ask for all the objects that have a certain = attribute - like AS numbers registered to Chile? I ask these questions because "for the protocol to be fully useful" is = open-ended. I.e., "useful to whom" and in what way. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_6C62FB01-5D12-4EF7-B241-C3F5C0D568BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
That's a search designed to = return a multi-element response. We made a conscious decision as a group = to defer search processing, but in an interesting twist of fate Andy and = I have been talking about it off-list today. I agree that we have to = find a way to specify search functionality for the protocol to be fully = useful - and not just for names. I don't yet know if it makes sense to = add search syntax and semantics to the existing query and response = drafts or if they belong in their own = document(s).

In trying to = decide for myself, I figured that the problem needs better = definition.

E.g., where do we draw the line between = searching and bulk retrieval.  For example ... =  "/ip/*"

Is the intent that I can ask for = 5 specific objects in one URL and get back the 5 responses?
Is = the intent that I can ask for all the objects in a lexical range = (abc*.se or 127.0.*)?
Is the intent that I can ask for all = object matching a regular expression (127.[0-9].6.[^.]+)?
Is = the intent that I can ask for all the objects that have a certain = attribute - like AS numbers registered to = Chile?

I ask these questions because "for the = protocol to be fully useful" is open-ended.  I.e., "useful to whom" = and in what way.

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

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

= --Apple-Mail=_6C62FB01-5D12-4EF7-B241-C3F5C0D568BF-- From sm@resistor.net Mon Dec 3 12:30:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE721F88FB for ; Mon, 3 Dec 2012 12:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umZFepGjoHcf for ; Mon, 3 Dec 2012 12:30:04 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6391921F88B1 for ; Mon, 3 Dec 2012 12:30:04 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB3KTttg019266; Mon, 3 Dec 2012 12:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354566599; bh=ZO2U4D7UXX8bkoI2KW0Hyc7ww7Q5jv7qI7xUdFXaojc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SI08F1H+IjX1I1rdyXIQGmbX10riSdSpvtrJnTZcnEHlR4zZIASux3w4YHZXS2y2M z8+J7Eb1z56Nnmx+MXvfzEv8RIGH9DYIfpXu9C6MoDUr4WbLcOHeLHzeofbOphh6BF rpYfJgn7TfrUD3IjbKISOHhqyunamaADhh4hoa30= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1354566599; i=@resistor.net; bh=ZO2U4D7UXX8bkoI2KW0Hyc7ww7Q5jv7qI7xUdFXaojc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sKzK3w5IIj+K41l/UVqLOqrFN+YfNLRx1I+3uHWi8g+bBnhIjbavAkKxo7lOrNGFG bKvJjKFZqXr29Q6AzPhF28cuJhABZdEN0fKzKMPbfmvmqLu87tF2ZROZoGsdGinAQ6 A7Gc0XGKHSr5pYjAwsJL2kLH/bvU84ODkNwlt2Zk= Message-Id: <6.2.5.6.2.20121203113535.0abea830@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Dec 2012 12:29:46 -0800 To: Edward Lewis From: SM In-Reply-To: References: <20121130234803.72618.qmail@joyce.lan> <6.2.5.6.2.20121203100555.09a29730@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:30:05 -0000 Hi Ed, At 11:26 03-12-2012, Edward Lewis wrote: >There is a rat hole discussion that could happen here. First, the >IETF shies away from recognizing people having affiliations. The >IETF doesn't have members, no voting And I am ok with that. :-) >mechanism before approving a document. The IETF relies on consensus >being volunteered from participants. That leaves open the >possibility that the result can be highly biased "the wrong way" - >in the sense that the entirety of the problem was underestimated or >represented just a fraction of the operator communitys' >concerns. The best the IETF can do is try to beat the bushes to get >as much input as it can, not sit back and expect volunteers to come calling. The work on the drafts is still in its infancy. In my humble opinion it is better to give the work sufficient time to take shape. I would avoid using "the IETF" as it means nothing. There were a lot of people in the room at the two WG sessions. I gather that they are aware of the work being done and they volunteered to do some work. >A lesson from the PROVREG WG and EPP. EPP was first published >around 2003 and eventually elevated to full standard by 2009. The >elevation followed the full IETF process. However, the operator >community, which pretty much came of age around 2004-2005 (estimates >vary) was unaware of the IETF's mailing list for EPP. So in 2009 >there was a lot of skepticism in the operator community over the >elevation of EPP to full standard when it seemed that the protocol >had so many flaws. Full Standard does not mean anything. :-) However, I think that there is a lesson to be learned from what you wrote above. There may be flaws in the documents published by this working group. It can happen to any (IETF) document. If some people think that it would be better to reduce or fix flaws there is a WGLC and a Last Call for people to read the documents and point out what is wrong. >Between October 2009 and May 2010 a few things happened (the bookend >dates here correspond to CENTR Tech meetings). The operator >community and the PROVREG mail list were introduced to each >other. It seems that while those on the PROVREG list were aware of >the state of the art of registration, those who came on later never >heard of the list (because there was no IETF WG to gateway them >in). After this happened, the angst over the protocol subsided and >issues were worked out ceasing the desire to replace EPP with >something different. I'm keeping this short - the point is that >there really needs to be an effort from the IETF outwards to make >sure that what gets into IETF documents is relevant, and not rely on >reviews trickling in on time. Yes, but someone has to go and do that work. >And, returning to where my comments began, the operator community in >this case is not so neatly divided between names and >numbers. Perhaps in some sense is seems that way because the number >of numbers people on the list is disproportionately higher than >names people (if you are to count the number of RIRs as 5 registries >and the domain names as having around 300). NIRs though...they >expand the RIR's 5 number registries by about double that. In my opinion the number of X does not matter. If you replace X with vendors you end up with the same type of discussions in other working groups. It can be quite discouraging to do any work. Regards, -sm From andy@arin.net Mon Dec 3 14:09:23 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAB021F88A4 for ; Mon, 3 Dec 2012 14:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re3mV8akQ-fN for ; Mon, 3 Dec 2012 14:09:22 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 8995821F8862 for ; Mon, 3 Dec 2012 14:09:22 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 1F06C213650; Mon, 3 Dec 2012 17:09:22 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 77C5821363D; Mon, 3 Dec 2012 17:09:21 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 3 Dec 2012 17:09:15 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.60]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 17:09:21 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... Thread-Index: AQHN0aLXm581P2UMTUGwpf12ogzsiQ== Date: Mon, 3 Dec 2012 22:09:19 +0000 Message-ID: In-Reply-To: <20121203183443.52163.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 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: "ed.lewis@neustar.biz" Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:09:23 -0000 On 12/3/12 1:34 PM, "John Levine" wrote: >Andy and Scott's draft has a small fixed set of query terms. They >look to me to be adequate for RIR queries, but I would be pretty >amazed if people thought that set were also adequate for DNR queries >if WEIRDS is supposed to be a replacement for the current WHOIS. If anybody thinks the internationalization topic at the last meeting was hard, just wait until you throw searches into the mix. Concentrating first on lookups gets us forward progress on the things which constitute 99% of the query volume. Holding all work to get that last 1%, work which will be an order of magnitude more difficult to specify, is not a good trade off. -andy From johnl@taugh.com Mon Dec 3 14:18:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437421F892F for ; Mon, 3 Dec 2012 14:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMNbu0n82STR for ; Mon, 3 Dec 2012 14:18:21 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AE05421F892B for ; Mon, 3 Dec 2012 14:18:14 -0800 (PST) Received: (qmail 92565 invoked from network); 3 Dec 2012 22:18:13 -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=16994.50bd2525.k1212; bh=oB+nxkJBHJNucwOtCXp7fe51EhLbldSVWA17fJ6JYwk=; b=LpIRg93oASDHKKZDyULEI46JypgRz5aMIA/BwaKi4Umipl1FlAulTXo3Gs9ugNewOXDfxI6ex3Utq0pFZ4OW5243M58xxX0bqosrvzLU2RTvn/HAGyvG6q56Tj5lTjZAzXaILcIPwhUOHgYGQ48MynI0KDNoNodOd+5zjUPuz6Y= 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=16994.50bd2525.k1212; bh=oB+nxkJBHJNucwOtCXp7fe51EhLbldSVWA17fJ6JYwk=; b=m3ORwiwXrbCEbZ8P4bZxSc/84hwgnPaqW6pSg1PWTfZ8A1d6i71HQVyZYOP/rqvCX7zzsnHzvx3BCfTQM4/qUpMHLP/B1JwveQPUGvt3aijOrgvJnuolIhHNKSutRuwaAtTP25YlGOyo6onthmPuCP6+n/meafoNgqcy46swnc8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 3 Dec 2012 22:17:51 -0000 Date: 3 Dec 2012 17:18:13 -0500 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:18:22 -0000 > Concentrating first on lookups gets us forward progress on the things > which constitute 99% of the query volume. Holding all work to get that > last 1%, work which will be an order of magnitude more difficult to > specify, is not a good trade off. That's a perfectly reasonable approach, but again I want to be explict that's we say that's what we're doing if indeed it is. R's, John From johnl@iecc.com Mon Dec 3 14:19:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F7421F8616 for ; Mon, 3 Dec 2012 14:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.098 X-Spam-Level: X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTxbqate-czu for ; Mon, 3 Dec 2012 14:19:07 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 698E021F85C9 for ; Mon, 3 Dec 2012 14:19:07 -0800 (PST) Received: (qmail 92864 invoked from network); 3 Dec 2012 22:19:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Dec 2012 22:19:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50bd255a.xn--3zv.k1211; i=johnl@user.iecc.com; bh=J/NDbSYcqTxIVXNRPJgDWDDLZAqOiGxEPYY/1gdCW/0=; b=r90MJwSwA4oma0rjXBd9kDQLV27BnMFB/fW74CAXWD6eqitUe12LN61RtnUm09o8joz/SMBT08imYGHrV3oFJLNvEhRVpt4nw/hEn0LPwQAY67X3VUtrqxphV5m2akJoWsylmPB7QQ5d97uRsltxdFjSH/NFVl3/Yx3GZV4XWAs= 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=50bd255a.xn--3zv.k1211; olt=johnl@user.iecc.com; bh=J/NDbSYcqTxIVXNRPJgDWDDLZAqOiGxEPYY/1gdCW/0=; b=N8TPEmJbj5p1H7cqeo/cyr2DG/V7JCXDSY+N7VUMJP/QgBp786eGXKIwaLSG9ngTJNxrhSK+SBh3Hk10eFqHABgsOnv20np4mPUHxqmA/C/7btzuxTPxJYuPAWwW4jcXCvyrSYYajKFzzk4TpbHfn7r0kDl7LuR7Sx3IZga3LH8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Dec 2012 22:18:44 -0000 Message-ID: <20121203221844.60343.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 Cc: ed.lewis@neustar.biz Subject: Re: [weirds] search was Re: requirements/success was ... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Dec 2012 22:19:08 -0000 Assuming we try to handle searching (see previous message), ... >In trying to decide for myself, I figured that the problem needs better definition. > >E.g., where do we draw the line between searching and bulk retrieval. For example ... "/ip/*" We don't. The client asks the question, the server decides whether it's willing to answer it. My inclination would be to add a query prefix like /multi to indicate that the client is asking for multiple results, and the results of a /multi query is a JSON array, even if it only has one entry. The array might start with a status value to say whether these are all the matching results, or just a subset, and it'd probably be useful to provide some way, either an HTTP return code or additional status values for nothing matched and too many things matched. Servers are not required to be strictly truthful, e.g., if the list is truncated they don't have to say so. From nkong@cnnic.cn Tue Dec 4 19:48:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5121F8BFD for ; Tue, 4 Dec 2012 19:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-wPoYYL7SGv for ; Tue, 4 Dec 2012 19:48:52 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 5D60421F8BFC for ; Tue, 4 Dec 2012 19:48:52 -0800 (PST) Received: from unknown127.0.0.1 (HELO [192.168.101.70]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 05 Dec 2012 11:48:44 +0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: Date: Wed, 5 Dec 2012 11:48:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <137C04A0-5DC9-4C04-8A6F-5125C4B1B81D@cnnic.cn> References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-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: Wed, 05 Dec 2012 03:48:53 -0000 Hi Edward, Thanks for your comments. Please see my feedbacks to Item #2 inline. > Item #2 >=20 > Section 3.1.1, federated authentication, seems to be an ill-fit in a = requirements document. The possible approaches are fine descriptions as = far as they go, but, they aren't requirements. It's not bad to place = hold them here until there's a document detailing a solution or a = solution approach, but - well, they aren't requirements. >=20 > But it's the requirement that is there that seems flakey. I = understand the utility of a federated authentication model but don't see = how it is germane to the definition of this protocol. I mean - = authentication is merely the task of proving I am who I claim to be. If = this is done via a trusted third party that is trusted by many servers = (in the sense that there are clients, servers and third parties), that = is fine. >=20 > It's a good discussion to have, but I don't see it as a requirement. = I can see 3.1.1. being labeled as a note on how to build the = authentication system. IMHO, the sec draft is more than just a requirements document. So in = this draft, we try to capture related everything, including not only = requirements but also approaches, as discussed in the mailing list and = IETF meeting. Based on the related discussion, I think there are potential = requirements on federated authentication and this topic might be in the = scope of the sec draft. I agree that there would be some uncertain = issues (e.g. detailed requirements and approaches) on this topic. I hope = we can have further discussion based on the section 3.1.1 in order to = make sure these uncertain issues. If necessary, I'm also fine to detail = this topic in another document in future. Cheers, Ning From internet-drafts@ietf.org Wed Dec 5 08:52:32 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E280921F8750; Wed, 5 Dec 2012 08:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8bWgqK4NXIX; Wed, 5 Dec 2012 08:52:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650EC21F8C04; Wed, 5 Dec 2012 08:52:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121205165231.30152.6283.idtracker@ietfa.amsl.com> Date: Wed, 05 Dec 2012 08:52:31 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-using-http-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: Wed, 05 Dec 2012 16:52:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Using the Registration Data Access Protocol (RDAP) with = HTTP Author(s) : Andrew Lee Newton Byron J. Ellacott Ning Kong Filename : draft-ietf-weirds-using-http-01.txt Pages : 14 Date : 2012-12-05 Abstract: This document describes the usage of the Registration Data Access Protocol (RDAP) using HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-using-http-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-using-http-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gavin.brown@centralnic.com Wed Dec 5 09:20:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF321F8CEB for ; Wed, 5 Dec 2012 09:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fJ5yWLTsl4Q for ; Wed, 5 Dec 2012 09:20:24 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 326CA21F8CE9 for ; Wed, 5 Dec 2012 09:20:24 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 1DDEA712CA2 for ; Wed, 5 Dec 2012 17:20:22 +0000 (UTC) Message-ID: <50BF8255.9060502@centralnic.com> Date: Wed, 05 Dec 2012 17:20:21 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [weirds] RDAP implementation at CentralNic X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Dec 2012 17:20:25 -0000 Dear colleagues, We have just launched a prototype RDAP service. This implementation is based on the following drafts: draft-ietf-weirds-using-http-00 draft-ietf-weirds-rdap-query-01 draft-ietf-weirds-json-response-01 We believe that the server complies with the above specifications, but if you discover any issues, please let us know. We will track updates to these drafts and update our implementation accordingly. You can test our server using any command-line SSL-capable HTTP client, such as curl: $ curl https://rdap.centralnic.com/domain/centralnic.pw We are planning on building and releasing open-source clients that can consume RDAP data. When these become available, we will post to this list. Cheers, Gavin. -- 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 zhoulinlin@cnnic.cn Sun Dec 9 19:29:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E812E21F8DD0 for ; Sun, 9 Dec 2012 19:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGjNwI3MpKpH for ; Sun, 9 Dec 2012 19:29:17 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D03D821F8DAC for ; Sun, 9 Dec 2012 19:29:15 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 10 Dec 2012 11:29:09 +0800 From: "Linlin Zhou" To: "'Byron Ellacott'" , "'John R Levine'" References: In-Reply-To: Date: Mon, 10 Dec 2012 11:29:08 +0800 Message-ID: <004301cdd686$843e4e90$8cbaebb0$@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: AQHNy/p7HgDYvBFM50mo0Eqr55Nrxpf7tmSAgAI70oCAAuz+AIAAFQoAgAELpICAD3EfEA== Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 03:29:18 -0000 Sorry for the late reply. > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Byron Ellacott > Sent: Friday, November 30, 2012 3:26 PM > To: John R Levine > Cc: weirds@ietf.org > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt > > > > >This is one of the reasons why I pushed back so hard against coupling > >the numbers and names WEIRDS designs. The people who want names need > >to figure this out and come up with at least an approximate set of > >query types and terms, but I haven't seen much progress in that regard. > > http://tools.ietf.org/html/draft-zhou-weirds-dnrd-ap-object-inventory is a > decent effort at the lookup side of this, by identifying the result terms and by > implication the object types. > > In name space, there are mainly 4 query types described in the draft-zhou-weirds-dnrd-ap-object-inventory. They are queries for domain name, nameserver, contact and registrar. This draft gives a concept of entity which represents a contact, registrant or registrar. I think sections 2.3, 2,4 and 2.5 of this draft include the name registries' query requirements. From ed.lewis@neustar.biz Wed Dec 12 12:00:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C4521E8128 for ; Wed, 12 Dec 2012 12:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.595 X-Spam-Level: X-Spam-Status: No, score=-100.595 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOsvLcQmmvA8 for ; Wed, 12 Dec 2012 12:00:03 -0800 (PST) Received: from eastrmfepo101.cox.net (eastrmfepo101.cox.net [68.230.241.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9700D21E8110 for ; Wed, 12 Dec 2012 12:00:02 -0800 (PST) Received: from eastrmimpo306 ([68.230.241.238]) by eastrmfepo101.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121212195956.RBAW2891.eastrmfepo101.cox.net@eastrmimpo306> for ; Wed, 12 Dec 2012 14:59:56 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo306 with cox id ajzv1k0023cuADQ01jzvaM; Wed, 12 Dec 2012 14:59:55 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.50C8E23B.0198,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=EqRQXFgA c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=WQbcPEAUyV4A:10 a=hGBaWAWWAAAA:8 a=itrjNh4ZBAIA:10 a=48vgC7mUAAAA:8 a=lu39Royhef68-UXDp6UA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=_W_S_7VecoQA:10 a=guzKgqrvARoMrLYK:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1D4834F-AAA4-4512-9E98-4D9311E37BCC" From: Edward Lewis In-Reply-To: <137C04A0-5DC9-4C04-8A6F-5125C4B1B81D@cnnic.cn> Date: Wed, 12 Dec 2012 14:59:53 -0500 Message-Id: <920A607B-571E-4A52-9709-4EA0F5FC6F91@neustar.biz> References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> <137C04A0-5DC9-4C04-8A6F-5125C4B1B81D@cnnic.cn> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-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: Wed, 12 Dec 2012 20:00:04 -0000 --Apple-Mail=_D1D4834F-AAA4-4512-9E98-4D9311E37BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ning, Continuing my preference for top posting. (An old issue.): Well, moving or reserving the text for another document isn't desirable = - because that just gets messy. And it is true that any document can discuss whatever it needs to - = there's no need to restrict requirements documents to just requirements. What I would float for comment is this - Add a new header called Security Policy Options and move 3.1.1 under = that. The reason is that I don't see federated authentication as a = necessity, i.e., not as a requirement per se. There's nothing wrong = with the idea of federated authentication, but in working through my use = cases I don't see it as a part of my plans now. (I'm only saying this = to give you my frame of mind, others will likely disagree and I respect = those differences.) In my opinion, "federated" authentication is a statement about policy, = which is one layer up in terms of protocol development. We've been = steering clear of policy in other parts of the protocol definition and I = think consistency is good. On the other hand, if one were to participate in a federated = authentication method, then there is a natural requirement that the = method be compatible with what is available in HTTP - so I get that = there's a requirement to consider. But that is on the federation = method, not the "rest" of the protocol. The way it (3.1.1) reads now, with a requirement in the section, makes = it seem like a federated authentication method is itself a requirement. = And that is why I called the section an "ill fit." On Dec 4, 2012, at 22:48, Ning Kong wrote: >=20 > Hi Edward, >=20 > Thanks for your comments. Please see my feedbacks to Item #2 inline. >=20 >> Item #2 >>=20 >> Section 3.1.1, federated authentication, seems to be an ill-fit in a = requirements document. The possible approaches are fine descriptions as = far as they go, but, they aren't requirements. It's not bad to place = hold them here until there's a document detailing a solution or a = solution approach, but - well, they aren't requirements. >>=20 >> But it's the requirement that is there that seems flakey. I = understand the utility of a federated authentication model but don't see = how it is germane to the definition of this protocol. I mean - = authentication is merely the task of proving I am who I claim to be. If = this is done via a trusted third party that is trusted by many servers = (in the sense that there are clients, servers and third parties), that = is fine. >>=20 >> It's a good discussion to have, but I don't see it as a requirement. = I can see 3.1.1. being labeled as a note on how to build the = authentication system. >=20 > IMHO, the sec draft is more than just a requirements document. So in = this draft, we try to capture related everything, including not only = requirements but also approaches, as discussed in the mailing list and = IETF meeting. >=20 > Based on the related discussion, I think there are potential = requirements on federated authentication and this topic might be in the = scope of the sec draft. I agree that there would be some uncertain = issues (e.g. detailed requirements and approaches) on this topic. I hope = we can have further discussion based on the section 3.1.1 in order to = make sure these uncertain issues. If necessary, I'm also fine to detail = this topic in another document in future. >=20 > Cheers, > Ning >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_D1D4834F-AAA4-4512-9E98-4D9311E37BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On the other hand, if one were to = participate in a federated authentication method, then there is a = natural requirement that the method be compatible with what is available = in HTTP - so I get that there's a requirement to consider.  But = that is on the federation method, not the "rest" of the = protocol.

The way it (3.1.1) reads now, with a = requirement in the section, makes it seem like a federated = authentication method is itself a requirement.  And that is why I = called the section an "ill fit."

On Dec 4, 2012, at = 22:48, Ning Kong wrote:


Hi = Edward,

Thanks for your comments. Please see my feedbacks to Item = #2 inline.

Item = #2

Section 3.1.1, federated authentication, seems to be an = ill-fit in a requirements document.  The possible approaches are = fine descriptions as far as they go, but, they aren't requirements. =  It's not bad to place hold them here until there's a document = detailing a solution or a solution approach, but - well, they aren't = requirements.

But it's the = requirement that is there that seems flakey.  I understand the = utility of a federated authentication model but don't see how it is = germane to the definition of this protocol.  I mean - = authentication is merely the task of proving I am who I claim to be. =  If this is done via a trusted third party that is trusted by many = servers (in the sense that there are clients, servers and third = parties), that is fine.

It's a good = discussion to have, but I don't see it as a requirement.  I can see = 3.1.1. being labeled as a note on how to build the authentication = system.

IMHO, the sec draft is more than just a = requirements document. So in this draft, we try to capture related = everything, including not only requirements but also approaches, as = discussed in the mailing list and IETF meeting.

Based on the = related discussion, I think there are potential requirements on = federated authentication and this topic might be in the scope of the sec = draft. I agree that there would be some uncertain issues (e.g. detailed = requirements and approaches) on this topic. I hope we can have further = discussion based on the section 3.1.1 in order to make sure these = uncertain issues. If necessary, I'm also fine to detail this topic in = another document in = future.

Cheers,
Ning

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

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

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

= --Apple-Mail=_D1D4834F-AAA4-4512-9E98-4D9311E37BCC-- From johnl@iecc.com Wed Dec 12 14:37:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6C21E8054 for ; Wed, 12 Dec 2012 14:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47SxqwAXehGI for ; Wed, 12 Dec 2012 14:37:06 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 54DED1F0CB2 for ; Wed, 12 Dec 2012 14:37:05 -0800 (PST) Received: (qmail 7655 invoked from network); 12 Dec 2012 22:37:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Dec 2012 22:37:04 -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=50c90710.xn--btvx9d.k1212; i=johnl@user.iecc.com; bh=G9ghNtHBg3mqIgsrexZuzZ2NClmUK0LZOo+rmydvnWo=; b=Epe83GYj9ZkN5e+2PrJ0ZgfeEabiVBBpVCV6SLiQTITabg7rYJURKCXufuvFv0kBE18kuXLsmgeLRyvzrlc7s8BRMIiSwc4I6fR+snDxZCktFvP4TZG2PgMwtiZmNQ7/3OoZoVyNQXWdOFt8wBgdRqrJk/5f+9EGLreW6Eyng04= 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=50c90710.xn--btvx9d.k1212; olt=johnl@user.iecc.com; bh=G9ghNtHBg3mqIgsrexZuzZ2NClmUK0LZOo+rmydvnWo=; b=P0Fiz4j/YmdsUtmAPdQXUq8VNVeealCPMdGkTKyFQ28EHlT+MziRDDeK42whHI9wLgkYB/6jpQL9vg3dVQixwoWpuZoBYKqhofwRqcdGsVS/IvSZ8pkHysEPEZ69BpCQ6znPsTF0IYesoE+l9CA/55+hyb5XJudBlJR/k5tJmo4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Dec 2012 22:36:41 -0000 Message-ID: <20121212223641.32836.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <920A607B-571E-4A52-9709-4EA0F5FC6F91@neustar.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-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: Wed, 12 Dec 2012 22:37:06 -0000 >Hi Ning, > >Continuing my preference for top posting. (An old issue.): top posting hate hate hate die die die Now that we have that out of the way ... >Add a new header called Security Policy Options and move 3.1.1 under that. The >reason is that I don't see federated authentication as a necessity, i.e., not >as a requirement per se. I added the federated thing in the first place, and it does seem to have gotten a bit out of control. All I proposed to say is that the authentication schemes should not preclude federated auth, e.g., don't do something that requires a unique credential for each server. R's, John From gavin.brown@centralnic.com Fri Dec 14 04:44:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063C421F861D for ; Fri, 14 Dec 2012 04:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x5FCbQtWYtV for ; Fri, 14 Dec 2012 04:44:24 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B021F85FC for ; Fri, 14 Dec 2012 04:44:23 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 52637712F54 for ; Fri, 14 Dec 2012 12:44:22 +0000 (UTC) Message-ID: <50CB1F26.6070909@centralnic.com> Date: Fri, 14 Dec 2012 12:44:22 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [weirds] rdapper - command line RDAP client X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:44:25 -0000 Dear colleagues, CentralNic has developed a command-line client for the Registration Data Access Protocol. This client is open source and written in the Perl programming language. It should work with any server that complies with the most recently published drafts, although since I'm only aware of one such server (ours), I make no promises as to its compliance. You can check out the code from this URL: https://github.com/jodrell/rdapper Documentation is here: https://github.com/jodrell/rdapper/blob/master/rdapper/README.md Any comments, suggestions, and bug reports will be much appreciated. Regards, -- 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 nkong@cnnic.cn Fri Dec 14 19:28:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B373521F8A47 for ; Fri, 14 Dec 2012 19:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gCumaylNowk for ; Fri, 14 Dec 2012 19:28:46 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6E58721F892D for ; Fri, 14 Dec 2012 19:28:45 -0800 (PST) Received: from unknown127.0.0.1 (HELO [10.4.86.169]) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 15 Dec 2012 11:28:38 +0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_67DD6A43-3DE2-4926-A149-7EBCFB2F1C51" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ning Kong In-Reply-To: <920A607B-571E-4A52-9709-4EA0F5FC6F91@neustar.biz> Date: Sat, 15 Dec 2012 11:28:34 +0800 Message-Id: References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> <137C04A0-5DC9-4C04-8A6F-5125C4B1B81D@cnnic.cn> <920A607B-571E-4A52-9709-4EA0F5FC6F91@neustar.biz> To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-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: Sat, 15 Dec 2012 03:28:46 -0000 --Apple-Mail=_67DD6A43-3DE2-4926-A149-7EBCFB2F1C51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ed, As I mentioned before, the reason why we added 3.1.1 to discuss = federated authentication is there were discussions about this issue. = Based on these discussions, IMHO, federated authentication may be a = possible requirement. If WEIRDS WG can get a definitely conclusion that = federated authentication is not a requirement in future, I'd like to = accept omitting this topic. But if we agree that federated authentication should be considered as a = requirement in future, I don't think we should only discuss it as a = policy issue. I do think the protocol issues related with federated = authentication needs to be considered, just like the traditional = authentication in Section 3.1.=20 Cheers, Ning > Add a new header called Security Policy Options and move 3.1.1 under = that. The reason is that I don't see federated authentication as a = necessity, i.e., not as a requirement per se. There's nothing wrong = with the idea of federated authentication, but in working through my use = cases I don't see it as a part of my plans now. (I'm only saying this = to give you my frame of mind, others will likely disagree and I respect = those differences.) >=20 > In my opinion, "federated" authentication is a statement about policy, = which is one layer up in terms of protocol development. We've been = steering clear of policy in other parts of the protocol definition and I = think consistency is good. >=20 > On the other hand, if one were to participate in a federated = authentication method, then there is a natural requirement that the = method be compatible with what is available in HTTP - so I get that = there's a requirement to consider. But that is on the federation = method, not the "rest" of the protocol. >=20 > The way it (3.1.1) reads now, with a requirement in the section, makes = it seem like a federated authentication method is itself a requirement. = And that is why I called the section an "ill fit." --Apple-Mail=_67DD6A43-3DE2-4926-A149-7EBCFB2F1C51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As I mentioned before, the reason why we added 3.1.1 to discuss = federated authentication is there were discussions about this issue. = Based on these discussions, IMHO, federated authentication may be a = possible requirement. If WEIRDS WG can get a definitely conclusion that = federated authentication is not a requirement in future, I'd like = to accept omitting this topic.

But if we agree that federated authentication should be = considered as a requirement in future, I don't think we should only = discuss it as a policy issue. I do think the protocol issues related = with federated authentication needs to be considered, just like the = traditional authentication in Section = 3.1. 

Cheers,
Ning

Add a new header called = Security Policy Options and move 3.1.1 under that.  The reason is = that I don't see federated authentication as a necessity, i.e., not as a = requirement per se.  There's nothing wrong with the idea of = federated authentication, but in working through my use cases I don't = see it as a part of my plans now.  (I'm only saying this to give = you my frame of mind, others will likely disagree and I respect those = differences.)

In my opinion, "federated" = authentication is a statement about policy, which is one layer up in = terms of protocol development.  We've been steering clear of policy = in other parts of the protocol definition and I think consistency is = good.

On the other hand, if one were to = participate in a federated authentication method, then there is a = natural requirement that the method be compatible with what is available = in HTTP - so I get that there's a requirement to consider.  But = that is on the federation method, not the "rest" of the = protocol.

The way it (3.1.1) reads now, with a = requirement in the section, makes it seem like a federated = authentication method is itself a requirement.  And that is why I = called the section an "ill fit."

= --Apple-Mail=_67DD6A43-3DE2-4926-A149-7EBCFB2F1C51-- From internet-drafts@ietf.org Tue Dec 18 10:22:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BA021F8B17; Tue, 18 Dec 2012 10:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2j-09aXTImR; Tue, 18 Dec 2012 10:22:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318DF21F8B1E; Tue, 18 Dec 2012 10:22:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121218182228.21322.61529.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 10:22:28 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:22:28 -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 Query Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-02.txt Pages : 11 Date : 2012-12-18 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexandrsergeyev@gmail.com Tue Dec 18 10:23:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2670221F85EF for ; Tue, 18 Dec 2012 10:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqQBCnmVT7QQ for ; Tue, 18 Dec 2012 10:23:30 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7391C21F8425 for ; Tue, 18 Dec 2012 10:23:29 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so2930753wib.12 for ; Tue, 18 Dec 2012 10:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=+FBA303P5lPeLl2EPTlJHQqstCuE2Ab3DI4ONy+xb+U=; b=Hg/PrfREw8svGHfpxRJoAbO/GtlgW4USyg6P8wBId3F63uQvHbY8Rlspa9WLjmyv+h mVpNJOVH+JzY4FFKMzi8xUYcMiggm917yK2XGYn9vheWEyUg35QfRBB60cbeWt3Wr6AW 78AVVSGgJbYiZs/zPrW6uE7PW+zoxKFO6xnCuvOcJDyZ7C4Ihc3zyldRQD36uFjiW4vE RPT+sgthZFNsCcfav4NMD7FN33nCm+NnWbnI2jKkzeD66gLxo5ihJSIlauePsvxOeDSf 6nowj379OAOw/eS4kizxLUJjybWRb6Xg8Qk+tKQnsDcX13Swdu31KtPXCB9kUkpiSljq sewQ== MIME-Version: 1.0 Received: by 10.194.5.74 with SMTP id q10mr6470081wjq.13.1355855007999; Tue, 18 Dec 2012 10:23:27 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Tue, 18 Dec 2012 10:23:27 -0800 (PST) Date: Tue, 18 Dec 2012 13:23:27 -0500 X-Google-Sender-Auth: E4DUkQ91zkpbZHb2lhGQ42geghg Message-ID: From: Alex Sergeyev To: weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [weirds] Comments on draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:23:31 -0000 Hi there, Greatly improved document BTW! I really want to just add couple minor things and not sure if they were mentioned in -00 discussion or somewhere else: * case insensitivity is only mentioned in referenced documents, nothing in response formatting, questions are: - should server ever care about request/response using same case or not? - should links (value, href fields in examples) be formatted same way as "handle" or "name" elements? same about "registrationBy" and other fields... - can server implementation go crazy sending everything in mixed case? * some JSON examples are incorrectly formatted, needs JSONLint or smth else run on them (most mess is from commas) -- Alex. From shollenbeck@verisign.com Tue Dec 18 10:27:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC421F8B27 for ; Tue, 18 Dec 2012 10:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZlm4K8-ySmF for ; Tue, 18 Dec 2012 10:27:26 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE8E21F8AD8 for ; Tue, 18 Dec 2012 10:27:26 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUNC1jRk5sia3M/FTOoMAxHQSRg9Ma8gl@postini.com; Tue, 18 Dec 2012 10:27:26 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qBIIRPGA012582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Dec 2012 13:27:25 -0500 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 13:27:24 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-02.txt Thread-Index: AQHN3Uylj0zufgET70G540iHyCRjh5ge3thQ Date: Tue, 18 Dec 2012 18:27:23 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6CBE66@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <20121218182228.21322.61529.idtracker@ietfa.amsl.com> In-Reply-To: <20121218182228.21322.61529.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-02.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:27:26 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Tuesday, December 18, 2012 1:22 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-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 : Registration Data Access Protocol Query Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-02.txt > Pages : 11 > Date : 2012-12-18 This version includes edits for all of the open issues that Andy and I coul= d identify. An updated response draft will be published soon. Scott=20 From andy@arin.net Tue Dec 18 11:28:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3902221F8A52 for ; Tue, 18 Dec 2012 11:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8jzsNJ4jNgK for ; Tue, 18 Dec 2012 11:28:05 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8D21F86EA for ; Tue, 18 Dec 2012 11:28:05 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id D6FD2164EDB; Tue, 18 Dec 2012 14:28:04 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 3A970164ED2; Tue, 18 Dec 2012 14:28:04 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 18 Dec 2012 14:27:43 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 18 Dec 2012 14:27:51 -0500 From: Andy Newton To: Alex Sergeyev , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-01 Thread-Index: AQHN3UzKJ6O9dpucTkCmu3GOLCz35Zge8OwA Date: Tue, 18 Dec 2012 19:27:50 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898BF54@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.2.5.121010 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-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 19:28:06 -0000 On 12/18/12 1:23 PM, "Alex Sergeyev" wrote: >Hi there, > >Greatly improved document BTW! Thanks. >* case insensitivity is only mentioned in referenced documents, >nothing in response formatting, questions are: > - should server ever care about request/response using same case or >not? If you are talking about JSON names, they should be case sensitive. Though I guess that's plainly spelled out. I could add some text pointing that out. > - should links (value, href fields in examples) be formatted same >way as "handle" or "name" elements? same about "registrationBy" and >other fields... The intent was to follow the case sensitivity as quoted. The members of the links objects actually use values specified in another RFC which follows a different naming capitalization convention. > - can server implementation go crazy sending everything in mixed case? I would hope not. >* some JSON examples are incorrectly formatted, needs JSONLint or >smth else run on them (most mess is from commas) One was pointed out to me. If you see others please let me know. I'll see about running some additional checks. -andy From andy@arin.net Tue Dec 18 14:23:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D021E8054 for ; Tue, 18 Dec 2012 14:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE+Xygd2VM5b for ; Tue, 18 Dec 2012 14:23:25 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3554D21E8039 for ; Tue, 18 Dec 2012 14:23:25 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id BCBD7165136; Tue, 18 Dec 2012 17:23:24 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 69F951650F4; Tue, 18 Dec 2012 17:23:24 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 18 Dec 2012 17:23:07 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 18 Dec 2012 17:23:17 -0500 From: Andy Newton To: Alex Sergeyev , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-01 Thread-Index: AQHN3UzKJ6O9dpucTkCmu3GOLCz35Zge8OwAgAAxBYA= Date: Tue, 18 Dec 2012 22:23:17 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898C06A@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898BF54@CHAXCH01.corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <72A5AB445C06C140A51E34428EA4E828@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:23:25 -0000 On 12/18/12 2:27 PM, "Andy Newton" wrote: >One was pointed out to me. If you see others please let me know. >I'll see about running some additional checks. Actually, I went through all of them and fixed them. Thanks. -andy From wil@cloudregistry.net Tue Dec 18 15:55:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D2D1F0CB3 for ; Tue, 18 Dec 2012 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlYc62uKw8hn for ; Tue, 18 Dec 2012 15:55:44 -0800 (PST) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id 973121F041A for ; Tue, 18 Dec 2012 15:55:44 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id k25so1187574iah.9 for ; Tue, 18 Dec 2012 15:55:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=9+6oOmxP48m7FKh/5FOzsk6684EMeB6SSIP0SYo3gAE=; b=J+3tbB5FHecWM7U5QAfTVF7HrGExjrxhUTMDwwqbNAIArMsMPuv4ZdnVWjm4p1s6xq yy9Ru1/r+75KEvwdJE1EmSq4XSgQbXUIGESt2IeyzE6NEwIZEXkXKYpF4eLT0gMI8mIg 6g0E5HyFmQE90skS5TYTYCOLTGnRk8ih1oVMvzwPgEKCbfxj2n5AEBuHUqFbmXsNTpl5 b66z4oa9cq+rfaheP6qwAtek+2l7wMCrhUbPFL1tC91SOeibeodkEzBZBYq4WOf1W6Oc qXp+mPyUDwM2gOjb59Y92CzsP3z7NOCk7XerZymtLW8iCMmp2NT93Gt3DtmkarMgK0g9 4x/g== Received: by 10.50.196.164 with SMTP id in4mr277608igc.86.1355874944094; Tue, 18 Dec 2012 15:55:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.46.8 with HTTP; Tue, 18 Dec 2012 15:55:03 -0800 (PST) From: Wil Tan Date: Wed, 19 Dec 2012 10:55:03 +1100 Message-ID: To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=14dae93405c96712f404d1293c5e X-Gm-Message-State: ALoCoQmycTfihIxIBLXA2zefbRRtl0pnwceDGHICKn5rJol1+bOmuotsghRVeHUJjjd+Uzq0da2R Cc: "weirds@ietf.org" Subject: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:55:45 -0000 --14dae93405c96712f404d1293c5e Content-Type: text/plain; charset=UTF-8 I'd like to propose that we use URI query instead of path segments in this specification. So, instead of: /ip/192.0.2.0/24 Use: /?type=ip&q=192.0.2.0/24 or /ip/?q=192.0.2.0/24 The main advantage to this approach is that there is a distinction between a query vs. a known resource. IMO, the distinction is important. The latter is returned as a full URL in the response body so there's no need to standardize its representation, but the former is what this draft is about. When a client is making a query, it may not know a whole lot about the subject it is querying about. For example, it may not know the CIDR block prefix and bitmask length. So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable resource URL of "/ip/192.0.2.0/24". A positive side effect is that html forms automatically work without client-side javascript. .wil --14dae93405c96712f404d1293c5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to propose that we use URI query instead of path segments in t= his specification.

So, instead of:

<= div>=C2=A0 /ip/192.0.2.0/24

Use:

=C2=A0 /?type=3Dip&q=3D192.0.2.0/24

or
=

=C2=A0 /ip/?q=3D19= 2.0.2.0/24


The main advantage to this approac= h is that=C2=A0there is a distinction between a query vs. a known resource.= IMO, the distinction is important. The latter is returned as a full URL in= the response body so there's no need to standardize its representation= , but the former is what this draft is about.

When a client is making a query, it may not know a= whole lot about the subject it is querying about. For example, it may not = know the CIDR block prefix and bitmask length.

So, sending a query of "/?type=3Dip&q=3D192.0.2.13" may lead = me to a stable resource URL of "/ip/19= 2.0.2.0/24".

A positive side e= ffect is that html forms automatically work without client-side javascript.=

.wil
--14dae93405c96712f404d1293c5e-- From zhoulinlin@cnnic.cn Tue Dec 18 18:17:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6528D21E8034 for ; Tue, 18 Dec 2012 18:17:02 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpAGIrr9Mx5n for ; Tue, 18 Dec 2012 18:17:01 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2E78621F856D for ; Tue, 18 Dec 2012 18:16:59 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 19 Dec 2012 10:16:51 +0800 From: "Linlin Zhou" To: "'Wil Tan'" , "'Hollenbeck, Scott'" References: In-Reply-To: Date: Wed, 19 Dec 2012 10:16:51 +0800 Message-ID: <014501cddd8e$e8515030$b8f3f090$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01CDDDD1.F6749030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3dezTKROcbd7f9Rvq7Nx0XTiPgdgADGqjA Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 02:17:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0146_01CDDDD1.F6749030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think these 3 URIs are equivalent from the perspective of a client. = Query string like /?type=3Dip&q=3D192.0.2.0/24 usually represents the = search result, but URI such as /ip/192.0.2.0/24 is supposed to return an = IP representation. For RDAP queries, I think this kind of URI = /ip/192.0.2.0/24 is more appropriate, especially in typical REST design. =20 Regards, Linlin =20 From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf = Of Wil Tan Sent: Wednesday, December 19, 2012 7:55 AM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: [weirds] Query vs. Path (comment on = draft-ietf-weirds-rdap-query-02) =20 I'd like to propose that we use URI query instead of path segments in = this specification. =20 So, instead of: =20 /ip/192.0.2.0/24 =20 Use: =20 /?type=3Dip&q=3D192.0.2.0/24 =20 or =20 /ip/?q=3D192.0.2.0/24 =20 =20 The main advantage to this approach is that there is a distinction = between a query vs. a known resource. IMO, the distinction is important. = The latter is returned as a full URL in the response body so there's no = need to standardize its representation, but the former is what this = draft is about. =20 When a client is making a query, it may not know a whole lot about the = subject it is querying about. For example, it may not know the CIDR = block prefix and bitmask length. =20 So, sending a query of "/?type=3Dip&q=3D192.0.2.13" may lead me to a = stable resource URL of "/ip/192.0.2.0/24". =20 A positive side effect is that html forms automatically work without = client-side javascript. =20 .wil ------=_NextPart_000_0146_01CDDDD1.F6749030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think = these 3 URIs are equivalent from the perspective of a client. Query = string like /?type=3Dip&q=3D192.0.2.0/24 usually represents the = search result, but URI such as /ip/192.0.2.0/24 is supposed to return an = IP representation. For RDAP queries, I think this kind of URI = /ip/192.0.2.0/24 is more appropriate, especially in typical REST = design.

 =

Regards,

Linlin=

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Wil Tan
Sent: Wednesday, December 19, 2012 7:55 = AM
To: Hollenbeck, Scott
Cc: = weirds@ietf.org
Subject: [weirds] Query vs. Path (comment on = draft-ietf-weirds-rdap-query-02)

 

I'd like to propose that we use URI = query instead of path segments in this = specification.

 

So, instead = of:

 

=

 

Use:

 

  /?type=3Dip&q=3D192.0.2.0/24

=

 

or

 

  /ip/?q=3D192.0.2.0/24

=

 

 

The main advantage to this approach = is that there is a distinction between a query vs. a known = resource. IMO, the distinction is important. The latter is returned as a = full URL in the response body so there's no need to standardize its = representation, but the former is what this draft is = about.

 

When a client is making a query, it = may not know a whole lot about the subject it is querying about. For = example, it may not know the CIDR block prefix and bitmask = length.

 

So, sending a query of = "/?type=3Dip&q=3D192.0.2.13" may lead me to a stable = resource URL of "/ip/192.0.2.0/24".

 

A positive side effect is that html = forms automatically work without client-side = javascript.

 

.wil

------=_NextPart_000_0146_01CDDDD1.F6749030-- From aservin@lacnic.net Wed Dec 19 04:22:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D90B21F8AE0 for ; Wed, 19 Dec 2012 04:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE167-HFXpBd for ; Wed, 19 Dec 2012 04:22:52 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id CBA7521F87B2 for ; Wed, 19 Dec 2012 04:22:51 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:c85a:2101:87d8:8af8]) by mail.lacnic.net.uy (Postfix) with ESMTP id D2506308427 for ; Wed, 19 Dec 2012 10:22:42 -0200 (UYST) Message-ID: <50D1B194.2010300@lacnic.net> Date: Wed, 19 Dec 2012 10:22:44 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <014501cddd8e$e8515030$b8f3f090$@cn> In-Reply-To: <014501cddd8e$e8515030$b8f3f090$@cn> X-Enigmail-Version: 1.4.6 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] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 12:22:52 -0000 Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST type model. /as On 19/12/2012 00:16, Linlin Zhou wrote: > I think these 3 URIs are equivalent from the perspective of a client. > Query string like /?type=ip&q=192.0.2.0/24 usually represents the search > result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP > representation. For RDAP queries, I think this kind of URI > /ip/192.0.2.0/24 is more appropriate, especially in typical REST design. > > > > Regards, > > Linlin > > > > *From:*weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > Behalf Of *Wil Tan > *Sent:* Wednesday, December 19, 2012 7:55 AM > *To:* Hollenbeck, Scott > *Cc:* weirds@ietf.org > *Subject:* [weirds] Query vs. Path (comment on > draft-ietf-weirds-rdap-query-02) > > > > I'd like to propose that we use URI query instead of path segments in > this specification. > > > > So, instead of: > > > > /ip/192.0.2.0/24 > > > > Use: > > > > /?type=ip&q=192.0.2.0/24 > > > > or > > > > /ip/?q=192.0.2.0/24 > > > > > > The main advantage to this approach is that there is a distinction > between a query vs. a known resource. IMO, the distinction is important. > The latter is returned as a full URL in the response body so there's no > need to standardize its representation, but the former is what this > draft is about. > > > > When a client is making a query, it may not know a whole lot about the > subject it is querying about. For example, it may not know the CIDR > block prefix and bitmask length. > > > > So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable > resource URL of "/ip/192.0.2.0/24 ". > > > > A positive side effect is that html forms automatically work without > client-side javascript. > > > > .wil > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From gavin.brown@centralnic.com Wed Dec 19 05:55:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24721F87A6 for ; Wed, 19 Dec 2012 05:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdFx5blB2n0n for ; Wed, 19 Dec 2012 05:55:11 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9521F876E for ; Wed, 19 Dec 2012 05:55:11 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 6607E712DC0 for ; Wed, 19 Dec 2012 13:55:09 +0000 (UTC) Message-ID: <50D1C73D.6050801@centralnic.com> Date: Wed, 19 Dec 2012 13:55:09 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [weirds] Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:55:12 -0000 Postal address information for entities is returned in a flat array format: "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393" ], For any registry whose database design was developed to support EPP, this is quite lossy, since the specific meaning of each field is lost. I suggest that in addition to the above format, the standard should also permit a full object, like so: "postalAddress" : { street: [ "123 Maple Ave", "Suite 90001", ], city: "Vancouver", sp: "BC", pc: "12393", cc: "CA" }, It would be pretty easy for clients to work out which model was being used, and handle it accordingly. Servers should use one model or the other, but not both. 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 andy@arin.net Wed Dec 19 06:44:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5DA21F8490 for ; Wed, 19 Dec 2012 06:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNVfkzdnhxh9 for ; Wed, 19 Dec 2012 06:44:07 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 1076A21F8586 for ; Wed, 19 Dec 2012 06:44:07 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 77D31164FEB; Wed, 19 Dec 2012 09:44:06 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 00D46164F20; Wed, 19 Dec 2012 09:44:06 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Dec 2012 09:43:52 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 19 Dec 2012 09:44:05 -0500 From: Andy Newton To: Arturo Servin , "weirds@ietf.org" Thread-Topic: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) Thread-Index: AQHN3fdLx5pcvK0XT0Wk/FnOVPmgaA== Date: Wed, 19 Dec 2012 14:44:04 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898C28A@CHAXCH01.corp.arin.net> In-Reply-To: <50D1B194.2010300@lacnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:44:08 -0000 On 12/19/12 7:22 AM, "Arturo Servin" wrote: > > Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST type >model. > I agree with Linlin and Arturo. -andy From carlosm3011@gmail.com Wed Dec 19 06:48:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3BC21F8615 for ; Wed, 19 Dec 2012 06:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkhALCm5hn3H for ; Wed, 19 Dec 2012 06:48:42 -0800 (PST) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 413BD21F8608 for ; Wed, 19 Dec 2012 06:48:42 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id q11so481587yhf.12 for ; Wed, 19 Dec 2012 06:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CnSfCDg1uHyjz4qoDg/W7WKMM3XL64hqIYODiuD+1LY=; b=wguHabhJv+2rGwj+mKzb3xDyGAG0uPChLc8oNuhsSTjyUsqeQUdAiORyhpRuEna2t8 nSTsIKNXw4UxzYHZ8MgI0JN/KD4VSoTFmPc9UZ7ou7lFyVgiWye85408VcJujE/RRZBh miPfPINU/rphplWSvySWHqxMWTgYszRV9trCB8b6jAnO2+AofkY6B86sA65/JFMzpDDN kS7R/FbIqjTjqBDIS37lrG8lvEKlFPxkipE4KqVf2BRaOTCWTo8aexNwM/p3Jlcs7U6E SNUTeLWH4Zzz3Gx8duOgWdDmZ0Rc46lTFeeN7dTDamSKRqbHGL8Ggf799QEbpYrT6jnN Wzrw== X-Received: by 10.236.147.204 with SMTP id t52mr5981117yhj.9.1355928521814; Wed, 19 Dec 2012 06:48:41 -0800 (PST) Received: from europa.local ([200.7.85.140]) by mx.google.com with ESMTPS id w1sm4377407anl.5.2012.12.19.06.48.39 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 06:48:40 -0800 (PST) Message-ID: <50D1D3C5.30609@gmail.com> Date: Wed, 19 Dec 2012 12:48:37 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Arturo Servin References: <014501cddd8e$e8515030$b8f3f090$@cn> <50D1B194.2010300@lacnic.net> In-Reply-To: <50D1B194.2010300@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:48:43 -0000 I agree. But, if I read it correctly, the original post aimed to differentiate between lookups and searches. I read the original post as: /ip/10.1.1.0/24 would mean 'i want a lookup for this entry' /ip?q=10.1.1.0/24 would mean 'search for something that covers this entry' But I perhaps misread it. regards, ~Carlos On 12/19/12 10:22 AM, Arturo Servin wrote: > > Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST type > model. > > /as > > On 19/12/2012 00:16, Linlin Zhou wrote: >> I think these 3 URIs are equivalent from the perspective of a client. >> Query string like /?type=ip&q=192.0.2.0/24 usually represents the search >> result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP >> representation. For RDAP queries, I think this kind of URI >> /ip/192.0.2.0/24 is more appropriate, especially in typical REST design. >> >> >> >> Regards, >> >> Linlin >> >> >> >> *From:*weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On >> Behalf Of *Wil Tan >> *Sent:* Wednesday, December 19, 2012 7:55 AM >> *To:* Hollenbeck, Scott >> *Cc:* weirds@ietf.org >> *Subject:* [weirds] Query vs. Path (comment on >> draft-ietf-weirds-rdap-query-02) >> >> >> >> I'd like to propose that we use URI query instead of path segments in >> this specification. >> >> >> >> So, instead of: >> >> >> >> /ip/192.0.2.0/24 >> >> >> >> Use: >> >> >> >> /?type=ip&q=192.0.2.0/24 >> >> >> >> or >> >> >> >> /ip/?q=192.0.2.0/24 >> >> >> >> >> >> The main advantage to this approach is that there is a distinction >> between a query vs. a known resource. IMO, the distinction is important. >> The latter is returned as a full URL in the response body so there's no >> need to standardize its representation, but the former is what this >> draft is about. >> >> >> >> When a client is making a query, it may not know a whole lot about the >> subject it is querying about. For example, it may not know the CIDR >> block prefix and bitmask length. >> >> >> >> So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable >> resource URL of "/ip/192.0.2.0/24 ". >> >> >> >> A positive side effect is that html forms automatically work without >> client-side javascript. >> >> >> >> .wil >> >> >> >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From andy@arin.net Wed Dec 19 06:59:44 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9698021F8439 for ; Wed, 19 Dec 2012 06:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZXZ6l1Gvl2b for ; Wed, 19 Dec 2012 06:59:44 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5C21F85BC for ; Wed, 19 Dec 2012 06:59:44 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id AE63E1651A8; Wed, 19 Dec 2012 09:59:43 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id D46491651A3; Wed, 19 Dec 2012 09:59:42 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 19 Dec 2012 09:59:29 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Wed, 19 Dec 2012 09:59:42 -0500 From: Andy Newton To: Gavin Brown , "weirds@ietf.org" Thread-Topic: [weirds] Entity postal address information in draft-ietf-weirds-json-response-01 Thread-Index: AQHN3fl5DirUcIhhvE25OBgjBMhchA== Date: Wed, 19 Dec 2012 14:59:41 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> In-Reply-To: <50D1C73D.6050801@centralnic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [192.149.252.228] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:59:44 -0000 On 12/19/12 8:55 AM, "Gavin Brown" wrote: >Postal address information for entities is returned in a flat array >format: > > "postalAddress" : > [ > "123 Maple Ave", > "Suite 90001", > "Vancouver", > "BC", > "12393" > ], > >For any registry whose database design was developed to support EPP, >this is quite lossy, since the specific meaning of each field is lost. > >I suggest that in addition to the above format, the standard should also >permit a full object, like so: > > "postalAddress" : > { > street: [ "123 Maple Ave", "Suite 90001", ], > city: "Vancouver", > sp: "BC", > pc: "12393", > cc: "CA" > }, > >It would be pretty easy for clients to work out which model was being >used, and handle it accordingly. Servers should use one model or the >other, but not both. That's an interesting compromise. I would suggest "postalAddress" : { "structured" : { ... }, "flat" : [ ... ] } And if we have to figure out which structured format to use, EPP seems the most reasonable to me. I do think we need to ask the question of why we need structured postal addresses though. Is it for automated sending of postal mail? I would think that from a law enforcement point of view, a human is ALWAYS gonna interpret the address so a flat structure is fine. -andy From wil@cloudregistry.net Wed Dec 19 07:24:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7121F89C0 for ; Wed, 19 Dec 2012 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyvk8J8zRnZj for ; Wed, 19 Dec 2012 07:24:24 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0ED21F8505 for ; Wed, 19 Dec 2012 07:24:24 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so4379245qan.10 for ; Wed, 19 Dec 2012 07:24:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wNA6N15RNyI+FSuRvEerWWbfYb6y85/dmxX4x6PM43Q=; b=jxpeSc/CJhWXb9lKVuzHBxoBiMrNaxc2NB5QOxuq5N4tOjVGapiz66uFB6N/KH1rjf LJo6s6V4HONrcYuTThdATGvsY0bg6pSIHRugu7FQJaA71V/kAqRaA/YDocGoK4JzwqLh YfPYf/u0DoSJf+Ifb2emwC4QEjUG+dFj77tb+0Uy4pKYgcCBLNG/a/WCMMhO0uQRgebX 8oChODh7xIIUfP/YEsrIWH9eFFJMTJe565ghWdkPm0iWWI+8tWbGcsXs7AHCbJmhsGk6 FlS4TxA4DT5Re7I253X4PYoBRqPDBYqaBof91aj6jmkKp+JaOxJ/IG4q7fOlhFmEiO+i lpkA== Received: by 10.224.45.6 with SMTP id c6mr2843822qaf.54.1355930663627; Wed, 19 Dec 2012 07:24:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.71.237 with HTTP; Wed, 19 Dec 2012 07:23:42 -0800 (PST) In-Reply-To: <50D1D3C5.30609@gmail.com> References: <014501cddd8e$e8515030$b8f3f090$@cn> <50D1B194.2010300@lacnic.net> <50D1D3C5.30609@gmail.com> From: Wil Tan Date: Thu, 20 Dec 2012 02:23:42 +1100 Message-ID: To: "Carlos M. Martinez" Content-Type: multipart/alternative; boundary=20cf3074b9fa8baa3404d136356b X-Gm-Message-State: ALoCoQl2kDuwhYiCgGTBzy4Os2Z15ZGR+RkOfiWLviJPh3i5LlQYV/F4c9zFD2VErNAQQ3cxsK2V Cc: "weirds@ietf.org" Subject: Re: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:24:25 -0000 --20cf3074b9fa8baa3404d136356b Content-Type: text/plain; charset=UTF-8 On Thu, Dec 20, 2012 at 1:48 AM, Carlos M. Martinez wrote: > I agree. But, if I read it correctly, the original post aimed to > differentiate between lookups and searches. > > Thanks Carlos, indeed that's what I meant. > I read the original post as: > > /ip/10.1.1.0/24 would mean 'i want a lookup for this entry' > Right, and I agree that this is in line with REST style. /ip?q=10.1.1.0/24 would mean 'search for something that covers this entry' > > Right, it is a "search query", and would probably be most common in the case of address assignments, because clients are likely to just pass in an IP, since it wouldn't know the block length. So for search queries, should we use something like the following? /ip?q=10.1.1.5 which would return a response or redirect to /ip/10.1.1.0/24 .wil > But I perhaps misread it. > > regards, > > ~Carlos > > On 12/19/12 10:22 AM, Arturo Servin wrote: > > > > Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a > REST type > > model. > > > > /as > > > > On 19/12/2012 00:16, Linlin Zhou wrote: > >> I think these 3 URIs are equivalent from the perspective of a client. > >> Query string like /?type=ip&q=192.0.2.0/24 usually represents the > search > >> result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP > >> representation. For RDAP queries, I think this kind of URI > >> /ip/192.0.2.0/24 is more appropriate, especially in typical REST > design. > >> > >> > >> > >> Regards, > >> > >> Linlin > >> > >> > >> > >> *From:*weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > >> Behalf Of *Wil Tan > >> *Sent:* Wednesday, December 19, 2012 7:55 AM > >> *To:* Hollenbeck, Scott > >> *Cc:* weirds@ietf.org > >> *Subject:* [weirds] Query vs. Path (comment on > >> draft-ietf-weirds-rdap-query-02) > >> > >> > >> > >> I'd like to propose that we use URI query instead of path segments in > >> this specification. > >> > >> > >> > >> So, instead of: > >> > >> > >> > >> /ip/192.0.2.0/24 > >> > >> > >> > >> Use: > >> > >> > >> > >> /?type=ip&q=192.0.2.0/24 > >> > >> > >> > >> or > >> > >> > >> > >> /ip/?q=192.0.2.0/24 > >> > >> > >> > >> > >> > >> The main advantage to this approach is that there is a distinction > >> between a query vs. a known resource. IMO, the distinction is important. > >> The latter is returned as a full URL in the response body so there's no > >> need to standardize its representation, but the former is what this > >> draft is about. > >> > >> > >> > >> When a client is making a query, it may not know a whole lot about the > >> subject it is querying about. For example, it may not know the CIDR > >> block prefix and bitmask length. > >> > >> > >> > >> So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable > >> resource URL of "/ip/192.0.2.0/24 ". > >> > >> > >> > >> A positive side effect is that html forms automatically work without > >> client-side javascript. > >> > >> > >> > >> .wil > >> > >> > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >> > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --20cf3074b9fa8baa3404d136356b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 20, 2= 012 at 1:48 AM, Carlos M. Martinez <carlosm3011@gmail.com> wrote:
I agree. But, if I read it correctly, the original post ai= med to
differentiate between lookups and searches.


Thanks Carlos, indeed that's what = I meant.
=C2=A0
I read the original post as:

/ip/10.1.1.0/24 would = mean 'i want a lookup for this entry'

Right, and I agree that this is in line with REST style.

/ip?q=3D10.1.1.0/24 wo= uld mean 'search for something that covers this entry'


Right, it is a "search query"= ;, and would probably be most common in the case of address assignments, be= cause clients are likely to just pass in an IP, since it wouldn't know = the block length.

So for search queries, should we use something like the= following?

/ip?q=3D10.1.1.5 which would return a = response or redirect to /ip/10.1.1.0/24<= /div>


.wil

=C2=A0
But I perhaps misread it.

regards,

~Carlos

On 12/19/12 10:22 AM, Arturo Servin wrote:
>
> =C2=A0 =C2=A0 =C2=A0 Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST typ= e
> model.
>
> /as
>
> On 19/12/2012 00:16, Linlin Zhou wrote:
>> I think these 3 URIs are equivalent from the perspective of a clie= nt.
>> Query string like /?type=3Dip&q=3D192.0.2.0/24 usually represents the search
>> result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP
>> representation. For RDAP queries, I think this kind of URI
>> /ip/192.0.2.0/24= is more appropriate, especially in typical REST design.
>>
>>
>>
>> Regards,
>>
>> Linlin
>>
>>
>>
>> *From:*weirds-bounces@i= etf.org [mailto:weirds-bounc= es@ietf.org] *On
>> Behalf Of *Wil Tan
>> *Sent:* Wednesday, December 19, 2012 7:55 AM
>> *To:* Hollenbeck, Scott
>> *Cc:* weirds@ietf.org
>> *Subject:* [weirds] Query vs. Path (comment on
>> draft-ietf-weirds-rdap-query-02)
>>
>>
>>
>> I'd like to propose that we use URI query instead of path segm= ents in
>> this specification.
>>
>>
>>
>> So, instead of:
>>
>>
>>
>> =C2=A0 /ip/192.0= .2.0/24 <http://19= 2.0.2.0/24>
>>
>>
>>
>> Use:
>>
>>
>>
>> =C2=A0 /?type=3Dip&q=3D192.0.2.0/24 <http://192.0.2.0/24>
>>
>>
>>
>> or
>>
>>
>>
>> =C2=A0 /ip/?q=3D= 192.0.2.0/24 <http= ://192.0.2.0/24>
>>
>>
>>
>>
>>
>> The main advantage to this approach is that there is a distinction=
>> between a query vs. a known resource. IMO, the distinction is impo= rtant.
>> The latter is returned as a full URL in the response body so there= 's no
>> need to standardize its representation, but the former is what thi= s
>> draft is about.
>>
>>
>>
>> When a client is making a query, it may not know a whole lot about= the
>> subject it is querying about. For example, it may not know the CID= R
>> block prefix and bitmask length.
>>
>>
>>
>> So, sending a query of "/?type=3Dip&q=3D192.0.2.13" = may lead me to a stable
>> resource URL of "/ip/192.0.2.0/24 <http://192.0.2.0/24>".
>>
>>
>>
>> A positive side effect is that html forms automatically work witho= ut
>> client-side javascript.
>>
>>
>>
>> .wil
>>
>>
>>
>> _______________________________________________
>> weirds mailing list
>> weirds@ietf.org
>> https://www.ietf.org/mailman/listinfo/weirds
>>
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
>
_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--20cf3074b9fa8baa3404d136356b-- From aservin@lacnic.net Wed Dec 19 09:22:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B22E21F85A7 for ; Wed, 19 Dec 2012 09:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwgIIrevHoEZ for ; Wed, 19 Dec 2012 09:22:07 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0448521F844C for ; Wed, 19 Dec 2012 09:22:07 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:b7:7b15:c5ee:8d42]) by mail.lacnic.net.uy (Postfix) with ESMTP id 9F465308432; Wed, 19 Dec 2012 15:21:59 -0200 (UYST) Message-ID: <50D1F7B7.6080205@lacnic.net> Date: Wed, 19 Dec 2012 15:21:59 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wil Tan References: <014501cddd8e$e8515030$b8f3f090$@cn> <50D1B194.2010300@lacnic.net> <50D1D3C5.30609@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:22:08 -0000 I though searches was out of scope for now. Anyhow, it adds some complexity and I do not see the benefit. /as On 19/12/2012 13:23, Wil Tan wrote: > > On Thu, Dec 20, 2012 at 1:48 AM, Carlos M. Martinez > > wrote: > > I agree. But, if I read it correctly, the original post aimed to > differentiate between lookups and searches. > > > Thanks Carlos, indeed that's what I meant. > > > I read the original post as: > > /ip/10.1.1.0/24 would mean 'i want a lookup for > this entry' > > > Right, and I agree that this is in line with REST style. > > /ip?q=10.1.1.0/24 would mean 'search for > something that covers this entry' > > > Right, it is a "search query", and would probably be most common in the > case of address assignments, because clients are likely to just pass in > an IP, since it wouldn't know the block length. > > So for search queries, should we use something like the following? > > /ip?q=10.1.1.5 which would return a response or redirect to > /ip/10.1.1.0/24 > > > .wil > > > > But I perhaps misread it. > > regards, > > ~Carlos > > On 12/19/12 10:22 AM, Arturo Servin wrote: > > > > Agreed with Linlin. /ip/192.0.2.0/24 > is more appropriate in a REST type > > model. > > > > /as > > > > On 19/12/2012 00:16, Linlin Zhou wrote: > >> I think these 3 URIs are equivalent from the perspective of a client. > >> Query string like /?type=ip&q=192.0.2.0/24 > usually represents the search > >> result, but URI such as /ip/192.0.2.0/24 is > supposed to return an IP > >> representation. For RDAP queries, I think this kind of URI > >> /ip/192.0.2.0/24 is more appropriate, > especially in typical REST design. > >> > >> > >> > >> Regards, > >> > >> Linlin > >> > >> > >> > >> *From:*weirds-bounces@ietf.org > [mailto:weirds-bounces@ietf.org ] *On > >> Behalf Of *Wil Tan > >> *Sent:* Wednesday, December 19, 2012 7:55 AM > >> *To:* Hollenbeck, Scott > >> *Cc:* weirds@ietf.org > >> *Subject:* [weirds] Query vs. Path (comment on > >> draft-ietf-weirds-rdap-query-02) > >> > >> > >> > >> I'd like to propose that we use URI query instead of path segments in > >> this specification. > >> > >> > >> > >> So, instead of: > >> > >> > >> > >> /ip/192.0.2.0/24 > >> > >> > >> > >> Use: > >> > >> > >> > >> /?type=ip&q=192.0.2.0/24 > > >> > >> > >> > >> or > >> > >> > >> > >> /ip/?q=192.0.2.0/24 > >> > >> > >> > >> > >> > >> The main advantage to this approach is that there is a distinction > >> between a query vs. a known resource. IMO, the distinction is > important. > >> The latter is returned as a full URL in the response body so > there's no > >> need to standardize its representation, but the former is what this > >> draft is about. > >> > >> > >> > >> When a client is making a query, it may not know a whole lot > about the > >> subject it is querying about. For example, it may not know the CIDR > >> block prefix and bitmask length. > >> > >> > >> > >> So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a > stable > >> resource URL of "/ip/192.0.2.0/24 > ". > >> > >> > >> > >> A positive side effect is that html forms automatically work without > >> client-side javascript. > >> > >> > >> > >> .wil > >> > >> > >> > >> _______________________________________________ > >> weirds mailing list > >> weirds@ietf.org > >> https://www.ietf.org/mailman/listinfo/weirds > >> > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > From alexandrsergeyev@gmail.com Wed Dec 19 10:03:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA8E21F84DB for ; Wed, 19 Dec 2012 10:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iGHmNAQ84Z0 for ; Wed, 19 Dec 2012 10:03:51 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBB621F8480 for ; Wed, 19 Dec 2012 10:03:51 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t11so1123744wey.12 for ; Wed, 19 Dec 2012 10:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/zFA/Lg3l8eNVISsxE+yVwTKs1JGGqDFQP354uf32uE=; b=i0KlQ7UL+5tMw8i58VfoUW/SKHpGy2UUSghBeqw/IzeqOk5qI/kcv+kiqD+BS64TAq +riRKCxTIOVHYocdk52ds8MFR5+TTBnFxfstqLxZyvmrhEHqa3ZSjqFDwoG78L6qxgoC 96YFaZ1QX59foe6KV/Q4VFCT26zxZuof+PGCd64cenro0AD3pq/dFsUf6itCKR/sF1v8 OqxY4ZD8gV/VivkIWCQrpt2Q9f30G79tV9qkRoYCcvg+Yp++EWkzgibjwQOrIbGu2+Kl 4ZnqA85x6f8NFaqNHhAOfHfdstVBs6dwObKtYvrkC+FWzEBytK80VNBasX3EFkX+2OgY 9JhQ== MIME-Version: 1.0 Received: by 10.194.85.234 with SMTP id k10mr13022349wjz.53.1355940230323; Wed, 19 Dec 2012 10:03:50 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Wed, 19 Dec 2012 10:03:50 -0800 (PST) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898C06A@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E57898BF54@CHAXCH01.corp.arin.net> <62D9228640AC7F49B2DD9ED0C9CE60E57898C06A@CHAXCH01.corp.arin.net> Date: Wed, 19 Dec 2012 13:03:50 -0500 X-Google-Sender-Auth: 2fJasmO3Y5GgMhZCpAYbWMgNy_A Message-ID: From: Alex Sergeyev To: Andy Newton Content-Type: text/plain; charset=UTF-8 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:03:52 -0000 Ah, great, one more question.... Does DNR object not supposed to have "roles" field in entities at all? It's not in example and I wonder if that should be some kind of "registrant/billing/tech" or something or it's planned to not do this in DNR? Alex. On Tue, Dec 18, 2012 at 5:23 PM, Andy Newton wrote: > On 12/18/12 2:27 PM, "Andy Newton" wrote: > >>One was pointed out to me. If you see others please let me know. >>I'll see about running some additional checks. > > Actually, I went through all of them and fixed them. Thanks. > > -andy > From alexandrsergeyev@gmail.com Wed Dec 19 11:02:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FFD21F862D for ; Wed, 19 Dec 2012 11:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwusz1-9ri-O for ; Wed, 19 Dec 2012 11:02:51 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0ED21F8689 for ; Wed, 19 Dec 2012 11:02:49 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1094541wgb.13 for ; Wed, 19 Dec 2012 11:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=3dYV7WBhJPBZv1hrRc8Qv+wMJSoTjLi/wBTfj8Gg5vg=; b=LlAplvMYYuDJfGXf+47xhdgtWVQa31gBx71hSmviDALIiOAaM1gOO33a1eSR04MJpv fGk1N3/8HIAniZv0MlR4fb7UWtFbVCrDGVBsMOjFaNm1yO3LsnW/ELUaPyIFBfDlTZDK GTK9uSrbd8yobP9sfi3p2yotJuV3Yct+VkbSUzvluPFotoFuNKDVuIwXCKakp2+V3oWp H+bp0SZGCnCHttbbVbEwDQXbOu8nubhcmsAfXU+xLs7Lhwqokkmf2KgOvXvVK/m+5eTQ 1K/I0BV5w2SDoOwAEhZG28AsFY1S4Yv5LvYJDzS1HjuXorSPPZPFmovrWXPFcOhRz4DI t6Ww== MIME-Version: 1.0 Received: by 10.180.100.163 with SMTP id ez3mr5791135wib.24.1355943768566; Wed, 19 Dec 2012 11:02:48 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Wed, 19 Dec 2012 11:02:48 -0800 (PST) Date: Wed, 19 Dec 2012 14:02:48 -0500 X-Google-Sender-Auth: ZAg778vq8KxV7e1iYL35mHbnDfo Message-ID: From: Alex Sergeyev To: weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [weirds] JSON generation python lib X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 19 Dec 2012 19:02:51 -0000 All, I'm currently working on improving experimental weirds code that we run in Dyn, same time I was going thru new proposals, and modified lib we published 5 months ago. https://github.com/dyninc/flask-weirds This has interesting component, objects.py that I'll try to keep updated according to draft-ietf-weirds-json-response in future. You can see that I'm lazy programmer and did not really write enough tests, but more of a demonstration that lib works: https://github.com/dyninc/flask-weirds/blob/master/flask_weirds/objects_test.py Anyway. In order to play with it over REST you'll need to have flask (pip install flask) and some modules that flask requires. You may not install this module to your system just play with it in command line, something like this: ------------------ asergeyev@:~$ python weirdsexample.py --debug Running the app, you should be able to query http://hostname:5000/fakedomain/example.org ... Try also .net .edu .info and other domains and later with "example:password" authentication. * Running on http://0.0.0.0:5000/ * Restarting with reloader Running the app, you should be able to query http://hostname:5000/fakedomain/example.org ... Try also .net .edu .info and other domains and later with "example:password" authentication. -------------------- It's really minimalistic app that only knows few "fakedomain" objects and nothing else.... Using different screen you might do: ------------------ asergeyev@:~$ curl -L http://127.0.0.1:5000/fakedomain/example.net { "name": "example.net" } asergeyev@:~$ curl -L http://example:password@127.0.0.1:5000/fakedomain/example.net { "entities": { "entityNames": [ "Internet Assigned Numbers Authority" ] }, "name": "example.net", "remarks": [ "You're very valuable for us and we'll give you all the info." ] } asergeyev@:~$ curl -L http://127.0.0.1:5000/fakedomain/example.biz { "errorCode": 65281, "description": [ "Requested object was not found in our database." ], "title": "Not Found" } ------------------ Or use "rdapper" mentioned on the list earlier: ------------------ asergeyev@:rdapper (master)$ ./rdapper --host=localhost:5000 --TYPE=fakedomain example.net Name : example.net asergeyev@:rdapper (master)$ ./rdapper --host=localhost:5000 --TYPE=fakedomain example.biz Error: 404 Not Found ------------------ I did not look hard enough to make rdapper understand authentication (obvious --username and --password did not help). Really want to get to our public-facing weirds first. Hope it has some value for this WG and wish you all happy holidays. Alex. From gavin.brown@centralnic.com Thu Dec 20 02:16:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEA321F8778 for ; Thu, 20 Dec 2012 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or9Y43BZWTgv for ; Thu, 20 Dec 2012 02:16:16 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 301F821F879E for ; Thu, 20 Dec 2012 02:16:16 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 7CCBA712B90; Thu, 20 Dec 2012 10:16:09 +0000 (UTC) Message-ID: <50D2E569.4030407@centralnic.com> Date: Thu, 20 Dec 2012 10:16:09 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: abc@alexsergeyev.com, weirds@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] JSON generation python lib X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Dec 2012 10:16:17 -0000 > I did not look hard enough to make rdapper understand authentication > (obvious --username and --password did not help). Really want to get > to our public-facing weirds first. Authentication was added on tuesday - it should work with any server supporting basic authentication (it certainly works with ours). SSL client cert support was also added at the same time. One gotcha is that rdapper constructs its own "Authorization" header rather than using LWP::UserAgent's credentials() method, for the reason that I imagine that if there was a server, supporting both anonymous and authenticated clients, the server would not send a 401 response, which would cause LWP::UserAgent to resubmit with the provided credentials. If you had a server that used digest authentication, then you'd have to have a separate endpoint for authenticated access, in order to send the nonce to the client. 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 gavin.brown@centralnic.com Thu Dec 20 02:59:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522FC21F860A for ; Thu, 20 Dec 2012 02:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGqGsl1vXslF for ; Thu, 20 Dec 2012 02:59:27 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE621F85DC for ; Thu, 20 Dec 2012 02:59:27 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 21CE6712C38; Thu, 20 Dec 2012 10:59:25 +0000 (UTC) Message-ID: <50D2EF8C.307@centralnic.com> Date: Thu, 20 Dec 2012 10:59:24 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:59:28 -0000 On 19/12/2012 14:59, Andy Newton wrote: > That's an interesting compromise. I would suggest > > "postalAddress" : > { > "structured" : > { > ... > }, > "flat" : > [ > ... > ] > } Agreed - although I think there should be some wording to encourage implementers to pick and use one type only, rather than duplicating the data in both types of structure (which the extract above seems to do). > I do think we need to ask the question of why we need structured postal > addresses though. Is it for automated sending of postal mail? I would > think that from a law enforcement point of view, a human is ALWAYS gonna > interpret the address so a flat structure is fine. Even if a human is responsible for parsing the address, there are situations where there is ambiguity. If you have an address like this: "postalAddress": [ "123 Example Street", "Exampletown", "NL", ], "NL" could be "Netherlands" or "Newfoundland" - you'd have to find out the meaning and order of the fields via an out-of-band process. With a structured address, the client and end-user know instantly whether the postage for their letter is domestic or international. For example of where having structured data is useful, consider: 1. law enforcement and anti-abuse people who may need to programmatically determine the jurisdiction in which the registrants of a large number of resources reside, where the number of records is large enough that manual inspection is impractical, or 2. Maintainers of "Geo IP" and "ASN to Country" databases, or other aggregations of registration data. 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 alexandrsergeyev@gmail.com Thu Dec 20 03:53:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A175721F8816 for ; Thu, 20 Dec 2012 03:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTxn8YRD97xl for ; Thu, 20 Dec 2012 03:53:09 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90F21F8812 for ; Thu, 20 Dec 2012 03:53:09 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id r6so1534673wey.10 for ; Thu, 20 Dec 2012 03:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CvTCY22gxRKajEdc0a4TDXdU1d6k24hr/Z8X5hrvWtY=; b=QEGfOOVTIDFAEDZZnSttMrJtGuJoWANi1e0n/rNDdGpfBDZPEPyMH869mdlGzeYqTS 2jT/KFXX5yc5HZfjKBz+z+hedMhr/UAqrZuZzJmSavgip4SiceRrV4SVMUhdaFj/mn/O SmxktjcEbWwf/XRaNGNtO6Lt8yDRCeObGfyZRp4lXd8cueWno9/ucBLufa9cr9AB2ObG l67qjPJ8MZRewWTHgjClM/paVMlXDn+4wt0pTlfgCcRkNy2hr4+BKZjLU02gl+b7Ih5+ IbeNOVcEgALV07Ub5Y4/H/OTjo/o+88GRMN0QIk/O1oNqqgsTd6jLOBYzRDDJjuSi4t9 zVpg== MIME-Version: 1.0 Received: by 10.194.171.198 with SMTP id aw6mr3259429wjc.3.1356004388557; Thu, 20 Dec 2012 03:53:08 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Thu, 20 Dec 2012 03:53:08 -0800 (PST) In-Reply-To: <50D2E569.4030407@centralnic.com> References: <50D2E569.4030407@centralnic.com> Date: Thu, 20 Dec 2012 06:53:08 -0500 X-Google-Sender-Auth: 288YyVUIezbYAqkMkod8L8ekEyM Message-ID: From: Alex Sergeyev To: Gavin Brown Content-Type: text/plain; charset=UTF-8 Cc: weirds@ietf.org Subject: Re: [weirds] JSON generation python lib X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Dec 2012 11:53:10 -0000 On Thu, Dec 20, 2012 at 5:16 AM, Gavin Brown wrote: > One gotcha is that rdapper constructs its own "Authorization" header > rather than using LWP::UserAgent's credentials() method, for the reason > that I imagine that if there was a server, supporting both anonymous > and authenticated clients, the server would not send a 401 response, > which would cause LWP::UserAgent to resubmit with the provided credentials. Server supporting both authenticated and public access to data is my case. (I think if auth supplied it should be sent to the server by your app) BTW, I offered it before because it's just how some clients work, it would be good to have optional way to specify smth like this in the request: /domain/example.net?drop_privileges (server ignores auth even if my HTTP client sends it) /domain/example.net?require_auth (server would fail with 401 if no auth is supplied) There is many libs around that would do things in irritating manner with HTTP Auth. All browsers, will not drop authentication (not sure if you can force it by Javascript), therefore plugins or dynamic scripts would not be able to request "regular" version of documents once permissions with username/password are elevated. BTW It's relatively trivial to add digest auth to my example app. If you do it faster than I'll get to it, feel free to send pull request. Alex. From jaap@NLnetLabs.nl Thu Dec 20 06:39:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49721F88F5 for ; Thu, 20 Dec 2012 06:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiGHPLqL+hav for ; Thu, 20 Dec 2012 06:39:06 -0800 (PST) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id B8FBF21F85E8 for ; Thu, 20 Dec 2012 06:39:05 -0800 (PST) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id qBKEcoiO087496; Thu, 20 Dec 2012 15:38:51 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201212201438.qBKEcoiO087496@bela.nlnetlabs.nl> To: Andy Newton In-reply-to: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> Comments: In-reply-to Andy Newton message dated "Wed, 19 Dec 2012 14:59:41 +0000." Date: Thu, 20 Dec 2012 15:38:50 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bela.nlnetlabs.nl [127.0.0.1]); Thu, 20 Dec 2012 15:38:57 +0100 (CET) Cc: "weirds@ietf.org" , Gavin Brown Subject: Re: [weirds] Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:39:07 -0000 [I think I'm reacting on Andy's mail here but I might attribute this to the wrong person. Apologies in that case]. > That's an interesting compromise. I would suggest > > "postalAddress" : > { > "structured" : > { > ... > }, > "flat" : > [ > ... > ] > } I find it a bit odd to have twice the same data. The way the data is presented to the user is to my taste more a presentation issue then a protocol issue. It is also way easier to remove structure then going the reverse, therefore I would prefer to go for a structured approach. And if we have to figure out which structured format to use, EPP seems the most reasonable to me. Given that a lot provisioning is done using EPP, that is an obvious choice. I don't remember where the format which EPP comes from, but it might be useful to look at other formats as well. As an example, the UPU has an addressing standard (S42. see ). They also have an expert group which collects the various templates using the terminology of this standard. This standard is under currently revision in cooperation with ISO/TC 211 as well as the ISO 19160 addressing project (see ). I do think we need to ask the question of why we need structured postal addresses though. Is it for automated sending of postal mail? I would think that from a law enforcement point of view, a human is ALWAYS gonna interpret the address so a flat structure is fine. For machine readable exchange of address information there is the UPU standard S53. This standards uses elements as defined in the S42 and uses XML. Still, it will be advisable use at minimum as inspiration. It might be that only humans look at the data which comes of "the word protocol" but understanding by humans is often aided by a structural presentation. jaap From aservin@lacnic.net Thu Dec 20 06:50:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D949D21F884F for ; Thu, 20 Dec 2012 06:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxOHG32N-yxa for ; Thu, 20 Dec 2012 06:50:47 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0B721F880A for ; Thu, 20 Dec 2012 06:50:47 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:d0:4724:31fc:a2b]) by mail.lacnic.net.uy (Postfix) with ESMTP id 894D330843E for ; Thu, 20 Dec 2012 12:50:34 -0200 (UYST) Message-ID: <50D325BB.9080106@lacnic.net> Date: Thu, 20 Dec 2012 12:50:35 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <62D9228640AC7F49B2DD9ED0C9CE60E57898C2C6@CHAXCH01.corp.arin.net> <201212201438.qBKEcoiO087496@bela.nlnetlabs.nl> In-Reply-To: <201212201438.qBKEcoiO087496@bela.nlnetlabs.nl> X-Enigmail-Version: 1.4.6 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] Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:50:48 -0000 On 20/12/2012 12:38, Jaap Akkerhuis wrote: > [I think I'm reacting on Andy's mail here but I might attribute this > to the wrong person. Apologies in that case]. > > > That's an interesting compromise. I would suggest > > > > "postalAddress" : > > { > > "structured" : > > { > > ... > > }, > > "flat" : > > [ > > ... > > ] > > } > > > I find it a bit odd to have twice the same data. The way the data is > presented to the user is to my taste more a presentation issue then a > protocol issue. It is also way easier to remove structure then going > the reverse, therefore I would prefer to go for a structured approach. I think it is only one of the two. If you have structured data, you serve that. Otherwise you serve the flat. Regards /as From wendy@seltzer.org Thu Dec 20 09:49:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E2C21F8A71 for ; Thu, 20 Dec 2012 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_12=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnwO517EURlT for ; Thu, 20 Dec 2012 09:49:55 -0800 (PST) Received: from mail.seltzer.org (peppercorn.seltzer.org [166.84.7.31]) by ietfa.amsl.com (Postfix) with ESMTP id B6FE821F8931 for ; Thu, 20 Dec 2012 09:49:55 -0800 (PST) Message-ID: <50D34FC1.6010003@seltzer.org> Date: Thu, 20 Dec 2012 12:49:53 -0500 From: Wendy Seltzer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <0.1.3B.B1E.1CDDA4FEBF0BC90.0@drone096.ral.icpbounce.com> In-Reply-To: <0.1.3B.B1E.1CDDA4FEBF0BC90.0@drone096.ral.icpbounce.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [weirds] FWD: ICANN News Alert -- Expert Working Group on gTLD Directory Services Launched X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Dec 2012 17:49:56 -0000 This group might be able to provide or suggest some experts to ICANN's new "Expert Working Group". Deadline for expression of interest Dec. 31. --Wendy On Fri, Dec 14, 2012 at 6:08 PM, ICANN News Alert wrote: > ** > [image: ICANN] News Alert > > http://www.icann.org/en/news/announcements/announcement-2-14dec12-en.htm > ------------------------------ > Expert Working Group on gTLD Directory Services Launched > > 14 December 2012 > > *13 December 2012...* Fadi Chehadé, ICANN's President and CEO, is > announcing the creation of an Expert Working Group on gTLD Directory > Services. This first step in fulfilling the ICANN Board's directiveto help redefine the purpose and provision of gTLD registration data will > provide a foundation to help the ICANN community (through the Generic Names > Supporting Organization, GNSO) create a new global policy for gTLD > directory services. The working group will be chaired by Jean-Francois > Baril, > as the group's Lead Facilitator, and interested individuals with the > requisite experience are invited to indicate their interest in serving as > volunteer working group members (more information below). Board Chair, > Steve Crocker, and Director, Chris Disspain, will serve as Board liaisons > to the working group. > > The objectives of the working group are to 1) define the purpose of > collecting and maintaining gTLD registration data, and consider how to > safeguard the data, and 2) provide a proposed model for managing gTLD > directory services that addresses related data accuracy and access issues, > while taking into account safeguards for protecting data. This output will > feed into a Board-initiated GNSO policy development process to serve as a > foundation for the GNSO's creation of new consensus policy, and requisite > contract changes, as appropriate. The working group will be informed by the > WHOIS Policy Working Group's report[PDF, 1.44 MB] and previous community input and GNSO work over the last > decade, will address key questions set forth by the Security and Stability > Advisory Committee (SSAC) in their report, SAC055 > 1[PDF, > 348 KB], and will take into consideration current and future Internet > operations and services. The working group also will address concerns of > the parties who provide, collect, maintain, publish or use this data as it > relates to ICANN's remit. > > ICANN staff will publish an issues report that incorporates the working > group's output, which will form the basis of a Board-initiated GNSO PDP. > ICANN and its leadership will be focused on facilitation of the expedited > policy work to enable the GNSO to recommend a consensus policy that, at a > minimum, addresses the purpose of collecting, maintaining and making > available gTLD registration data, and related data accuracy and access > issues. Such a policy would be contractually binding on ICANN accredited > gTLD registrars and gTLD registries upon adoption by the ICANN Board. > Working Group Schedule and Operations > > The working group will conduct its activities from January through April > 2013 and may be extended, if needed. Work will be conducted primarily > online and through conference calls, and two face-to-face meetings are > expected. The working group will periodically provide public updates on its > progress, and output from the working group is expected to be presented for > community discussion online and at the ICANN Beijing meeting in April 2013. > ICANN Staff will support the working group. > Working Group Volunteers > > Qualified individuals are being identified to participate in the working > group. Individuals with the following characteristics are invited to > indicate their interest in serving as volunteer working group members by > sending an expression of interest and their resume/CV by email to > expertworkinggroup@icann.org by 31 December 2012. > > Volunteer working group members should: have significant operational > knowledge and experience with WHOIS, registrant data, or directory > services; be open to new ideas and willing to forge consensus; be able to > think strategically and navigate conflicting views; have a record of > fostering improvements and delivering results; have a desire to create a > new model for gTLD directory services; and be able to volunteer > approximately 12-20 hours a month during January – April 2013 to the > working group. Individuals who have worked extensively in the areas of > registration data collection, access, accuracy, use, privacy, security, law > enforcement, and standards and protocols are also encouraged to consider > working group membership. As the working group will be a collection of > experts, it is not expected to be comprised solely of representatives of > current ICANN community interests. Although members may not come directly > from ICANN structures, the working group will have a deep understanding of, > and concern for, the ICANN communities' interests.The working group's > results will feed into the GNSO's bottom-up, policy development process > where all community interests will be encouraged to participate in the > decision-making efforts. > > ICANN will reimburse working group members for travel and other expenses > associated with working group activities, per ICANN reimbursement rules. > ------------------------------ > > 1In SAC055, SSAC called for an expert working group to define the purpose of > collecting and maintaining gTLD registration data and address questions > such as: Why are data collected? What purpose will the data serve? Who > collects the data? Where is the data stored and how long is it stored? > Where is the data escrowed and how long is it escrowed? Who needs the data > and why? Who needs access to logs of access to the data and why? > > > From simon.perreault@viagenie.ca Fri Dec 21 06:13:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9ED21F84DB for ; Fri, 21 Dec 2012 06:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChfrW7+nT4bj for ; Fri, 21 Dec 2012 06:13:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5654621F843E for ; Fri, 21 Dec 2012 06:13:55 -0800 (PST) Received: from porto.nomis80.org (unknown [195.98.238.107]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B49EA4044F for ; Fri, 21 Dec 2012 09:13:54 -0500 (EST) Message-ID: <50D46EA1.6050307@viagenie.ca> Date: Fri, 21 Dec 2012 15:13:53 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <50D1C73D.6050801@centralnic.com> In-Reply-To: <50D1C73D.6050801@centralnic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:13:56 -0000 Please allow me to remind everyone that the IETF has a standard for such information: vCard. Let's use it and focus on WEIRDS, not on postal address formats. And there is a draft about a JSON representation for vCard: http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 It's really straightforward IMHO... Simon Le 2012-12-19 14:55, Gavin Brown a écrit : > Postal address information for entities is returned in a flat array format: > > "postalAddress" : > [ > "123 Maple Ave", > "Suite 90001", > "Vancouver", > "BC", > "12393" > ], > > For any registry whose database design was developed to support EPP, > this is quite lossy, since the specific meaning of each field is lost. > > I suggest that in addition to the above format, the standard should also > permit a full object, like so: > > "postalAddress" : > { > street: [ "123 Maple Ave", "Suite 90001", ], > city: "Vancouver", > sp: "BC", > pc: "12393", > cc: "CA" > }, > > It would be pretty easy for clients to work out which model was being > used, and handle it accordingly. Servers should use one model or the > other, but not both. > > G. > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From andy@arin.net Fri Dec 21 06:34:44 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D863D21F862D for ; Fri, 21 Dec 2012 06:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pba9Ak1eAKgu for ; Fri, 21 Dec 2012 06:34:44 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B221F8628 for ; Fri, 21 Dec 2012 06:34:43 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 54C6A213684; Fri, 21 Dec 2012 09:34:43 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id DBB9321364C; Fri, 21 Dec 2012 09:34:42 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Dec 2012 09:34:21 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 21 Dec 2012 09:34:42 -0500 From: Andy Newton To: Alex Sergeyev Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-01 Thread-Index: AQHN3UzKJ6O9dpucTkCmu3GOLCz35Zge8OwAgAAxBYCAAZ2sAIAClh0A Date: Fri, 21 Dec 2012 14:34:40 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2C9@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.2.5.121010 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] Comments on draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:34:45 -0000 On 12/19/12 1:03 PM, "Alex Sergeyev" wrote: >Does DNR object not supposed to have "roles" field in entities at all? >It's not in example and I wonder if that should be some kind of >"registrant/billing/tech" or something or it's planned to not do this >in DNR? No, it can have them. If we are beginning to find the split between the RIR and DNR "inheritance" a little cumbersome, I can merge the two. This split was originally done to show the unification of the RIR and DNR world. But if the working group is past that then perhaps the document would be easier to read if the two models were fully merged. I'm looking for opinions here. -andy From andy@arin.net Fri Dec 21 06:42:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0FC21F843A for ; Fri, 21 Dec 2012 06:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhXrP8DifQes for ; Fri, 21 Dec 2012 06:42:27 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 88F5721F842E for ; Fri, 21 Dec 2012 06:42:27 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 2571616527B; Fri, 21 Dec 2012 09:42:27 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9086A165254; Fri, 21 Dec 2012 09:42:26 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Dec 2012 09:42:07 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 21 Dec 2012 09:42:25 -0500 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 Thread-Index: AQHN34lkRD0kTNYfFEO9DkSyvw/kFA== Date: Fri, 21 Dec 2012 14:42:25 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2F4@CHAXCH01.corp.arin.net> In-Reply-To: <50D46EA1.6050307@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:42:28 -0000 On 12/21/12 9:13 AM, "Simon Perreault" wrote: >Please allow me to remind everyone that the IETF has a standard for such >information: vCard. Let's use it and focus on WEIRDS, not on postal >address formats. > >And there is a draft about a JSON representation for vCard: >http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 > >It's really straightforward IMHO... > >Simon Simon, I think the issue here is if registries have the data store in a way that they can fill out a vCard structure. The EPP structure is likely the most common for this community. Perhaps we should see if the EPP structure maps into vCard. Of course, none of this gets us away from needing a flat structure. Can vCard accommodate that? -andy From alexandrsergeyev@gmail.com Fri Dec 21 07:19:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21621F84C2 for ; Fri, 21 Dec 2012 07:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18u9rdvcPsGE for ; Fri, 21 Dec 2012 07:19:55 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F521F872E for ; Fri, 21 Dec 2012 07:19:55 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn3so2820948wib.17 for ; Fri, 21 Dec 2012 07:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hoVYvWWZ8hchKUkvx/qhLnqd+N1StOh04OJtxqFyJw4=; b=wJxsgjPVCPbbgMR257bTn/y8sN5yqJxuztTtpacpBakCVGrS7W62MM4ZWlijfEtLJh rQ2Co8rGjiQM7xt/rmjJqCl+pycn47dJiL/SV2QWP2ipmeMBTOSABve1qDqnY1x4ZY0E vP2TDFpj26Ptu4Najoc6fZJRoqee/mi1KyoYhb94ktCCcqxhzvGwojdhFKJe775gN3RJ 4GoPyt396dn6rsEnyHpKxahebaNG5BvbZfhjQtWoRKYF2hmBO8hT3bmqIJCZta6oWQRx 4/4ACF/MyPNXmm3LtFf7Rba1gZQ3t2AvzB92CNp89U1BAilTOvOBAYI0CweHx0h4CUKD gBcA== MIME-Version: 1.0 Received: by 10.180.20.177 with SMTP id o17mr16217206wie.24.1356103193953; Fri, 21 Dec 2012 07:19:53 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Fri, 21 Dec 2012 07:19:53 -0800 (PST) In-Reply-To: References: <50D1C73D.6050801@centralnic.com> <50D46EA1.6050307@viagenie.ca> Date: Fri, 21 Dec 2012 10:19:53 -0500 X-Google-Sender-Auth: 7vvsAMn-OqgsX4ivoEUxcvdlCR4 Message-ID: From: Alex Sergeyev To: weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:19:56 -0000 > Please allow me to remind everyone that the IETF has a standard for such > information: vCard. Let's use it and focus on WEIRDS, not on postal addre= ss > formats. Earlier this year many people mentioned that they just don't have ability to present structured data. vCard is even more structured than EPP, it would be hard to get there. Now back to having both "flat" and "structured" in postalAddress.... I like structured data but I think that having many ways to present the info makes it harder for clients to parse and adds more ability for server software engineers to get creative. Also: * there is nothing good from additional nesting, adds complexity and points for potential exception handling * extensions will randomly use hashes and "structured/flat" approach following the example (I truly assume that weirds might be universal "object info" protocol, not just for replacing whois) I would offer this: * keep presentation as plain ordered string list * make server able to provide postalAddressFields list that describes positions that were used e.g "postalAddress" : [ "123 Maple Ave", "Suite 90001", "Vancouver", "BC", "12393", "CA" ], "postalAddressFields": [ "street", "street", "city", "sp", "postal", "cc" ] with list of appropriate strings in appendix (mine are from attempts to recall EPP) I also think such approach could be used elsewhere - phones, emails, entityNames.... (wording for "*Fields" is tricky... essentially I wish it would be "must if it has ability to reveal data structure") Still feel it's not ideal but at least it gives schema that everyone should follow when extending things. -- Alex. On Fri, Dec 21, 2012 at 9:13 AM, Simon Perreault wrote: > > And there is a draft about a JSON representation for vCard: > http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 > > It's really straightforward IMHO... > > Simon > > > Le 2012-12-19 14:55, Gavin Brown a =C3=A9crit : >> >> Postal address information for entities is returned in a flat array >> format: >> >> "postalAddress" : >> [ >> "123 Maple Ave", >> "Suite 90001", >> "Vancouver", >> "BC", >> "12393" >> ], >> >> For any registry whose database design was developed to support EPP, >> this is quite lossy, since the specific meaning of each field is lost. >> >> I suggest that in addition to the above format, the standard should also >> permit a full object, like so: >> >> "postalAddress" : >> { >> street: [ "123 Maple Ave", "Suite 90001", ], >> city: "Vancouver", >> sp: "BC", >> pc: "12393", >> cc: "CA" >> }, >> >> It would be pretty easy for clients to work out which model was being >> used, and handle it accordingly. Servers should use one model or the >> other, but not both. >> >> G. >> > > > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From simon.perreault@viagenie.ca Fri Dec 21 07:32:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90F621F869B for ; Fri, 21 Dec 2012 07:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu2C5VZ6e26B for ; Fri, 21 Dec 2012 07:32:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0557C21F84EA for ; Fri, 21 Dec 2012 07:32:30 -0800 (PST) Received: from porto.nomis80.org (unknown [195.98.238.107]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 58FE04044F; Fri, 21 Dec 2012 10:32:29 -0500 (EST) Message-ID: <50D4810C.3010304@viagenie.ca> Date: Fri, 21 Dec 2012 16:32:28 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Newton References: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2F4@CHAXCH01.corp.arin.net> In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2F4@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] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:32:30 -0000 Le 2012-12-21 15:42, Andy Newton a écrit : > I think the issue here is if registries have the data store in a way that > they can fill out a vCard structure. The EPP structure is likely the most > common for this community. Perhaps we should see if the EPP structure maps > into vCard. Of course, none of this gets us away from needing a flat > structure. Can vCard accommodate that? Let's see what RFC 5733 contains... I'm looking for correspondence with vCard elements from RFC 6350. > 2.3. Individual and Organizational Names ........................5 Correspond to vCard properties FN and ORG. > 2.4. Address ....................................................6 > 2.4.1. Street, City, and State or Province .................6 > 2.4.2. Postal Code .........................................6 > 2.4.3. Country .............................................6 Corresponds to vCard property ADR. > 2.5. Telephone Numbers ..........................................6 Corresponds to vCard property TEL. > 2.6. Email Addresses ............................................6 Corresponds to vCard property EMAIL. > 2.7. Dates and Times ............................................6 Corresponds to the various and usual vCard date/time data types. Did I miss anything? Based on this overview I think vCard can easily represent EPP contact information. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Dec 21 07:33:09 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9A721F8667 for ; Fri, 21 Dec 2012 07:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEqFnjpL75zv for ; Fri, 21 Dec 2012 07:33:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B127A21F84EA for ; Fri, 21 Dec 2012 07:33:08 -0800 (PST) Received: from porto.nomis80.org (unknown [195.98.238.107]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4D9604044F for ; Fri, 21 Dec 2012 10:33:07 -0500 (EST) Message-ID: <50D48132.1010800@viagenie.ca> Date: Fri, 21 Dec 2012 16:33:06 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "weirds@ietf.org" References: <50D1C73D.6050801@centralnic.com> <50D46EA1.6050307@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:33:09 -0000 Le 2012-12-21 16:18, Alex Sergeyev a écrit : >> Please allow me to remind everyone that the IETF has a standard for such >> information: vCard. Let's use it and focus on WEIRDS, not on postal address >> formats. > Earlier this year many people mentioned that they just don't have > ability to present structured data. vCard is even more structured > than EPP, it would be hard to get there. > Now back to having both "flat" and "structured" in postalAddress.... vCard has both a structured postal address property (ADR) and an unstructured one (LABEL), precisely because structured does not work for everyone and every situation. Look, vCard has been around for a long time. It has been used a lot, and it has evolved with practice. What you want is probably in it. > I like structured data but I think that having many ways to present > the info makes it harder for clients to parse and adds more ability > for server software engineers to get creative. Also: > * there is nothing good from additional nesting, adds complexity and > points for potential exception handling Who said anything about nesting? vCard is a flat list of properties. That's it. > * extensions will randomly use hashes and "structured/flat" approach > following the example (I truly assume that weirds might be universal > "object info" protocol, not just for replacing whois) WEIRDS could specify a restricted "profile" of vCard. It has been done before: http://tools.ietf.org/html/rfc6493 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From andy@arin.net Fri Dec 21 07:53:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E751221F8775 for ; Fri, 21 Dec 2012 07:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAE6+OBhhQdV for ; Fri, 21 Dec 2012 07:53:25 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 375CC21F85C3 for ; Fri, 21 Dec 2012 07:53:25 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id DF05321364E; Fri, 21 Dec 2012 10:53:24 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 467002135F0; Fri, 21 Dec 2012 10:53:24 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Dec 2012 10:52:56 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Fri, 21 Dec 2012 10:53:16 -0500 From: Andy Newton To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 Thread-Index: AQHN35C5Rc1JFg4f6E2bw8fFXtt0lZgjZ3AA Date: Fri, 21 Dec 2012 15:53:15 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> In-Reply-To: <50D48132.1010800@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:53:26 -0000 On 12/21/12 10:33 AM, "Simon Perreault" wrote: >vCard has both a structured postal address property (ADR) and an >unstructured one (LABEL), precisely because structured does not work for >everyone and every situation. I think that solves our requirement. I assume we would be embedding these vCards. Is that correct? Are there other opinions regarding switching to vCard? -andy From alexandrsergeyev@gmail.com Fri Dec 21 07:56:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E321F8792 for ; Fri, 21 Dec 2012 07:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWFudkxMe2sn for ; Fri, 21 Dec 2012 07:56:20 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by ietfa.amsl.com (Postfix) with ESMTP id BB2B121F86C3 for ; Fri, 21 Dec 2012 07:56:19 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id r5so2289876wey.35 for ; Fri, 21 Dec 2012 07:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QC1FGRUpXql/Xqqur/lYpY46OfQYpdJUamSrYvJjdDU=; b=q3Op3cEXufIDUOeM46uEF4wTn6Q6kFMUn9RVNqzUaf0GHFz8ng3AKlVZen9Nq3epzb h9opZgQORd18hlrS1AuqToYR5EqFBukKLr/9AxjLUhZ6yTwmmCAHmq9jSZXUqGwPZtzJ egJ9UWo7UXMDaE2YfK9px8eVZB8mbOUD88bnBWkYAHZF8rf/r71RRejxVtffcgDOH3Ek qq04Evhx35GVTWlFYAYInghq5tC9voi7zxdGjjVtAeSp4GyH+x3WNgNqzjzLXIiTv6Lj mFXfZwYAhAFgykdGPggnth3OiBQGnbLbVpVEq7+AgaOFwJoAZyUOjMB81qNHqv2Z/3z3 jhqQ== MIME-Version: 1.0 Received: by 10.194.85.234 with SMTP id k10mr24336509wjz.53.1356105378767; Fri, 21 Dec 2012 07:56:18 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.217.43.195 with HTTP; Fri, 21 Dec 2012 07:56:18 -0800 (PST) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> References: <50D48132.1010800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> Date: Fri, 21 Dec 2012 10:56:18 -0500 X-Google-Sender-Auth: B3QEcZl5Tv0ifyKtgibnPmCy8jY Message-ID: From: Alex Sergeyev To: Andy Newton Content-Type: text/plain; charset=UTF-8 Cc: "weirds@ietf.org" Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:56:21 -0000 just want to clarify below: >>vCard has both a structured postal address property (ADR) and an >>unstructured one (LABEL), precisely because structured does not work for >>everyone and every situation. > I think that solves our requirement. > I assume we would be embedding these vCards. Is that correct? > Are there other opinions regarding switching to vCard? whole "entities" concept gets replaced to "vcards" or it's only for postalAddress? -- Alex From simon.perreault@viagenie.ca Fri Dec 21 08:07:32 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FC121F87F4 for ; Fri, 21 Dec 2012 08:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmIHGqKpsnzv for ; Fri, 21 Dec 2012 08:07:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B721F86A4 for ; Fri, 21 Dec 2012 08:07:31 -0800 (PST) Received: from porto.nomis80.org (unknown [195.98.238.107]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C031240453; Fri, 21 Dec 2012 11:07:29 -0500 (EST) Message-ID: <50D48941.8040207@viagenie.ca> Date: Fri, 21 Dec 2012 17:07:29 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alex Sergeyev References: <50D48132.1010800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:07:33 -0000 Le 2012-12-21 16:56, Alex Sergeyev a écrit : > whole "entities" concept gets replaced to "vcards" or it's only for > postalAddress? Looking at this: http://tools.ietf.org/html/draft-ietf-weirds-json-response-01#section-7.1 I think some elements would be replaced by a vCard, some others would remain WEIRDS' business. Replaced by a vCard: entityNames postalAddress emails phones In WEIRDS: remarks (although vCard has a NOTE property... not sure) links (although vCard has a URL property... not sure) handle roles registrationDate lastChangedDate (vCard has a REV property with a timestamp value) lastChangedBy 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 peter@denic.de Sat Dec 22 15:00:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E876621F88B0 for ; Sat, 22 Dec 2012 15:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeGexeF+uHgU for ; Sat, 22 Dec 2012 15:00:12 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77321F888F for ; Sat, 22 Dec 2012 15:00:11 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TmY37-0006ht-G4; Sun, 23 Dec 2012 00:00:09 +0100 Received: from localhost by x27.adm.denic.de with local id 1TmY37-0007e6-CS; Sun, 23 Dec 2012 00:00:09 +0100 Date: Sun, 23 Dec 2012 00:00:09 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20121222230009.GH26636@x28.adm.denic.de> References: <50D1C73D.6050801@centralnic.com> <50D46EA1.6050307@viagenie.ca> <50D48132.1010800@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D48132.1010800@viagenie.ca> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 23:00:13 -0000 On Fri, Dec 21, 2012 at 04:33:06PM +0100, Simon Perreault wrote: > vCard has both a structured postal address property (ADR) and an > unstructured one (LABEL), precisely because structured does not work for > everyone and every situation. > > Look, vCard has been around for a long time. It has been used a lot, and > it has evolved with practice. What you want is probably in it. so has WHOIS. My understanding was that structured data was one of the many drivers behind a whois replacement. Has this "requirement" now gone? -Peter From johnl@iecc.com Sat Dec 22 16:25:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EB621F88CC for ; Sat, 22 Dec 2012 16:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.021 X-Spam-Level: X-Spam-Status: No, score=-109.021 tagged_above=-999 required=5 tests=[AWL=2.178, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3R0nBOwrVAM for ; Sat, 22 Dec 2012 16:25:18 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04721F8891 for ; Sat, 22 Dec 2012 16:25:18 -0800 (PST) Received: (qmail 3760 invoked from network); 23 Dec 2012 00:25:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Dec 2012 00:25:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50d64f6b.xn--30v786c.k1212; i=johnl@user.iecc.com; bh=DChjaI45TY50mLQ6thvCSm7yXnzAYtmROJ6goy/9C50=; b=D7Q7yFIsKxuf0CY0/qvMyc9nQKDakIeRBwvf74f9etxaXRX3usm75WwkQHzyhdm44IuPwJuMCK69odLmATOBnYcDQtPAf+aC6u2SzkZcDAabOnRpLdfAviA3IEamgQOLU/waJWvgViDzq2fdTKof7Q7XiJg+20VoLgx/UWAawdM= 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=50d64f6b.xn--30v786c.k1212; olt=johnl@user.iecc.com; bh=DChjaI45TY50mLQ6thvCSm7yXnzAYtmROJ6goy/9C50=; b=QCwlDphOlhD12kr5Vun8D0nARFZkjmcOtKKVhRvmgKscLUkS7XoQ2uTIbRiNjfclWojuAFHs0VvBJJJyoW5v2SILT8WBPU+QFsz/1BjrlkycWOvLdPm0khX2hq2O/rL4av/QT++Mp/mEaWLJKnhlKWFHLuH7cFdxVfE+3Vb1s5g= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Dec 2012 00:24:53 -0000 Message-ID: <20121223002453.88824.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20121222230009.GH26636@x28.adm.denic.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: pk@DENIC.DE Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 00:25:19 -0000 >so has WHOIS. My understanding was that structured data was one of the >many drivers behind a whois replacement. Has this "requirement" now gone? The data providers can only return what they have. If the underlying data doesn't have any structure, no quantity of MUST in a spec will change that. From marc.blanchet@viagenie.ca Sun Dec 23 08:02:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8530521F882E for ; Sun, 23 Dec 2012 08:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.991 X-Spam-Level: X-Spam-Status: No, score=-101.991 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tkgUT+3keS5 for ; Sun, 23 Dec 2012 08:02:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98121F882C for ; Sun, 23 Dec 2012 08:02:41 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8096C403FD; Sun, 23 Dec 2012 11:02:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <20121223002453.88824.qmail@joyce.lan> Date: Sun, 23 Dec 2012 11:02:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> References: <20121223002453.88824.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1283) Cc: pk@DENIC.DE, weirds@ietf.org Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 16:02:41 -0000 Le 2012-12-22 =E0 19:24, John Levine a =E9crit : >> so has WHOIS. My understanding was that structured data was one of = the >> many drivers behind a whois replacement. Has this "requirement" now = gone? >=20 > The data providers can only return what they have. If the underlying > data doesn't have any structure, no quantity of MUST in a spec will > change that. ok. but postal addresses have been in that state for a lot of apps. That = does not prevent to structure the format. Every registry will then try to fit the best they can the data they have = in the structure of the format. For example, some may have the postal code, some may have but embedded = in the street address. So the structure format having a postal code, = then those who can put the postal code in the right field, some who = can't just continue as they were doing.=20 In other words, the protocol format should be the "best possible" (not = the perfect one) and then each organization maps its current dataset = into that format. And overtime, things will improve as new registries = come, as old registries are redoing their apps/database, as ... Given that vcard is not only used a lot into the field for all kind of = apps, and that vcard is an IETF format, I would suggest to closely look = at it to reuse as much as possible, instead of reinventing the wheel. = Moreover, vcard includes the i18n requirements. Marc. >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From johnl@taugh.com Sun Dec 23 09:17:32 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17E21F8B2D for ; Sun, 23 Dec 2012 09:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRA79-lKs8rS for ; Sun, 23 Dec 2012 09:17:31 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8619621F8B2B for ; Sun, 23 Dec 2012 09:17:30 -0800 (PST) Received: (qmail 88668 invoked from network); 23 Dec 2012 17:17:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15a5b.50d73ca8.k1212; bh=KKt4DlxR3859JElh4pNY5CUTdihBNWoU50SShMyw4RI=; b=G7Uu01iqG6FIrn0VRVjHBD2KaesPWWpFr1VraX2Vw+gLAuKJKH9Dh+PRvedE4lGXv+mlQL4C+FRm+3aphk2XYmbRJUfazJUPYc7s++wg6yZPojMItylY4GXU/enSEAlgHmBB/GPRo40M4+wpyriCwstjW+X5AaEo2qVmTL0gHBU= 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=15a5b.50d73ca8.k1212; bh=KKt4DlxR3859JElh4pNY5CUTdihBNWoU50SShMyw4RI=; b=m2LcND8Q/jqTpPJ9zIijP8KVemPfBq7K6agdf+YrHp17LGj3gMz8w4ADTwGRhyQmw0P3Bp3bsfY9KT1zS3ekTDETwkn7ol1ZS2DTWmEFoKvQLkeZPnV5M8JiK75CT3wykmTcIjwukDMFQD/fAc14073dqJjk5y+17V/bxqtJgnk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 23 Dec 2012 17:17:06 -0000 Date: 23 Dec 2012 12:17:28 -0500 Message-ID: From: "John R Levine" To: "Marc Blanchet" In-Reply-To: <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> References: <20121223002453.88824.qmail@joyce.lan> <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 17:17:32 -0000 > Given that vcard is not only used a lot into the field for all kind of apps, and that vcard is an IETF format, I would suggest to closely look at it to reuse as much as possible, instead of reinventing the wheel. Moreover, vcard includes the i18n requirements. I wouldn't object to using the vcard address format, so long as there's also some way to return address info when the provider isn't able to shoehorn it into the vcard fields. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From gavin.brown@centralnic.com Mon Dec 24 02:51:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1821F87DF for ; Mon, 24 Dec 2012 02:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Eq8nEFE3Kw for ; Mon, 24 Dec 2012 02:51:01 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84121F87A6 for ; Mon, 24 Dec 2012 02:51:01 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id B0BBB712B89; Mon, 24 Dec 2012 10:50:58 +0000 (UTC) Message-ID: <50D83392.80404@centralnic.com> Date: Mon, 24 Dec 2012 10:50:58 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Simon Perreault , andy@arin.net References: <50D1C73D.6050801@centralnic.com> <50D46EA1.6050307@viagenie.ca> In-Reply-To: <50D46EA1.6050307@viagenie.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 10:51:02 -0000 On 21/12/2012 14:13, Simon Perreault wrote: > Please allow me to remind everyone that the IETF has a standard for such > information: vCard. Let's use it and focus on WEIRDS, not on postal > address formats. > > And there is a draft about a JSON representation for vCard: > http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 Reusing an existing representation makes a lot of sense to me, as long as: 1. the profile is restricted to pretty much the same data as the current spec supports. 2. both flat and structured address data is supported. 3. data which are common to all the object types (registration/update times, sponsoring registrar, etc) have the same names across all objects. 4. the formatting of dates, telephone numbers, etc are the same across all objects. Otherwise, implementations are going to have to introduce special object-specific handlers for the same data, which will be a pain. Here's how I see an entity representation working, with a vCard representation merged with the format in draft-ietf-weirds-json-response-01: { "handle" : "SH8013-REP", "fn" : "John Doe", "status" : [ "validated", "locked" ], "org" : { "text" : "Example Inc" }, "adr" : { /* used by servers with flat address data */ "label" : "123 Example Dr., Suite 100, Dulles, VA, 20166-6503, US", /* used by servers with structured address data */ "street" : "123 Example Dr., Suite 100", "locality" : "Dulles", "region" : "VA", "code" : "20166-6503", "country" : "US" }, "tel" : [ { "type" : "voice", "uri" : "tel : +1.7035555555x1234" }, { "type" : "fax", "uri" : "tel : +1.7035555556" } ], "email" : { "text" : "jdoe@example.com" }, "remarks" : [ "she sells seas shells", "down by the seashore" ], "links" : [ { "value" : "http : //example.com/entity/XXXX", "rel" : "self", "href" : "http : //example.com/entity/XXXX" } ], "port43" : "whois.example.net", "registrationDate" : "1990-12-31T23 : 59 : 60Z", "registrationBy" : "ABC123", "lastChangedDate" : "1990-12-31T23 : 59 : 60Z", "lastChangedBy" : "ABC123", "sponsoredBy" : "SponsorXYZ", "resoldBy" : "ResellerPDQ" } -- 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 vesely@tana.it Mon Dec 24 09:02:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239021F88D0 for ; Mon, 24 Dec 2012 09:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LisaO5qSYAcw for ; Mon, 24 Dec 2012 09:02:02 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DE04C21F889D for ; Mon, 24 Dec 2012 09:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1356368520; bh=ZOihUtWBz9HOPcjwx7Lg2mXbygW85/FdOr7Z7C3Zb2M=; l=947; h=Date:From:To:References:In-Reply-To; b=S5Q+qz7wW2hdMeQxqv0hmUo2rxJCiA03Uifj1qA5nQzD2OL2f+xr01/22lFk3Jx2o 3k2QAvZ7BBFdFRyxfHKvW6MpXsvGG80l1o0nDava3l+vLj+i9xiMLAZyoX6dZ8Py2J 41aT9e1SKQf72ApA2Qs9jgTfJVfDEXTmkUTRyCjM= Received: from [37.159.123.223] ([37.159.123.223]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 24 Dec 2012 18:01:59 +0100 id 00000000005DC035.0000000050D88A87.000044D2 Message-ID: <50D88A81.2090605@tana.it> Date: Mon, 24 Dec 2012 18:01:53 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <50D48132.1010800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> <50D48941.8040207@viagenie.ca> In-Reply-To: <50D48941.8040207@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 17:02:02 -0000 On Fri 21/Dec/2012 17:07:29 +0100 Simon Perreault wrote: > Le 2012-12-21 16:56, Alex Sergeyev a écrit : >> whole "entities" concept gets replaced to "vcards" or it's only for >> postalAddress? > > Looking at this: > > http://tools.ietf.org/html/draft-ietf-weirds-json-response-01#section-7.1 > > I think some elements would be replaced by a vCard, some others would > remain WEIRDS' business. > > Replaced by a vCard: > entityNames > postalAddress > emails vCard defines an email type, such as "work", which can be extended so as to match, for example, automated and non-automated mailboxes of the abuse role. > phones > In WEIRDS: > remarks (although vCard has a NOTE property... not sure) > links (although vCard has a URL property... not sure) What changes, beside the field's name? > handle > roles > registrationDate > lastChangedDate (vCard has a REV property with a timestamp value) > lastChangedBy From simon.perreault@viagenie.ca Tue Dec 25 00:20:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4821F8BD2 for ; Tue, 25 Dec 2012 00:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnkIGX17a54D for ; Tue, 25 Dec 2012 00:19:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 191D021F87B1 for ; Tue, 25 Dec 2012 00:19:59 -0800 (PST) Received: from porto.nomis80.org (85-169-38-139.rev.numericable.fr [85.169.38.139]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 148B2403AB for ; Tue, 25 Dec 2012 03:19:57 -0500 (EST) Message-ID: <50D961AC.3040202@viagenie.ca> Date: Tue, 25 Dec 2012 09:19:56 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <50D48132.1010800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> <50D48941.8040207@viagenie.ca> <50D88A81.2090605@tana.it> In-Reply-To: <50D88A81.2090605@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 08:20:04 -0000 Le 2012-12-24 18:01, Alessandro Vesely a écrit : >> Replaced by a vCard: >> entityNames >> postalAddress >> emails > > vCard defines an email type, such as "work", which can be extended so as > to match, for example, automated and non-automated mailboxes of the > abuse role. Yes, IMHO that would be good protocol design. >> phones > >> In WEIRDS: >> remarks (although vCard has a NOTE property... not sure) >> links (although vCard has a URL property... not sure) > > What changes, beside the field's name? I'm not sure exactly what is the extent of your question, but I was thinking that the vCard would be embedded into the WEIRDS JSON structure, not merged. For example you would have a "vCard" item whose value would be a vCard JSON structure. The reason for that is that WEIRDS should not care (too much) about contact information. I can imagine a ton of use cases where programs would not care about this information and would treat it as a blob. So, taking "links" as an example, would those links be about the contact (e.g. "this person has a website at this address"), or do they have WEIRDS-specific semantics? I guess it's the latter, which is why I did not move it to the vCard. 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 vesely@tana.it Wed Dec 26 03:42:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE42A21F8C93 for ; Wed, 26 Dec 2012 03:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eirA9TKs8xlE for ; Wed, 26 Dec 2012 03:42:58 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C1BF721F8628 for ; Wed, 26 Dec 2012 03:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1356522175; bh=OzeR74NADBQdSfG0+mlPA2D8U1Ltzpieayc+UvYdNzY=; l=2288; h=Date:From:To:References:In-Reply-To; b=gJyH+fYCy1ro47wGfRyk7Emrv1ZovPjXhTk+Qq4YiR34mvepp5p9GpYgFhS1OVlow RhW7CHCvTc7chrRDa2sr2sO71w4+rhkBWK3RDRo7YXLA1UhIKV1KRxaWhQH014Wr0E rZfTLVGHLXYRo4HhIBnpeRK8EDNAP5bST4M4pTuc= Received: from [109.113.150.186] ([109.113.150.186]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Wed, 26 Dec 2012 12:42:54 +0100 id 00000000005DC039.0000000050DAE2BE.00005C61 Message-ID: <50DAE2BC.4090406@tana.it> Date: Wed, 26 Dec 2012 12:42:52 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: weirds@ietf.org References: <50D48132.1010800@viagenie.ca> <62D9228640AC7F49B2DD9ED0C9CE60E57898D442@CHAXCH01.corp.arin.net> <50D48941.8040207@viagenie.ca> <50D88A81.2090605@tana.it> <50D961AC.3040202@viagenie.ca> In-Reply-To: <50D961AC.3040202@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 11:42:59 -0000 On Tue 25/Dec/2012 09:19:56 +0100 Simon Perreault wrote: > Le 2012-12-24 18:01, Alessandro Vesely a écrit : >>> Replaced by a vCard: >>> entityNames >>> postalAddress >>> emails >> >> vCard defines an email type, such as "work", which can be extended so as >> to match, for example, automated and non-automated mailboxes of the >> abuse role. > > Yes, IMHO that would be good protocol design. For merge-vs-embed considerations, a reliable way to determine a complaint reporting email address /is/ WEIRDS-specific. At least, I came to this WG after learning that Deciding where to send an unsolicited report will typically rely on heuristics. http://tools.ietf.org/html/rfc6650#section-5.3 June 2012 >>> phones >> >>> In WEIRDS: >>> remarks (although vCard has a NOTE property... not sure) >>> links (although vCard has a URL property... not sure) >> >> What changes, beside the field's name? > > I'm not sure exactly what is the extent of your question, but I was > thinking that the vCard would be embedded into the WEIRDS JSON > structure, not merged. For example you would have a "vCard" item whose > value would be a vCard JSON structure. WHOIS data is traditionally flattened, irrespective of the depth of the underlying database. It eases both parsing and presentation. > The reason for that is that WEIRDS should not care (too much) about > contact information. I can imagine a ton of use cases where programs > would not care about this information and would treat it as a blob. As long as the same data is not repeated at top level too, that makes sense. It may ease comprehension and aid the design of visual layouts. > So, taking "links" as an example, would those links be about the contact > (e.g. "this person has a website at this address"), or do they have > WEIRDS-specific semantics? I guess it's the latter, which is why I did > not move it to the vCard. Hm... We have some fields, like "remarks" which are quite popular (7 TLDs, according to Linlin's analysis.) "Links" seems to be less used than that. In cases where semantics corresponds, by using the same field names WEIRDS and vCard can reinforce one another. Whether WEIRDS data could then be considered an extended vCard is a minor issue, IMHO. From zhoulinlin@cnnic.cn Wed Dec 26 17:58:13 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6B21F8C9F for ; Wed, 26 Dec 2012 17:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NaiGOlBrPWC for ; Wed, 26 Dec 2012 17:58:12 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id F0CEC21F8C98 for ; Wed, 26 Dec 2012 17:58:07 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 27 Dec 2012 09:58:04 +0800 From: "Linlin Zhou" To: "'Marc Blanchet'" References: <20121223002453.88824.qmail@joyce.lan> <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> In-Reply-To: <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> Date: Thu, 27 Dec 2012 09:58:03 +0800 Message-ID: <006001cde3d5$9bb1ea80$d315bf80$@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: Ac3hJvdxQvPpbFKzTnKeexN/zd9XDgCqmoWQ Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 01:58:13 -0000 Dear Marc, > In other words, the protocol format should be the "best possible" (not the > perfect one) and then each organization maps its current dataset into that format. > And overtime, things will improve as new registries come, as old registries are > redoing their apps/database, as ... > > Given that vcard is not only used a lot into the field for all kind of apps, and that > vcard is an IETF format, I would suggest to closely look at it to reuse as much as > possible, instead of reinventing the wheel. Moreover, vcard includes the i18n > requirements. > As seeing you mentioned the i18n requirements included in the vcard, I'd like to know more details about it. Could you please give any reference? Thanks. Linlin From marc.blanchet@viagenie.ca Thu Dec 27 06:28:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3F621F8C8D for ; Thu, 27 Dec 2012 06:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqYQKqt841F2 for ; Thu, 27 Dec 2012 06:28:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37D1621F8C6F for ; Thu, 27 Dec 2012 06:28:10 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A0B3640445; Thu, 27 Dec 2012 09:28:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <006001cde3d5$9bb1ea80$d315bf80$@cn> Date: Thu, 27 Dec 2012 09:28:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7BBBC1E3-C25A-461F-8522-96FB8638DD88@viagenie.ca> References: <20121223002453.88824.qmail@joyce.lan> <83B545A9-FA01-40B2-A1E1-444D3B570FEB@viagenie.ca> <006001cde3d5$9bb1ea80$d315bf80$@cn> To: "Linlin Zhou" X-Mailer: Apple Mail (2.1283) Cc: weirds@ietf.org Subject: Re: [weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 14:28:10 -0000 Le 2012-12-26 =E0 20:58, Linlin Zhou a =E9crit : > Dear Marc, >> In other words, the protocol format should be the "best possible" = (not the >> perfect one) and then each organization maps its current dataset into = that > format. >> And overtime, things will improve as new registries come, as old > registries are >> redoing their apps/database, as ... >>=20 >> Given that vcard is not only used a lot into the field for all kind = of > apps, and that >> vcard is an IETF format, I would suggest to closely look at it to = reuse as > much as >> possible, instead of reinventing the wheel. Moreover, vcard includes = the > i18n >> requirements. >>=20 > As seeing you mentioned the i18n requirements included in the vcard, = I'd > like to know more details about it. Could you please give any = reference? sure. first, I'm not claiming that vcard i18n "features" are in match = with weirds requirements (maybe, maybe not). But: - previous vcard version (RFC2425,=85) was not "clean" for i18n. = multiple charsets, etc=85 - current version of vcard (RFC6350): the group went to make sure any = i18n requirement was met. so, more precisely: + mandating UTF-8 (section 3.1, RFC6350) + escaping (section 3.4) + dates/time in iso format (section 4.3) + language (section 5.1) + geo=20 + tz + tel: based on x.520 Please see RFC6350. Marc. > Thanks. >=20 > Linlin From alexandrsergeyev@gmail.com Mon Dec 31 08:05:46 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54F21F87FD for ; Mon, 31 Dec 2012 08:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fazRQYZMuR5 for ; Mon, 31 Dec 2012 08:05:45 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3821F87D4 for ; Mon, 31 Dec 2012 08:05:45 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id eh20so11419904obb.23 for ; Mon, 31 Dec 2012 08:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qWJllvbhoubR1G6/On/Xb8Pw+oQ/2cV9D6O+AOHSVkY=; b=KqShZKk/P7mft7Co23gWivdaBh6zaP6vE+l+I2zsTK/WXVv89sbCV7lc+e6MPYYxJd Ts401lTGdcdWPc4hmBzcQQUxzy7OI2asumlltCLqHeyGbU55PD/AlJK3RCja1ZrWO2ZL nYLKTIpJpvit54s7TvSQHKatPIwFIIZFT089hwMfyEf4HkH94Wh6pl8epu24Wg9uofUD kaFfnaSRwrsL7C5TCEsrcxL5x4srIlhc/xhi5TifehtSsxewSPqoBS+e+9Kn21JfxiH5 0NiE85P2q4IY3E7DqRHWiTuCT2v8admRn/ehyBLDg7FQYpFkpOcoCFCPSENhVBTAvmC/ sQHw== MIME-Version: 1.0 Received: by 10.60.32.39 with SMTP id f7mr22173465oei.86.1356969945017; Mon, 31 Dec 2012 08:05:45 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.76.122.108 with HTTP; Mon, 31 Dec 2012 08:05:44 -0800 (PST) In-Reply-To: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2C9@CHAXCH01.corp.arin.net> References: <62D9228640AC7F49B2DD9ED0C9CE60E57898D2C9@CHAXCH01.corp.arin.net> Date: Mon, 31 Dec 2012 11:05:44 -0500 X-Google-Sender-Auth: cDNbYkFglGwL7J_lPhHFFsIQ6sA Message-ID: From: Alex Sergeyev To: Andy Newton Content-Type: text/plain; charset=UTF-8 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-01 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 16:05:46 -0000 Andy, new comment/question: Do you think the "The IP Network Object Class" (section 10) should include "status" field to be similar to other objects? -- Alex.