From ietf-secretariat-reply@ietf.org Thu Aug 1 02:10:40 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894E521F84F9 for ; Thu, 1 Aug 2013 02:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ESvh0a5xexe for ; Thu, 1 Aug 2013 02:10:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F5B21F84B1 for ; Thu, 1 Aug 2013 02:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801091027.9703.56243.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 02:10:27 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 01 Aug 2013 03:02:32 -0700 Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 09:10:40 -0000 Changed milestone "draft-ietf-weirds-using-http to the IESG", set due date to February 2013 from February 2013. Changed milestone "draft-ietf-weirds-rdap-sec to the IESG", set due date to April 2013 from April 2013. Changed milestone "draft-ietf-weirds-rdap-query to the IESG", set due date to June 2013 from June 2013. Added milestone "draft-ietf-weirds-ibject-inventory to the IESG", due August 2013. Changed milestone "draft-ietf-weirds-json-response to the IESG", set due date to September 2013 from September 2013. Changed milestone "draft-ietf-weirds-redirects to the IESG", set due date to December 2013 from December 2013. URL: http://datatracker.ietf.org/wg/weirds/charter/ From ietf-secretariat-reply@ietf.org Thu Aug 1 02:11:00 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB421E8093 for ; Thu, 1 Aug 2013 02:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq3MBHeJwf57 for ; Thu, 1 Aug 2013 02:10:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09A21E8099 for ; Thu, 1 Aug 2013 02:10:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801091050.9706.63544.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 02:10:50 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 01 Aug 2013 03:02:32 -0700 Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 09:11:00 -0000 Changed milestone "draft-ietf-weirds-ibject-inventory to the IESG", set description to "draft-ietf-weirds-object-inventory to the IESG". URL: http://datatracker.ietf.org/wg/weirds/charter/ From ietf-secretariat-reply@ietf.org Thu Aug 1 03:07:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2310321F9AD1 for ; Thu, 1 Aug 2013 03:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bng+4-afi6Z for ; Thu, 1 Aug 2013 03:07:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4121F9E35 for ; Thu, 1 Aug 2013 03:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801100714.21095.77004.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 03:07:14 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 01 Aug 2013 03:25:54 -0700 Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 10:07:29 -0000 Changed milestone "draft-ietf-weirds-object-inventory to the IESG", set due date to October 2013 from August 2013, added draft-ietf-weirds-object-inventory to milestone. Changed milestone "draft-ietf-weirds-rdap-query to the IESG", set due date to November 2013 from June 2013, added draft-ietf-weirds-rdap-query to milestone. Changed milestone "draft-ietf-weirds-json-response to the IESG", set due date to November 2013 from September 2013, added draft-ietf-weirds-json-response to milestone. Changed milestone "draft-ietf-weirds-redirects to the IESG", set due date to November 2013 from December 2013, added draft-ietf-weirds-redirects to milestone. URL: http://datatracker.ietf.org/wg/weirds/charter/ From superuser@gmail.com Thu Aug 1 03:27:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052C321F9E69 for ; Thu, 1 Aug 2013 03:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFsZOfkncTuQ for ; Thu, 1 Aug 2013 03:27:14 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7337321F9C4A for ; Thu, 1 Aug 2013 03:25:20 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so5714789wgh.1 for ; Thu, 01 Aug 2013 03:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VoIdFAmkP5FIdyV5a+WsV8heNeSAtxqfY9u3M+XlK3A=; b=QxIo8etDNrrcT3upoJaQ15ObXLQxtPF/9vVveonUpQt8IwOtPsvjN4iYm6rQH5Jwkk AFY5qYwVKSPShRM2c6IqLo1k97rUasdwvDsm9VEcXbMNZkg+a4ef5dQ8fA8RMpvwrQtw 8Wveqx0IQIvHmLsICk1zsgfocpANF0+6gwSOowPl3JlD/cfreVmLW6LT3onnMhyJtdIo mgb4uKzwsw0SiBpScjGu6LnsfAUNjjJWzewDqissixoyhYHf73nrkg9AGONk8As3DpVr G8YKrAoUxuRwQK/j3DHtIc9XUdxfXTEgIsccu3sF9ZKlGOwGeT7zZjRaReYIFhWDZI3o 6Lcg== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr671062wic.19.1375352711817; Thu, 01 Aug 2013 03:25:11 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 1 Aug 2013 03:25:11 -0700 (PDT) Date: Thu, 1 Aug 2013 12:25:11 +0200 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3436ad4335604e2e041cb Subject: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 10:27:29 -0000 --001a11c3436ad4335604e2e041cb Content-Type: text/plain; charset=ISO-8859-1 Colleagues, It's my understanding that our paths forward are as follows, based on today's meeting: Search: 1) We will roll a rudimentary search capability into the rdap-query document, and repeat Working Group Last Call focusing on the new material once it's added. I have changed its state in the tracker back to "WG Document", and set a new milestone of November. That means a second WGLC will start in early to mid October. Please let me know if you think that's too aggressive or not aggressive enough. 2) The working group can decide on a specific syntax on the mailing list. It didn't make sense to dedicate precious microphone time to discussing that this morning, especially since the two proposed syntaxes on the summary slide are so similar. This seems like a coin flip to me, but the working group can decide however it wishes. 3) The working group will need to explore which fields will be searchable, and which capabilities (ordering, paging) need to be supported. This will be predicated on what current registries are doing, or what things registries are pledging to implement. It sounds like Scott did some of that research already to get us started; the group should continue to explore this and come up with a proposed set of capabilities. 4) We will not work on advanced search, or adopt a separate document for basic search, at this point. 5) Basic search will be specified, but will not be required to implement. 6) We need internationalization clue here. I'll see if I can secure some. 7) The results of the search work will impact the JSON response document. Object Inventory: 1) This is now an official milestone. I've set it for October of this year, meaning WGLC around late September. Again, please let me know if this needs to be changed in either direction. I will act as document shepherd. The group should review the document and send comments to the mailing list so we can get it ready for a Working Group Last Call; I expect this will be pretty painless. Redirects: 1) We have more work to do in this area, especially since it's tied to bootstrapping. This remains an active WG item. I've set a milestone of November on this one as well, but it can be adjusted. Bootstrapping: 1) This one appears to need the most R&D by the working group. Fortunately, a lot of good discussion occurred at the mic today. We will ensure this issue, and redirection, get ample time at the microphone in Vancouver. 2) There is no single WG document for this yet; two are proposed for adoption now, and some hybrid model was also proposed in the meeting today. When that third draft appears, we can do a (probably extended) call for adoption in order to choose a path forward. 3) I will create a milestone for this. I presume Pete will approve it given its obvious necessity and the attention it's getting, but he might surprise me. :-) Please let me know if I got any of this wrong, or if any of the actions or dates need adjustment. -MSK, WEIRDS co-chair --001a11c3436ad4335604e2e041cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

It's my understandi= ng that our paths forward are as follows, based on today's meeting:
=
Search:
1) We will roll a rudimentary search c= apability into the rdap-query document, and repeat Working Group Last Call = focusing on the new material once it's added.=A0 I have changed its sta= te in the tracker back to "WG Document", and set a new milestone = of November.=A0 That means a second WGLC will start in early to mid October= .=A0 Please let me know if you think that's too aggressive or not aggre= ssive enough.

2) The working group can decide on a specific syntax on the = mailing list.=A0 It didn't make sense to dedicate precious microphone t= ime to discussing that this morning, especially since the two proposed synt= axes on the summary slide are so similar.=A0 This seems like a coin flip to= me, but the working group can decide however it wishes.

3) The working group will need to explore which fields will = be searchable, and which capabilities (ordering, paging) need to be support= ed.=A0 This will be predicated on what current registries are doing, or wha= t things registries are pledging to implement.=A0 It sounds like Scott did = some of that research already to get us started; the group should continue = to explore this and come up with a proposed set of capabilities.

4) We will not work on advanced search, or adopt a separate = document for basic search, at this point.

5) Basic search= will be specified, but will not be required to implement.

6) We need internationalization clue here.=A0 I'll see i= f I can secure some.

7) The results of the search work wi= ll impact the JSON response document.

Object Inventory:
1) This is now an official milestone.=A0 I've set it for Oct= ober of this year, meaning WGLC around late September.=A0 Again, please let= me know if this needs to be changed in either direction.=A0 I will act as = document shepherd.=A0 The group should review the document and send comment= s to the mailing list so we can get it ready for a Working Group Last Call;= I expect this will be pretty painless.

Redirects:
1) We have more work to do in this = area, especially since it's tied to bootstrapping.=A0 This remains an a= ctive WG item.=A0 I've set a milestone of November on this one as well,= but it can be adjusted.

Bootstrapping:
1) This one appears to need the= most R&D by the working group.=A0 Fortunately, a lot of good discussio= n occurred at the mic today.=A0 We will ensure this issue, and redirection,= get ample time at the microphone in Vancouver.

2) There is no single WG document for this yet; two are proposed for ad= option now, and some hybrid model was also proposed in the meeting today.= =A0 When that third draft appears, we can do a (probably extended) call for= adoption in order to choose a path forward.

3) I will create a milestone for this.=A0 I presume Pete wil= l approve it given its obvious necessity and the attention it's getting= , but he might surprise me.=A0 :-)

Please let me know if = I got any of this wrong, or if any of the actions or dates need adjustment.=

-MSK, WEIRDS co-chair

--001a11c3436ad4335604e2e041cb-- From ietf-secretariat-reply@ietf.org Thu Aug 1 03:28:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473721F9AFD for ; Thu, 1 Aug 2013 03:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eBtgvq8YU7y for ; Thu, 1 Aug 2013 03:28:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C0A21F86B2 for ; Thu, 1 Aug 2013 03:28:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801102812.10696.22521.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 03:28:12 -0700 From: IETF Secretariat Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 10:28:54 -0000 Changed milestone "draft-ietf-weirds-using-http to the IESG", resolved as "Done", added draft-ietf-weirds-using-http to milestone. Changed milestone "draft-ietf-weirds-rdap-sec to the IESG", resolved as "Done", added draft-ietf-weirds-rdap-sec to milestone. URL: http://datatracker.ietf.org/wg/weirds/charter/ From ietf-secretariat-reply@ietf.org Thu Aug 1 03:29:02 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2355F21F99C1 for ; Thu, 1 Aug 2013 03:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umrXACUlkTVh for ; Thu, 1 Aug 2013 03:29:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2821F9B07 for ; Thu, 1 Aug 2013 03:28:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801102851.10702.8498.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 03:28:51 -0700 From: IETF Secretariat Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 10:29:02 -0000 URL: http://datatracker.ietf.org/wg/weirds/charter/ From simon.perreault@viagenie.ca Thu Aug 1 06:49:05 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4099721E818B for ; Thu, 1 Aug 2013 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sT45nvJtdxW for ; Thu, 1 Aug 2013 06:49:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4422321E80FB for ; Thu, 1 Aug 2013 06:48:57 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8BFAF44A83 for ; Thu, 1 Aug 2013 09:48:56 -0400 (EDT) Message-ID: <51FA6747.3060006@viagenie.ca> Date: Thu, 01 Aug 2013 15:48:55 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] Interop report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 13:49:05 -0000 All, Here's the interop report in email form, since we didn't have time for a live form. The slides form is still here: http://tools.ietf.org/agenda/87/slides/slides-87-weirds-2.pdf We had an interoperability testing session on Saturday afternoon. Attendance was composed of: - 8 servers, of which... ... 5 were "number" servers ... 2 were "name" servers ... 1 was a redirect server - 1 client - 1 test suite (acting as a client) targeting servers We ran a survey to know what features were implemented. The features _not_ implemented by _most_ implementations were: draft-ietf-weirds-json-response: 5.4 lang draft-ietf-weirds-using-http 5.2 302 Response with Location: 5.2 303 Response with Location: 5.2 307 Response with Location: 5.5 429 Response 5.6 Access-Control-Allow-Origin Header 9.3 Return Content-language Header Features _not_ implemented by _some_ implementations were: (some features here are not listed because they are specific for one kind of registry (i.e. addresses vs domains)) draft-ietf-weirds-rdap-query 3.4 /nameserver/ 3.4 /nameserver/ 3.6 /help draft-ietf-weirds-json-response: 5.3 remarks 5.6 status 5.7 port43 5.8 public id 6.2.1 secureDNS dsData 6.2.2 secureDNS keyData Immediate results of the interop test were: - We discovered at least 39 issues in implementations. Many were fixed on the spot. - We identified a few questions about the specs. Question #1: Double Slashes Should double slashes be allowed? Consider these two examples: A) http://example.com//ip/1.2.3.4/32 B) http://example.com/ip/1.2.3.4//32 A) looks like it should be allowed, based on common practice. Double slashes have commonly been allowed since HTTP servers serving files from a Unix-like filesystem don't care about double slashes. However, B) looks like it should not be allowed, based on CIDR notation syntax. Since we don't see any value in allowing double slashes, we propose to explicitly disallow them, and we propose to add text to that effect in the query draft. Question #2: Authentication How can we return different content depending on whether auth is used or not? For example, a domain name registry may want to return basic information when authentication is not used, whereas using authentication would allow one to also obtain personal contact information for a domain name. We want to use HTTP auth for that, but the problem is that HTTP auth is triggered by unauthorized access. So you can't use the same URL for authorized and unauthorized access. One proposal discussed during the interop meeting would be to add an "auth=" query parameter. The token would identify the clearance level, and would be registry-specific. For example, a registry could define an "auth=registrar" clearance level allowing their registrars to access restricted information. It would be appropriate to have the WG view on the proposal. The feedback from implementers was that it would be good to redo this at the next IETF (Vancouver). Given that implementations will be more mature, that specs will change, and that the test suite will evolve with more comprehensive coverage, this makes a lot of sense. So we plan to do it again in Vancouver, and we plan to start testing features higher up the stack: IDN support, jCard support, etc. Simon and Marc -- 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 marc.blanchet@viagenie.ca Thu Aug 1 06:49:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4D21E80FB for ; Thu, 1 Aug 2013 06:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAu3uBKVIToz for ; Thu, 1 Aug 2013 06:49:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6F21E8174 for ; Thu, 1 Aug 2013 06:49:19 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 96D7444A83; Thu, 1 Aug 2013 09:49:18 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 1 Aug 2013 15:49:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 13:49:21 -0000 Le 2013-08-01 =E0 12:25, "Murray S. Kucherawy" a = =E9crit : > Colleagues, >=20 > It's my understanding that our paths forward are as follows, based on = today's meeting: >=20 ... >=20 > Bootstrapping: > 1) This one appears to need the most R&D by the working group. = Fortunately, a lot of good discussion occurred at the mic today. We = will ensure this issue, and redirection, get ample time at the = microphone in Vancouver. >=20 > 2) There is no single WG document for this yet; two are proposed for = adoption now, and some hybrid model was also proposed in the meeting = today. When that third draft appears, we can do a (probably extended) = call for adoption in order to choose a path forward. I intend to write a third draft on the third solution. However, my take = is that after some discussion, hopefully we will converge enough to drop = two drafts and merge and update one for wg consideration. We shall not = do a call for adoption on each one to find the concensus. I'm not sure = if this was your intention, but I just want to put my 2 cents into what = I think we should do as the convergence process on this topic. Marc.= From marc.blanchet@viagenie.ca Thu Aug 1 06:55:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B3421E81B1 for ; Thu, 1 Aug 2013 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydmELVEKbIWU for ; Thu, 1 Aug 2013 06:55:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2558921F9C6B for ; Thu, 1 Aug 2013 06:55:31 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6472B46FC4; Thu, 1 Aug 2013 09:55:30 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Thu, 1 Aug 2013 15:55:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0461F0E5-2569-42E5-838E-8E4A631F691E@viagenie.ca> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 13:55:33 -0000 Le 2013-08-01 =E0 12:25, "Murray S. Kucherawy" a = =E9crit : > Colleagues, >=20 > It's my understanding that our paths forward are as follows, based on = today's meeting: >=20 ...=20 > Search: > 1) We will roll a rudimentary search capability into the rdap-query = document, and repeat Working Group Last Call focusing on the new = material once it's added. I have changed its state in the tracker back = to "WG Document", and set a new milestone of November. That means a = second WGLC will start in early to mid October. Please let me know if = you think that's too aggressive or not aggressive enough. fine by me, but I'm not one of the authors. ... >=20 > 4) We will not work on advanced search, or adopt a separate document = for basic search, at this point. I would suggest rephrasing that "advanced search" (as not the stuff = folded into the basic specs) is lower priority for now. It may be just = good to do parallel work, because one can complement the other... ... >=20 > 6) We need internationalization clue here. I'll see if I can secure = some. I think there are many participants in this wg that have some enough = good i18n clue, and could be described as part of a non-existent i18n = swat team . They may not have been taking the time to give their own = comments in public, but may be soon... ;-) =20 Marc. From superuser@gmail.com Thu Aug 1 07:16:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E5821E8217 for ; Thu, 1 Aug 2013 07:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc91oEM55E91 for ; Thu, 1 Aug 2013 07:16:19 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3732121E8202 for ; Thu, 1 Aug 2013 07:16:07 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q54so1727483wes.5 for ; Thu, 01 Aug 2013 07:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cU37UQyxM8vHFILlulR1gMaAYfYtdayFjqTjw+D3zFc=; b=fz4UMqHdV37bR6ni880fg3RLHIyWjcfZuHttFklzY7JdLPJ2ufFhVTL2iU2Jup2Dnc povVXlTSY8H1NHN9FsbhoHDJNZmvoE3B5DwQFObe1s9p5KVzGfoTKrbXDNJ2gN2fN731 ihg/o4dRnOB73kjhuenqryzy958rD14W+7Cd38UnU1WYMC/gbyZMcEe8puwbEJvqopYj jtveCZSPStoVPTOEwgsRzQ3BgjuLli9cb/fS431v4ZsSgx7JeeWPp8x0BiCdWks7G9rb WNCYQHk6xH8NVLNLoNn9Q2LC6Ot5+wmyWrV4VSCLcSk4s3cht00EMf9eGC7deqDkoVw3 /g+g== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr8105988wib.19.1375366566346; Thu, 01 Aug 2013 07:16:06 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 1 Aug 2013 07:16:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 16:16:06 +0200 Message-ID: From: "Murray S. Kucherawy" To: Marc Blanchet Content-Type: multipart/alternative; boundary=e89a8f3ba2559f882604e2e37b1e Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 14:16:21 -0000 --e89a8f3ba2559f882604e2e37b1e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 3:49 PM, Marc Blanchet wrote: > > 2) There is no single WG document for this yet; two are proposed for > adoption now, and some hybrid model was also proposed in the meeting today. > When that third draft appears, we can do a (probably extended) call for > adoption in order to choose a path forward. > > I intend to write a third draft on the third solution. However, my take is > that after some discussion, hopefully we will converge enough to drop two > drafts and merge and update one for wg consideration. We shall not do a > call for adoption on each one to find the concensus. I'm not sure if this > was your intention, but I just want to put my 2 cents into what I think we > should do as the convergence process on this topic. > Typically what I do in the datatracker is put all of the candidates in "Call for Adoption" state, and then only the one the WG selects actually becomes a WG document. Either way, the outcome is only a single one. -MSK --e89a8f3ba2559f882604e2e37b1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 3:49 PM, Marc Blanchet <ma= rc.blanchet@viagenie.ca> wrote:
> 2) There is no single WG document for t= his yet; two are proposed for adoption now, and some hybrid model was also = proposed in the meeting today. =A0When that third draft appears, we can do = a (probably extended) call for adoption in order to choose a path forward.<= br>

I intend to write a third draft on the third solution. However, my ta= ke is that after some discussion, hopefully we will converge enough to drop= two drafts and merge and update one for wg consideration. =A0We shall not = do a call for adoption on each one to find the concensus. I'm not sure = if this was your intention, but I just want to put my 2 cents into what I t= hink we should do as the convergence process on this topic.

Typically wh= at I do in the datatracker is put all of the candidates in "Call for A= doption" state, and then only the one the WG selects actually becomes = a WG document.=A0 Either way, the outcome is only a single one.

-MSK
--e89a8f3ba2559f882604e2e37b1e-- From sanz@denic.de Thu Aug 1 07:41:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFD911E816D for ; Thu, 1 Aug 2013 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whuAiv2dfJPV for ; Thu, 1 Aug 2013 07:41:52 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF2D21E827C for ; Thu, 1 Aug 2013 07:41:10 -0700 (PDT) Received: from notes1.fra2.osl.denic.de (notes1.fra2.osl.denic.de [10.122.50.48]) by office.denic.de with esmtp id 1V4u3w-0001c5-Hr; Thu, 01 Aug 2013 16:41:08 +0200 In-Reply-To: References: X-KeepSent: AAF67D8F:1D9DD4CC-C1257BBA:00501493; type=4; name=$KeepSent To: "Murray S. Kucherawy" X-Mailer: Lotus Notes Release 8.5.3FP1 Septem 15, 2011 From: Marcos Sanz Message-ID: Date: Thu, 1 Aug 2013 16:41:00 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 01.08.2013 16:41:08 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 14:41:52 -0000 Murray, all, I felt in the room a strong push back to the *concrete* DNS bootstrappi= ng solution as described in http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 , which I do not find in your summary. FWIW: I also personally find this bootstrapping implementation A Bad Id= ea. And for clarification: I am not against DNS bootstrapping in genera= l. Best, Marcos weirds-bounces@ietf.org wrote on 01/08/2013 12:25:11: > Von: "Murray S. Kucherawy" > An: "weirds@ietf.org" , > Datum: 01/08/2013 12:28 > Betreff: [weirds] Outcomes of today's meeting > Gesendet von: weirds-bounces@ietf.org > > Colleagues, > It's my understanding that our paths forward are as follows, based > on today's meeting: > Search: > 1) We will roll a rudimentary search capability into the rdap-query > document, and repeat Working Group Last Call focusing on the new > material once it's added.=C2=A0 I have changed its state in the track= er > back to "WG Document", and set a new milestone of November.=C2=A0 Tha= t > means a second WGLC will start in early to mid October.=C2=A0 Please = let > me know if you think that's too aggressive or not aggressive enough. > 2) The working group can decide on a specific syntax on the mailing > list.=C2=A0 It didn't make sense to dedicate precious microphone time= to > discussing that this morning, especially since the two proposed > syntaxes on the summary slide are so similar.=C2=A0 This seems like a= > coin flip to me, but the working group can decide however it wishes. > 3) The working group will need to explore which fields will be > searchable, and which capabilities (ordering, paging) need to be > supported.=C2=A0 This will be predicated on what current registries a= re > doing, or what things registries are pledging to implement.=C2=A0 It > sounds like Scott did some of that research already to get us > started; the group should continue to explore this and come up with > a proposed set of capabilities. > 4) We will not work on advanced search, or adopt a separate document > for basic search, at this point. > 5) Basic search will be specified, but will not be required to implem= ent. > > 6) We need internationalization clue here.=C2=A0 I'll see if I can se= cure some. > 7) The results of the search work will impact the JSON response docum= ent. > Object Inventory: > 1) This is now an official milestone.=C2=A0 I've set it for October o= f > this year, meaning WGLC around late September.=C2=A0 Again, please le= t me > know if this needs to be changed in either direction.=C2=A0 I will ac= t as > document shepherd.=C2=A0 The group should review the document and sen= d > comments to the mailing list so we can get it ready for a Working > Group Last Call; I expect this will be pretty painless. > Redirects: > 1) We have more work to do in this area, especially since it's tied > to bootstrapping.=C2=A0 This remains an active WG item.=C2=A0 I've se= t a > milestone of November on this one as well, but it can be adjusted. > Bootstrapping: > 1) This one appears to need the most R&D by the working group. > Fortunately, a lot of good discussion occurred at the mic today.=C2=A0= We > will ensure this issue, and redirection, get ample time at the > microphone in Vancouver. > > 2) There is no single WG document for this yet; two are proposed for > adoption now, and some hybrid model was also proposed in the meeting > today.=C2=A0 When that third draft appears, we can do a (probably > extended) call for adoption in order to choose a path forward. > 3) I will create a milestone for this.=C2=A0 I presume Pete will appr= ove > it given its obvious necessity and the attention it's getting, but > he might surprise me.=C2=A0 :-) > Please let me know if I got any of this wrong, or if any of the > actions or dates need adjustment. > -MSK, WEIRDS co-chair > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds= From superuser@gmail.com Thu Aug 1 08:12:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06211E80F0 for ; Thu, 1 Aug 2013 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmzfzp2BgM5I for ; Thu, 1 Aug 2013 08:12:53 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E53711E80DF for ; Thu, 1 Aug 2013 08:12:49 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1761153wgh.2 for ; Thu, 01 Aug 2013 08:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bypa05UnaSNVFZLjjxYrJ6ncR+e7Ixy6HMp5BOt5Gw4=; b=dPnfLVVKofxC62AO99EihX96VltUJ1NdKNOdBAF8phs5IQmEa5mq9CQipQnaBxw7pB 8M24zmvL9dMQY4rdzjSN+x+xfM18CXjn4uDcaiCvYiXi8j3BdU+QAjmeCTvdUwFVmv1k TuRvc4Ts9WiGAQugZGjaIH/46NS2nBat/lNJloklOSnRGe+nUATXMVTlCzbPhT1MNx5D DErMX39GD4VMyGaLBeBs+KIsmjAM8bfxKzYI6Tss8sA1apOEWauhvreul5sc2/lzo+RS cJQ5Z1gYHINIlENbEeaDMY+pHgOPz8fIe5rcwm7m70s7DBAg3aanYAINuqZxDB87hDg8 LssA== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr1612682wic.19.1375369968407; Thu, 01 Aug 2013 08:12:48 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 1 Aug 2013 08:12:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 17:12:48 +0200 Message-ID: From: "Murray S. Kucherawy" To: Marcos Sanz Content-Type: multipart/alternative; boundary=001a11c3436a66dedf04e2e446e6 Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 01 Aug 2013 15:12:54 -0000 --001a11c3436a66dedf04e2e446e6 Content-Type: text/plain; charset=ISO-8859-1 Hi Marcos, thanks for the follow-up. I didn't find that there was particularly warm response to any of the options. That's why I believe the whole topic needs more R&D in general. Sorry if that should've been more explicit in that note. -MSK On Thu, Aug 1, 2013 at 4:41 PM, Marcos Sanz wrote: > Murray, > all, > > I felt in the room a strong push back to the *concrete* DNS bootstrapping > solution as described in > http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 > , which I do not find in your summary. > > FWIW: I also personally find this bootstrapping implementation A Bad Idea. > And for clarification: I am not against DNS bootstrapping in general. > > Best, > Marcos > > weirds-bounces@ietf.org wrote on 01/08/2013 12:25:11: > > > Von: "Murray S. Kucherawy" > > An: "weirds@ietf.org" , > > Datum: 01/08/2013 12:28 > > Betreff: [weirds] Outcomes of today's meeting > > Gesendet von: weirds-bounces@ietf.org > > > > Colleagues, > > > It's my understanding that our paths forward are as follows, based > > on today's meeting: > > > Search: > > 1) We will roll a rudimentary search capability into the rdap-query > > document, and repeat Working Group Last Call focusing on the new > > material once it's added. I have changed its state in the tracker > > back to "WG Document", and set a new milestone of November. That > > means a second WGLC will start in early to mid October. Please let > > me know if you think that's too aggressive or not aggressive enough. > > > 2) The working group can decide on a specific syntax on the mailing > > list. It didn't make sense to dedicate precious microphone time to > > discussing that this morning, especially since the two proposed > > syntaxes on the summary slide are so similar. This seems like a > > coin flip to me, but the working group can decide however it wishes. > > > 3) The working group will need to explore which fields will be > > searchable, and which capabilities (ordering, paging) need to be > > supported. This will be predicated on what current registries are > > doing, or what things registries are pledging to implement. It > > sounds like Scott did some of that research already to get us > > started; the group should continue to explore this and come up with > > a proposed set of capabilities. > > > 4) We will not work on advanced search, or adopt a separate document > > for basic search, at this point. > > > 5) Basic search will be specified, but will not be required to implement. > > > > 6) We need internationalization clue here. I'll see if I can secure > some. > > > 7) The results of the search work will impact the JSON response document. > > > Object Inventory: > > 1) This is now an official milestone. I've set it for October of > > this year, meaning WGLC around late September. Again, please let me > > know if this needs to be changed in either direction. I will act as > > document shepherd. The group should review the document and send > > comments to the mailing list so we can get it ready for a Working > > Group Last Call; I expect this will be pretty painless. > > > Redirects: > > 1) We have more work to do in this area, especially since it's tied > > to bootstrapping. This remains an active WG item. I've set a > > milestone of November on this one as well, but it can be adjusted. > > > Bootstrapping: > > 1) This one appears to need the most R&D by the working group. > > Fortunately, a lot of good discussion occurred at the mic today. We > > will ensure this issue, and redirection, get ample time at the > > microphone in Vancouver. > > > > 2) There is no single WG document for this yet; two are proposed for > > adoption now, and some hybrid model was also proposed in the meeting > > today. When that third draft appears, we can do a (probably > > extended) call for adoption in order to choose a path forward. > > > 3) I will create a milestone for this. I presume Pete will approve > > it given its obvious necessity and the attention it's getting, but > > he might surprise me. :-) > > > Please let me know if I got any of this wrong, or if any of the > > actions or dates need adjustment. > > > -MSK, WEIRDS co-chair > > _______________________________________________ > > weirds mailing list > > weirds@ietf.org > > https://www.ietf.org/mailman/listinfo/weirds > > --001a11c3436a66dedf04e2e446e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcos, thanks for the follow-up.

I didn= 9;t find that there was particularly warm response to any of the options.= =A0 That's why I believe the whole topic needs more R&D in general.= =A0 Sorry if that should've been more explicit in that note.

-MSK


On Thu, Aug 1, 2013 at 4:41 PM, Marcos Sanz &l= t;sanz@denic.de><= /span> wrote:
Murray,
all,

I felt in the room a strong push back to the *concrete* DNS bootstrapping s= olution as described in
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap= -00
, which I do not find in your summary.

FWIW: I also personally find this bootstrapping implementation A Bad Idea. = And for clarification: I am not against DNS bootstrapping in general.

Best,
Marcos

weirds-bounces@ietf.org wrot= e on 01/08/2013 12:25:11:

> Von: "Murray S. Kucherawy" <superuser@gmail.com>
> An: "weirds@ietf.org"= <weirds@ietf.org>,
> Datum: 01/08/2013 12:28
> Betreff: [weirds] Outcomes of today's meeting
> Gesendet von: weirds-bounce= s@ietf.org
>
> Colleagues,

> It's my understanding that our paths forward are as follows, based=
> on today's meeting:

> Search:
> 1) We will roll a rudimentary search capability into the rdap-query > document, and repeat Working Group Last Call focusing on the new
> material once it's added.=A0 I have changed its state in the track= er
> back to "WG Document", and set a new milestone of November.= =A0 That
> means a second WGLC will start in early to mid October.=A0 Please let<= br> > me know if you think that's too aggressive or not aggressive enoug= h.

> 2) The working group can decide on a specific syntax on the mailing > list.=A0 It didn't make sense to dedicate precious microphone time= to
> discussing that this morning, especially since the two proposed
> syntaxes on the summary slide are so similar.=A0 This seems like a
> coin flip to me, but the working group can decide however it wishes.
> 3) The working group will need to explore which fields will be
> searchable, and which capabilities (ordering, paging) need to be
> supported.=A0 This will be predicated on what current registries are > doing, or what things registries are pledging to implement.=A0 It
> sounds like Scott did some of that research already to get us
> started; the group should continue to explore this and come up with > a proposed set of capabilities.

> 4) We will not work on advanced search, or adopt a separate document > for basic search, at this point.

> 5) Basic search will be specified, but will not be required to impleme= nt.
>
> 6) We need internationalization clue here.=A0 I'll see if I can se= cure some.

> 7) The results of the search work will impact the JSON response docume= nt.

> Object Inventory:
> 1) This is now an official milestone.=A0 I've set it for October o= f
> this year, meaning WGLC around late September.=A0 Again, please let me=
> know if this needs to be changed in either direction.=A0 I will act as=
> document shepherd.=A0 The group should review the document and send > comments to the mailing list so we can get it ready for a Working
> Group Last Call; I expect this will be pretty painless.

> Redirects:
> 1) We have more work to do in this area, especially since it's tie= d
> to bootstrapping.=A0 This remains an active WG item.=A0 I've set a=
> milestone of November on this one as well, but it can be adjusted.

> Bootstrapping:
> 1) This one appears to need the most R&D by the working group.
> Fortunately, a lot of good discussion occurred at the mic today.=A0 We=
> will ensure this issue, and redirection, get ample time at the
> microphone in Vancouver.
>
> 2) There is no single WG document for this yet; two are proposed for > adoption now, and some hybrid model was also proposed in the meeting > today.=A0 When that third draft appears, we can do a (probably
> extended) call for adoption in order to choose a path forward.

> 3) I will create a milestone for this.=A0 I presume Pete will approve<= br> > it given its obvious necessity and the attention it's getting, but=
> he might surprise me.=A0 :-)

> Please let me know if I got any of this wrong, or if any of the
> actions or dates need adjustment.

> -MSK, WEIRDS co-chair
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds


--001a11c3436a66dedf04e2e446e6-- From marc.blanchet@viagenie.ca Fri Aug 2 04:52:14 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5D821E838D for ; Fri, 2 Aug 2013 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R82g430X508 for ; Fri, 2 Aug 2013 04:52:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D596521E8392 for ; Fri, 2 Aug 2013 04:52:06 -0700 (PDT) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 892CB4042B; Fri, 2 Aug 2013 07:52:05 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Fri, 2 Aug 2013 13:52:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marcos Sanz X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Aug 2013 11:52:14 -0000 Le 2013-08-01 =E0 16:41, Marcos Sanz a =E9crit : > Murray, > all, >=20 > I felt in the room a strong push back I'm sorry. that is not my reading. I've heard a mix of support and not.=20= Having said that, I'm agnostic to any and wanted to have a good = discussion on the way forward which I think we (somewhat) achieved in = the time we had. Marc. > to the *concrete* DNS bootstrapping solution as described in > http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00 > , which I do not find in your summary. >=20 > FWIW: I also personally find this bootstrapping implementation A Bad = Idea. And for clarification: I am not against DNS bootstrapping in = general. >=20 > Best, > Marcos >=20 > weirds-bounces@ietf.org wrote on 01/08/2013 12:25:11: >=20 >> Von: "Murray S. Kucherawy" >> An: "weirds@ietf.org" , >> Datum: 01/08/2013 12:28 >> Betreff: [weirds] Outcomes of today's meeting >> Gesendet von: weirds-bounces@ietf.org >>=20 >> Colleagues, >=20 >> It's my understanding that our paths forward are as follows, based >> on today's meeting: >=20 >> Search: >> 1) We will roll a rudimentary search capability into the rdap-query >> document, and repeat Working Group Last Call focusing on the new >> material once it's added. I have changed its state in the tracker >> back to "WG Document", and set a new milestone of November. That >> means a second WGLC will start in early to mid October. Please let >> me know if you think that's too aggressive or not aggressive enough. >=20 >> 2) The working group can decide on a specific syntax on the mailing >> list. It didn't make sense to dedicate precious microphone time to >> discussing that this morning, especially since the two proposed >> syntaxes on the summary slide are so similar. This seems like a >> coin flip to me, but the working group can decide however it wishes. >=20 >> 3) The working group will need to explore which fields will be >> searchable, and which capabilities (ordering, paging) need to be >> supported. This will be predicated on what current registries are >> doing, or what things registries are pledging to implement. It >> sounds like Scott did some of that research already to get us >> started; the group should continue to explore this and come up with >> a proposed set of capabilities. >=20 >> 4) We will not work on advanced search, or adopt a separate document >> for basic search, at this point. >=20 >> 5) Basic search will be specified, but will not be required to = implement. >>=20 >> 6) We need internationalization clue here. I'll see if I can secure = some. >=20 >> 7) The results of the search work will impact the JSON response = document. >=20 >> Object Inventory: >> 1) This is now an official milestone. I've set it for October of >> this year, meaning WGLC around late September. Again, please let me >> know if this needs to be changed in either direction. I will act as >> document shepherd. The group should review the document and send >> comments to the mailing list so we can get it ready for a Working >> Group Last Call; I expect this will be pretty painless. >=20 >> Redirects: >> 1) We have more work to do in this area, especially since it's tied >> to bootstrapping. This remains an active WG item. I've set a >> milestone of November on this one as well, but it can be adjusted. >=20 >> Bootstrapping: >> 1) This one appears to need the most R&D by the working group. >> Fortunately, a lot of good discussion occurred at the mic today. We >> will ensure this issue, and redirection, get ample time at the >> microphone in Vancouver. >>=20 >> 2) There is no single WG document for this yet; two are proposed for >> adoption now, and some hybrid model was also proposed in the meeting >> today. When that third draft appears, we can do a (probably >> extended) call for adoption in order to choose a path forward. >=20 >> 3) I will create a milestone for this. I presume Pete will approve >> it given its obvious necessity and the attention it's getting, but >> he might surprise me. :-) >=20 >> Please let me know if I got any of this wrong, or if any of the >> actions or dates need adjustment. >=20 >> -MSK, WEIRDS co-chair >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From superuser@gmail.com Mon Aug 5 10:36:20 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BC821F9DE1; Mon, 5 Aug 2013 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM7gArkbRBeo; Mon, 5 Aug 2013 10:36:18 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id CE10021F9DCE; Mon, 5 Aug 2013 10:36:16 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id en1so1812072wid.14 for ; Mon, 05 Aug 2013 10:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vPAUTz7a0ot2q8ra52Tz4eNGJImLQq9JLRGbfsI3APQ=; b=CJfhMmrxzsMuRbCyMU2erMqgrzUsq3uPTWiRHtXEzlOBZm6zwDVW9S3TDHVDB5u/qW zQ8L4MIqWdUhFe654RfIocAsDKKBPqzLBQzaWQmdkP7tgQ/rPear03nKLJkE5LQhPMho jE5tvaaUU8FOdkvs4SfBX0R0k9T91H0apv7FVjsCvkcmlaiC4sJGT02jKunI+heSn8b5 DsmzkrC91/hjpCM7kKKVK6BE4Yqhjt7WKBTLer5Z6d/LoAYeYKzvVq2sgwUTANlgX1nN iuDJUGThirR+OvfH38NdHIJc8rI3KveFfZ7nAg4L32Ja1SCOWd+BqrIQOrGJ5i26EbBs gvhQ== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr4081195wic.52.1375724174482; Mon, 05 Aug 2013 10:36:14 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Mon, 5 Aug 2013 10:36:14 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130724111528.0d2bf428@resistor.net> References: <20130715230614.25146.34230.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130724111528.0d2bf428@resistor.net> Date: Mon, 5 Aug 2013 10:36:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=001a11c34302baa56b04e336bee6 Cc: ietf , "weirds@ietf.org" Subject: Re: [weirds] Last Call: (Security Services for the Registration Data Access Protocol) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Aug 2013 17:36:20 -0000 --001a11c34302baa56b04e336bee6 Content-Type: text/plain; charset=ISO-8859-1 Hi SM, thanks for your comments. I'm shepherding the document, so replies inline: On Wed, Jul 24, 2013 at 12:21 PM, SM wrote: > According to Section 1, the Registration Data Access Protocol is a Lookup > Format, > JSON Responses and HTTP usage. This looks like a weird protocol to me. > If the said protocol is HTTP + JSON (responses) it would be clearer to the > reader to explain that in one specification. Section 1 mentions that: > > "One goal of RDAP is to provide security services that do not exist in > the WHOIS" > > I don't see how adding a fourth document helps to achieve that goal. > RDAP is far from the first protocol specification to exist across multiple RFCs, so this approach isn't uncommon. That said, I take it you believe the material here should be rolled into one of the other documents? > In Section 3.1: > > 'To that end, RDAP clients and servers MUST implement the > authentication framework specified in "HTTP Authentication: > Basic and Digest Access Authentication" [RFC2617].' > > This draft refers to the above authentication framework as the RDAP > authentication framework. The draft then explains how the "basic" and > "digest" schemes work. This is "how-to" stuff. The draft sets the > following requirement: > > 'If the "basic" scheme is used, HTTP Over TLS [RFC2818] MUST be used > to protect the client's credentials from disclosure while in transit > (see Section 3.4).' > > If I understood correctly HTTPS is needed for security only if the "basic" > scheme" is used. > Correct, that's what it says. > "RDAP SHOULD be capable of supporting future authentication methods > defined for use with HTTP." > > That sounds like a "SHOULD CONSIDER". Given how ill-defined the protocol > is I doubt that the above is actionable. > You said two important things here: 1) Can you please elaborate on why you think this is "ill-defined" and, if possible, how this could be remedied? 2) Insofar as this draft amounts to a requirements document, I take "SHOULD be capable" to mean the actual implementation needs to have hooks for the stated capability, or have a very good reason for not providing those hooks (e.g., the same capability is available some other way). In Section 3.1.1: > > "RDAP MAY include a federated authentication mechanism that permits > a client to access multiple RDAP servers in the same federation > with one credential." > > Using an upper-case "may" does not bring much in terms of security. The > draft takes the stance that security is an optional feature. > More precisely, the draft takes the stance that federated authentication is an option. The working group doesn't feel the need to elevate this to SHOULD or MUST, likely because operators might not be compelled to federate themselves with anyone for whatever local security or privacy reasons apply. > > Section 3.1.1 looks like an executive summary for federated authentication. > Right, and the benefits it provides in the context of RDAP. Is that a criticism or an observation? What do you suggest? > In Section 3.3: > > "An RDAP service has to be available to be useful. There are no RDAP- > unique requirements to provide availability, but as a general > security consideration a service operator needs to be aware of the > issues associated with denial of service." > > The text says that the service must be available to be useful and that > there isn't any requirement for the service to be available. > The next sentence (which you omitted) provides the context. Operators are advised to be aware of denial-of-service considerations, and there's a document referenced that provides useful information. Depending on the uptake of RDAP and the other services that begin to depend upon it, it might become a DoS target. Hardening against such attacks will be important to begin with, but might become critical later. I think this is not a waste of space. > In Section 3.4: > > "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to > provide that protection by encrypting all traffic sent on the > connection between client and server." > > The above describes the protocol as a web service. > It is a web service, in as much as it uses web protocols. Is there some improvement you'd like to suggest? > > "When this scheme is used, HTTP Over TLS MUST be used to protect the > client's credentials from disclosure while in transit.' > > The above repeats a "MUST" mentioned in a previous section. > True, this can be fixed by replacing it with a reference to Section 3.1. > > In Section 5: > > "RDAP might need to be extended to provide this service in the future." > > This does not look like a security consideration. > Non-repudiation (which is the context of the paragraph from which that sentence was taken) is one of the classic properties of security, so I don't agree. It's useful to point out to the reader that non-repudiation is not provided by any of the capabilities discussed here, and its absence might be conspicuous. > > "Code injection refers to adding code into a computer system > or program to alter the course of execution." > > I can only wonder about who is the target audience after reading the above. > It's true that the specific things called out in that paragraph are not specific to RDAP, but rather to anything built atop HTTP. Do you suggest something else, perhaps something more general like a statement that any known HTTP-based attack might also affect an RDAP service? > > The security considerations section seems like an attempt to write > something about security as there isn't nothing to say about the protocol. > SecDir often scratches its head when a document says very little, so what you're saying is often the case. However, sometimes it's enough to say "This is built on top of HTTP, so all the security issues known about HTTP and HTTPS also apply here." Do you have a specific suggestion? > > Overall, the draft does not look like a technical specification. It looks > like the working group took FYI 36 as a template for designing a security > service instead of thinking about security and designing a security service. > That seems a little sharp. This draft is manifestly not a technical specification insofar as it does not define a new protocol. I would say it's partly a requirements document and partly an applicability statement, and the latter at least is normally a standards track document. I don't know what "thinking about security" we are expected to do beyond making use of the security services that have already been made available to applications built atop HTTP. Do you have any specific suggestions? -MSK --001a11c34302baa56b04e336bee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi SM, thanks for your comments.=A0 I'm shepherding th= e document, so replies inline:

On Wed, Jul 24, 2013 at 12:21 PM, SM <= ;sm@resistor.net&g= t; wrote:
According to Section 1, the Registration Dat= a Access Protocol is a Lookup Format,
JSON Responses and HTTP usage. =A0This looks like a weird protocol to me. = =A0If the said protocol is HTTP + JSON (responses) it would be clearer to t= he reader to explain that in one specification. =A0Section 1 mentions that:=

=A0 "One goal of RDAP is to provide security services that do not exis= t in
=A0 =A0the WHOIS"

I don't see how adding a fourth document helps to achieve that goal.

RDAP is far from the first protocol speci= fication to exist across multiple RFCs, so this approach isn't uncommon= .=A0 That said, I take it you believe the material here should be rolled in= to one of the other documents?
=A0
In Section 3.1:

=A0 'To that end, RDAP clients and servers MUST implement the
=A0 =A0authentication framework specified in "HTTP Authentication:
=A0 =A0Basic and Digest Access Authentication" [RFC2617].'

This draft refers to the above authentication framework as the RDAP authent= ication framework. =A0The draft then explains how the "basic" and= "digest" schemes work. =A0This is "how-to" stuff. =A0T= he draft sets the following requirement:

=A0 'If the "basic" scheme is used, HTTP Over TLS [RFC2818] M= UST be used
=A0 =A0to protect the client's credentials from disclosure while in tra= nsit
=A0 (see Section 3.4).'

If I understood correctly HTTPS is needed for security only if the "ba= sic" scheme" is used.

Correct= , that's what it says.
=A0
=A0 "RDAP SHOULD be capable of supporting future authentication method= s
=A0 =A0defined for use with HTTP."

That sounds like a "SHOULD CONSIDER". =A0Given how ill-defined th= e protocol is I doubt that the above is actionable.
You said two important things here:

1) Can y= ou please elaborate on why you think this is "ill-defined" and, i= f possible, how this could be remedied?

2) Insofar as this draft amounts to a requirements document,= I take "SHOULD be capable" to mean the actual implementation nee= ds to have hooks for the stated capability, or have a very good reason for = not providing those hooks (e.g., the same capability is available some othe= r way).


In Section 3.1.1:

=A0 "RDAP MAY include a federated authentication mechanism that permit= s
=A0 =A0a client to access multiple RDAP servers in the same federation
=A0 =A0with one credential."

Using an upper-case "may" does not bring much in terms of securit= y. =A0The draft takes the stance that security is an optional feature.
<= /blockquote>

More precisely, the draft takes the stance = that federated authentication is an option.=A0 The working group doesn'= t feel the need to elevate this to SHOULD or MUST, likely because operators= might not be compelled to federate themselves with anyone for whatever loc= al security or privacy reasons apply.
=A0

Section 3.1.1 looks like an executive summary for federated authentication.=

Right, and the benefits it provides in= the context of RDAP.=A0 Is that a criticism or an observation?=A0 What do = you suggest?


In Section 3.3:

=A0 "An RDAP service has to be available to be useful. =A0There are no= RDAP-
=A0 =A0unique requirements to provide availability, but as a general
=A0 =A0security consideration a service operator needs to be aware of the =A0 =A0issues associated with denial of service."

The text says that the service must be available to be useful and that ther= e isn't any requirement for the service to be available.

The next sentence (which you omitted) provides the co= ntext.=A0 Operators are advised to be aware of denial-of-service considerat= ions, and there's a document referenced that provides useful informatio= n.=A0 Depending on the uptake of RDAP and the other services that begin to = depend upon it, it might become a DoS target.=A0 Hardening against such att= acks will be important to begin with, but might become critical later.=A0 I= think this is not a waste of space.


In Section 3.4:

=A0 "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to=
=A0 =A0provide that protection by encrypting all traffic sent on the
=A0 =A0connection between client and server."

The above describes the protocol as a web service.
It is a web service, in as much as it uses web protocols.=A0 Is= there some improvement you'd like to suggest?
=A0

=A0 "When this scheme is used, HTTP Over TLS MUST be used to protect t= he
=A0 =A0client's credentials from disclosure while in transit.'

The above repeats a "MUST" mentioned in a previous section.

True, this can be fixed by replacing it with= a reference to Section 3.1.
=A0

=A0 "Code injection refers to adding code into a computer system
=A0 =A0or program to alter the course of execution."

I can only wonder about who is the target audience after reading the above.=

It's true that the specific things= called out in that paragraph are not specific to RDAP, but rather to anyth= ing built atop HTTP.=A0 Do you suggest something else, perhaps something mo= re general like a statement that any known HTTP-based attack might also aff= ect an RDAP service?

=A0

The security considerations section seems like an attempt to write somethin= g about security as there isn't nothing to say about the protocol.
<= /blockquote>

SecDir often scratches its head when a docu= ment says very little, so what you're saying is often the case.=A0 Howe= ver, sometimes it's enough to say "This is built on top of HTTP, s= o all the security issues known about HTTP and HTTPS also apply here."= =A0 Do you have a specific suggestion?
=A0

Overall, the draft does not look like a technical specification. =A0It look= s like the working group took FYI 36 as a template for designing a security= service instead of thinking about security and designing a security servic= e.

That seems a little sharp.

This dra= ft is manifestly not a technical specification insofar as it does not defin= e a new protocol.=A0 I would say it's partly a requirements document an= d partly an applicability statement, and the latter at least is normally a = standards track document.

I don't know what "thinking about security" we= are expected to do beyond making use of the security services that have al= ready been made available to applications built atop HTTP.=A0 Do you have a= ny specific suggestions?

-MSK
--001a11c34302baa56b04e336bee6-- From johnl@iecc.com Mon Aug 5 17:11:34 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21121F9DB0 for ; Mon, 5 Aug 2013 17:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.15 X-Spam-Level: X-Spam-Status: No, score=-110.15 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwZK5HDp7qCu for ; Mon, 5 Aug 2013 17:11:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C5F7F21F9C4C for ; Mon, 5 Aug 2013 17:11:14 -0700 (PDT) Received: (qmail 61266 invoked from network); 6 Aug 2013 00:04:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 00:04:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52003d8b.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=DEaZqfEmB/i4simhI2QdUCvkqLnhUmS4QxdOs2bQIYk=; b=DCUEa3jzLAIIjvaR3KssDcPVJ10XHduxsImEXLg7+NQyfkjZn7g9P6UIp+VsgGvtt7E7QdUiHm+GmR3/441CpBrVxtIJeNQBpzmWKvZUTQuQPIhECpLi+nP5ls+ezBAPhgFW/uLRKX9fqSPHViVNgob45z5BT8lDpKb0cVK2fXcEv6y8VdUGokvKWxDEpECAn/miNVvVigFaeUqXiT1KcTtWy+CRqSA4ZNyAT4qEBuMLUL2WKTHxeaPW7HYxcglz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52003d8b.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=DEaZqfEmB/i4simhI2QdUCvkqLnhUmS4QxdOs2bQIYk=; b=kzayoP3USDdh3t8aMpkZbvV0jabgeUKFe/YMYEH/22rihe46cGmZcN7NuTUq3/CCoQMbDXlIf26whxJkf0/iSpPw5HmLQfslGfo+gKxk2sFlfA2rRMeYfHgJQXywvIzNPeF+d16tt5VrvnjmF+75y4R9xVobY/o1y8kR+jxa3SKmlsqUF5t26YKZF2ZgJQRRbZFpHnggW8UO316YCH9qqGOna5qEsEYaAGPcrYICclHcMKKTdA2kCpzglG87yHcz Date: 6 Aug 2013 00:04:05 -0000 Message-ID: <20130806000405.24891.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <0461F0E5-2569-42E5-838E-8E4A631F691E@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 00:11:34 -0000 >I would suggest rephrasing that "advanced search" (as not the stuff folded into the >basic specs) is lower priority for now. It may be just good to do parallel work, >because one can complement the other... I'd prefer to declare advanced search to be dead unless we identify a significant server operator who is planning to provide it. I know how to spec out all sorts of complicated search schemes, but anything more than prefix matching requires complex database techniques and I don't see why any operator would go to the expense. R's, John From johnl@iecc.com Mon Aug 5 17:27:33 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63B221F9DAD for ; Mon, 5 Aug 2013 17:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.202 X-Spam-Level: X-Spam-Status: No, score=-110.202 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDP+NWId07Cy for ; Mon, 5 Aug 2013 17:27:19 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C345B21F9CAD for ; Mon, 5 Aug 2013 17:27:18 -0700 (PDT) Received: (qmail 64886 invoked from network); 6 Aug 2013 00:27:17 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 00:27:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=520042e5.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=bo4xji6FLm0VPADVnl9qX1J/dypd5koXxJ5/FrhD5eg=; b=GQxUbEOSi4/Ie2uyAiKdBlFlVlPnnEDlM6NV/ZyT/KBlkvFaDpjN+cDh60DxktYwnB4wTZ4qgUOZocCixZIeYfi86fzTiX7Xfe2TP581FPd+VHPt5Qv4Ic06c0S/5nL0Lr0saKlsq+8x+WxyWwrDuyDznwlL93NuZgMHiNjERIgUkD6QcbwDjNqcCk2nM+OhHdwYUemaYr/f+DvAUjKOMBxrCLpdF+DlAGJFnJtvAuLppkTrwxxLHBE/3dKZKnoJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=520042e5.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=bo4xji6FLm0VPADVnl9qX1J/dypd5koXxJ5/FrhD5eg=; b=VQnT330lEjUdLtDxgwEqs1FVIXVd5uGnr+OoQTV7p6QS5x8Qtbo/p4iIzEFWrNH5dBgu0NyyumCeSkK2bDLOwpQu39P9HnqjJnvNC7hbz404cgg+D2TMEVtHUR1jfSCC8OnoQ8XRZepRN+rCYY749gg3XbubSUe+gD+fNwen5bFATnfsc+3/NWMZmimDOpjbsEaE4Ck1oavISc8qwwRhQYxOULoEdj1rjbtJNUyMPPwIkVgrhxmyi2X81A/OjYIv Date: 6 Aug 2013 00:26:55 -0000 Message-ID: <20130806002655.24966.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Bootstrapping update X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 00:27:34 -0000 >I felt in the room a strong push back to the *concrete* DNS bootstrapping solution ... In discussions in the room, the new bit of data I got was that more than one TLD operator was unhappy with anything that put IANA in the critical path, which rules out both the iana.org registry and .rdap,arpa, leaving us with SRV or NAPTR in the TLD. Being a Lazy Programmer(tm), I registered rdap-servers.net a while ago, and if the pointers are in the TLDs, I'll mirror them at .http.rdap-servers.net and/or .https.rdap-servers.net. (I may be a lazy programmer, but I can write lazy programs in python.) Speaking for Lazy Programmers around the world, we'd really appreciate it if you used SRV, and stuck to these: _http._tcp.tld SRV 0 0 80 some-server-name _https._tcp.tld SRV 0 0 443 some-server-name i.e., use the standard port numbers, and don't be clever about URL mapping or weights and priorities, so we can mirror them with A or AAAA or CNAME. With sufficient DNSSEC, we should have a reasonable defense against downgrade attacks for TLDs that offer https. Also, I talked to Andy Newton shortly before we got on our respective planes who said that load testing of ARIN's web farm showed that it could easily handle redirect loads even at the query rate for .COM. That tells me the plan to do numbers by pointing at a helpful default server and expecting it to redirect is workable. That doesn't rule out smarter bootstraps using the rarely changing IANA tables, but it provides a simple path for simple clients. R's, John From ajs@anvilwalrusden.com Mon Aug 5 18:34:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6621F9C0A for ; Mon, 5 Aug 2013 18:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q35FYcejYuA for ; Mon, 5 Aug 2013 18:34:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF0421F9BCA for ; Mon, 5 Aug 2013 18:34:20 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6D6438A031 for ; Tue, 6 Aug 2013 01:34:19 +0000 (UTC) Date: Mon, 5 Aug 2013 21:34:17 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20130806013417.GB49661@mx1.yitter.info> References: <0461F0E5-2569-42E5-838E-8E4A631F691E@viagenie.ca> <20130806000405.24891.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130806000405.24891.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 01:34:26 -0000 On Tue, Aug 06, 2013 at 12:04:05AM -0000, John Levine wrote: > I'd prefer to declare advanced search to be dead unless we identify a > significant server operator who is planning to provide it. I agree with this. > anything more than prefix matching requires complex database > techniques and I don't see why any operator would go to the expense. Not really (at least not any more, if you're using a non-toy RDBMS), but it doesn't matter. It's expensive to the WG to define how it will work in the absence of someone saying what they plan to do, so we shouldn't do it on the grounds that aimless speculation is a waste of group energy. A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Tue Aug 6 00:47:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBEB21F9E34 for ; Tue, 6 Aug 2013 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYGRwrtJ5AcZ for ; Tue, 6 Aug 2013 00:47:30 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D07F221F9D7E for ; Tue, 6 Aug 2013 00:47:28 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so2128890wgh.5 for ; Tue, 06 Aug 2013 00:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z9Me/mvLdvQpIHgT9Hkhru0UrzHn/qEgJkJbt1DeVTc=; b=pKyHd8YHVdCXNz2NkStuGIQ3NERqGxDW06IAK6FgXepfcdASi4CMGpFZXECPIdlLRo JSP862Wii0T19UkLRgNDEGGZVg57rDXc10sJJ5BrGnwRS342UpVNNrngTEVuaei3O/6b L3uIFj0Z2yAq/KKK9MBj29dJe63/QXGFm59Ke1GxDIMS6iQVTYY802z0rcdKKjiit3nO f2kzIqvpVdoWO0aXsusGj/2AsNIFXhTNePEAieAzStiGoqlvLjaAu1nukxf4K9K/kIe5 HyS9DPS9dgTtITuVWtyt9VF9fIfdKi+8A6n+jmV6f27Yjb0G/5EKW3ecW4/T9n7rB0UC UV+A== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr67561wjn.23.1375775247911; Tue, 06 Aug 2013 00:47:27 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 6 Aug 2013 00:47:27 -0700 (PDT) Date: Tue, 6 Aug 2013 00:47:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba975e6f151ef04e342a297 Subject: [weirds] Draft IETF 87 minutes available X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 07:47:30 -0000 --047d7ba975e6f151ef04e342a297 Content-Type: text/plain; charset=ISO-8859-1 The chairs thank Steve Sheng for taking notes during the meeting. The draft minutes are now available at: http://www.ietf.org/proceedings/87/minutes/minutes-87-weirds Please have a look at your convenience and confirm that the minutes capture the discussion that took place. Thanks to all of those who attended. See you in Vancouver! -MSK, WEIRDS co-chair --047d7ba975e6f151ef04e342a297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The chairs thank Steve Sheng for taking notes du= ring the meeting.=A0 The draft minutes are now available at:

http://ww= w.ietf.org/proceedings/87/minutes/minutes-87-weirds

Please have a look at your convenience and confirm that the minut= es capture the discussion that took place.

Thanks to all of those wh= o attended.=A0 See you in Vancouver!

-MSK, WEIRDS co-chair
--047d7ba975e6f151ef04e342a297-- From shollenbeck@verisign.com Tue Aug 6 03:54:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F021F9DF0 for ; Tue, 6 Aug 2013 03:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.709 X-Spam-Level: X-Spam-Status: No, score=-6.709 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8vcMQ2y264V for ; Tue, 6 Aug 2013 03:54:23 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1221F9633 for ; Tue, 6 Aug 2013 03:54:21 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUgDV3ZhyXD2XPrm9VLtp8OejoMl71nQz@postini.com; Tue, 06 Aug 2013 03:54:23 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r76AsIKR008825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 06:54:18 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 6 Aug 2013 06:54:18 -0400 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Draft IETF 87 minutes available Thread-Index: AQHOknk45RvF2XNxCUOWZpaQ9eF/45mIAZgA Date: Tue, 6 Aug 2013 10:54:17 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4922B88B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4922B88BBRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Draft IETF 87 minutes available X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 10:54:28 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4922B88BBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks like a reasonable summary to me. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Tuesday, August 06, 2013 3:47 AM To: weirds@ietf.org Subject: [weirds] Draft IETF 87 minutes available The chairs thank Steve Sheng for taking notes during the meeting. The draf= t minutes are now available at: http://www.ietf.org/proceedings/87/minutes/minutes-87-weirds Please have a look at your convenience and confirm that the minutes capture= the discussion that took place. Thanks to all of those who attended. See you in Vancouver! -MSK, WEIRDS co-chair --_000_831693C2CDA2E849A7D7A712B24E257F4922B88BBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks like a reasonable summary to me.

 

Scott

 

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, August 06, 2013 3:47 AM
To: weirds@ietf.org
Subject: [weirds] Draft IETF 87 minutes available<= /p>

 

The chairs thank Stev= e Sheng for taking notes during the meeting.  The draft minutes are no= w available at:

ht= tp://www.ietf.org/proceedings/87/minutes/minutes-87-weirds

Please have a look at= your convenience and confirm that the minutes capture the discussion that = took place.

Thanks to all of those who attended.  See you in Vancouver!=

-MSK, WEIRDS co-chair

--_000_831693C2CDA2E849A7D7A712B24E257F4922B88BBRN1WNEXMBX01vc_-- From johnl@iecc.com Tue Aug 6 07:17:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DD621F8D0D for ; Tue, 6 Aug 2013 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.368 X-Spam-Level: X-Spam-Status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyMUSR6KhwLZ for ; Tue, 6 Aug 2013 07:17:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B2B0F21F9C37 for ; Tue, 6 Aug 2013 07:17:17 -0700 (PDT) Received: (qmail 21455 invoked from network); 6 Aug 2013 14:17:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 14:17: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:mime-version:content-type:content-transfer-encoding; s=52010569.xn--hew.k1308; i=johnl@user.iecc.com; bh=RTE/N2uTemxLoG4BgV/K/wo48Tmv4lBYLR3QGCDOm+s=; b=dwKZhytQklX9xcgFPn4bh2Fh6FmsKnbgap2t4fDOWBubzcozVTFhd02ajYUpOGoSgnxRp69eGcmlnBEQs/t4P8pI1VStR0TjlpI0BKxLVSvP2UekVM9EuZcAAmUPVzIGkx5sEm7PNbO1oZ6nI7/uWvhWvwTzCklnPSJ26oGVZr6OPkkhA0rj4txiaGzw7fWmoOR8B9s8UZpfr790hv2MyLK58N7TfxMlvkpPl+9j0yrVdox32ElVC+Z5cRWZp9f8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52010569.xn--hew.k1308; olt=johnl@user.iecc.com; bh=RTE/N2uTemxLoG4BgV/K/wo48Tmv4lBYLR3QGCDOm+s=; b=LwdkF97t/9jliO1XrnTIk+TECq/qpRib+Nt4cmQBtIRg1kmW14C3BG4SORBUNCmJOXHv+hr95guTLsiYzrwJE7yj6yt+RSITK9Iljgm4KnWdiFUE2HxMmqsGgzevVDQq3Dg/fraA/qPhKxvW1AOozOy1BxDFKzJB98OzFb6I/J8DrDF+Slgudu7c+Gg9crrIufVopnnB/EKqytMPKVhmXTsSgrcdq5eBmGaRhnTPlwVduA2ZMavzDZtluyQK6ox6 Date: 6 Aug 2013 14:16:51 -0000 Message-ID: <20130806141651.35184.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4922B88B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Draft IETF 87 minutes available X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Aug 2013 14:17:22 -0000 >Looks like a reasonable summary to me. Agreed, except that for Carlos' talk I still don't understand why there's any discussion of server pooling for names. I'm not aware of any TLDs that are interested, and it's not one of the techniques we're discussing for name bootstraps. R's, John From superuser@gmail.com Wed Aug 7 11:30:06 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994BC21E805A for ; Wed, 7 Aug 2013 11:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6DcwShSDTcn for ; Wed, 7 Aug 2013 11:30:04 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0521F9DF1 for ; Wed, 7 Aug 2013 11:29:59 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so4166672wib.17 for ; Wed, 07 Aug 2013 11:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sTe84TzO4+nB0dZmIYZsjOP+Owre07E31di8+tzfDYc=; b=W2XVF+foDBXKF1VoZDf6TVmxruHOWpry4XTCNbPhRFuEfm2jzksZTjMXD37rhsqBT3 OMq6NnJ4b6XO6M2Vhju8pA1Ccxk9llLMjGPqmRHuWrkpgC+OnlHKiGxmd8scFg0InG/I EWOZtk03GmcvEdi2Ox03KX6ZDZAmX4IorruTz1tHabdBQzW8t7dYY2mPETlIB1hvMb16 IhMq3jXdbrJRWiW7whey0B1SYobzoLOrYbpNzPXXZLxU6D+W1oNn8XEuwJ22cSDXgJmt SLlsvlgPYjy2vs5OSiNapp/g4YK0t0s/LZkjIyvSbt3EHSkzoiy8kamrshkca38F7qkR vf2g== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr2905728wic.60.1375900198765; Wed, 07 Aug 2013 11:29:58 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 7 Aug 2013 11:29:58 -0700 (PDT) Date: Wed, 7 Aug 2013 11:29:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=001a11c26a5e9808b504e35fba7a Subject: [weirds] Search and query URIs X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Aug 2013 18:30:06 -0000 --001a11c26a5e9808b504e35fba7a Content-Type: text/plain; charset=ISO-8859-1 Of possible interest to us when we specify how to construct query and search URIs: https://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn/ -MSK --001a11c26a5e9808b504e35fba7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Of possible interest to us when we specify how to con= struct query and search URIs:

https://datatracker.ietf.org/d= oc/draft-nottingham-uri-get-off-my-lawn/

-MSK
--001a11c26a5e9808b504e35fba7a-- From carlosm3011@gmail.com Wed Aug 7 13:04:53 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EAE11E814D for ; Wed, 7 Aug 2013 13:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nez-fNGiIWSz for ; Wed, 7 Aug 2013 13:04:52 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9811E812C for ; Wed, 7 Aug 2013 13:04:51 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mf11so1514907lab.29 for ; Wed, 07 Aug 2013 13:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SxLS62GjrRVURr7/fMhnr/zgd+ZIur/9s8M3U1u7zQE=; b=OQqaH70mxn+5l47HVPy1Smu+4eLKjnSwD8128IQouNB96/5fg6NBjqLtBRzCmyvsSB 3NGD6aMHGaew5kRZOVO9aRfPXvOVvGJeDBsLf1p3EA4NlZ0dIte7CxslKliL4/C5flMs zsR5lNP5pWk/B/ARumeteyNOgmriNm5bWNL7WCzHcHo9uAObn02GYVhMKdHpybHa979T taLFZPoQIdaU+jOD+BjFmBnpA2ZB6Rum3UDcZO36wPweNkpj5qD4TmTQiI5GT8F327wG lgutSIburP5EOR9tGHWhtauKydyxr92nAo2RntDnWmvcIbdHzDy1S6iowuO7csBDSP3y DixA== MIME-Version: 1.0 X-Received: by 10.152.27.227 with SMTP id w3mr2076269lag.84.1375905890273; Wed, 07 Aug 2013 13:04:50 -0700 (PDT) Received: by 10.112.168.225 with HTTP; Wed, 7 Aug 2013 13:04:50 -0700 (PDT) In-Reply-To: <20130806000405.24891.qmail@joyce.lan> References: <0461F0E5-2569-42E5-838E-8E4A631F691E@viagenie.ca> <20130806000405.24891.qmail@joyce.lan> Date: Wed, 7 Aug 2013 17:04:50 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: John Levine Content-Type: multipart/alternative; boundary=089e0158c292d5905c04e3610d78 Cc: "" Subject: Re: [weirds] Outcomes of today's meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:04:53 -0000 --089e0158c292d5905c04e3610d78 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Mon, Aug 5, 2013 at 9:04 PM, John Levine wrote: > >I would suggest rephrasing that "advanced search" (as not the stuff > folded into the > >basic specs) is lower priority for now. It may be just good to do > parallel work, > >because one can complement the other... > > I'd prefer to declare advanced search to be dead unless we identify a > significant server operator who is planning to provide it. > Agreed. ~Carlos > --089e0158c292d5905c04e3610d78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --089e0158c292d5905c04e3610d78-- From olaf@NLnetLabs.nl Sun Aug 11 04:41:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0725621F84B1; Sun, 11 Aug 2013 04:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.073 X-Spam-Level: X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln4J6kIXvRa0; Sun, 11 Aug 2013 04:41:08 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20B21F9FA7; Sun, 11 Aug 2013 04:34:07 -0700 (PDT) Received: from [IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355] ([IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7BBXxGD081975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Aug 2013 13:34:01 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7BBXxGD081975 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1376220843; bh=izHjUQlDG+fmhlRXMovzA+L9CYRYXdrLNKFGtdrT4p8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GjTuOw8KoYHJyOPro0zWSrIrSLSluLZ39dy9e2zgX+3kso+1ZFM6jjk9rDy6U2kEX Uc0jpqKnFxpeS0zR+cWwAxZ/2PC7LwmEUtUD0lj2VI+SNIvprjNDF9ku2ANzFW4ig7 e2N1aCCqm1T2DwOy20xQLNClC2sFu4bprYapIlJs= Content-Type: multipart/signed; boundary="Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Sun, 11 Aug 2013 13:33:58 +0200 Message-Id: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> References: To: Larry Masinter X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Sun, 11 Aug 2013 13:34:02 +0200 (CEST) Cc: draft-ietf-weirds-using-http.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org, "weirds@ietf.org Group" Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Aug 2013 11:41:09 -0000 --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Larry, [ Adding the WG, for transparency purposes. ] In my role of doc-shepherd I've put some comments in-line. Overall I am = trying to tease out the actionable bits and try to suggest some = resolutions. I leave it to the document editors to come up with concrete = text. It is clear to me that addressing Larry's comments will lead to a better = context which will help future implementors. Thanks for that Larry. On Jul 31, 2013, at 2:19 PM, Larry Masinter wrote: > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate ). >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-weirds-using-http-07 > Title: HTTP usage in the Registration Data Access Protocol (RDAP) > Reviewer: Larry Masinter=09 > Review Date: 7/31/2013 > IETF Last Call Date: [include if known] > IESG Telechat Date: On agenda of 2013-08-15 IESG telechat > Summary: The document needs quite a bit of editorial work, but the = protocol itself seems OK, modulo a few questions. >=20 > Major Issues/Minor issues: I think the document suffers enough = editorial confusion that they rise to the level of "Major" >=20 > Please define what "Registration Data" is on first use. > Please define what "Registration Data Directory Services" are. > Please supply a reference for "RESTful" >=20 > Please explain what you mean by "better" in: > "By giving the various Directory Services common > behavior, a single client is better able to retrieve data from > Directory Services adhering to this behavior." > Better how? >=20 > Please explain or give an example about what is insufficient in: > "the WHOIS protocol is insufficient to > modern registration data service requirements." >=20 >=20 > The sentence > =E2=80=9D Where complexity may reside, it is the goal of this = document..." > is awkward, suggest just striking "Where complexity may > reside". >=20 >=20 > Please explain who "SSAC" is and why their opinion about WHOIS is = relevant. > in " As is noted in SSAC Report ..." >=20 > Please give a reference for RDAP >=20 This whole set of comments suggest that for somebody not active in the = Internet Registry world this work falls out of thin air. At IETF last = call Subremanian Moonesamy had similar comments. I believe your = suggestions for expansions would go a long way fixing that. >=20 > Section 2 Terminology: > " In this document, an RDAP client is an HTTP User Agent performing = an > RDAP query, and an RDAP server is an HTTP server providing an RDAP > response. RDAP query and response formats are described in other > documents in the collection of RDAP specifications, while this > document describes how RDAP clients and servers use HTTP to = exchange > queries and responses." >=20 > I think you're defining a way of layering RDAP-like functionality = using > HTTP instead of something lower level. This doesn't seem like = "terminology" -- > this document defines a kind of RDAP client and a kind of RDAP server. Action: Change of header ? >=20 > Section 3 "Design Intents" >=20 > Neither "design intents" or "design ctriteria" seems to fit > what you're talking about. "Design constraints"? "Design > considerations" ? Notable "design decisions" ? >=20 > I don't understand whether restricting responses to zero or one > result is a difficult or onerous constraint. >=20 Suggested action: Change the first sentence to: "In this document made a number of design choices are made"=20 > "First, each query is meant ..." Each RDAP query itself? In all RDAP > applications ever? If not, in what circumstances? Which RDAP > queries have this constraint? >=20 I believe this to be Each RDAP query by all RDAP applications ever. If = that is a misunderstanding (and the working-group will no-doubt correct = me if I misunderstand) then we probably need clarifying text . > Is it the "semantics" of the "request/response" that allows > for future response formats? I think you're saying something > about the protocol being extensible in the future to allow > other formats than JSON. >=20 Correct. Would adding something like "i.e. the protocol is extendable to = allow other formats than JSON" help to clarify? > Moving "including cache control, authorization, compression, and > redirection" to after "HTTP offers a number of mechanisms" (surrounded = by > parentheses) will make the sentence clearer.=20 Clear action. >=20 > However, I'm not convinced that you can avoid giving more > specific advice about how cache control, authorization,=20 > compression and redirection work with RDAP. For example, > the cache-busting section indicates that cache control headers > aren't sufficient. >=20 > How will RDAP over HTTP work on a hotel network which redirects HTTP > requests each day at noon? I do not recall this to be discussed in detail in the WG. Are there = references for generic approaches to these sort of problems?=20 Also, how specific does this need to be given that the protocol serves a = specify use case with specific users (producers and clients of Internet = Registry data that is currently published in WHOIS databases). The actions are either "don't be more specific", add a reference, or add = text.=20 >=20 > " an RDAP specific JSON media > type, the generic JSON media type, or both." >=20 > Please be explicit "application/json" for "the generic JSON media = type" > and give an explicit example of "an RDAP specific JSON media type" > and provide references where those are defined. Those seem very clear suggestions for resolution, thanks. Action: Editorial clarification. >=20 > 5.1 Positive Answers >=20 > can you be more explicit about what kind of response is expected? Would it be sufficient to refer to the fact that a JSON object will be = returned? >=20 > Please address the use of HTTPS with TLS vs. HTTP. Would a reference to = http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec suffice? >=20 > I question the use of 404 Not Found to indicate "no information > regarding the query", since it doesn't distinguish between "no = information" > and "wrong query". Not sure what you mean with 'wrong query'. If you mean "Malformed Query" then that is addressed by section 5.4.=20= If you mean "No business asking" then that is addressed in the last = paragraph of 5.3. >=20 > Please be more explicit about "a RDAP-HTTP Server" rather than > "a server" in 5.3, 5.4 etc. >=20 Clear action. > " Optionally, it MAY > include additional information regarding the negative answer in the > HTTP entity body." > how can this be used interoperably with such little specified? >=20 > I admit I am baffled by the Extensibility section 6, since I can't see > how it allows extensions.... for what? Under what cicumstances? > How do you distinguish between known and unknown extensions? >=20 > Section 7: Security Considerations > Normally, a security considerations section might outline threats > and mitigations for them. This section doesn't seem to. I think this is also where we see that the specifications are a bit = targeted to a specific audience of Internet Registry producers and = clients. I am of the impression that the WG wants to keep the mesh of normative = cross references to other documents to a minimum. but maybe a reference = to http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec would help here = to? >=20 > Section 9.1 URIs and IRIs > This is confusing, of course clients can use whatever internally > they want. =20 >=20 > How is a "URI" used in a response? The response is RDAP information. e.g. in redirects. >=20 > Transforming URIs to IRIs is a potentially buggy heuristic process > and should not be recommended here. The Internationalization aspects have been discussed ad nausea in the = WG. Most of the i18n takes place in constructing the query = (http://tools.ietf.org/html/draft-ietf-weirds-rdap-query) there the only = elements that are subject to i18n are the DNS names used(in the queries) = and their translation is well defined. So what is left for transforming the URIs is the mapping between A- and = U- Labels for the domain part of the URI itself.=20 (Would sort of clarification help in the document?) >=20 > 9.2=20 > "Under most scenarios" -- a few scenarios would be helpful. >=20 Action for editors? Thanks for the Review. --Olaf --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSB3amAAoJEFRqER47aqpkfBwP/jaqqM1l8VN7Pvo5QHcNvkze QjWFSk0vwm78I1wddDkTmN3/Ra4NPvBa/uAvi93jEBlkZtUJVbQUx1H+PGusTD1K 1g2ZXw6gPZQF6o7NtIiC27mwIXqEkQGlTrua8Cd7zyQBkVmz8J583PNjLsz1zNgt 3M4n3VD0IX3z7R14lehL40dFtu0vTCn2TWd6wsJxFTAHVOqp/CvLCjJ+8/0am2YG 8KS13Bte/t8MbgeT9wRiX48NX17+bb/RgLQzF/Vk5WMD/pOpdeNRbrSLQtKAtYPG B5wphMfXjKtCzaIuWgw4i/AY1KSZUPNLTriXOXOk43Owli6WuitzTK/NzkJz+0ST euC9xaE+kcZx/dLD+pFKgBy84u5RctrXgQrcBKgTf/b65KkPbBB+nuCpaEeqmaHn 8RZX7XuqDY/y1nQhI/hqGGXJUnhfAatTpvyg1TM8WT7kVDnq/jJvCTYhflnoDJa3 DvEChyDjouLOyeCSimQDuU63XVO1kGQjqXtwuD1/tRUZT7isqYuorOz5gYkSGvKa cx+icd0FSxu4TKYqNbixaXz3C7EKoxblSs/XPBJke+dQDzuNVa+dZwyINBpkieNC YPA1bJ63zphp6ddz3hRmRrgboYGoULw009c1IPopw8ZnIcj7JxeeWrkMZmyWIEd/ TOcsI71iQaVfM8FyPxfO =qWXl -----END PGP SIGNATURE----- --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF-- From olaf@NLnetLabs.nl Sun Aug 11 04:41:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B6D11E8116 for ; Sun, 11 Aug 2013 04:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.907 X-Spam-Level: X-Spam-Status: No, score=-100.907 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGBBHj+5wiJc for ; Sun, 11 Aug 2013 04:41:10 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7421F9FC8 for ; Sun, 11 Aug 2013 04:34:11 -0700 (PDT) Received: from [IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355] ([IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7BBXxGE081975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Aug 2013 13:34:05 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7BBXxGE081975 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1376220850; bh=icvXV/dPVYsr3y6Wgr4UHARI96FjQCdWSfwjOtAFp2g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nLEOYZrPWOTHVcLukXE8INlDVdcivQWlVfVqtLiezJUdghqhI2abanoQjcUFVPqUm wAM0hGfR2yhtEQHT30RObyAks9WAdjlO+XdBL8ecf2h7XvcBbGUanNYKB1p6zVTeB7 f06se8Rh8NI401wOmwa1BSpkqmblLDFRnW289AY0= Content-Type: multipart/signed; boundary="Apple-Mail=_B0A6FA75-F086-4A4B-9DD5-D628F7C4BB3F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: <6.2.5.6.2.20130716195548.0d5b1db0@resistor.net> Date: Sun, 11 Aug 2013 13:34:00 +0200 Message-Id: <49DC0519-83F6-4571-9CA0-A3A7EA66B14C@NLnetLabs.nl> References: <20130715230536.14139.1854.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130716195548.0d5b1db0@resistor.net> To: SM X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Sun, 11 Aug 2013 13:34:05 +0200 (CEST) Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http@tools.ietf.org Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Aug 2013 11:41:15 -0000 --Apple-Mail=_B0A6FA75-F086-4A4B-9DD5-D628F7C4BB3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Subramanian, [ Adding the WG, for transparency purposes. ] [ I've dropped the IETF list at this point, as we seem to delve into = details, feel free to add the IETF list if you think that is wise] [ Adding Pete to the CC, for information, nothing actionable] On Jul 17, 2013, at 6:15 AM, SM wrote: > At 16:05 15-07-2013, The IESG wrote: >> The IESG has received a request from the Web Extensible Internet >> Registration Data Service WG (weirds) to consider the following = document: >> - 'HTTP usage in the Registration Data Access Protocol (RDAP)' >> as Proposed Standard >=20 > The Abstract mentions that: >=20 > "This document is one of a collection that together describe the > Registration Data Access Protocol (RDAP). It describes how RDAP is > transported using the Hypertext Transfer Protocol (HTTP)." >=20 > In Section 2 it is mentioned that: >=20 > "RDAP query and response formats are described in other documents > in the collection of RDAP specifications, while this document > describes how RDAP clients and servers use HTTP to exchange > queries and responses." >=20 > I read the document and I did not find any other information about = collection of RDAP specifications. >=20 > According to Section 1: >=20 > "This document describes the usage of HTTP for Registration Data > Directory Services." >=20 > =46rom Section 2: >=20 > "In accordance with [SAC-051], this document describes the base > behavior for a Registration Data Access Protocol (RDAP). > [SAC-051] describes a protocol profile of RDAP for Domain Name > Registries (DNRs), the Domain Name Registration Data > Access Protocol (DNRD-AP)." >=20 > The recommendation in SAC051 is to adopt the following terminology: >=20 > "Domain Name Registration Data Access Protocol (DNRD-AP). > The components of a (standard) communications exchange=ADqueries > and responses=ADthat specify the access to DNRD" >=20 > I did not find any other information about the Registration Data = Access Protocol. It is weird that the IETF is standardizing a = collection of documents which is undocumented. It is also weird that = the IETF is standardizing the Registration Data Access Protocol when = there isn't any information about the said protocol except for the = terminology mentioned above. >=20 > =46rom Section 1: >=20 > "A replacement protocol is expected to retain the simple = transactional > nature of WHOIS, while providing a specification for queries and > responses, redirection to authoritative sources, support for > Internationalized Domain Names (IDNs, [RFC5890]), and support for > localized registration data such as addresses and organisation or > person names." >=20 > I read the draft again and I still did not know what the replacement = protocol is. I suggest clarifying where the Registration Data Access = Protocol actually exists and where is it specified. >=20 All of these points above seem to me to suggest that the context in = which this document is used is not clear to the innocent reader (Are = there any in this space?). =20 The review by Larry Manister = (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10141.html) = also touches on this point. He makes concrete suggestions in order to = fix the document: >> Please define what "Registration Data" is on first use. >> Please define what "Registration Data Directory Services" are. >> Please supply a reference for "RESTful" >>=20 >> Please explain what you mean by "better" in: >> "By giving the various Directory Services common >> behavior, a single client is better able to retrieve data from >> Directory Services adhering to this behavior." >> Better how? >>=20 >> Please explain or give an example about what is insufficient in: >> "the WHOIS protocol is insufficient to >> modern registration data service requirements." >>=20 >>=20 >> The sentence >> =94 Where complexity may reside, it is the goal of this document..." >> is awkward, suggest just striking "Where complexity may >> reside". >>=20 >>=20 >> Please explain who "SSAC" is and why their opinion about WHOIS is = relevant. >> in " As is noted in SSAC Report ..." >>=20 >> Please give a reference for RDAP The request that I read in your and Larry's review is to clarify what = RDAP is and in what context it is used. I think Larry's suggestions help = achieving that, correct? > In Section 1: >=20 > "This is the basic usage pattern for this protocol: >=20 > 1. A client issues an HTTP query using GET. As an example, a query > for the network registration 192.0.2.0 might be http:// > example.com/ip/192.0.2.0. >=20 > 2. If the receiving server has the information for the query, it > examines the Accept header field of the query and returns a 200 > response with a response entity appropriate for the requested > format. >=20 > 3. If the receiving server does not have the information for the > query but does have knowledge of where the information can be > found, it will return a redirection response (3xx) with the > Location: header field containing an HTTP(S) URL (Uniform > Resource Locator) pointing to the information or another server > known to have knowledge of the location of the information. The > client is expected to re-query using that HTTP URL. >=20 > 4. If the receiving server does not have the information being > requested and does not have knowledge of where the information > can be found, it returns a 404 response. >=20 > 5. If the receiving server will not answer a request for policy > reasons, it will return an error response (4xx) indicating the > reason for giving no answer." >=20 > The above is basically HTTP being given another name. Section 3 of = the draft says that: >=20 > "HTTP also benefits from widespread investment in scalability, > reliability, and performance, and widespread programmer = understanding > of client behaviours for RESTful web services, reducing the cost to > deploy Registration Data Directory Services and clients." >=20 > It seems that someone decided to choose port 80 and then went to find = the reasons for that choice. Can I ask for some references for the = above? I am okay if I am told that I have to believe that it is true = because it is written in a RFC. Would all this be solved with a reference to RESTful?=20 >=20 > =46rom Section 4.2: >=20 > "Servers MUST ignore unknown query parameters. Use of unknown query > parameters for cache-busting is described in Appendix B." >=20 > If I understood the requirement it is that the servers must ignore = unknown query parameters while the draft documents usage of unknown = query parameters in Appendix B. This doesn't make sense to me. Appendix B describes how _clients_ make use of those parameters to = circumvent middle boxes, like caching proxies. In other words given = that Servers MUST ignore the query parameters appendix B describes a = cool hack to circumvent unwanted middle box behavior. I don't think any action is required, unless you have suggestions for = specific language? >=20 > =46rom Section 5: >=20 > "While no standard HTTP response code is forbidden in usage, at a > minimum clients SHOULD understand the response codes described in > this section as they will be in common use by servers." >=20 > I don't understand the "SHOULD understand". Would this work: SHOULD implement the specified behavior for the response codes described = in=85. >=20 > =46rom the Security Considerations section: >=20 > "This document does not pose strong security requirements to the RDAP > protocol." >=20 > I read the about as meaning that the unspecified RDAP protocol does = not need strong security requirements. >=20 > "Additional security considerations to the RDAP protocol will be > covered in future RFCs documenting specific security mechanisms and > schemes." >=20 > I assumed that security considerations was about considering security = concerns and discussing about them. The above leaves that to future = RFCs. Larry has similar remarks.=20 >=20 > In Section 9.1: >=20 > "Clients can use IRIs [RFC3987] for internal use as they see fit, but > MUST transform them to URIs [RFC3986] for interaction with RDAP > servers." >=20 > That means that servers do not support internationalization. Yes the parts of servers that deal with the queries is defined to deal = with URIs. The i18n aspect here is that the client is instructed to = normalize the query behavior, not the server. The part of servers that deals with responses and internal lookup magic = do need to have understanding of i18n, that is in 9.2. I am not sure how this comment is actionable? Suggestions? >=20 > =46rom Section 9.2: >=20 > "On the other hand, when servers return data and have knowledge > that the data is in a language or script, the data SHOULD be > annotated with language identifiers whenever they are available, > thus allowing clients to process and display the data accordingly. >=20 > The mechanism for including a language identifier in a response will > be defined in subsequent documents describing specific response > formats." >=20 > The approach adopted in this future Proposed Standard is that = everything will be defined in some future document. This future = Proposed Standard is under-specified to the such an extent that it would = be extremely difficult to implement without insider information. Yep, it is clear that that is the overall theme in your review. Acting = on this would involve adding a number of references to other documents = in he WEIRD suite.=20 > By the way, the RFC 4627 and RFC 5234 references should be normative. >=20 Thanks for your thorough review,=20 Best, --Olaf --Apple-Mail=_B0A6FA75-F086-4A4B-9DD5-D628F7C4BB3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSB3aoAAoJEFRqER47aqpk2m0P/1+G5pRGJA7crpJZDDt3jzkG Y40Ko9MYzbm7CUI3g8lhAtrgO2DqsjbMU0QPZL2pcj+9lXFmx1+0bs9dM/nyqvUA 102sStVK/8Gh46LTMyD5klm7zXfvhOlhp1qbC6QPyPOl/aALoBA/LZ85ItEt5m2d 5XuHg1JFMA5uxF4Xo7iVV93q2mj9thrgAZu/xyMgeNeR2IdQ0E18ohXMH/hZfAYs f/NuEx+fKdjLDSCvS3Cy6oQw8Qp1RNw6GtnI5rXYdoG6FtzX1pYhsvp/gq5j37ou sf/1wGYVMjRdBH9+dRb6HSKXWophqWhvkWdTsZllVBTbVo12N5PJy3vjNR/EcVMb aS2eCETsmgbqvrdDZjVhxsRx9+PBRoxgfG1VFBUmyT+fnIgb4TrKcVgFfGR2XyWw WecSIA9ZUkDXfNl5+BBfCltUVLjVDL/MQF/H0t6P55yvqRA6hjBo7IgcT5flTnRv 6wooKhed7V9x3TiR3HEoGufn0l1DfvzvuKSJzd1TtJFclD9UyLNIzrpXwT/cEz9g j32EXSAkV7pirxZBkU7C/ivuvLx7DbpAZFzbLcDifzpQCWBqHMey2fYPNfU0MS4u Dru52Ee9Jjqr1TA93RLZG8mJAjsFlNDcJSFNLbVC222domFY98E2WcanZDfLsvez 0M8kTwVPSkkGA1bZVGTB =CxyI -----END PGP SIGNATURE----- --Apple-Mail=_B0A6FA75-F086-4A4B-9DD5-D628F7C4BB3F-- From johnl@iecc.com Sun Aug 11 08:14:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7E11E8149 for ; Sun, 11 Aug 2013 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.091 X-Spam-Level: X-Spam-Status: No, score=-105.091 tagged_above=-999 required=5 tests=[AWL=-3.981, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlmhK1RJPLCj for ; Sun, 11 Aug 2013 08:14:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0611E810F for ; Sun, 11 Aug 2013 08:06:48 -0700 (PDT) Received: (qmail 45177 invoked from network); 11 Aug 2013 15:06:47 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Aug 2013 15:06:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5207a886.xn--9vv.k1308; i=johnl@user.iecc.com; bh=hUz0KOy8T6hi6TuIJ/GHh8ZYVFWlm15sh0mOkXIs5yM=; b=P0nbkGY6qedh3AFz7XIAc2IBR0bivOSNlHom2xPyHUthvNYSzA9yxK6fvLuew4ZzlaboAum8eQwLt7c1MRZSDjRW+bwAqvJK+NI61mVKfOvo+eriJIvrHeXBdWGFLjDk5MR3bAj3finnIoQ/I8MZ7cfM5M+Dwz1gxm23DsQuD3mah+9HJ3Q+0tyDlJNEhtbR3TPWC5Etoj2qVKOGxhziVs6blvIz7Hn77GlmNmlVnSesqCMTwhUOwFpvSp/W7cl9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5207a886.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=hUz0KOy8T6hi6TuIJ/GHh8ZYVFWlm15sh0mOkXIs5yM=; b=H8vw3AU82VArv7rW6DhbCgXqLLCID89RI3lONTKTaIrb94HKOL5vkiuWKx3BDX/PcKZNA3SOOfrCae8UYLqOmiYk0JrQNN1X2VKrfwDJx7dthmS7Iv+4ZhfoRc2tqvC7vykocqWmNXZQGvupRmeP88kJpqJHdpue8/7WertLhlQucAK093d08IJyPmi851Iqrmec9f4s/c1ydzztE4yHs4yq2D0Snkh/lr05nwxPrOEwFmevgP8cAn+r4do+kL0C Date: 11 Aug 2013 15:06:24 -0000 Message-ID: <20130811150624.14063.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Aug 2013 15:14:29 -0000 >> However, I'm not convinced that you can avoid giving more >> specific advice about how cache control, authorization, >> compression and redirection work with RDAP. For example, >> the cache-busting section indicates that cache control headers >> aren't sufficient. >> >> How will RDAP over HTTP work on a hotel network which redirects HTTP >> requests each day at noon? My suggestion would be to take this part out. At some point, if you're using HTTP, you get what HTTP gives you. None of these issues are unique to RDAP, so at most we could put in a few pointers to other places where they are addressed or discussed. My personal preferred ways to avoid overeager caches are to use https, or a SOCKS proxy to a better behaved host, but I wouldn't write that into a spec either. R's, John From barryleiba.mailing.lists@gmail.com Mon Aug 12 12:56:31 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D168C21F9D18; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N09rG1txlm2t; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6B21F9D05; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so2874509veb.18 for ; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nWUMmJCLU+HjXvOzMAcI22mmUL99uS4ZWaiVQ0wMvtI=; b=qBn/iGaDSbmGRzswm5Q31aLo/HrY5iO2e5c9Ew/rm7ncA4+3UWbOzb2SkOhQQaqlaT EkPf9aeZN962r/kgbJs99jjUw6otE8dqIoESFf2EpjB44mfksqpQ3wYMObn9czDlv5ZA g+dhCsY3w+gTZHKNUBugx69fGp60sv+MYqCrkyAieAr05kp7pNIk8qeLosdSISundrig lnFwxqtKh24H5bxWq/6WQJ4nXAIfgjWgSDrj39gMN9pyhc7aDyCHwCwiEg7NK1IuhNzG MtIJL9kmaFfkyWKty5sfwG18jJ6ti7G9s+g1BYsmyJv6FHL+bFpVZcpWEjB6EQ/6pJTx yWrg== MIME-Version: 1.0 X-Received: by 10.58.73.202 with SMTP id n10mr573312vev.7.1376337390518; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) In-Reply-To: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> Date: Mon, 12 Aug 2013 21:56:30 +0200 X-Google-Sender-Auth: Tsy_8L7DMNmN89XyakoOHxW6fms Message-ID: From: Barry Leiba To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Aug 2013 19:56:32 -0000 >> I question the use of 404 Not Found to indicate "no information >> regarding the query", since it doesn't distinguish between "no information" >> and "wrong query". > > Not sure what you mean with 'wrong query'. > If you mean "Malformed Query" then that is addressed by section 5.4. > If you mean "No business asking" then that is addressed in the last paragraph of 5.3. 404 is meant to say that the URL you're asking for doesn't exist (or the server isn't willing to disclose that it exists). When you use HTTP to retrieve a web page, there doesn't need to be a distinction between "the web page doesn't exist" and "the web page is empty" (that is, there's no information for me to give you). I'll just give you no information. When you use RDAP, presumably there *is* a useful distinction between the two. Larry's questioning whether it's wise to use 404 for the latter -- what you're asking for exists, but there's nothing to say about it. And so the question is whether there's a useful distinction in RDAP between "you're querying about something that doesn't exist" and "you're querying about something that exists, but there's no information available about it." If not, then 404 might be OK. If so, though, there should be different status codes, and 404 belongs to the former. Barry From olaf@NLnetLabs.nl Tue Aug 13 00:41:45 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAC21E80C6; Tue, 13 Aug 2013 00:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc4-0-aeTkRB; Tue, 13 Aug 2013 00:41:44 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79F21E80E0; Tue, 13 Aug 2013 00:41:40 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7D7fSOf092467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 09:41:29 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7D7fSOf092467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1376379691; bh=02nsMptkDneobbH5xfuqqAnp5VAeEb3suCJEyFQ/+zY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Zq1+lFTG68QRGX/2CNyXsTpT00JLlJpYhH/YHqFcqj1aS2vEfWuOUaSLi+WrOmbpM yPEw83Y2WFHVsYV+5aNujYLpSVpbM5Qpdtgzi4VocIQK8sLC0T1yvxIaBIU1D58mcd leKigKE/WOfR9tkU9+QjQz1frY7WsLwsmQkp+xjI= Content-Type: multipart/signed; boundary="Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Tue, 13 Aug 2013 09:41:30 +0200 Message-Id: <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> To: Barry Leiba X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 13 Aug 2013 09:41:31 +0200 (CEST) Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 07:41:45 -0000 --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 12, 2013, at 9:56 PM, Barry Leiba = wrote: >>> I question the use of 404 Not Found to indicate "no information >>> regarding the query", since it doesn't distinguish between "no = information" >>> and "wrong query". >>=20 >> Not sure what you mean with 'wrong query'. >> If you mean "Malformed Query" then that is addressed by section = 5.4. >> If you mean "No business asking" then that is addressed in the last = paragraph of 5.3. >=20 > 404 is meant to say that the URL you're asking for doesn't exist (or > the server isn't willing to disclose that it exists). >=20 > When you use HTTP to retrieve a web page, there doesn't need to be a > distinction between "the web page doesn't exist" and "the web page is > empty" (that is, there's no information for me to give you). I'll > just give you no information. >=20 > When you use RDAP, presumably there *is* a useful distinction between > the two. Larry's questioning whether it's wise to use 404 for the > latter -- what you're asking for exists, but there's nothing to say > about it. >=20 > And so the question is whether there's a useful distinction in RDAP > between "you're querying about something that doesn't exist" and > "you're querying about something that exists, but there's no > information available about it." If not, then 404 might be OK. If > so, though, there should be different status codes, and 404 belongs to > the former. I can see 3 cases, which (I think) are all addressed: * Malformed query (I cannot answer this type of query) (5.4: 400) * I can parse the query but have no data (5.3 first paragraph: 404) * I can parse the query but don't want to hand you the data (5.3: 4XX = range, with optional information in the body) The last option is really of the form "there's no information for me to = give you" Am I misreading? Do not hesitate to use the clue-bat, if I am. --Olaf --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSCeMqAAoJEFRqER47aqpkXkYP/1peknyY+Uf8a88XNZstnXag 1GGc8EZnF/lqQLNRdRS21HuKkATKwe+LFrW/nw/Nb2qB0toU5e39iQILsJ/qxm4x rAWNFjGpGXF2s786QNZHZYlpON8sQnnj7q3hXlnfL5lTYnO1lxGPvnItdnBOpc/e LFU5ooXycM4PdxK3eynuW4d1wVvQdnUTskJCqdgOgGwaMLWtIStrioKpkJ57b8TT 1EirEvuI0zMqecbR9KyErImoKNkdvUjWiLCMD8K/FIH59N0WJpe7xDb1oTQ7hNK4 5eskLPLFomL89vIOfoJAEBn9KQKpciHBo5WMvMBa90wYTuXG+JkkJbfPA9XcODGo En6WiZxyGtdf1YkqwhbpjaFBjATqOi83yJS6i2jD49mgcPkQjp2zksgLId/Md/Bp HV8WmcZUvhxsCzk33+LnrhkOEe1OihNgYzDbz2hea+PEK+fhQjc9g20PD4Z9tcyD ElmujighkNBZVyZRiWG1sBzQ2/hu8LIFidxevAiD5TzYQ/atU/Dty/m2s2BVKL+K fmZJZ+sW4CC5z/yL+Ryi3zwt1dVFtonauF9nojmcDy4UbpNvLw/JJapi1l8ihCjb Z0DKliT/z44P7kygpp907iu7VfYbx7PWoju3X8E4ngqzoBMCYz/3i7MsujrOJUFb rb1N+b7vq2P/ZhLoBGum =BGzn -----END PGP SIGNATURE----- --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C-- From sm@resistor.net Tue Aug 13 05:07:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F2011E8152; Tue, 13 Aug 2013 05:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.444 X-Spam-Level: X-Spam-Status: No, score=-99.444 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57T3CVE11O2G; Tue, 13 Aug 2013 05:07:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E735811E814D; Tue, 13 Aug 2013 05:07:10 -0700 (PDT) Received: from sm-THINK.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 r7DC6ota022208; Tue, 13 Aug 2013 05:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376395617; bh=Vw+jDurUtXj1aJ/vnLsQ6o0o6LYRFJAPZo7rANrqtm4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Hkyy+35cLeIerIO4d9cUB+iKBmIDvW5qZAgKE5ZrLXEV/ElC0kWWw6iZ1YwnKxtRv /rCj/xp3rWrvSBibOotETMWGU0SFwHkELSEFyYJbUj4hQoJb72uIFwwaKMJI8ZIOCr xyQkHlZPLNHHRHcK6Duj1Xjab4Pp/19A4qWq20Eg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376395617; i=@resistor.net; bh=Vw+jDurUtXj1aJ/vnLsQ6o0o6LYRFJAPZo7rANrqtm4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KmJUzywz2QuqYhMo2Bzu86ScLa3u+YVvaGax8wx0tTrAaEWObHeTrPvyshmi73NF+ JJx6Vk0r3r3G8k5z8z7V8VLrjisEPpjyhjoBzHkNVAr985UOg9d9iEnex9SleCE0uJ hDzNCLsZPjnhgVxIlK/6dkUXYzi17NNUN3jP1UtQ= Message-Id: <6.2.5.6.2.20130813042024.0b65b518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 05:06:22 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <20130715230614.25146.34230.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130724111528.0d2bf428@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org, weirds@ietf.org Subject: Re: [weirds] Last Call: (Security Services for the Registration Data Access Protocol) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 12:07:12 -0000 Hi Murray, At 10:36 AM 8/5/2013, Murray S. Kucherawy wrote: >RDAP is far from the first protocol specification to exist across >multiple RFCs, so this approach isn't uncommon. That said, I take >it you believe the material here should be rolled into one of the >other documents? Yes. >Correct, that's what it says. > > "RDAP SHOULD be capable of supporting future authentication methods > defined for use with HTTP." > >That sounds like a "SHOULD CONSIDER". Given how ill-defined the >protocol is I doubt that the above is actionable. > > >You said two important things here: > >1) Can you please elaborate on why you think this is "ill-defined" >and, if possible, how this could be remedied? It's difficult to understand what RDAP is as it is not clearly defined. That is what I meant by "ill-defined". In the above example, the "SHOULD" does not specify anything. It looks like a "forward-looking statement" as the "future authentication methods" are unknown. I would look at the specification in terms of what is required to achieve interoperability now instead of trying to define future needs. In terms of protocol it would be what the two sides have to do to talk to each other. One of the issues in MILE what that there wasn't a clear separation of the HTTP aspect and the MILE aspect. In simple terms it is better not to redefine how HTTP works; i.e. a 404 is a 404 instead of a contextual meaning of that code. >2) Insofar as this draft amounts to a requirements document, I take >"SHOULD be capable" to mean the actual implementation needs to have >hooks for the stated capability, or have a very good reason for not >providing those hooks (e.g., the same capability is available some other way). The draft is intended as a proposed standard. In my opinion that is different from a requirements document. The usage of SHOULD does not make it implementable. It is like using SHOULD to beat people up if they do not implement some future capability. :-) >More precisely, the draft takes the stance that federated >authentication is an option. The working group doesn't feel the >need to elevate this to SHOULD or MUST, likely because operators >might not be compelled to federate themselves with anyone for >whatever local security or privacy reasons apply. I mean that the draft does not contain any security feature which is mandatory to implement. >Right, and the benefits it provides in the context of RDAP. Is that >a criticism or an observation? What do you suggest? I don't think that the executive summary provides much value. I suggest dropping the tutorial material. :-) >The next sentence (which you omitted) provides the >context. Operators are advised to be aware of denial-of-service >considerations, and there's a document referenced that provides >useful information. Depending on the uptake of RDAP and the other >services that begin to depend upon it, it might become a DoS >target. Hardening against such attacks will be important to begin >with, but might become critical later. I think this is not a waste of space. Ok. >It is a web service, in as much as it uses web protocols. Is there >some improvement you'd like to suggest? The approach taken can create interoperability issues. I would look at this in terms of what the codes has to do. >Non-repudiation (which is the context of the paragraph from which >that sentence was taken) is one of the classic properties of >security, so I don't agree. It's useful to point out to the reader >that non-repudiation is not provided by any of the capabilities >discussed here, and its absence might be conspicuous. This draft looks like a tutorial for the not-well-informed. :-) There is likely some BCP which already discusses about non-repudiation. >It's true that the specific things called out in that paragraph are >not specific to RDAP, but rather to anything built atop HTTP. Do >you suggest something else, perhaps something more general like a >statement that any known HTTP-based attack might also affect an RDAP service? I would use that as the starting point and then discuss attacks which are specific to the service. >SecDir often scratches its head when a document says very little, so >what you're saying is often the case. However, sometimes it's >enough to say "This is built on top of HTTP, so all the security >issues known about HTTP and HTTPS also apply here." Do you have a >specific suggestion? It would be better to point to the relevant sections if the objective is to help the reader identify relevant issues. >That seems a little sharp. The comments were strong. :-( >This draft is manifestly not a technical specification insofar as it >does not define a new protocol. I would say it's partly a >requirements document and partly an applicability statement, and the >latter at least is normally a standards track document. I personally think that there is a lack of understanding of what an applicability statement is. I commented on the draft from a technical specification angle. >I don't know what "thinking about security" we are expected to do >beyond making use of the security services that have already been >made available to applications built atop HTTP. Do you have any >specific suggestions? It is a lot of work to explain or suggest text. It's not worth putting in the effort if the working group believes that the draft is okay. Regards, -sm >-MSK From barryleiba@gmail.com Tue Aug 13 05:46:22 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F0E21E812D; Tue, 13 Aug 2013 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR1053DhYrs1; Tue, 13 Aug 2013 05:46:21 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3520321E8135; Tue, 13 Aug 2013 05:46:19 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so275749qab.18 for ; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nIgYVMiAxv7OIFy9GM+Mv5tfNwkqe/gJ4wEkSNfnumo=; b=ya/LKi+CTs7LgXilCAkJz96IxcTHffKDLjbC+2iQ0nwr9Kh0vND+SBp0vdVZd9bN6H ij0PUwZ/aR3COyG9dqxQntHJUsCtcXcHh+EEAkPmIF4+XfcGlsziVsKtDvqqbIUriKPb U0zxZPu+K2UQ51mI8MOUP84egc3+dmWnJ3HoutUb2yepo35b9rRJiNZh9WyUj/uPyy8Z w89DZOyLVb1lBDofoqjFM2/qFKCYbxof5ULYTi6BwSfLAlW213L91Nl8UOGFD12Qji+R De918v6PabLjrZ12ZXlo91a7kbg7mWPkxwY9gdI856zPJTwV1ASuTWs08CbIiPLZ8QK5 PXJQ== MIME-Version: 1.0 X-Received: by 10.224.34.68 with SMTP id k4mr4565564qad.17.1376397977586; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) In-Reply-To: <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> Date: Tue, 13 Aug 2013 14:46:17 +0200 X-Google-Sender-Auth: 6yinPbn3FWJGNKBjdZROAet0Cxg Message-ID: From: Barry Leiba To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 12:46:22 -0000 >> And so the question is whether there's a useful distinction in RDAP >> between "you're querying about something that doesn't exist" and >> "you're querying about something that exists, but there's no >> information available about it." If not, then 404 might be OK. If >> so, though, there should be different status codes, and 404 belongs to >> the former. > > I can see 3 cases, which (I think) are all addressed: > > * Malformed query (I cannot answer this type of query) (5.4: 400) > * I can parse the query but have no data (5.3 first paragraph: 404) > * I can parse the query but don't want to hand you the data (5.3: 4XX range, with optional information in the body) > > The last option is really of the form "there's no information for me to give you" Hm. Specific example: I make a query to you at this URL: http://rdap.example.com/ip/203.0.113.0/24 That is clearly a properly formed query, so 400 is not on the table. Case 1: You are *not* the right place to ask about 203.0.113.0/24. This is what the HTTP 404 code is meant for, and I would think you'd respond with a 404. Case 2: You *are* the right place to ask about 203.0.113.0/24, but your policies do not allow you to give me the data. This is your third case above, and you will respond with some 4XX code. Case 3: You *are* the right place to ask about 203.0.113.0/24, and your policies allow you to give me the data... but there's just no data to give me. Is this a real case? Can it happen? If it happens, what status code will you send back? If case 3 can't happen, and it really is only cases 1 and 2 (and malformed), then we're done, and the stuff about 404 is fine. If case 3 can happen, we need to talk about it. Barry From andy@arin.net Tue Aug 13 06:32:12 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E923B21E8159; Tue, 13 Aug 2013 06:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVnSiyI1hKVo; Tue, 13 Aug 2013 06:32:07 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 6432A21E812F; Tue, 13 Aug 2013 06:32:07 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 16406165143; Tue, 13 Aug 2013 09:32:07 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9BEE916512F; Tue, 13 Aug 2013 09:32:04 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 13 Aug 2013 09:32:04 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.236]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 13 Aug 2013 09:32:04 -0400 From: Andy Newton To: Barry Leiba , Olaf Kolkman Thread-Topic: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 Thread-Index: AQHOmCM64I/D2mWoDEWTDZ8arUS4bpmTIrSA Date: Tue, 13 Aug 2013 13:32:02 +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.3.6.130613 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 Group" , "draft-ietf-weirds-using-http.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 13:32:13 -0000 On 8/13/13 8:46 AM, "Barry Leiba" wrote: > >Specific example: > >I make a query to you at this URL: >http://rdap.example.com/ip/203.0.113.0/24 > >That is clearly a properly formed query, so 400 is not on the table. > >Case 1: You are *not* the right place to ask about 203.0.113.0/24. >This is what the HTTP 404 code is meant for, and I would think you'd >respond with a 404. > >Case 2: You *are* the right place to ask about 203.0.113.0/24, but >your policies do not allow you to give me the data. >This is your third case above, and you will respond with some 4XX code. > >Case 3: You *are* the right place to ask about 203.0.113.0/24, and >your policies allow you to give me the data... but there's just no >data to give me. >Is this a real case? Can it happen? If it happens, what status code >will you send back? > >If case 3 can't happen, and it really is only cases 1 and 2 (and >malformed), then we're done, and the stuff about 404 is fine. If case >3 can happen, we need to talk about it. > >Barry > Barry, In case 3, if 203.0.113.0/24 is not an exact boundary for a network registration, the proper thing to do according to the query draft is to return the network registration that encompasses 203.0.113.0/24. Therefore I think case 3 cannot happen. There are similar semantics for autnum ranges. For domains, name servers, and entities, either they exist or they don't. Does the help? -andy From barryleiba@gmail.com Tue Aug 13 06:56:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B068D21E8149; Tue, 13 Aug 2013 06:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+r5dE4mi6TP; Tue, 13 Aug 2013 06:56:19 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 132DE21E80D8; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id i11so4286761qej.5 for ; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/hLboLeqb4QV9SsNxrafNzmxLoM5YCHeRJj5XE+P8ik=; b=JtoOs2JRqcf874H4xnyWPuQvRTMKuWJ2jTo47HAGIuZNFb1mB6/eFJmTJ+wanY6KPD 2mCQEYGF2aO+xn2q3pEwkggDZG+FkmU8l8koJOGaloKSov5fkaPUooldYYx5G74IcQUH 1QsNk+tRXVe4oyhDAErufVs880kESZsH1npNmbYXqAiPi9PwUDXjsFV+mJheP+LGkhgO NwGDpR0U6Px59v4zTgHKNaRKS0jFrwoR+0d3LsT6GDogMhMVFfQyzbs2cb8mEwD0NeKP AXyGYJjOXcxkUf30n7i0PWmwdqUpmglUKAWLAOASN9EVKyntnn5T0balH85x7YnlpXs1 saYQ== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr4843814qeb.1.1376402175251; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 15:56:15 +0200 X-Google-Sender-Auth: Uq1rqnbzy0H6KUnAO9GVIM50Igc Message-ID: From: Barry Leiba To: Andy Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , Larry Masinter , "draft-ietf-weirds-using-http.all@tools.ietf.org" , "weirds@ietf.org Group" , IESG Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 13:56:37 -0000 > In case 3, if 203.0.113.0/24 is not an exact boundary for a network > registration, the proper thing to do according to the query draft is to > return the network registration that encompasses 203.0.113.0/24. Therefore > I think case 3 cannot happen. There are similar semantics for autnum > ranges. For domains, name servers, and entities, either they exist or they > don't. > > Does the help? It does. If it's not possible to have a valid query that's been sent to the right place, but to have no data to return... then we're OK. Perhaps part of the problem here is that using-http seems to depend on rdap-query, but there's no normative reference to rdap-query here (only from rdap-query to using-http). Does using-http really make *any* sense at all without rdap-query? Barry From johnl@iecc.com Tue Aug 13 09:03:11 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040AE11E80AD for ; Tue, 13 Aug 2013 09:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZOSXZVcGs96 for ; Tue, 13 Aug 2013 09:03:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38C11E80A2 for ; Tue, 13 Aug 2013 09:03:06 -0700 (PDT) Received: (qmail 43076 invoked from network); 13 Aug 2013 16:03:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Aug 2013 16:03:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=520a58b7.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=TNpWhw6eM4qArDa1KfarsZvonsJfMHy/8zSm4VKoLmQ=; b=JK58pXJKIBP+AYoe5i6oFQMnZnmCNNr+4zvKZQZkLECM3f9VSZelhsumbguNOwGPblXqXM5c4O64/0Uyl6j2md/h/H22/lwFzWPYJCX6zdkxoUygQvghnTTxISJqhFl+XTrAU2xwQ9eg74cRh0ypWkVtXPjnFlOI6EBD1Hxosol7ciU3YZDZ7HfKOr9niaAvlPOS+a6PLt5zOq3jqW0mzWfp5QzBHt17Gq18sswLFKLUT/aEDDL720hArLXgSJhF DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=520a58b7.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=TNpWhw6eM4qArDa1KfarsZvonsJfMHy/8zSm4VKoLmQ=; b=SYdLr3nAb5929uf92yv3k3kxeFA8ZF3crAKtWMuArnjjBXUJIacAmTZ5mIli7r1Rid+BsjnAbMuOV5j2n++qK6nQsPCtbZuRljWKv4Ol3g/aUgC+LVKeniUx01aQ58FPD9Kb8StOxxszhwHZy+/ZCL3Cw6pdkdV75LnjTFE0webKhenCkDnkjO8ZMfH6wW/MdSeeZy3evh4ZUzbDd9w/8eYipxaIo9k7lXlTpRKr8SLHHnZclJRpio56CXfigEah Date: 13 Aug 2013 16:02:41 -0000 Message-ID: <20130813160241.2979.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 16:03:11 -0000 >In case 3, if 203.0.113.0/24 is not an exact boundary for a network >registration, the proper thing to do according to the query draft is to >return the network registration that encompasses 203.0.113.0/24. Therefore >I think case 3 cannot happen. There are similar semantics for autnum >ranges. For domains, name servers, and entities, either they exist or they >don't. > >Does the help? I was about to say roughly the same thing. If a number range or a TLD is delegated to you, you'd better have something to say about it, even if the something is that it's not further delegated and not in use. The closest I can come to having nothing to say is queries for a name that is a delegation point within a registry, such as k12.ny.us or co.uk, but even there the registries say (respectively) that it's a US locality or that it's not available for delegation. R's, John From sm@resistor.net Tue Aug 13 11:09:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E131311E8118 for ; Tue, 13 Aug 2013 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=1.578, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGCMY-p6pl+t for ; Tue, 13 Aug 2013 11:09:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E39DD21F91B7 for ; Tue, 13 Aug 2013 11:09:08 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7DI8w73001885; Tue, 13 Aug 2013 11:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376417347; bh=eyl7lIrgD/b0vnwlLLZ5sAiaL+5YH5SSiZnpY6cZITo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u4RE9jOv/CkBeFm3ZgK80XirKsjImA7TaVffO9RTLVBvYcH6+pRsQ1g0BxpUwzyxL p6+xhA3AavZtT0/Skp8L0AzZT94CshzKHJKWnykzGcZZzizErtI/aGUIyhjq1NL3WI j0g6Q+15KekRHuqzZFTd9aGvDtiuUcdhCsfBFtMQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376417347; i=@resistor.net; bh=eyl7lIrgD/b0vnwlLLZ5sAiaL+5YH5SSiZnpY6cZITo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Qc0MM2Myc9gDNCmS47PKgG3YiRsL28ilXm995Kk5tdRXTZWMX/ti87K8Q1FJrHDV6 LkX9iEAAytHXyQlq8bAf00mDNGluLrqKN8+6jXlkch3+EntZeUohe7Jo9TLblnmIQf VdlVNAuTKB+dqC4GWKOuU7atal6CcF1lnCpiszBk= Message-Id: <6.2.5.6.2.20130813101652.0d843508@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 10:59:55 -0700 To: Olaf Kolkman From: SM In-Reply-To: <49DC0519-83F6-4571-9CA0-A3A7EA66B14C@NLnetLabs.nl> References: <20130715230536.14139.1854.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130716195548.0d5b1db0@resistor.net> <49DC0519-83F6-4571-9CA0-A3A7EA66B14C@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Larry Masinter , weirds@ietf.org, draft-ietf-weirds-using-http@tools.ietf.org Subject: Re: [weirds] Last Call: (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Aug 2013 18:09:10 -0000 Hi Olaf, At 04:34 11-08-2013, Olaf Kolkman wrote: >[ Adding the WG, for transparency purposes. ] >[ I've dropped the IETF list at this point, as=20 >we seem to delve into details, feel free to add=20 >the IETF list if you think that is wise] >[ Adding Pete to the CC, for information, nothing actionable] Adding ietf@ is never wise. :-) >On Jul 17, 2013, at 6:15 AM, SM wrote: >All of these points above seem to me to suggest=20 >that the context in which this document is used=20 >is not clear to the innocent reader (Are there any in this space?). The first sentence (see above) is a good summary=20 of my comments. There are innocent readers in=20 this space. I'll restrain myself from commenting about this. :-) >The review by Larry Manister=20 >(http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10141.html)= =20 >also touches on this point. He makes concrete=20 >suggestions in order to fix the document: I agree with the points raised by Larry Masinter. >The request that I read in your and Larry's=20 >review is to clarify what RDAP is and in what=20 >context it is used. I think Larry's suggestions help achieving that,= correct? That is correct. >Would all this be solved with a reference to RESTful? I don't think so. As Larry pointed out, there is=20 a significant number of editorial issues which=20 can be considered as a major issue. The protocol=20 is okay. It's how it is specified which is the=20 problem, e.g. layering. Adding a reference to=20 RESTful is unfortunately not a fix. >Appendix B describes how _clients_ make use of=20 >those parameters to circumvent middle boxes,=20 >like caching proxies. In other words given that=20 >Servers MUST ignore the query parameters=20 >appendix B describes a cool hack to circumvent unwanted middle box= behavior. > >I don't think any action is required, unless you=20 >have suggestions for specific language? Could you provide some examples of known query=20 parameters as it may make the discussion easier? >Would this work: >SHOULD implement the specified behavior for the response codes described= in=85. That may work. It would be helpful if there is=20 some explanatory text for the "SHOULD". >Yes the parts of servers that deal with the=20 >queries is defined to deal with URIs. The i18n=20 >aspect here is that the client is instructed to=20 >normalize the query behavior, not the server. Ok. >The part of servers that deals with responses=20 >and internal lookup magic do need to have=20 >understanding of i18n, that is in 9.2. Section 9.2. has a "SHOULD" and basically says nothing. :-) >I am not sure how this comment is actionable? Suggestions? The entire document needs an editorial pass. I=20 don't know what text to suggest as anything I can=20 think of would not make sense as I look at the entire document. I would suggest looking at Larry's review and=20 edit the draft from that perspective. Once the=20 major issues (I am using the word "issue"=20 lightly) are resolved it is simply a matter of=20 doing another pass of the draft for consistency. Regards, -sm=20 From duerst@it.aoyama.ac.jp Wed Aug 14 05:59:01 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D102511E8152; Wed, 14 Aug 2013 05:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+LxxNyckZNB; Wed, 14 Aug 2013 05:58:55 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F511E81DD; Wed, 14 Aug 2013 05:58:54 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r7ECwiqV002945; Wed, 14 Aug 2013 21:58:45 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3263_3d2e_406ba228_04e1_11e3_9183_001e6722eec2; Wed, 14 Aug 2013 21:58:44 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 13954BFBC0; Wed, 14 Aug 2013 21:58:06 +0900 (JST) Message-ID: <520B7EE9.8010708@it.aoyama.ac.jp> Date: Wed, 14 Aug 2013 21:58:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Aug 2013 07:10:33 -0700 Cc: draft-ietf-weirds-using-http.all@tools.ietf.org, "weirds@ietf.org Group" , "apps-discuss@ietf.org" , IESG Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 14 Aug 2013 12:59:02 -0000 On 2013/08/13 21:46, Barry Leiba wrote: > Case 3: You *are* the right place to ask about 203.0.113.0/24, and > your policies allow you to give me the data... but there's just no > data to give me. > Is this a real case? Can it happen? If it happens, what status code > will you send back? > > If case 3 can't happen, and it really is only cases 1 and 2 (and > malformed), then we're done, and the stuff about 404 is fine. If case > 3 can happen, we need to talk about it. There is no need for a special status code for empty documents, they can be expressed in HTTP. Just in case case 3 could happen, what about something like Content-Length: 0 Or an 'empty' XML or JSON document or whatever the payload is? Regards, Martin. From spencerdawkins.ietf@gmail.com Wed Aug 14 06:33:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD011E815B; Wed, 14 Aug 2013 06:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMypKiA7eWiE; Wed, 14 Aug 2013 06:33:14 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6D21F9BCA; Wed, 14 Aug 2013 06:33:14 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so1631343obp.36 for ; Wed, 14 Aug 2013 06:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=le26r+8OEyi/rMTzCxe1eZOpHbpuBHB+FkJqRetF42E=; b=dJZvbc+q2WrzqsFYVWyoKzvSiODojEDCJgZKRrAXRei6LyY0cVtg5ppz+e+ewjo4aa j5xfBCJPgwbJN8Z5fEMiglswlIj641R39rwRUYv9fwgVSucBvFnoaVse5lPMNTCbxwyM 4gbJ/NFlAPcsWnWr0qrP8pxNLxakebEaoMFnEzolXSYlvqBpY2xK7qlS+TGyyXXFQ2/z BevCVnVhKo3BDcygIFbxJXTVlif6wfbSH4+tGlwrJ4pO4fOIQ6ZTBZuw5/JoF3ISbcC5 WaA0uIXlYDnEvPS4w02NHYk3cNG5ecYa8XrxZzkxGeiS74KyE7opuxJf2jNs9Zj0oZgV SNdA== X-Received: by 10.60.60.41 with SMTP id e9mr9587676oer.47.1376487193104; Wed, 14 Aug 2013 06:33:13 -0700 (PDT) Received: from [192.168.0.30] (99-200-110-204.pools.spcsdns.net. [99.200.110.204]) by mx.google.com with ESMTPSA id r4sm46372649oem.3.2013.08.14.06.32.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 06:33:12 -0700 (PDT) Message-ID: <520B8702.5030004@gmail.com> Date: Wed, 14 Aug 2013 08:32:50 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> <520B7EE9.8010708@it.aoyama.ac.jp> In-Reply-To: <520B7EE9.8010708@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Aug 2013 07:10:33 -0700 Cc: "apps-discuss@ietf.org" , draft-ietf-weirds-using-http.all@tools.ietf.org, "weirds@ietf.org Group" , Barry Leiba , IESG Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 14 Aug 2013 13:33:15 -0000 On 8/14/2013 7:58 AM, "Martin J. Dürst" wrote: > On 2013/08/13 21:46, Barry Leiba wrote: > >> Case 3: You *are* the right place to ask about 203.0.113.0/24, and >> your policies allow you to give me the data... but there's just no >> data to give me. >> Is this a real case? Can it happen? If it happens, what status code >> will you send back? >> >> If case 3 can't happen, and it really is only cases 1 and 2 (and >> malformed), then we're done, and the stuff about 404 is fine. If case >> 3 can happen, we need to talk about it. > > There is no need for a special status code for empty documents, they > can be expressed in HTTP. > > Just in case case 3 could happen, what about something like > Content-Length: 0 > > Or an 'empty' XML or JSON document or whatever the payload is? > > Regards, Martin. FWIW, I was sympathetic to Larry's concern about 404 overload expressed during IESG evaluation, at the Comment level. Of course, I'm not the right guy to say whether a new status code is required. If you tell people how to distinguish between "I can't tell you what I know" and "I can't tell you because I don't know anything" using a zero-length document in the response, that would address my comment without introducing a new status code. Thanks, Spencer From internet-drafts@ietf.org Fri Aug 16 09:15:26 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D979E11E8152; Fri, 16 Aug 2013 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66xAAPZ7dpdQ; Fri, 16 Aug 2013 09:15:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D73A11E8168; Fri, 16 Aug 2013 09:15:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130816161523.3326.99924.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 09:15:23 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-05.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:15:27 -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-05.txt Pages : 82 Date : 2013-08-16 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-json-response-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Aug 16 09:15:28 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B311E8152; Fri, 16 Aug 2013 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tKkOJS5W-hY; Fri, 16 Aug 2013 09:15:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F4911E8168; Fri, 16 Aug 2013 09:15:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130816161528.18556.41830.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 09:15:28 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:15: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-06.txt Pages : 15 Date : 2013-08-16 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Fri Aug 16 09:19:30 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809C811E81D2 for ; Fri, 16 Aug 2013 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbCIRQSEr+VX for ; Fri, 16 Aug 2013 09:19:24 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7686111E82A3 for ; Fri, 16 Aug 2013 09:19:24 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUg5RC57ZB6J04yRXrv6kX8RJ/ZTDM3wP@postini.com; Fri, 16 Aug 2013 09:19:24 PDT 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 r7GGJKRN011529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Aug 2013 12:19:23 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 16 Aug 2013 12:19:20 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: I-D Action: draft-ietf-weirds-rdap-query-06.txt Thread-Index: AQHOmpwJuI09dcBOOEuYdkVP+N8uxpmYAwUg Date: Fri, 16 Aug 2013 16:19:20 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49238323@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20130816161528.18556.41830.idtracker@ietfa.amsl.com> In-Reply-To: <20130816161528.18556.41830.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-06.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:19:30 -0000 -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, August 16, 2013 12:15 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: I-D Action: draft-ietf-weirds-rdap-query-06.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-06.txt > Pages : 15 > Date : 2013-08-16 >=20 > 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 most significant change is that Andy and I have added proposed basic se= arch processing text as discussed during the Berlin meeting. Scott From shollenbeck@verisign.com Fri Aug 16 10:08:51 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A57B11E8281 for ; Fri, 16 Aug 2013 10:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws3IfBPypigP for ; Fri, 16 Aug 2013 10:08:46 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E411E8166 for ; Fri, 16 Aug 2013 10:08:45 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUg5cm9/3/Bc3V6R1Cc+eDRiABgsMJOTI@postini.com; Fri, 16 Aug 2013 10:08:46 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r7GH8e25010821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Aug 2013 13:08:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 16 Aug 2013 13:08:40 -0400 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: Summary of IESG DISCUSS Comments for rdap-sec (and proposed changes) Thread-Index: Ac6ao0AEjnEMoiZiQM+jG7qk03H+xw== Date: Fri, 16 Aug 2013 17:08:40 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49238511@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] Summary of IESG DISCUSS Comments for rdap-sec (and proposed changes) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Aug 2013 17:08:51 -0000 All of the ballot comments can be seen here: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ballot/343468/ I'm also making minor changes to address the non-blocking comments. Here's = a summary of the DISCUSS comments received from the IESG along with propose= d text changes. >From Richard Barnes: > (1) The Authentication section should be Client Authentication, since > that's all it covers. Shouldn't there be some discussion of Server > Authentication as well? My response: "Thanks for the feedback, Richard. The section title is correc= t. The intention is to describe RDAP application of authentication security= services for both clients and servers, so yes, I should add text to addres= s server authentication. I don't think much is needed since we have no uniq= ue server authentication requirements beyond what we get with TLS. How abou= t this?" Add to section 3.1: RDAP does not impose any unique server authentication requirements. The ser= ver authentication provided by TLS fully addresses the needs of RDAP. In ge= neral, transports for RDAP must either provide a TLS-protected transport (e= .g., HTTPS) or a mechanism that provides an equivalent level of server auth= entication. > (2) I don't see anything here or in draft-ietf-weirds-using-http that > says that RDAP clients MUST support TLS. Shouldn't that be the case, > since HTTPS is the standard security mechanism? You should probably > also > consider how this would impact requirements around URIs for RDAP > services. My response: I'm going to suggest that such text should be added to using-h= ttp since that document addresses how clients and servers use HTTP to excha= nge information. An appropriate reference to HTTP Over TLS and/or rdap-sec = can be added to using-http. >From Sean Turner: > s3.1 contains the following: >=20 > To that end, RDAP clients and > servers MUST implement the authentication framework specified in > "HTTP Authentication: Basic and Digest Access Authentication" > [RFC2617]. >=20 > Does that mean the client and server need to support both basic and > digest? My response: Thanks for the feedback, Sean. A server needs to support one o= r the other. A client must be prepared to support both. Add to section 3.1: Servers MUST support either Basic or Digest authentication; they are not re= quired to support both. Clients MUST support both to interoperate with ser= vers that support one or the other. > s3.1: I think the gist here that should maybe be made clearer is that > servers need MUST implement TLS with server side certificates - no? My response: If there is a need to protect plaintext credentials they MUST. > What > I'm curious about here is whether there should be a SRV-ID or URI-ID is > needed for RDAP and isn't some kind of reference to RFC 6125 warranted > here? My response: I'm open to suggestions. Whatever is appropriate for a web ser= ver would be appropriate for RDAP. (I have not received a reply from Sean on this last point.) Scott From internet-drafts@ietf.org Mon Aug 19 05:32:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDB11E8248; Mon, 19 Aug 2013 05:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01i2HwDqD2U2; Mon, 19 Aug 2013 05:32:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1C21F9406; Mon, 19 Aug 2013 05:32:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819123238.683.46991.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 05:32:38 -0700 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-05.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 12:32:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Security Services for the Registration Data Access Proto= col Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-05.txt Pages : 11 Date : 2013-08-19 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-sec-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From edainow@afilias.info Tue Aug 20 08:53:54 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2521F9C99 for ; Tue, 20 Aug 2013 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-DZttzOkaFU for ; Tue, 20 Aug 2013 08:53:49 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C340E21F9C89 for ; Tue, 20 Aug 2013 08:53:47 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VBoFe-0004eu-5o for weirds@ietf.org; Tue, 20 Aug 2013 15:53:46 +0000 Received: from mail-yh0-f46.google.com ([209.85.213.46]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VBoFe-0001Sx-5U for weirds@ietf.org; Tue, 20 Aug 2013 15:53:46 +0000 Received: by mail-yh0-f46.google.com with SMTP id l109so134587yhq.19 for ; Tue, 20 Aug 2013 08:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=rkjgCz9591+tLAJY0BiWKYv4Y5rMedZ8iY/CIlugNjA=; b=UEsG3q+RPsH04l7Wo8SP3r9PCW8Ms311FHbOxwkGHuSc4idNcVlDg5lglgr2+uKYb5 o5alAW7zWuQoU0HXxkg3vfIWlGCWvqUMylFjHCyFdVUYPQVm0tF8Z1JN1xj6aEWk3bCA A1L6M6vOf7wn+Vxn29YxYh2kzQVa4Kt7EWfmNlVcNfaAFZD8JrmC1l2t/eMbaAj6jUPD 9GOi+BHK6PaLKlSm4WTLzAqyl7sV7Lmry71t5c/2/H0ladJMX1U6d/9bV3HcZpMlHFs1 qYYOg7cCgFAS1u8OjqAl/MlhGkQhvH++7FOBBHuS5De54BksrrAkmp+KF7cDOmwLhr3Q ZNXw== X-Gm-Message-State: ALoCoQnLKSfiijxn5CPSZ23rbxywfEXixA7OPhKR2wWJOtg0AskPmwUBZ0qiurFeFstxi5iOzhwh2mFCDrCsz1zNA1Ja/Cv2DrJhqaadV1RToZkkd+PxsvTcjP+cbaXcDqYIUCfbo7QG X-Received: by 10.236.48.101 with SMTP id u65mr1283421yhb.77.1377014021028; Tue, 20 Aug 2013 08:53:41 -0700 (PDT) X-Received: by 10.236.48.101 with SMTP id u65mr1283412yhb.77.1377014020936; Tue, 20 Aug 2013 08:53:40 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id v96sm2233884yhp.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 08:53:40 -0700 (PDT) Message-ID: <52139101.6090408@afilias.info> Date: Tue, 20 Aug 2013 11:53:37 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] Comments on draft-ietf-weirds-rdap-query-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Aug 2013 15:53:54 -0000 3.1.2. where XXX is an asplain autonomous system number [RFC5396]. There were several suggestions on the previous draft about improved wording for "asplain". The most consistent change would be to use the wording in 3.1, "an AS Plain autonomous system number". 3.2.1. Domain Search Domain search requires a qualifier, ldhName or unicodeName. So the client has to figure out what type of name is being searched. This is inconsistent with domain lookup, where the server is expected to distinguish between ldh and unicode names, and there is no work for the client. 3.2.3. Entity Search Entity lookup is by handle, but search is by name. This seems somewhat inconsistent, but practical, since search by name is generally more useful. For more completeness, perhaps there should also be a search by handle. It is supported by some existing whois servers. See for example, whois -h whois.pir.org contact 35975136-% -Ernie From edainow@afilias.info Tue Aug 20 09:10:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3343911E8247 for ; Tue, 20 Aug 2013 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKTS+MreGj9h for ; Tue, 20 Aug 2013 09:10:02 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7C23E11E8102 for ; Tue, 20 Aug 2013 09:10:02 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VBoVL-0005w9-5l for weirds@ietf.org; Tue, 20 Aug 2013 16:09:59 +0000 Received: from mail-ye0-f181.google.com ([209.85.213.181]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VBoVL-0002FO-5Q for weirds@ietf.org; Tue, 20 Aug 2013 16:09:59 +0000 Received: by mail-ye0-f181.google.com with SMTP id q5so124327yen.40 for ; Tue, 20 Aug 2013 09:09:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=qR4kMbw1qP0jCjVjV5GCuwbwJUWvki/VlV4TENevbiw=; b=iIpnkRVILuvZ/aNFa2YKa4/N7+kzTMUr+FNYZxKwNwH1iaXmt+7iSgGEIP3Y7t5ceW 5RoyEni8bwDjBSYtpSGn3LY1XttlAkf9CMAgmANSqEVJ1WDmR5jrImSpxpfjrJeRpFsb JDQnmkdCOtv2pKg+dlyMKV9T79g5mFkHOCDI2KvQA637jas76nwQ4HfpsrjKZmW5zLKw 8miV7AscW+aDENWSnmd1X4fl74IOCmBafCZnClf0ql7JPlwTcrRV1reM4sx2Dpd+zLtJ GJ7y8WFYbco3XjDoiSVhkUo/l+/KT1YtFxDEYZCy0aF6B6KxYpYuriQLlckoFh7oTboN CNQg== X-Gm-Message-State: ALoCoQklcZuMd/slSynjhLJ6mhEY2qVGXxDqxXd1gk8MjhqIWrPnqSfjyUiuMQ52j7wlayRf82HMTimu7Wy7bSvOzFB+JffAWq4KjAKeGqWW2BC0BcnlL5DE8JXoux6UXpNi9sWObkoq X-Received: by 10.236.22.233 with SMTP id t69mr1456853yht.67.1377014993956; Tue, 20 Aug 2013 09:09:53 -0700 (PDT) X-Received: by 10.236.22.233 with SMTP id t69mr1456844yht.67.1377014993814; Tue, 20 Aug 2013 09:09:53 -0700 (PDT) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id s9sm2306772yhb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 09:09:53 -0700 (PDT) Message-ID: <521394CE.7060400@afilias.info> Date: Tue, 20 Aug 2013 12:09:50 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:10:09 -0000 9. Responding To Searches The domains array returned from a search "domains" : [ { "handle" : "1-XXXX", "name" : "1.example.com", ... }, seems inconsistent with the request in draft-ietf-weirds-rdap-query-06 and with domain responses already defined. It should have "ldhName" or "unicodeName" (or both) instead of "name". This response would match the search query if the latter is changed to domains/?name= Domains is a new array, not used elsewhere. But "nameservers" and "entities" arrays returned from search are already defined, as quite large structures. Does this mean the server can return any subset of information from these structures in a search response? This will result in a rather lengthy response for an entities search by name, since the name ("fn") is embedded inside the vcardArray. Some examples here would help. I think simple new arrays specific for "nameservers" and "entities" search results might be preferable. -Ernie From michael@mwyoung.ca Tue Aug 20 10:57:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1411E8113 for ; Tue, 20 Aug 2013 10:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ZLyuMgtYNu for ; Tue, 20 Aug 2013 10:57:09 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54511E80DF for ; Tue, 20 Aug 2013 10:56:46 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 3so422455qea.35 for ; Tue, 20 Aug 2013 10:56:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=GEtRDAiCznJYb4jz9NrDZW8d2BiS6BOVh7m5hEYi7vc=; b=OOqetIbvvIVpuQ7WwymkpdHmLbD2wA3QE4Ot51Gsr7KMPDb8Ic4YGqXEgVqFieOx3y qKjj+NeIpe+xhc2FASapMOUmFPqjjASF9WBsdQGLXVHHDHTjHemUhyMA3JTm0oN2PPzB 1RM7LoTCn4hAuODVkTpfsIFEGtMqlWpt7plY9xOA/qbYlSecZFlQIjnKMKfbb9O1KmeR xhm2OfAySBn2q6Tue91V/G6lul283cAVtVdL1HLrFQfvjc0mgg/vHhs75UuUTiQyRkTv BlxtezbT3k08KbYwuJ5k2LvnEj3Y1WnpNXTtXgcZhy2SG5timA1ihxNmeHTNW7MA5n9O 7CJA== X-Gm-Message-State: ALoCoQmboTKnZTKZZidDeviz6JV4by/0WdbWcBBn70bMs6Lrw3v+Z522l6e4TvcFOPkUdW1q3cIa X-Received: by 10.49.74.102 with SMTP id s6mr3763259qev.24.1377021373588; Tue, 20 Aug 2013 10:56:13 -0700 (PDT) Received: from [172.16.1.44] (CPE74d02b4255c8-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.3.13]) by mx.google.com with ESMTPSA id s9sm3168225qev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 10:56:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECB5A78-27B2-4D6C-B25D-9625A3ABF9FA" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: <521394CE.7060400@afilias.info> Date: Tue, 20 Aug 2013 13:56:09 -0400 Message-Id: <765D23A9-B69F-46DE-B713-78DCFA75BBB9@mwyoung.ca> References: <521394CE.7060400@afilias.info> To: Ernie Dainow X-Mailer: Apple Mail (2.1508) Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:57:48 -0000 --Apple-Mail=_9ECB5A78-27B2-4D6C-B25D-9625A3ABF9FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ernie, Do you have any examples of what you propose for a new array specific to = nameservers and entities? -M On 2013-08-20, at 12:09 PM, Ernie Dainow wrote: > 9. Responding To Searches >=20 > The domains array returned from a search >=20 > "domains" : > [ > { > "handle" : "1-XXXX", > "name" : "1.example.com", > ... > }, >=20 > seems inconsistent with the request in draft-ietf-weirds-rdap-query-06 = and with domain responses already defined. It should have "ldhName" or = "unicodeName" (or both) instead of "name". >=20 > This response would match the search query if the latter is changed to = domains/?name=3D >=20 > Domains is a new array, not used elsewhere. But "nameservers" and = "entities" arrays returned from search are already defined, as quite = large structures. Does this mean the server can return any subset of = information from these structures in a search response? This will result = in a rather lengthy response for an entities search by name, since the = name ("fn") is embedded inside the vcardArray. Some examples here would = help. I think simple new arrays specific for "nameservers" and = "entities" search results might be preferable. >=20 > -Ernie >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_9ECB5A78-27B2-4D6C-B25D-9625A3ABF9FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii edainow@afilias.info> = wrote:
9.  Responding To Searches

The domains array = returned from a search

"domains" :
=     [
      {
=         "handle" : "1-XXXX",
=         "name" : "1.example.com",
=         ...
=       },

seems inconsistent with = the request in draft-ietf-weirds-rdap-query-06 and with domain responses = already defined. It should have "ldhName" or "unicodeName" (or both) = instead of "name".

This response would match the search query if = the latter is changed to domains/?name=3D<search = pattern>

Domains is a new array, not used elsewhere. But = "nameservers" and "entities" arrays returned from search are already = defined, as quite large structures. Does this mean the server can return = any subset of information from these structures in a search response? = This will result in a rather lengthy response for an entities search by = name, since the name ("fn") is embedded inside the vcardArray. Some = examples here would help. I think simple new arrays specific for = "nameservers" and "entities" search results might be = preferable.

-Ernie

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




MICHAEL = YOUNG




= --Apple-Mail=_9ECB5A78-27B2-4D6C-B25D-9625A3ABF9FA-- From andy@arin.net Tue Aug 20 11:00:39 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B521F995F for ; Tue, 20 Aug 2013 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWlgPFwlXkEq for ; Tue, 20 Aug 2013 11:00:29 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29C21F842A for ; Tue, 20 Aug 2013 11:00:26 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E2C4016505E; Tue, 20 Aug 2013 14:00:25 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 60E5E165011; Tue, 20 Aug 2013 14:00:25 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 20 Aug 2013 14:00:25 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 14:00:24 -0400 From: Andy Newton To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05 Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmeYsUA Date: Tue, 20 Aug 2013 18:00:24 +0000 Message-ID: In-Reply-To: <521394CE.7060400@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <94D6FEDA4AAE064E9FD09410F174FC2C@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:00:39 -0000 On 8/20/13 12:09 PM, "Ernie Dainow" wrote: >9. Responding To Searches > >The domains array returned from a search > >"domains" : > [ > { > "handle" : "1-XXXX", > "name" : "1.example.com", > ... > }, > >seems inconsistent with the request in draft-ietf-weirds-rdap-query-06 >and with domain responses already defined. It should have "ldhName" or >"unicodeName" (or both) instead of "name". This was a cut&paste error. Thanks. >Domains is a new array, not used elsewhere. But "nameservers" and >"entities" arrays returned from search are already defined, as quite >large structures. Does this mean the server can return any subset of >information from these structures in a search response? This will result >in a rather lengthy response for an entities search by name, since the >name ("fn") is embedded inside the vcardArray. Some examples here would >help. I think simple new arrays specific for "nameservers" and >"entities" search results might be preferable. Would 'entitySearchResults', 'nameserverSearchResults', and 'domainSearchResults' work better? -andy From johnl@iecc.com Tue Aug 20 11:13:48 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785F11E8117 for ; Tue, 20 Aug 2013 11:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq0ZdErz2GmD for ; Tue, 20 Aug 2013 11:13:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B057011E8119 for ; Tue, 20 Aug 2013 11:13:43 -0700 (PDT) Received: (qmail 27026 invoked from network); 20 Aug 2013 18:13:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Aug 2013 18:13:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5213b1d6.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=f4+pPyOAnK/iGGtM4fw561PzZwDCa2FpYvzbqk1Jx3k=; b=BWxDGQQHfF2B1+vvMUnbfmo0equChgWgXt93NkMLPnVCsDMo/BpAGypljfPENDNfqvQkvaqs7Xe1iCZFJFY7fqF0r3g8q4qOEwAITWbB+set83+xbkwpLhkczJrzJZqoAQpIRmPCxvT+4ChBbrOMepXQoz80B6eEMKWMVL80u9LVstrEBNKbMuCOs1E7+n2CHwCInn/1RmVzh58iKNuxbabB2KvcRtAr4S1UoG9t2bMZB/3t1odCro8xuf6IRhGi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5213b1d6.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=f4+pPyOAnK/iGGtM4fw561PzZwDCa2FpYvzbqk1Jx3k=; b=Bnj2GfYROrvpZkPLSgzlfKJTB8bq4SnRnvevDgP3Sv75YI3hOgaoBrTETnQ8IRZY9w+fv759hqItHcRPcMBuO8RzXZnXE6Gf1EZ6wB5pi+vlXasbXmf2rELXO7KNt7C5/CriQk7nKInyMqpkrCVN8jLT3NNu5k1h1HpgdZcyIdVXk91RvcoYih0Frh6o3u8SEiw4AHD4PVa4oj1n0yEDtvAaelDFDgvD7IN5YkvP21iNP1at0bVfdW6sE3KQklFB Date: 20 Aug 2013 18:13:20 -0000 Message-ID: <20130820181320.81570.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <52139101.6090408@afilias.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Aug 2013 18:13:49 -0000 >3.2.1. Domain Search >Domain search requires a qualifier, ldhName or unicodeName. So the >client has to figure out what type of name is being searched. This is >inconsistent with domain lookup, where the server is expected to >distinguish between ldh and unicode names, and there is no work for the >client. The two aren't the same. If you have a complete domain name, you can tell from inspection that it's either ldh or not. If you have a pattern like "ab*", you can't tell whether the * is intended to match ldh or unicode without some extra help. R's, John From edainow@afilias.info Tue Aug 20 12:01:32 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A1B11E827C for ; Tue, 20 Aug 2013 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JCCaOs-AjOn for ; Tue, 20 Aug 2013 12:01:25 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB011E8286 for ; Tue, 20 Aug 2013 12:00:11 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VBrA1-0000lk-3i for weirds@ietf.org; Tue, 20 Aug 2013 19:00:09 +0000 Received: from mail-lb0-f172.google.com ([209.85.217.172]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VBrA0-000117-6O for weirds@ietf.org; Tue, 20 Aug 2013 19:00:09 +0000 Received: by mail-lb0-f172.google.com with SMTP id o7so786205lbv.31 for ; Tue, 20 Aug 2013 12:00:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IucLWZcp/pxq7vNQEBeMnlA7qBC/ibtfOT7t/mT8Bq0=; b=MowrEqj5pgsg14tGi7nbHCbxDoQGHKlrGBwftBjW7RTB0H83rQ858BzyPe4JuneN/R qdFWtcOI6SvgjvoZ9r85tfPJrt7bSQvklN1pJnQUJ7JU0YCZGSakF6X6xLPaxJOz2th3 IULq9nzdFCLJFAUkfrc3toUnALHmrnv/hEbwWk4aEv0Tuck9BJa5zkG1VnPkx0Nex3Zw skU7eT40Z/60sCDsbZAhYL2KL/9egDqJtxsDnmTvWL8huDLjQUjCwjXdFw8gsT1sVukS RPbw16JFoU7M4lbOaK9ZrjKKxy764lqueXTuHsp+XMCllwbyPa+b5Sl7PqZNpLE7yawO +X/g== X-Gm-Message-State: ALoCoQn3wvfp2QTp7PZSXuGkuZFtyb2uMgEJv/Es3xGWkc4d8TMS8aL//r9+uo1lKuNhDKilYKy0fw1Yx0Nn70eobuZAGIn6IXAuktIQ1Kza7wvDJkIMWuYcylqGWrRc1H+JZp+H9gJM X-Received: by 10.112.128.166 with SMTP id np6mr3778714lbb.7.1377025202541; Tue, 20 Aug 2013 12:00:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.128.166 with SMTP id np6mr3778704lbb.7.1377025202431; Tue, 20 Aug 2013 12:00:02 -0700 (PDT) Received: by 10.112.21.170 with HTTP; Tue, 20 Aug 2013 12:00:02 -0700 (PDT) In-Reply-To: <20130820181320.81570.qmail@joyce.lan> References: <52139101.6090408@afilias.info> <20130820181320.81570.qmail@joyce.lan> Date: Tue, 20 Aug 2013 15:00:02 -0400 Message-ID: From: Ernie Dainow To: John Levine Content-Type: multipart/alternative; boundary=047d7b343ef209b72104e465aae1 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Aug 2013 19:01:32 -0000 --047d7b343ef209b72104e465aae1 Content-Type: text/plain; charset=ISO-8859-1 The client software doesn't know whether to do a ldh or unicode search so it has to be specified by the user. But the user likely wants to know all domains that begin with "ab", whether they are IDNs or not. This pattern splits search into two classes -- Latin script domains and all other scripts. -Ernie On Tue, Aug 20, 2013 at 2:13 PM, John Levine wrote: > >3.2.1. Domain Search > >Domain search requires a qualifier, ldhName or unicodeName. So the > >client has to figure out what type of name is being searched. This is > >inconsistent with domain lookup, where the server is expected to > >distinguish between ldh and unicode names, and there is no work for the > >client. > > The two aren't the same. > > If you have a complete domain name, you can tell from inspection that > it's either ldh or not. If you have a pattern like "ab*", you can't > tell whether the * is intended to match ldh or unicode without some > extra help. > > R's, > John > --047d7b343ef209b72104e465aae1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The client software doesn't know whether to do a ldh o= r unicode search so it has to be specified by the user. But the user likely= wants to know all domains that begin with "ab", whether they are= IDNs or not. This pattern splits search into two classes -- Latin script d= omains and all other scripts.

-Ernie




On Tue, Aug 20, 2013 at= 2:13 PM, John Levine <johnl@taugh.com> wrote:
>3.2.1. Domain Search >Domain search requires a qualifier, ldhName or unicodeName. So the
>client has to figure out what type of name is being searched. This is >inconsistent with domain lookup, where the server is expected to
>distinguish between ldh and unicode names, and there is no work for the=
>client.

The two aren't the same.

If you have a complete domain name, you can tell from inspection that
it's either ldh or not. =A0If you have a pattern like "ab*", = you can't
tell whether the * is intended to match ldh or unicode without some
extra help.

R's,
John

--047d7b343ef209b72104e465aae1-- From olaf@NLnetLabs.nl Tue Aug 20 12:32:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7423E11E8145 for ; Tue, 20 Aug 2013 12:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.826 X-Spam-Level: X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sUGc8Q45f0y for ; Tue, 20 Aug 2013 12:32:57 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3DD21F92E7 for ; Tue, 20 Aug 2013 12:32:40 -0700 (PDT) Received: from [192.168.178.125] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7KJWUcL099694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 21:32:32 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7KJWUcL099694 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1377027155; bh=VMaABb+9QbMHyhi/AYxYs39E/SDREpsA/D7wrQYbqyo=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=P4Alt9xlvsuYoTGKX6hgWh/hJOSFueLoOLtO43ps6oEYCfuKL78eYyPmm3GC50n0z QyTsag8UrgioB7Hu4pPjql1Rpo5qGEAtQ1Rr+ydjh+gidi94UduGhITECM4i0u0k+g I6rixccjlDp7zxKnXRzPvYlYIzUksrVJ+iOj+9UI= X-Authentication-Warning: open.nlnetlabs.nl: Host peer.kolkman.org [82.95.132.144] claimed to be [192.168.178.125] References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Olaf Kolkman Date: Tue, 20 Aug 2013 21:32:33 +0200 To: Barry Leiba X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Tue, 20 Aug 2013 21:32:33 +0200 (CEST) Cc: "draft-ietf-weirds-using-http.all@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Aug 2013 19:32:59 -0000 ( reducing the cc a bit) Barry, My conclusion out of the thread on the 404 is, no change to the doc, except f= or adding the reference, correct? Andy, et authors, do you need more from me as shepherd to proceed? Olaf Sent from my iPad On Aug 13, 2013, at 3:56 PM, Barry Leiba wrote: >> In case 3, if 203.0.113.0/24 is not an exact boundary for a network >> registration, the proper thing to do according to the query draft is to >> return the network registration that encompasses 203.0.113.0/24. Therefor= e >> I think case 3 cannot happen. There are similar semantics for autnum >> ranges. For domains, name servers, and entities, either they exist or the= y >> don't. >>=20 >> Does the help? >=20 > It does. If it's not possible to have a valid query that's been sent > to the right place, but to have no data to return... then we're OK. >=20 > Perhaps part of the problem here is that using-http seems to depend on > rdap-query, but there's no normative reference to rdap-query here > (only from rdap-query to using-http). Does using-http really make > *any* sense at all without rdap-query? >=20 > Barry >=20 From barryleiba@gmail.com Tue Aug 20 12:39:35 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C91B11E827B for ; Tue, 20 Aug 2013 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLrkROsmjz1B for ; Tue, 20 Aug 2013 12:39:34 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A34A011E8226 for ; Tue, 20 Aug 2013 12:39:34 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m15so465169qcq.0 for ; Tue, 20 Aug 2013 12:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tu2OyBkQKvd6+hu7yXARfOiQ5IGJd+XLvMqDffywXXY=; b=K+JidTJIt0b81zH+jhQUYn0Fa3FnO1L4+Z9vHRyh7nJzKR+apwy6CpwRE8FF9prahQ JkIBEzS0V83elyie/ENdBWRnBpIL/+SjndMmiEwAgXy/dhSp4nLGzIIUWSkrx5D+UU2h S5HEyjgmWVgFQ42mSld1tolH/baE2UEf8LU5G7HAvYxB1mVsN1Ev6dJSA14HK7+ZkMJx Px3wYnFjVs8NvcT8/U0Jk4wRPd8tCGh0+23U2tlrkKJbDWS8WefqAmDMzJIY1tR596o/ t8jC1stl27+fFwuFKPA2wl58yyRe4W+DxukqUDNGiyMJYxZmK1zD7OakCOpCxg2iuF5f drBQ== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr4244197qeb.1.1377027573746; Tue, 20 Aug 2013 12:39:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 20 Aug 2013 12:39:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Aug 2013 15:39:33 -0400 X-Google-Sender-Auth: y4gc9IfWZk50uqLZA_HBtkNQOSs Message-ID: From: Barry Leiba To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-weirds-using-http.all@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Aug 2013 19:39:35 -0000 > My conclusion out of the thread on the 404 is, no change to the doc, except for > adding the reference, correct? We're fine on the 404, yes. I still have two DISCUSS points: https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ballot/ I don't know whether you need to do anything about that right now as shepherd, but the bottom line is that I'm not sure it makes to proceed with this document now, without also having the rdap-query document along with it (and perhaps json-response, sending them all to the IESG as a trio). Barry From shollenbeck@verisign.com Tue Aug 20 18:09:41 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368BE11E830B for ; Tue, 20 Aug 2013 18:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5V8fG6lf7tL for ; Tue, 20 Aug 2013 18:09:35 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF511E80A2 for ; Tue, 20 Aug 2013 18:09:11 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUhQTNtzynLC0TP4n2jzYA2YybldfBmvV@postini.com; Tue, 20 Aug 2013 18:09:32 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r7L196aH008908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 21:09:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 20 Aug 2013 21:09:06 -0400 From: "Hollenbeck, Scott" To: Ernie Dainow Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query-06 Thread-Index: AQHOnb18Dd4hjmUJ/ESsix6yDNVWqpmeqXkAgAANDACAACO5AA== Date: Wed, 21 Aug 2013 01:09:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4923B10C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52139101.6090408@afilias.info> <20130820181320.81570.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4923B10CBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 01:09:41 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4923B10CBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Ernie Dainow Sent: Tuesday, August 20, 2013 3:00 PM To: John Levine Cc: weirds@ietf.org Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06 The client software doesn't know whether to do a ldh or unicode search so i= t has to be specified by the user. But the user likely wants to know all do= mains that begin with "ab", whether they are IDNs or not. This pattern spli= ts search into two classes -- Latin script domains and all other scripts. So what would you suggest? Scott --_000_831693C2CDA2E849A7D7A712B24E257F4923B10CBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Ernie Dainow
Sent: Tuesday, August 20, 2013 3:00 PM
To: John Levine
Cc: weirds@ietf.org
Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06

 

The client software doesn't know whether to do a ldh= or unicode search so it has to be specified by the user. But the user like= ly wants to know all domains that begin with "ab", whether they a= re IDNs or not. This pattern splits search into two classes -- Latin script domains and all other scripts.

 

So what would you suggest?

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F4923B10CBRN1WNEXMBX01vc_-- From olaf@NLnetLabs.nl Wed Aug 21 02:44:49 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3B11E81F2 for ; Wed, 21 Aug 2013 02:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KU8ihHkS9it for ; Wed, 21 Aug 2013 02:44:43 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C011E81EC for ; Wed, 21 Aug 2013 02:44:43 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7L9iYsu069911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Aug 2013 11:44:35 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7L9iYsu069911 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1377078277; bh=tx5UN5q20hA/ny+2CmSrVLDCt9e3O64O88jn2FXx/Nw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kIFkEasWc2zdO7KbX+cmz3V/ZuEIp+a+I8tD+ElkLC86gktzlXi9PQwsRSVxwvrKB +iSne+qZ4AdKaEbsxwz0AhPz+48SRk+WQAA5/HJIIDvhLCphkGpBWyk7gIdldfTaim 5JUN2jRET0os7g8jfVlPwONHvV/w9dgimEixE/es= Content-Type: multipart/signed; boundary="Apple-Mail=_E01D1BFC-4681-4FDA-80B6-8D40FF03BABF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Wed, 21 Aug 2013 11:44:33 +0200 Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 21 Aug 2013 11:44:36 +0200 (CEST) Cc: "draft-ietf-weirds-using-http.all@tools.ietf.org" , "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 09:44:49 -0000 --Apple-Mail=_E01D1BFC-4681-4FDA-80B6-8D40FF03BABF Content-Type: multipart/alternative; boundary="Apple-Mail=_BB231CB5-E0CC-4200-9FB9-864A0158DE25" --Apple-Mail=_BB231CB5-E0CC-4200-9FB9-864A0158DE25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 20 aug. 2013, at 21:39, Barry Leiba wrote: > We're fine on the 404, yes. I still have two DISCUSS points: > https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ballot/ >=20 > I don't know whether you need to do anything about that right now as > shepherd, but the bottom line is that I'm not sure it makes to proceed > with this document now, without also having the rdap-query document > along with it (and perhaps json-response, sending them all to the IESG > as a trio). I believe that the lack of context, or connection, to the other = documents were what triggered some of the comments of other reviewers as = well, if the normative reference mesh, with some words to describe the = interdependency would help the progress then that is probably the Good = Thing to do. (adding the informative reference in Appendix A is then a = triviality). However, it does mean that the 3 documents will sit blocking for each = other and will not pop out as RFC shortly.=20 I think it is a reasonable forward but maybe the WG has a different idea = on how to get this unblocked? --Olaf --Apple-Mail=_BB231CB5-E0CC-4200-9FB9-864A0158DE25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 barryleiba@computer.org> = wrote:


I don't know whether you need = to do anything about that right now as
shepherd, but the bottom line = is that I'm not sure it makes to proceed
with this document now, = without also having the rdap-query document
as a trio).
To: "'Ernie Dainow'" , References: <521394CE.7060400@afilias.info> In-Reply-To: <521394CE.7060400@afilias.info> Date: Wed, 21 Aug 2013 17:48:47 +0800 Message-ID: <00c701ce9e53$a1efbb00$e5cf3100$@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: Ac6dv8DXz9gqxWW+S+6E3UFoeny+/wAkzRdg Content-Language: zh-cn Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 09:48:56 -0000 section 4 search processing I don't quite understand " Servers SHOULD NOT partially match combinations of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. " What's the problem if a server handles this search? Can someone give me an example? > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Ernie Dainow > Sent: Wednesday, August 21, 2013 12:10 AM > To: weirds@ietf.org > Subject: [weirds] Comments on draft-ietf-weirds-json-response-05 > > 9. Responding To Searches > > The domains array returned from a search > > "domains" : > [ > { > "handle" : "1-XXXX", > "name" : "1.example.com", > ... > }, > > seems inconsistent with the request in draft-ietf-weirds-rdap-query-06 and > with domain responses already defined. It should have "ldhName" or > "unicodeName" (or both) instead of "name". > > This response would match the search query if the latter is changed to > domains/?name= > > Domains is a new array, not used elsewhere. But "nameservers" and "entities" > arrays returned from search are already defined, as quite large structures. > Does this mean the server can return any subset of information from these > structures in a search response? This will result in a rather lengthy response > for an entities search by name, since the name ("fn") is embedded inside the > vcardArray. Some examples here would help. I think simple new arrays specific > for "nameservers" and "entities" search results might be preferable. > > -Ernie > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From edainow@afilias.info Wed Aug 21 07:31:52 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8F611E83CE for ; Wed, 21 Aug 2013 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQXz9ZNVuWS5 for ; Wed, 21 Aug 2013 07:31:47 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 069A311E8210 for ; Wed, 21 Aug 2013 07:31:45 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VC9Rn-0007Kp-6P for weirds@ietf.org; Wed, 21 Aug 2013 14:31:43 +0000 Received: from mail-la0-f44.google.com ([209.85.215.44]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VC9Rn-0002MP-5o for weirds@ietf.org; Wed, 21 Aug 2013 14:31:43 +0000 Received: by mail-la0-f44.google.com with SMTP id eo20so411161lab.31 for ; Wed, 21 Aug 2013 07:31:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1nVJhh+IS1+97MqlQdZVoR4rPLU+FEXu6Pn/EZk5UKI=; b=SJqnwCMo+nh9g7Xm7DsW3Tb9rn8zunKas8TzE3jLUknyuG+aD/2VD4mdBFv+KbM4OV ZXmlZGu3Yi+t2lTrVcs7OKZLWXWYjLVbomuC1Qyj97O8kZrpojqf41uBP2TMDqKJMEI9 h/9UjGVdG1lCcJZsGauRFjcEOx6t2mmFk0i57UJpOtVh2Y7su/9B2ncDJyBQxGJHUHPZ 2W3IwXOr/gjt53Uu8J0ktpK+zKQIlSOT/GczWPbA4tuqTRugvpAEl8aHZdlYjL0ftfcd bL0NUyjvutN0BXkbekLfOpxXV32c6lXy5ZWYAEcS6CvpyYWxwbQaewZNB8zYtNf3E27a RBqQ== X-Gm-Message-State: ALoCoQkanvYa9sucs8YsCRoaE+97cd4Uv56Sj5lh8nMWfRBjgQdYPhH/cNGKoa2QeUr5EKOSMvR37kZDoowAnqNG1idvNw0TtXCHIX9ClxyeT1C4F6g1o/kSP+hMamDc+TvIfSA236Jd X-Received: by 10.112.26.106 with SMTP id k10mr7363692lbg.27.1377095497484; Wed, 21 Aug 2013 07:31:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.26.106 with SMTP id k10mr7363687lbg.27.1377095497370; Wed, 21 Aug 2013 07:31:37 -0700 (PDT) Received: by 10.112.21.170 with HTTP; Wed, 21 Aug 2013 07:31:37 -0700 (PDT) In-Reply-To: References: <521394CE.7060400@afilias.info> Date: Wed, 21 Aug 2013 10:31:37 -0400 Message-ID: From: Ernie Dainow To: Andy Newton Content-Type: multipart/alternative; boundary=001a1133a9cef15a7804e476074a Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:31:52 -0000 --001a1133a9cef15a7804e476074a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 2:00 PM, Andy Newton wrote: > On 8/20/13 12:09 PM, "Ernie Dainow" wrote: > > >Domains is a new array, not used elsewhere. But "nameservers" and > >"entities" arrays returned from search are already defined, as quite > >large structures. Does this mean the server can return any subset of > >information from these structures in a search response? This will result > >in a rather lengthy response for an entities search by name, since the > >name ("fn") is embedded inside the vcardArray. Some examples here would > >help. I think simple new arrays specific for "nameservers" and > >"entities" search results might be preferable. > > Would 'entitySearchResults', 'nameserverSearchResults', and > 'domainSearchResults' work better? > > Using existing objects is generally a good idea, but the search results are sufficiently different that using new names such as this would make the distinction clear. -Ernie --001a1133a9cef15a7804e476074a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 20, 2013 at 2:00 PM, Andy Newton <= andy@arin.net> wrote:
On 8/20/13 12:09 PM, "= ;Ernie Dainow" <edainow@afi= lias.info> wrote:

>Domains is a new array, not used elsewhere. But "nameservers"= and
>"entities" arrays returned from search are already defined, a= s quite
>large structures. Does this mean the server can return any subset of >information from these structures in a search response? This will resul= t
>in a rather lengthy response for an entities search by name, since the<= br> >name ("fn") is embedded inside the vcardArray. Some examples = here would
>help. I think simple new arrays specific for "nameservers" an= d
>"entities" search results might be preferable.

Would 'entitySearchResults', 'nameserverSearchResults'= ;, and
'domainSearchResults' work better?


Using = existing objects is generally a good idea, but the search results are suffi= ciently different that using new names such as this would make the distinct= ion clear.

-Ernie

=
--001a1133a9cef15a7804e476074a-- From edainow@afilias.info Wed Aug 21 07:44:10 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CFF11E8115 for ; Wed, 21 Aug 2013 07:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuJ5U7zousI8 for ; Wed, 21 Aug 2013 07:44:04 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 78F1411E80D9 for ; Wed, 21 Aug 2013 07:44:04 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VC9de-0008Uz-3W for weirds@ietf.org; Wed, 21 Aug 2013 14:43:58 +0000 Received: from mail-lb0-f175.google.com ([209.85.217.175]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VC9dd-00037R-6C for weirds@ietf.org; Wed, 21 Aug 2013 14:43:58 +0000 Received: by mail-lb0-f175.google.com with SMTP id 13so664476lba.6 for ; Wed, 21 Aug 2013 07:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YXX1Qk9uVynHPfYExW1tVhXrXqaB/RLW6hTx3Hkv1JE=; b=B7EBOupFwKup+Cr7XlduiGQEtJIK/uyBjIfasUPjKZy39VrrElExfT5bAN5KlJXruv NA6TVO2vBESDVmmQ9PTprxf7ihxsuB6zbwdq27tnC7m1yMOQzl7Tu2Bb3k8hnau7LzPe 55zz4spAxBRqZ9PsOPJjmbu4uB237esN32mrOoTPRoSoC/JJf8/B0FUP99ePOl+4MH/0 5cOCD4wRvXHoTf+OSOgHvYUv4KrEUBw6ffSB5IFg5+nQvks1woCZu0qnYHbsNq7inpQU gRraI4oW/uBFtykPTOhVt8Qop0oFlGn9YMDbtmFlxVWV83TIWO4MonGkdV+S8mXuCa7P vTgg== X-Gm-Message-State: ALoCoQmtkwnWBpTA8PsiGDJ5m8iRUxqGiOIyMNPudOTqj4b2RA7DjNVzKaXx+0a+unQ5xFANL3+MsiDsmg+JmncbP9awJMKxAuPgbgFh1C4+8DGb2anmUhAbbPaDZQq7TAcyAkOto8LU X-Received: by 10.152.36.170 with SMTP id r10mr362194laj.48.1377096231454; Wed, 21 Aug 2013 07:43:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.36.170 with SMTP id r10mr362185laj.48.1377096231342; Wed, 21 Aug 2013 07:43:51 -0700 (PDT) Received: by 10.112.21.170 with HTTP; Wed, 21 Aug 2013 07:43:51 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4923B10C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52139101.6090408@afilias.info> <20130820181320.81570.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4923B10C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 21 Aug 2013 10:43:51 -0400 Message-ID: From: Ernie Dainow To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=089e0160bb04b0eca304e4763372 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 14:44:10 -0000 --089e0160bb04b0eca304e4763372 Content-Type: text/plain; charset=ISO-8859-1 I thought the specification in draft-hollenbeck-weirds-rdap-search-02 would work, domains/?name= Any unicode/ldh considerations are handled by the server, as in the query domain/ -Ernie On Tue, Aug 20, 2013 at 9:09 PM, Hollenbeck, Scott wrote: > *From:* weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] *On > Behalf Of *Ernie Dainow > *Sent:* Tuesday, August 20, 2013 3:00 PM > *To:* John Levine > *Cc:* weirds@ietf.org > *Subject:* Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06**** > > ** ** > > The client software doesn't know whether to do a ldh or unicode search so > it has to be specified by the user. But the user likely wants to know all > domains that begin with "ab", whether they are IDNs or not. This pattern > splits search into two classes -- Latin script domains and all other > scripts.**** > > ** ** > > So what would you suggest?**** > > ** ** > > Scott**** > --089e0160bb04b0eca304e4763372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought the specification in=A0draft-hollenbeck-weirds-r= dap-search-02 would work,=A0domains/?name=3D<domain search pattern> =A0
Any unicode/ldh considerations are handled by the server, as in the query= =A0domain/<domain name>= ;

-Ernie


On Tue, Aug= 20, 2013 at 9:09 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Ernie Dainow
Sent: Tuesday, August 20, 2013 3:00 PM
To: John Levine
Cc: weirds@ietf= .org
Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-06=

=A0

The client software doesn't know whether to do a ldh or u= nicode search so it has to be specified by the user. But the user likely wa= nts to know all domains that begin with "ab", whether they are ID= Ns or not. This pattern splits search into two classes -- Latin script domains and all other scripts.

=A0=

So what would you suggest?<= u>

=A0

Scott


--089e0160bb04b0eca304e4763372-- From johnl@iecc.com Wed Aug 21 07:55:04 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB22411E8228 for ; Wed, 21 Aug 2013 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s+aYRpOqDLj for ; Wed, 21 Aug 2013 07:54:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7623611E8223 for ; Wed, 21 Aug 2013 07:54:47 -0700 (PDT) Received: (qmail 46587 invoked from network); 21 Aug 2013 14:54:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Aug 2013 14:54:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5214d4b5.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=nSEkr4C0yX9YV8JvQu/NhqZ1fZRvD6HY4mhKOUN8nvg=; b=G9O6IZtmiG9wHdUpBqGUBBf9kQpjt1Xc/6A6UJeCTlxUNCXy7zj93AciLGEdOg9nhSjX8sVN3ZVHY0fW33NG1WxQHXWpnHpjwEMOZt1L/rejWFE1k/lOXW3UOC4jRNfXWsGAjL0Nx8En/I+NuXsQw3/uNSKrGQZWFSzityQp7E84OQRHE4JD+0vDqHZnQaXbuNP2WsaOn+UqnbnW8TRExUqG58pOK3kZ4UVNoRxoT5nNZ0cFklOdTVii5YDHAEwP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5214d4b5.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=nSEkr4C0yX9YV8JvQu/NhqZ1fZRvD6HY4mhKOUN8nvg=; b=hHfMjebHgnr/U1eX9iqC5kjA8NfAKYqslOssLOCzucix6uWLWSOW0z1fpjAtZ9RsQ7PcV8cTXu1YDDOffvqV/N5yUnINXPWWFuypjCeT4wuKu4FORpsjZ20ZeCMbtNcQNmMxCtlOmQ4KQDwpHAlrSLxZtCAylCET7BmW8VculnNlwo+DqYoXiXDzwyIv6yrxRv7nRSAso1Y42Z/oDyksg2Ba6A4GWtKPtalptUtiLzSPhCJS8W1hUGhlifbAKtSL Date: 21 Aug 2013 14:54:23 -0000 Message-ID: <20130821145423.89524.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 14:55:04 -0000 >However, it does mean that the 3 documents will sit blocking for each other and will >not pop out as RFC shortly. > >I think it is a reasonable forward but maybe the WG has a different idea on how to get >this unblocked? I agree it's reasonable for them to be done at the same time. Given what's happened until now, it's not unlikely that we will find future issues in one of docs that require tweaks in the others. An example would be matching tweaks to the wildcard query and response formats. R's, John PS: With any luck, this might even encourage us to finish them all. From marc.blanchet@viagenie.ca Wed Aug 21 08:21:37 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB8811E822E for ; Wed, 21 Aug 2013 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4JExkpSulpA for ; Wed, 21 Aug 2013 08:21:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE911E8112 for ; Wed, 21 Aug 2013 08:21:33 -0700 (PDT) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CD06F46A16; Wed, 21 Aug 2013 11:21:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B99959D-8279-4EB1-A4B2-68C9460ADB2E" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: Date: Wed, 21 Aug 2013 11:21:30 -0400 Message-Id: References: To: Olaf Kolkman X-Mailer: Apple Mail (2.1508) Cc: "draft-ietf-weirds-using-http.all@tools.ietf.org" , Barry Leiba , "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 15:21:37 -0000 --Apple-Mail=_1B99959D-8279-4EB1-A4B2-68C9460ADB2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-08-21 =E0 05:44, Olaf Kolkman a =E9crit : >=20 > On 20 aug. 2013, at 21:39, Barry Leiba = wrote: >=20 >> We're fine on the 404, yes. I still have two DISCUSS points: >> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ballot/ >>=20 >> I don't know whether you need to do anything about that right now as >> shepherd, but the bottom line is that I'm not sure it makes to = proceed >> with this document now, without also having the rdap-query document >> along with it (and perhaps json-response, sending them all to the = IESG >> as a trio). >=20 >=20 > I believe that the lack of context, or connection, to the other = documents were what triggered some of the comments of other reviewers as = well, if the normative reference mesh, with some words to describe the = interdependency would help the progress then that is probably the Good = Thing to do. (adding the informative reference in Appendix A is then a = triviality). >=20 > However, it does mean that the 3 documents will sit blocking for each = other and will not pop out as RFC shortly.=20 I completly agree that having the set of documents = sent/processed/discussed/reviewed/updated all together is the only good = engineering decision. Each of them do not do a lot by themselves. An = implementation cannot really do only one of them. In fact, I always = thought it would have been better to have a single document. Therefore, I agree with IESG/Barry proposal to consider them as a = combined set of documents. Marc. >=20 > I think it is a reasonable forward but maybe the WG has a different = idea on how to get this unblocked? >=20 >=20 > --Olaf >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_1B99959D-8279-4EB1-A4B2-68C9460ADB2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 olaf@NLnetLabs.nl> a =E9crit = :
barryleiba@computer.org> = wrote:


I don't know whether you need = to do anything about that right now as
shepherd, but the bottom line = is that I'm not sure it makes to proceed
with this document now, = without also having the rdap-query document
as a trio).

= --Apple-Mail=_1B99959D-8279-4EB1-A4B2-68C9460ADB2E-- From andy@arin.net Wed Aug 21 08:33:29 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E3F11E8239 for ; Wed, 21 Aug 2013 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gib+XXcggbNK for ; Wed, 21 Aug 2013 08:33:24 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 45B2311E823F for ; Wed, 21 Aug 2013 08:33:22 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id BF00A213A26; Wed, 21 Aug 2013 11:33:21 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 49433213A23; Wed, 21 Aug 2013 11:33:21 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.101) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 21 Aug 2013 11:33:15 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH04.corp.arin.net ([10.1.30.101]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 11:33:14 -0400 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05 Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmeYsUAgAGbEoD//84ogA== Date: Wed, 21 Aug 2013 15:33:14 +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.3.6.130613 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_CE3A55DC27B81andyarinnet_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:33:29 -0000 --_000_CE3A55DC27B81andyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow > Date: Wednesday, August 21, 2013 10:31 AM To: Andrew Newton > Cc: "weirds@ietf.org" > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 Using existing objects is generally a good idea, but the search results are= sufficiently different that using new names such as this would make the di= stinction clear. I agree. Some software frameworks might work better with different names. T= hanks for pointing this out. -andy --_000_CE3A55DC27B81andyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: Ernie Dainow <edainow@afilias.info>
Date: Wednesday, August 21, 2013 10= :31 AM
To: Andrew Newton <andy@arin.net>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] Comments on d= raft-ietf-weirds-json-response-05

Using existing objects is generally a good idea, but the search results are suff= iciently different that using new names such as this would make the distinc= tion clear.

I agree. Some software frameworks might work better with different nam= es. Thanks for pointing this out.

-andy
--_000_CE3A55DC27B81andyarinnet_-- From andy@arin.net Wed Aug 21 08:39:15 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D399321F9BD5 for ; Wed, 21 Aug 2013 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-0e-cndx4zY for ; Wed, 21 Aug 2013 08:39:10 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89B11E8107 for ; Wed, 21 Aug 2013 08:39:09 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id C40F9213A40; Wed, 21 Aug 2013 11:39:08 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 4F075213A3D; Wed, 21 Aug 2013 11:39:08 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.101) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 21 Aug 2013 11:39:08 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH04.corp.arin.net ([10.1.30.101]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 11:39:07 -0400 From: Andy Newton To: Linlin Zhou , 'Ernie Dainow' , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05 Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmfrtGAgAAe1oA= Date: Wed, 21 Aug 2013 15:39:07 +0000 Message-ID: In-Reply-To: <00c701ce9e53$a1efbb00$e5cf3100$@cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 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-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:39:15 -0000 On 8/21/13 5:48 AM, "Linlin Zhou" wrote: >section 4 search processing > >I don't quite understand " Servers SHOULD NOT partially match combinations >of Unicode characters where a Unicode character may be legally combined >with >another Unicode character or characters. " What's the problem if a server >handles this search? Can someone give me an example? Linlin, Let me start by saying that I'm not an I18N expert. I have talked to several IETFers with more experience in internationalization issues, and the advice given was to avoid interoperability issues where combining characters can be confused with character of single code points but with the same semantic meaning. Honestly, I don't know what harm would come from just letting the server respond with its own rules. Nor do I know if the rules change depending on registry policy. This may be the case that the server responds with what the server has in a similar way we have done with lookups. -andy From aservin@lacnic.net Wed Aug 21 09:20:57 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF9D11E8104 for ; Wed, 21 Aug 2013 09:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A-mIZOf0DIO for ; Wed, 21 Aug 2013 09:20:56 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA311E8112 for ; Wed, 21 Aug 2013 09:20:52 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:d06a:9ea1:cd0a:5769]) by mail.lacnic.net.uy (Postfix) with ESMTP id D03B7308427 for ; Wed, 21 Aug 2013 13:20:28 -0300 (UYT) Message-ID: <5214E8E8.4050903@lacnic.net> Date: Wed, 21 Aug 2013 13:20:56 -0300 From: Arturo Servin Organization: LACNIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 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] [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 21 Aug 2013 16:20:57 -0000 The independence between documents was not a bug but a feature to avoid them to block each other. However, as noted, it has not working very well and I support to have a single set of documents. Regards. as On 8/21/13 6:44 AM, Olaf Kolkman wrote: > > On 20 aug. 2013, at 21:39, Barry Leiba > wrote: > >> We're fine on the 404, yes. I still have two DISCUSS points: >> https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/ballot/ >> >> >> I don't know whether you need to do anything about that right now as >> shepherd, but the bottom line is that I'm not sure it makes to >> proceed with this document now, without also having the >> rdap-query document along with it (and perhaps json-response, >> sending them all to the IESG as a trio). > > > I believe that the lack of context, or connection, to the other > documents were what triggered some of the comments of other > reviewers as well, if the normative reference mesh, with some words > to describe the interdependency would help the progress then that > is probably the Good Thing to do. (adding the informative > reference in Appendix A is then a triviality). > > However, it does mean that the 3 documents will sit blocking for > each other and will not pop out as RFC shortly. > > I think it is a reasonable forward but maybe the WG has a different > idea on how to get this unblocked? > > > --Olaf > > > > > _______________________________________________ weirds mailing > list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds > From zhoulinlin@cnnic.cn Thu Aug 22 00:42:42 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0180121F92C2 for ; Thu, 22 Aug 2013 00:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=1.604, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z0MnWSjnxQS for ; Thu, 22 Aug 2013 00:42:37 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 72BEC21F91CE for ; Thu, 22 Aug 2013 00:42:35 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Aug 2013 15:42:31 +0800 From: "Linlin Zhou" To: "'Andy Newton'" , "'Ernie Dainow'" , References: <00c701ce9e53$a1efbb00$e5cf3100$@cn> In-Reply-To: Date: Thu, 22 Aug 2013 15:42:31 +0800 Message-ID: <00aa01ce9f0b$28eeac30$7acc0490$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmfrtGAgAAe1oCAAJ2jEA== Content-Language: zh-cn Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 07:42:42 -0000 > -----Original Message----- > From: Andy Newton [mailto:andy@arin.net] > Sent: Wednesday, August 21, 2013 11:39 PM > To: Linlin Zhou; 'Ernie Dainow'; weirds@ietf.org > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 >=20 > On 8/21/13 5:48 AM, "Linlin Zhou" wrote: >=20 > >section 4 search processing > > > >I don't quite understand " Servers SHOULD NOT partially match > >combinations of Unicode characters where a Unicode character may be > >legally combined with another Unicode character or characters. " = What's > >the problem if a server handles this search? Can someone give me an > >example? >=20 > Linlin, >=20 > Let me start by saying that I'm not an I18N expert. I have talked to several > IETFers with more experience in internationalization issues, and the advice > given was to avoid interoperability issues where combining characters = can be > confused with character of single code points but with the same = semantic > meaning. I asked someone about the combining Unicode characters, he gave me an example such as "=E7" (Latin small letter c with cedilla). It can be = encoded as U+00E7 or U+0063 U+0327 (a regular "c" followed by a combining = cedilla). I don't know whether this is the right scenario discussed in this = section. If I have a domain contains this letter, for example fa=E7ade.com. A = user may partially search fa=E7*.com, the database find the record that Unicode = name starts with fa=E7, as you said in a similar way like lookups. While the = text in this section makes me feel that a user may possibly search U+0066 = U+0061 U+0063*.com or U+0066 U+0061 U+0063 U+0327*.com. Since Chinese Unicode characters don't have this situation, I want to know more about this = issue and how to handle it by the server. Anyway, thanks Andy. > Honestly, I don't know what harm would come from just letting the = server > respond with its own rules. Nor do I know if the rules change = depending on > registry policy. This may be the case that the server responds with = what the > server has in a similar way we have done with lookups. >=20 Regards, Linlin From pieter.vandepitte@dns.be Thu Aug 22 05:44:59 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010211E80DC for ; Thu, 22 Aug 2013 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.072 X-Spam-Level: X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=1.975, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT5hFU1j1E9P for ; Thu, 22 Aug 2013 05:44:55 -0700 (PDT) Received: from nug.nucleus.be (unknown [77.73.97.156]) by ietfa.amsl.com (Postfix) with ESMTP id 069BE11E819E for ; Thu, 22 Aug 2013 05:44:54 -0700 (PDT) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 13182CBD8030; Thu, 22 Aug 2013 14:44:52 +0200 (CEST) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 01D47CBD802E; Thu, 22 Aug 2013 14:44:52 +0200 (CEST) Date: Thu, 22 Aug 2013 14:44:51 +0200 (CEST) From: Pieter Vandepitte To: Linlin Zhou Message-ID: <1591772811.145940.1377175491646.JavaMail.zimbra@staff.dns.be> In-Reply-To: <00aa01ce9f0b$28eeac30$7acc0490$@cn> References: <00c701ce9e53$a1efbb00$e5cf3100$@cn> <00aa01ce9f0b$28eeac30$7acc0490$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_145939_1638785598.1377175491645" X-Originating-IP: [77.67.63.234] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC27 (Linux)/8.0.4_GA_5737) Thread-Topic: Comments on draft-ietf-weirds-json-response-05 Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmfrtGAgAAe1oCAAJ2jELuTd0DB X-Mailman-Approved-At: Thu, 22 Aug 2013 10:58:05 -0700 Cc: weirds@ietf.org Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:44:59 -0000 ------=_Part_145939_1638785598.1377175491645 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Linlin and Andy,=20 Isn't the solution to simply perform some normalization before searching (s= ee https://en.wikipedia.org/wiki/Canonical_equivalence ) and make sure the = data in your database is normalized the same way (e.g. NFC, NFD, NFKC or NF= KD)?=20 kr,=20 Pieter=20 Pieter Vandepitte=20 Software Engineer=20 +32 16 29 89 27=20 www.dnsbelgium.be=20 ----- Original Message ----- > From: "Linlin Zhou" > To: "Andy Newton" , "Ernie Dainow" , > weirds@ietf.org > Sent: Thursday, August 22, 2013 9:42:31 AM > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 > > -----Original Message----- > > From: Andy Newton [mailto:andy@arin.net] > > Sent: Wednesday, August 21, 2013 11:39 PM > > To: Linlin Zhou; 'Ernie Dainow'; weirds@ietf.org > > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05 > > > > On 8/21/13 5:48 AM, "Linlin Zhou" wrote: > > > > >section 4 search processing > > > > > >I don't quite understand " Servers SHOULD NOT partially match > > >combinations of Unicode characters where a Unicode character may be > > >legally combined with another Unicode character or characters. " What'= s > > >the problem if a server handles this search? Can someone give me an > > >example? > > > > Linlin, > > > > Let me start by saying that I'm not an I18N expert. I have talked to > several > > IETFers with more experience in internationalization issues, and the > advice > > given was to avoid interoperability issues where combining characters c= an > be > > confused with character of single code points but with the same semanti= c > > meaning. > I asked someone about the combining Unicode characters, he gave me an > example such as "=C3=A7" (Latin small letter c with cedilla). It can be e= ncoded > as U+00E7 or U+0063 U+0327 (a regular "c" followed by a combining cedilla= ). > I don't know whether this is the right scenario discussed in this section= . > If I have a domain contains this letter, for example fa=C3=A7ade.com. A u= ser may > partially search fa=C3=A7*.com, the database find the record that Unicode= name > starts with fa=C3=A7, as you said in a similar way like lookups. While th= e text > in this section makes me feel that a user may possibly search U+0066 U+00= 61 > U+0063*.com or U+0066 U+0061 U+0063 U+0327*.com. Since Chinese Unicode > characters don't have this situation, I want to know more about this issu= e > and how to handle it by the server. > Anyway, thanks Andy. > > Honestly, I don't know what harm would come from just letting the serve= r > > respond with its own rules. Nor do I know if the rules change depending= on > > registry policy. This may be the case that the server responds with wha= t > the > > server has in a similar way we have done with lookups. > > > Regards, > Linlin > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds ------=_Part_145939_1638785598.1377175491645 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Linlin and Andy,

Isn't the solution t= o simply perform some normalization before searching (see https://en.wikipedia.org/wiki/Can= onical_equivalence) and make sure the data in your database is nor= malized the same way (e.g. NFC, NFD, NFKC or NFKD)?

kr,

Pieter

Pieter Vandepitte
= +32 16 29 89 27

From: "Linlin Zhou= " <zhoulinlin@cnnic.cn>
To: "Andy Newton" <andy@arin.net= >, "Ernie Dainow" <edainow@afilias.info>, weirds@ietf.org
Se= nt: Thursday, August 22, 2013 9:42:31 AM
Subject: Re: [weirds= ] Comments on draft-ietf-weirds-json-response-05



> -----Original Message-----
> From: Andy Newton [mailt= o:andy@arin.net]
> Sent: Wednesday, August 21, 2013 11:39 PM
> = To: Linlin Zhou; 'Ernie Dainow'; weirds@ietf.org
> Subject: Re: [weir= ds] Comments on draft-ietf-weirds-json-response-05
>
> On 8/21= /13 5:48 AM, "Linlin Zhou" <zhoulinlin@cnnic.cn> wrote:
>
&= gt; >section 4 search processing
> >
> >I don't quite = understand " Servers SHOULD NOT partially match
> >combinations of= Unicode characters where a Unicode character may be
> >legally co= mbined with another Unicode character or characters. " What's
> >t= he problem if a server handles this search? Can someone give me an
> = >example?
>
> Linlin,
>
> Let me start by sayi= ng that I'm not an I18N expert. I have talked to
several
> IETFers= with more experience in internationalization issues, and the
advice
= > given was to avoid interoperability issues where combining characters = can
be
> confused with character of single code points but with th= e same semantic
> meaning.

I asked someone about th= e combining Unicode characters, he gave me an
example such as "=C3=A7" (= Latin small letter c with cedilla). It can be encoded
as U+00E7 or U+006= 3 U+0327 (a regular "c" followed by a combining cedilla).
I don't know w= hether this is the right scenario discussed in this section.

If I have a domain contains this letter, for example fa=C3=A7ade.com. A= user may
partially search fa=C3=A7*.com, the database find the record t= hat Unicode name
starts with fa=C3=A7, as you said in a similar way like= lookups. While the text
in this section makes me feel that a user may p= ossibly search U+0066 U+0061
U+0063*.com or U+0066 U+0061 U+0063 U+0327*= .com. Since Chinese Unicode
characters don't have this situation, I want= to know more about this issue
and how to handle it by the server.

Anyway, thanks Andy.

> Honestly, I don't = know what harm would come from just letting the server
> respond with= its own rules. Nor do I know if the rules change depending on
> regi= stry policy. This may be the case that the server responds with what
the=
> server has in a similar way we have done with lookups.
>

Regards,
Linlin

______________________= _________________________
weirds mailing list
weirds@ietf.org
http= s://www.ietf.org/mailman/listinfo/weirds

------=_Part_145939_1638785598.1377175491645-- From pieter.vandepitte@dns.be Thu Aug 22 01:38:09 2013 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C621F9E04 for ; Thu, 22 Aug 2013 01:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Q0JMIxLd1N for ; Thu, 22 Aug 2013 01:38:04 -0700 (PDT) Received: from nug.nucleus.be (unknown [77.73.97.156]) by ietfa.amsl.com (Postfix) with ESMTP id 295FD21F92C2 for ; Thu, 22 Aug 2013 01:38:03 -0700 (PDT) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 5F9F2CBD8032 for ; Thu, 22 Aug 2013 10:38:02 +0200 (CEST) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 54781CBD8030 for ; Thu, 22 Aug 2013 10:38:02 +0200 (CEST) Date: Thu, 22 Aug 2013 10:38:02 +0200 (CEST) From: Pieter Vandepitte To: weirds@ietf.org Message-ID: <968569653.97039.1377160682107.JavaMail.zimbra@staff.dns.be> In-Reply-To: <1601969143.91954.1377159203197.JavaMail.zimbra@staff.dns.be> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_97038_589219710.1377160682106" X-Originating-IP: [77.67.63.234] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC27 (Linux)/8.0.4_GA_5737) Thread-Topic: jcal as event format in json response Thread-Index: RW2H6PIZD84vUNQ37eAoc5jSHT9VXQ== X-Mailman-Approved-At: Thu, 22 Aug 2013 10:58:11 -0700 Subject: [weirds] jcal as event format in json response X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 Aug 2013 08:41:06 -0000 ------=_Part_97038_589219710.1377160682106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Perhaps a bit too late in the thinking process, but did anyone ever consider to propose jcal as event format (in analogy to jcard for contact information)? E.g. like this events: ["vcalendar", ["vevent", [ ["dtstamp", {}, "date-time", "2006-02-06T00:11:21Z"], ["summary", {}, "text", "Registration of mydomain.example"], ["categories", {}, "text", "registration"], ["contact", {}, "text", "OTHERID-LUNARNIC"] ], ["vevent", [ ... ] If yes, why reinvent the wheel? kr, Pieter Pieter Vandepitte Software Engineer +32 16 29 89 27 www.dnsbelgium.be ------=_Part_97038_589219710.1377160682106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Perhaps a bit too late in the thinkin= g process, but did anyone ever consider to propose jcal as event format (in= analogy to jcard for contact information)? E.g. like this

events: = ["vcalendar",
         &nb= sp;      ["vevent", [
        &= nbsp;           ["dt= stamp", {}, "date-time", "2006-02-06T00:11:21Z"],
   &nb= sp;            =     ["summary", {}, "text", "Registration of mydomain.e= xample"],
          =           ["categories", = {}, "text", "registration"],
       =             &nb= sp;["contact", {}, "text", "OTHERID-LUNARNIC"]

       =          ],

      &n= bsp;         ["vevent", [

    &nbs= p;           ...

    &= nbsp;       ]


If =
yes, why reinvent the wheel?

kr,

------=_Part_97038_589219710.1377160682106--

From edainow@afilias.info  Thu Aug 22 14:01:45 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984B421F9D0E for ; Thu, 22 Aug 2013 14:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.999,  BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LduMJMcEIAm for ; Thu, 22 Aug 2013 14:01:31 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B411E8215 for ; Thu, 22 Aug 2013 14:01:29 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VCc0X-0004V6-45 for weirds@ietf.org; Thu, 22 Aug 2013 21:01:29 +0000
Received: from mail-yh0-f49.google.com ([209.85.213.49]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VCc0W-000228-6C for weirds@ietf.org; Thu, 22 Aug 2013 21:01:29 +0000
Received: by mail-yh0-f49.google.com with SMTP id v1so273302yhn.36 for ; Thu, 22 Aug 2013 14:01:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=YAxDzZbFN4byE9Z7uT7Wj5RG1CFfSpDp0zDobiD39Us=; b=gb6UcHzQUbJbXMiCz+7U3gLMEsLCW1EBvQ07I6wOccGojQnUwEBeCWrLbufjli08Qa 0xwY41o/H4mrvykAs2Xh/kxHXojkABQv0MF9tP2wjEgacCzm1XCNEVpMt1zhU+0oI8xe /qvJNb3c0ZCXoJX8sKamEKViByncctC/85i774uE1ROcSPfUz+eK3BSKsXRwBgTqFxsw 2mtjO7OL8AO65WGaBLWHXzb26iHZ6PurunrTUv80nFzAQowV6IcohCUhGbsw917HV7u+ pG9C0LKoQLu3a7No5ivXbyB1IzZEJpSfZZj3ILO0YC2HF+RWwXISeVuC/mjmGEyYxxkU RSCg==
X-Gm-Message-State: ALoCoQmcROwXo+LeTPSq4ZMpt72urieXwJ4TVrv5iJQX/+qGXmafSj24ro2d15W8LArPmX2SrOUmL1qYTJLngWcIt3Qa3iTiGOiddI9TtkvfMMyzbvPsahbmRv+PXq/rgo5iO2n1t2ct
X-Received: by 10.236.121.144 with SMTP id r16mr3870075yhh.64.1377205283068; Thu, 22 Aug 2013 14:01:23 -0700 (PDT)
X-Received: by 10.236.121.144 with SMTP id r16mr3870052yhh.64.1377205282533; Thu, 22 Aug 2013 14:01:22 -0700 (PDT)
Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id c6sm16403584yhl.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Aug 2013 14:01:21 -0700 (PDT)
Message-ID: <52167C1D.5020107@afilias.info>
Date: Thu, 22 Aug 2013 17:01:17 -0400
From: Ernie Dainow 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Pieter Vandepitte 
References: <00c701ce9e53$a1efbb00$e5cf3100$@cn>  <00aa01ce9f0b$28eeac30$7acc0490$@cn> <1591772811.145940.1377175491646.JavaMail.zimbra@staff.dns.be>
In-Reply-To: <1591772811.145940.1377175491646.JavaMail.zimbra@staff.dns.be>
Content-Type: multipart/alternative; boundary="------------030306060509060602070604"
Cc: weirds@ietf.org
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Aug 2013 21:01:46 -0000

This is a multi-part message in MIME format.
--------------030306060509060602070604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Here is an example of doing a search 'abc*' against 'abçd' using each 
normalization type:
NFC  -1
NFKC -1
NFD   0
NFKD  0

The first two fail because ç is normalized to a single Unicode point, 
whereas the last two (Decomposed forms) succeed because ç is normalized 
to two Unicode points, c followed by cedilla.

In terms of usefulness to an RDAP client, I think a search result of 
'abçd' is more useful than no result. I believe that taking this 
approach would mean that we support partial match searches.

It is important that the normalization form used by the server is 
specified as part of the spec. Otherwise, clients will get different 
results depending on the server that is queried for the search.

(Python code to do this test is very simple. Note that it doesn't matter 
in what form the server has stored the data.)
import unicodedata
a = u'abçd'
for normtype in ('NFC', 'NFKC', 'NFD','NFKD'):
     anorm = unicodedata.normalize(normtype, a)
     print normtype, anorm.find('abc')

-Ernie


On 8/22/2013 8:44 AM, Pieter Vandepitte wrote:
> Linlin and Andy,
>
> Isn't the solution to simply perform some normalization before 
> searching (see 
> https://en.wikipedia.org/wiki/Canonical_equivalence) and make sure the 
> data in your database is normalized the same way (e.g. NFC, NFD, NFKC 
> or NFKD)?
>
> kr,
>
> Pieter
>
> *Pieter Vandepitte*
> *Software Engineer*
> +32 16 29 89 27
> *www.dnsbelgium.be *
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Linlin Zhou" 
>     *To: *"Andy Newton" , "Ernie Dainow"
>     , weirds@ietf.org
>     *Sent: *Thursday, August 22, 2013 9:42:31 AM
>     *Subject: *Re: [weirds] Comments on draft-ietf-weirds-json-response-05
>
>
>
>     > -----Original Message-----
>     > From: Andy Newton [mailto:andy@arin.net]
>     > Sent: Wednesday, August 21, 2013 11:39 PM
>     > To: Linlin Zhou; 'Ernie Dainow'; weirds@ietf.org
>     > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
>     >
>     > On 8/21/13 5:48 AM, "Linlin Zhou"  wrote:
>     >
>     > >section 4 search processing
>     > >
>     > >I don't quite understand " Servers SHOULD NOT partially match
>     > >combinations of Unicode characters where a Unicode character may be
>     > >legally combined with another Unicode character or characters.
>     " What's
>     > >the problem if a server handles this search? Can someone give me an
>     > >example?
>     >
>     > Linlin,
>     >
>     > Let me start by saying that I'm not an I18N expert. I have talked to
>     several
>     > IETFers with more experience in internationalization issues, and the
>     advice
>     > given was to avoid interoperability issues where combining
>     characters can
>     be
>     > confused with character of single code points but with the same
>     semantic
>     > meaning.
>
>     I asked someone about the combining Unicode characters, he gave me an
>     example such as "ç" (Latin small letter c with cedilla). It can be
>     encoded
>     as U+00E7 or U+0063 U+0327 (a regular "c" followed by a combining
>     cedilla).
>     I don't know whether this is the right scenario discussed in this
>     section.
>
>     If I have a domain contains this letter, for example façade.com. A
>     user may
>     partially search faç*.com, the database find the record that
>     Unicode name
>     starts with faç, as you said in a similar way like lookups. While
>     the text
>     in this section makes me feel that a user may possibly search
>     U+0066 U+0061
>     U+0063*.com or U+0066 U+0061 U+0063 U+0327*.com. Since Chinese Unicode
>     characters don't have this situation, I want to know more about
>     this issue
>     and how to handle it by the server.
>
>     Anyway, thanks Andy.
>
>     > Honestly, I don't know what harm would come from just letting
>     the server
>     > respond with its own rules. Nor do I know if the rules change
>     depending on
>     > registry policy. This may be the case that the server responds
>     with what
>     the
>     > server has in a similar way we have done with lookups.
>     >
>
>     Regards,
>     Linlin
>
>     _______________________________________________
>     weirds mailing list
>     weirds@ietf.org
>     https://www.ietf.org/mailman/listinfo/weirds
>
>


--------------030306060509060602070604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Here is an example of doing a search 'abc*' against 'abçd' using
    each normalization type:

    NFC  -1

    NFKC -1

    NFD   0

    NFKD  0

    

    The first two fail because ç is normalized to a single Unicode
    point, whereas the last two (Decomposed forms) succeed because ç is
    normalized to two Unicode points, c followed by cedilla.

    

    In terms of usefulness to an RDAP client, I think a search result of
    'abçd' is more useful than no result. I believe that taking this
    approach would mean that we support partial match searches.

    

    It is important that the normalization form used by the server is
    specified as part of the spec. Otherwise, clients will get different
    results depending on the server that is queried for the search.

    

    (Python code to do this test is very simple. Note that it doesn't
    matter in what form the server has stored the data.)

    import unicodedata

    a = u'abçd'

    for normtype in ('NFC', 'NFKC', 'NFD','NFKD'):

        anorm = unicodedata.normalize(normtype, a)

        print normtype, anorm.find('abc')

    

    -Ernie

    

    

    
On 8/22/2013 8:44 AM, Pieter Vandepitte
      wrote:

    

    

      

        
Linlin and Andy,

        

        


        

        
Isn't the solution to simply perform some normalization
          before searching (see https://en.wikipedia.org/wiki/Canonical_equivalence) and
          make sure the data in your database is normalized the same way
          (e.g. NFC, NFD, NFKC or NFKD)?

        


        

        
kr,

        


        

        
Pieter

        


        

        
Pieter Vandepitte
          
Software Engineer

          
+32 16 29 89 27

          
          


          

          

          

        

        

        
From:
          "Linlin Zhou" <zhoulinlin@cnnic.cn>

          To: "Andy Newton" <andy@arin.net>, "Ernie
          Dainow" <edainow@afilias.info>, weirds@ietf.org

          Sent: Thursday, August 22, 2013 9:42:31 AM

          Subject: Re: [weirds] Comments on
          draft-ietf-weirds-json-response-05

          


          

          

          


          

          > -----Original Message-----

          > From: Andy Newton [mailto:andy@arin.net]

          > Sent: Wednesday, August 21, 2013 11:39 PM

          > To: Linlin Zhou; 'Ernie Dainow'; weirds@ietf.org

          > Subject: Re: [weirds] Comments on
          draft-ietf-weirds-json-response-05

          > 

          > On 8/21/13 5:48 AM, "Linlin Zhou"
          <zhoulinlin@cnnic.cn> wrote:

          > 

          > >section 4 search processing

          > >

          > >I don't quite understand " Servers SHOULD NOT
          partially match

          > >combinations of Unicode characters where a Unicode
          character may be

          > >legally combined with another Unicode character or
          characters. " What's

          > >the problem if a server handles this search? Can
          someone give me an

          > >example?

          > 

          > Linlin,

          > 

          > Let me start by saying that I'm not an I18N expert. I
          have talked to

          several

          > IETFers with more experience in internationalization
          issues, and the

          advice

          > given was to avoid interoperability issues where
          combining characters can

          be

          > confused with character of single code points but with
          the same semantic

          > meaning.

          


          

          I asked someone about the combining Unicode characters, he
          gave me an

          example such as "ç" (Latin small letter c with cedilla). It
          can be encoded

          as U+00E7 or U+0063 U+0327 (a regular "c" followed by a
          combining cedilla).

          I don't know whether this is the right scenario discussed in
          this section.

          


          

          If I have a domain contains this letter, for example
          façade.com. A user may

          partially search faç*.com, the database find the record that
          Unicode name

          starts with faç, as you said in a similar way like lookups.
          While the text

          in this section makes me feel that a user may possibly search
          U+0066 U+0061

          U+0063*.com or U+0066 U+0061 U+0063 U+0327*.com. Since Chinese
          Unicode

          characters don't have this situation, I want to know more
          about this issue

          and how to handle it by the server.

          


          

          Anyway, thanks Andy.

          


          

          > Honestly, I don't know what harm would come from just
          letting the server

          > respond with its own rules. Nor do I know if the rules
          change depending on

          > registry policy. This may be the case that the server
          responds with what

          the

          > server has in a similar way we have done with lookups.

          > 

          


          

          Regards,

          Linlin

          


          

          _______________________________________________

          weirds mailing list

          weirds@ietf.org

          https://www.ietf.org/mailman/listinfo/weirds

        

        


        

      

    

    

  


--------------030306060509060602070604--

From andy@arin.net  Thu Aug 22 14:26:26 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03E11E814E for ; Thu, 22 Aug 2013 14:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level: 
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI5gTZD3PanD for ; Thu, 22 Aug 2013 14:26:21 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 292F911E8124 for ; Thu, 22 Aug 2013 14:26:21 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id C5DD9165251; Thu, 22 Aug 2013 17:26:20 -0400 (EDT)
Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 30F7B16524A; Thu, 22 Aug 2013 17:26:20 -0400 (EDT)
Received: from CHAXCH04.corp.arin.net (10.1.30.101) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 22 Aug 2013 17:26:14 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH04.corp.arin.net ([10.1.30.101]) with mapi id 14.02.0342.003; Thu, 22 Aug 2013 17:26:14 -0400
From: Andy Newton 
To: Ernie Dainow , Pieter Vandepitte 
Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05
Thread-Index: AQHOnb+/YcZBNtR6fE+F7nG5MDujxZmfrtGAgAAe1oCAAJ2jELuTd0DBxG4agYD//8PugA==
Date: Thu, 22 Aug 2013 21:26:13 +0000
Message-ID: 
In-Reply-To: <52167C1D.5020107@afilias.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.1.1.56]
Content-Type: multipart/alternative; boundary="_000_CE3BFA2527C95andyarinnet_"
MIME-Version: 1.0
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Aug 2013 21:26:26 -0000

--_000_CE3BFA2527C95andyarinnet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From: Ernie Dainow >
Date: Thursday, August 22, 2013 5:01 PM
To: Pieter Vandepitte >
Cc: Linlin Zhou >, Andrew N=
ewton >, "weirds@ietf.org" >
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05

It is important that the normalization form used by the server is specified=
 as part of the spec. Otherwise, clients will get different results dependi=
ng on the server that is queried for the search.

I like this approach. Which form do you recommend?

-andy

--_000_CE3BFA2527C95andyarinnet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <7D38D844172B0442B0E836433B3C161F@corp.arin.net>
Content-Transfer-Encoding: quoted-printable









From: Ernie Dainow <edainow@afilias.info>

Date: Thursday, August 22, 2013 5:0=
1 PM

To: Pieter Vandepitte <pieter.vandepitte@dns.be>

Cc: Linlin Zhou <zhoulinlin@cnnic.cn>, Andrew Newton <andy@arin.net>, "weirds@ietf.org" <weirds@ietf.org>

Subject: Re: [weirds] Comments on d=
raft-ietf-weirds-json-response-05










It
 is important that the normalization form used by the server is specified a=
s part of the spec. Otherwise, clients will get different results depending=
 on the server that is queried for the search.








I like this approach. Which form do you recommend?







-andy




--_000_CE3BFA2527C95andyarinnet_--

From johnl@iecc.com  Thu Aug 22 16:09:26 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9311E8232 for ; Thu, 22 Aug 2013 16:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.67
X-Spam-Level: 
X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXlaPFpNHHgs for ; Thu, 22 Aug 2013 16:09:21 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC4821F9CFB for ; Thu, 22 Aug 2013 16:09:21 -0700 (PDT)
Received: (qmail 94001 invoked from network); 22 Aug 2013 23:09:19 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 23:09:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52169a1f.xn--9vv.k1308; i=johnl@user.iecc.com; bh=mKr2+49io6LpllI5OnqgmHPZPidrke1pj47IUkQkMQw=; b=qkv9yhLVvvHeNAXOCN89sblFZQez7VDoPG1kKPeSKc2IIcqaCXTVepzu6Lo52ZJH3bia/dFnHJm5av9rYgYHd6ytE0aFmb6mE8v7ZZoM0684EHlLi9hiA+5TAgRH8cvcDScT8MyuSYn9aAd9wL9rnsK77QmTXuwIoutToWH/5zM7picJCC4FeAC30IUNviu40sWWV2SlAQdBIXZszozrSqvG4wbtEFTNPkjYyzJ1pnvva4RczjJVfUFQmaZ+g0P4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52169a1f.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=mKr2+49io6LpllI5OnqgmHPZPidrke1pj47IUkQkMQw=; b=KkozjdwBhZU9ZbcElU1ZlNqrIHSDdL881urRVB9ezBUtDEij5xNO3mKOZwlCUB9KhyW4MbNaRvHFExuyFR7Qhs2zYcP19f+OsDnhZbpNclZqKV2/rw88aMjHh5HRmUD4tuzHJIExuQBklxjeaY3NE2ZxwbK5BoJrujepBsnhB8J1b4fERDsIEAgPWOCTy1XLmO4CLyqoGjgJ7RYRvsbSeNBMnSUMh469fK7+8a5hzPasQnV9z2xM0ZZ0RU8sQW4p
Date: 22 Aug 2013 23:08:57 -0000
Message-ID: <20130822230857.3661.qmail@joyce.lan>
From: "John Levine" 
To: weirds@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Aug 2013 23:09:26 -0000

>It is important that the normalization form used by the server is specified as part of the
>spec. Otherwise, clients will get different results depending on the server that is queried
>for the search.
>
>I like this approach. Which form do you recommend?

Why would a server use a normalization other than the one for DNS names?

R's,
John

From shollenbeck@verisign.com  Thu Aug 22 17:58:19 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D665621F9A59 for ; Thu, 22 Aug 2013 17:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gJCYRWygsXS for ; Thu, 22 Aug 2013 17:58:14 -0700 (PDT)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6158221F9AA9 for ; Thu, 22 Aug 2013 17:57:55 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUhazkZSrQGMXdaqP3j157KKK18bG6zAO@postini.com; Thu, 22 Aug 2013 17:57:57 PDT
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r7N0voGI020025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 20:57:50 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 22 Aug 2013 20:57:50 -0400
From: "Hollenbeck, Scott" 
To: John Levine , "weirds@ietf.org" 
Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05
Thread-Index: AQHOn3q+Z75fcRSc6EeDvyYSIF2JJZmiAIyAgAActID//9r3UA==
Date: Fri, 23 Aug 2013 00:57:50 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F4923D386@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References:  <20130822230857.3661.qmail@joyce.lan>
In-Reply-To: <20130822230857.3661.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] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Aug 2013 00:58:20 -0000

> -----Original Message-----
> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On
> Behalf Of John Levine
> Sent: Thursday, August 22, 2013 7:09 PM
> To: weirds@ietf.org
> Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
>=20
> >It is important that the normalization form used by the server is
> specified as part of the
> >spec. Otherwise, clients will get different results depending on the
> server that is queried
> >for the search.
> >
> >I like this approach. Which form do you recommend?
>=20
> Why would a server use a normalization other than the one for DNS
> names?

RFC 5890 requires Normalization Form C (NFC)from Unicode Standard Annex #15=
.

Scott

From pieter.vandepitte@dns.be  Thu Aug 22 23:41:19 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35C11E8243 for ; Thu, 22 Aug 2013 23:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.73
X-Spam-Level: 
X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=0.317,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwzRLtgTVA5Y for ; Thu, 22 Aug 2013 23:41:14 -0700 (PDT)
Received: from nug.nucleus.be (unknown [77.73.97.156]) by ietfa.amsl.com (Postfix) with ESMTP id E316711E82B4 for ; Thu, 22 Aug 2013 23:41:13 -0700 (PDT)
Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 3F7C4447825B; Fri, 23 Aug 2013 08:41:12 +0200 (CEST)
Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 37AD04478254; Fri, 23 Aug 2013 08:41:12 +0200 (CEST)
Date: Fri, 23 Aug 2013 08:41:11 +0200 (CEST)
From: Pieter Vandepitte 
To: Scott Hollenbeck 
Message-ID: <1689529183.221675.1377240071909.JavaMail.zimbra@staff.dns.be>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4923D386@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References:  <20130822230857.3661.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4923D386@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_221674_1069050855.1377240071907"
X-Originating-IP: [77.67.63.234]
X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC27 (Linux)/8.0.4_GA_5737)
Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response-05
Thread-Index: AQHOn3q+Z75fcRSc6EeDvyYSIF2JJZmiAIyAgAActID//9r3ULDt674F
Cc: John Levine , weirds@ietf.org
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Aug 2013 06:41:19 -0000

------=_Part_221674_1069050855.1377240071907
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

As how i understand it, the NF only depends on how you store your domain names in your database (i.e. normalize your input in the same form as your working data). It's not because RFC 5890 requires NFC for U-label _representation_ that you are not allowed to use any other NF for storage. 

So I would not specify any NF in the specs. It's up to the developer how he will implement search (or will RDAP impose rules on _how_ data is stored? I hope not...) and let's hope the developer takes into account normalization (as any developer should do for any project...) and other stuff like character escaping, character encoding (same thing: it's not because RDAP requires UTF-8, that a developer may not use ISO-8859-1 encoding in the database) etc.... A spec cannot cover all errors a developer could possibly make, or am i so terribly wrong about that? In best case we could add a 'Recommendations' section/document but I would not make any requirements on that... 

kr 

Pieter 

Pieter Vandepitte 
Software Engineer 
+32 16 29 89 27 
www.dnsbelgium.be 

----- Original Message -----

> From: "Scott Hollenbeck" 
> To: "John Levine" , weirds@ietf.org
> Sent: Friday, August 23, 2013 2:57:50 AM
> Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05

> > -----Original Message-----
> > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On
> > Behalf Of John Levine
> > Sent: Thursday, August 22, 2013 7:09 PM
> > To: weirds@ietf.org
> > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
> >
> > >It is important that the normalization form used by the server is
> > specified as part of the
> > >spec. Otherwise, clients will get different results depending on the
> > server that is queried
> > >for the search.
> > >
> > >I like this approach. Which form do you recommend?
> >
> > Why would a server use a normalization other than the one for DNS
> > names?

> RFC 5890 requires Normalization Form C (NFC)from Unicode Standard Annex #15.

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

------=_Part_221674_1069050855.1377240071907
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


As how i understand it, the NF only depends on how you store your =
domain names in your database (i.e. normalize your input in the same form a=
s your working data). It's not because RFC 5890 requires NFC for U-label _r=
epresentation_ that you are not allowed to use any other NF for storage.

So I would not specify any NF in the specs. It's=
 up to the developer how he will implement search (or will RDAP impose rule=
s on _how_ data is stored? I hope not...) and let's hope the developer take=
s into account normalization (as any developer should do for any project...=
) and other stuff like character escaping, character encoding (same thing: =
it's not because RDAP requires UTF-8, that a developer may not use ISO-8859=
-1 encoding in the database) etc.... A spec cannot cover all errors a devel=
oper could possibly make, or am i so terribly wrong about that? In best cas=
e we could add a 'Recommendations' section/document but I would not make an=
y requirements on that...

kr

<=
div>Pieter

Pieter Vandepitte
Software Engineer
+32 16 29 89 27<=
/span>


From: "Scott Hollenbeck" <shollenbeck@veris=
ign.com>
To: "John Levine" <johnl@taugh.com>, weirds@iet=
f.org
Sent: Friday, August 23, 2013 2:57:50 AM
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05

> -----Original Message-----
> From: weirds-bounces@ietf.org [=
mailto:weirds-bounces@ietf.org] On
> Behalf Of John Levine
> Se=
nt: Thursday, August 22, 2013 7:09 PM
> To: weirds@ietf.org
> S=
ubject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
>=
 
> >It is important that the normalization form used by the serve=
r is
> specified as part of the
> >spec. Otherwise, clients =
will get different results depending on the
> server that is queried<=
br>> >for the search.
> >
> >I like this approach. =
Which form do you recommend?
> 
> Why would a server use a norm=
alization other than the one for DNS
> names?

RFC 5=
890 requires Normalization Form C (NFC)from Unicode Standard Annex #15.
=


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


------=_Part_221674_1069050855.1377240071907--

From edainow@afilias.info  Mon Aug 26 14:16:20 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D221F9E88 for ; Mon, 26 Aug 2013 14:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level: 
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=0.666,  BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA0tu38xzzuj for ; Mon, 26 Aug 2013 14:16:10 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9121F9FD7 for ; Mon, 26 Aug 2013 14:16:10 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VE48r-0001nF-5K for weirds@ietf.org; Mon, 26 Aug 2013 21:16:05 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VE48r-0005dt-4o for weirds@ietf.org; Mon, 26 Aug 2013 21:16:05 +0000
Received: by mail-ob0-f178.google.com with SMTP id ef5so3781236obb.23 for ; Mon, 26 Aug 2013 14:16:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=YeDPY9ehBGlVYdVGF137j8VJx/nLMa2VSDZkeODwlwc=; b=PDo0d/jfm/Vo/TTHl0TLs6tnTjRx1bQKy2QnVXkggxPNghLQ9oXLPq2hzmykhdgKGj 3OcplOnJ0VySBLw5sXrTSyPQ2Z67PJ5YKN1E/cyeBUMxDFlp9eXuGQQktv8iryYGtiLB nTMmYstr1conAuCflwy1Sjm1LlS35co5TwhtKb6SzWjca7mR0FFydi64v4S27guLYlIg LF7S+ImA9++WSxpXK9PXPfVnAzE+37Is4ytvbAeu9PPyu40oDAhhg9de6mOY6y18E82K qHLtZt3lvV239eCnkNccVoupwK3YoaotmiorQboLh5BUX+1vKsrSfQu07vehnBajZErE 9SvQ==
X-Gm-Message-State: ALoCoQkAWDMFqyXMKLRsS9RFPz+LqtdsBhQY63gEjZS78YFP//UInpxJwBFFUVqlzBhoVyUISZsH7PvjUecRHDf3emG/x5vyUS6LhwI+z57GkihRUCpNl9FPn0Zqi4vL3ePh/1NF/D+Z
X-Received: by 10.182.71.37 with SMTP id r5mr15823298obu.22.1377551759993; Mon, 26 Aug 2013 14:15:59 -0700 (PDT)
X-Received: by 10.182.71.37 with SMTP id r5mr15823289obu.22.1377551759849; Mon, 26 Aug 2013 14:15:59 -0700 (PDT)
Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id s14sm16788032oeo.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 14:15:58 -0700 (PDT)
Message-ID: <521BC58B.4030403@afilias.info>
Date: Mon, 26 Aug 2013 17:15:55 -0400
From: Ernie Dainow 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Pieter Vandepitte 
References:  <20130822230857.3661.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4923D386@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1689529183.221675.1377240071909.JavaMail.zimbra@staff.dns.be>
In-Reply-To: <1689529183.221675.1377240071909.JavaMail.zimbra@staff.dns.be>
Content-Type: multipart/alternative; boundary="------------050502090004090106060307"
Cc: weirds@ietf.org
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Aug 2013 21:16:20 -0000

This is a multi-part message in MIME format.
--------------050502090004090106060307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I think the example of searching "abc*" against "abçd" demonstrates that 
normalizing the search string to the same form as the target name is not 
sufficient to return the same results. If one server uses NFC, the 
normalized target is  U+0061, U+0062, U+00E7, U+0064 and a search for 
"abc" returns no result. A server using NFD against the normalized 
target U+0061, U+0062, U+0063, U+0327, U+0064 will return abçd.

If you store domain names in other than NFC, then every time you 
retrieve a name from storage you will have to normalize it to NFC to 
comply with RFC 5890. This would be a lot of overhead in a database search.

It seems to me that use of NFC makes it impossible to search against 
partial characters. Even if the search string is a partial character 
sequence, it will never find a match, since the target in NFC does not 
have decomposed characters from normalization and does not have other 
partial characters, since it is a valid IDN. The text in 
draft-ietf-weirds-rdap-query-06 could be greatly simplified by removing 
the paragraphs about partial matches and specifying that searches must 
be done against NFC normalized names (and recommending that names be 
stored in NFC form).

Note that this does not produce search results that may be more 
intuitive to a user. For example, in a French dictionary, the following 
words are listed in this order:
     semaine
     sémaphore
     semblant
     séminaire
So when people look up words beginning with "se", they expect to see 
alphabetic order regardless of the diacritical marks on the letter e.

I believe most people doing an RDAP search for "se*" would expect to get 
the whole list. With NFC normalization, they will only get
     semaine
     semblant

-Ernie


On 8/23/2013 2:41 AM, Pieter Vandepitte wrote:
> As how i understand it, the NF only depends on how you store your 
> domain names in your database (i.e. normalize your input in the same 
> form as your working data). It's not because RFC 5890 requires NFC for 
> U-label _representation_ that you are not allowed to use any other NF 
> for storage.
>
> So I would not specify any NF in the specs. It's up to the developer 
> how he will implement search (or will RDAP impose rules on _how_ data 
> is stored? I hope not...) and let's hope the developer takes into 
> account normalization (as any developer should do for any project...) 
> and other stuff like character escaping, character encoding (same 
> thing: it's not because RDAP requires UTF-8, that a developer may not 
> use ISO-8859-1 encoding in the database) etc.... A spec cannot cover 
> all errors a developer could possibly make, or am i so terribly wrong 
> about that? In best case we could add a 'Recommendations' 
> section/document but I would not make any requirements on that...
>
> kr
>
> Pieter
>
> *Pieter Vandepitte*
> *Software Engineer*
> +32 16 29 89 27
> *www.dnsbelgium.be *
>
>
> ------------------------------------------------------------------------
>


--------------050502090004090106060307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I think the example of searching "abc*" against "abçd" demonstrates
    that normalizing the search string to the same form as the target
    name is not sufficient to return the same results. If one server
    uses NFC, the normalized target is  U+0061, U+0062, U+00E7, U+0064
    and a search for "abc" returns no result. A server using NFD against
    the normalized target U+0061, U+0062, U+0063, U+0327, U+0064 will
    return abçd.

    

    If you store domain names in other than NFC, then every time you
    retrieve a name from storage you will have to normalize it to NFC to
    comply with RFC 5890. This would be a lot of overhead in a database
    search. 

    

    It seems to me that use of NFC makes it impossible to search against
    partial characters. Even if the search string is a partial character
    sequence, it will never find a match, since the target in NFC does
    not have decomposed characters from normalization and does not have
    other partial characters, since it is a valid IDN. The text in
    draft-ietf-weirds-rdap-query-06 could be greatly simplified by
    removing the paragraphs about partial matches and specifying that
    searches must be done against NFC normalized names (and recommending
    that names be stored in NFC form).

    

    Note that this does not produce search results that may be more
    intuitive to a user. For example, in a French dictionary, the
    following words are listed in this order:

        semaine

        sémaphore

        semblant

        séminaire

    So when people look up words beginning with "se", they expect to see
    alphabetic order regardless of the diacritical marks on the letter
    e. 

    

    I believe most people doing an RDAP search for "se*" would expect to
    get the whole list. With NFC normalization, they will only get

        semaine

        semblant

    

    -Ernie

    

    

    
On 8/23/2013 2:41 AM, Pieter Vandepitte
      wrote:

    

    

      

        
As how i understand it, the NF only depends on how you
          store your domain names in your database (i.e. normalize your
          input in the same form as your working data). It's not because
          RFC 5890 requires NFC for U-label _representation_ that you
          are not allowed to use any other NF for storage.

        

        


        

        
So I would not specify any NF in the specs. It's up to the
          developer how he will implement search (or will RDAP impose
          rules on _how_ data is stored? I hope not...) and let's hope
          the developer takes into account normalization (as any
          developer should do for any project...) and other stuff like
          character escaping, character encoding (same thing: it's not
          because RDAP requires UTF-8, that a developer may not use
          ISO-8859-1 encoding in the database) etc.... A spec cannot
          cover all errors a developer could possibly make, or am i so
          terribly wrong about that? In best case we could add a
          'Recommendations' section/document but I would not make any
          requirements on that...

        


        

        
kr

        


        

        
Pieter

        


        

        
Pieter Vandepitte
          
Software Engineer

          
+32 16 29 89 27

          
          


          

          

          

        

        


      

    

    

  


--------------050502090004090106060307--

From johnl@iecc.com  Mon Aug 26 14:34:53 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939B221F9DDE for ; Mon, 26 Aug 2013 14:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.614
X-Spam-Level: 
X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUUrcPu4f82U for ; Mon, 26 Aug 2013 14:34:49 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1980B21F94FF for ; Mon, 26 Aug 2013 14:34:48 -0700 (PDT)
Received: (qmail 54760 invoked from network); 26 Aug 2013 21:34:47 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 21:34:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521bc9f7.xn--3zv.k1308; i=johnl@user.iecc.com; bh=KpPyj7AmnXSptgX+97WyY+4AR4lGiUX9MUcheED3BPY=; b=hA2PtD/UVFpVrYn6qpZYEz2XUjHyGgZI0PhCvgUeLsbfrDiea4VpiHFpK7DBH/bHagjxretalVgDB1IT8lU9IMs+8q+5mJT1N+2pjB/FjONELmJIXPFJSLw8V1kNRG5RiL6nVktM6kFG9KRmADzqgCAT3qKulWa2rULGCtsQ3H494a0ANChigAT6VEMtmeTjJkV2lzCoDT9j914DRSQPv0aqWKlAgif5HCL3FJPUwIO0oV9YCqSKiyK4vQxITcU+
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521bc9f7.xn--3zv.k1308; olt=johnl@user.iecc.com; bh=KpPyj7AmnXSptgX+97WyY+4AR4lGiUX9MUcheED3BPY=; b=E8ge9SuBSbDcJvo2ZvTVSAAyYCHs+D64TDmTZoD89jV+M44R3/8DzlhyBxUJ8BUYY6N5x07MeT/DeUYw/5CsUx4aKGjULuArUFx1BXBoJH05UTInLAH0vSLErcbZDdwPmig1x5HumPAwdx0xA71pAJ4BfmO2UsvpAeU224lo5i31TmqVbshCh+AAkC3X4zcHqpNKpxb7OP6y7m9tWcDi2bZzPRsUGTpanVXOz8g7dVuLywb5M7xg2pBDTZQA9Fh8
Date: 26 Aug 2013 21:34:25 -0000
Message-ID: <20130826213425.82624.qmail@joyce.lan>
From: "John Levine" 
To: weirds@ietf.org
In-Reply-To: <521BC58B.4030403@afilias.info>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Aug 2013 21:34:53 -0000

>I believe most people doing an RDAP search for "se*" would expect to get 
>the whole list. With NFC normalization, they will only get
>     semaine
>     semblant

Unfortunately, this is a tarpit.  While the French consider e and é to
be approximately the same, the Swedes consider a, å, and ä to be as
different as a, b, and c.

I think the least bad we can do is to say that searches are against
NFC strings, and if you want to find accented characters, you have
to search for them.

R's,
John

From edainow@afilias.info  Mon Aug 26 14:47:44 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC521F9FC6 for ; Mon, 26 Aug 2013 14:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj+Op5lWa7mh for ; Mon, 26 Aug 2013 14:47:24 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 916A221F9F2B for ; Mon, 26 Aug 2013 14:47:24 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VE4d8-0002os-4V for weirds@ietf.org; Mon, 26 Aug 2013 21:47:22 +0000
Received: from mail-lb0-f174.google.com ([209.85.217.174]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VE4d8-0006Gb-3y for weirds@ietf.org; Mon, 26 Aug 2013 21:47:22 +0000
Received: by mail-lb0-f174.google.com with SMTP id w6so1913494lbh.33 for ; Mon, 26 Aug 2013 14:47:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=fe1Gr1ndv75/IHkymThfC52Fh0glcmCz+7uWcikacug=; b=gqXvAwgdT5J49fSOO1IcsiY5KCqfDzGSNNS3e88NlXDKAJ9HLloJfYt43SqAC5Sgp6 noGctnmv5A522TTGOBsDNr1C68FdBr1kOPSpWYb71jx7TbbhyxnbwhuSVtBy+R6NDBDO 6R+qFWUy2WpgVqwBlxBC3Koou+SCiDZQJO+F47ZpxVG6AW/tZEMWSNG+qK9OI1gg7B+d 4OJLd9cOHUDX0RWsDcOG+WMe1mht8IE5POvy81m1WkI6Mmx2sFw/3eGJ0ZyuT4TeEX6e t9sqvR4a/ksvXq8BV5j9nbvd5lv3M9vYM1IV5fDBAEb4+1eNIrhRCO1XUzWG/g3SzELv Gtlg==
X-Gm-Message-State: ALoCoQnv6M1xNzfIqjus/ThfByFVuzs2yDyskFwD2Rl3otOGnSkm4j/KD5qlIvWffNGsbrqbMNuh8WMwIw3CL4hY+HZ1A47b3qg+3uvQuh0ddrHUfeAlPk13G5+CjzpMoAyE0Cgasvoj
X-Received: by 10.112.9.195 with SMTP id c3mr3223881lbb.33.1377553635966; Mon, 26 Aug 2013 14:47:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.9.195 with SMTP id c3mr3223878lbb.33.1377553635884; Mon, 26 Aug 2013 14:47:15 -0700 (PDT)
Received: by 10.112.21.170 with HTTP; Mon, 26 Aug 2013 14:47:15 -0700 (PDT)
Date: Mon, 26 Aug 2013 17:47:15 -0400
Message-ID: 
From: Ernie Dainow 
To: "weirds@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1135e1f6204de704e4e0b32b
Subject: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Aug 2013 21:47:45 -0000

--001a1135e1f6204de704e4e0b32b
Content-Type: text/plain; charset=ISO-8859-1

In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization
rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
I don't think the normalization rules referred to are appropriate for RDAP
entity searches. The process in [I-D.ietf-precis-nickname] is designed to
produce unique names in order to avoid conflict of identifiers in chat
rooms or other applications. As such, it species a restricted set of
Unicode characters, the FreeformClass. But an Entity name, such as the name
of a Registrar, may be any Unicode string. Restricting names to a subset of
Unicode means that it may not be possible to enter a valid name of a
contact or organization.

-Ernie

--001a1135e1f6204de704e4e0b32b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


In 4.0 draft-ietf-weirds-rdap-query-06
=A0 =
=A0... When comparing entity names, servers SHOULD use the normalization ru=
les
=A0 =A0and code points specified by [I-D.ietf-precis-nickname=
] to determine


=A0 =A0partial matches.
	
I don't think the normalization rules referre=
d to are appropriate for RDAP entity searches. The process in [I-D.ietf-pre=
cis-nickname] is designed to produce unique names in order to avoid conflic=
t of identifiers in chat rooms or other applications. As such, it species a=
 restricted set of Unicode characters, the FreeformClass. But an Entity nam=
e, such as the name of a Registrar, may be any Unicode string. Restricting =
names to a subset of Unicode means that it may not be possible to enter a v=
alid name of a contact or organization.



-Ernie


--001a1135e1f6204de704e4e0b32b--

From pieter.vandepitte@dns.be  Tue Aug 27 02:16:57 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3421E80B8 for ; Tue, 27 Aug 2013 02:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.809
X-Spam-Level: 
X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[AWL=0.237,  BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKPl5Q4RlRom for ; Tue, 27 Aug 2013 02:16:51 -0700 (PDT)
Received: from mta01.nug.nucleus.be (mta01.nug.nucleus.be [77.73.97.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20E21E805D for ; Tue, 27 Aug 2013 02:16:48 -0700 (PDT)
Received: from localhost (localhost6.localdomain6 [127.0.0.1]) by mta01.nug.nucleus.be (Postfix) with ESMTP id EA82D12104D; Tue, 27 Aug 2013 11:16:45 +0200 (CEST)
Received: from mta01.nug.nucleus.be ([127.0.0.1]) by localhost (mta01.nug.nucleus.be [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QP9klj1FmVr8; Tue, 27 Aug 2013 11:16:40 +0200 (CEST)
Received: from localhost (localhost6.localdomain6 [127.0.0.1]) by mta01.nug.nucleus.be (Postfix) with ESMTP id EC88612104E; Tue, 27 Aug 2013 11:16:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mta01.nug.nucleus.be
Received: from mta01.nug.nucleus.be ([127.0.0.1]) by localhost (mta01.nug.nucleus.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DIVDTKg3pqTK; Tue, 27 Aug 2013 11:16:39 +0200 (CEST)
Received: from nug.nucleus.be (old.nug.nucleus.be [77.73.97.156]) by mta01.nug.nucleus.be (Postfix) with ESMTP id C7F1C12104D; Tue, 27 Aug 2013 11:16:39 +0200 (CEST)
Date: Tue, 27 Aug 2013 11:16:39 +0200 (CEST)
From: Pieter Vandepitte 
To: John Levine 
Message-ID: <1325678769.311613.1377594999597.JavaMail.zimbra@staff.dns.be>
In-Reply-To: <20130826213425.82624.qmail@joyce.lan>
References: <20130826213425.82624.qmail@joyce.lan>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_311612_752278053.1377594999595"
X-Originating-IP: [77.67.63.234]
X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC27 (Linux)/8.0.4_GA_5737)
Thread-Topic: Comments on draft-ietf-weirds-json-response-05
Thread-Index: ulvltf/0Dqg6Yjs6qwsgmM0GTEm8DQ==
Cc: weirds@ietf.org
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 09:16:57 -0000

------=_Part_311612_752278053.1377594999595
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I see the whole point now. I would rather agree with John's solution which =
is unambiguous to me...=20

kr=20

Pieter=20

Pieter Vandepitte=20
Software Engineer=20
+32 16 29 89 27=20
www.dnsbelgium.be=20

----- Original Message -----

> From: "John Levine" 
> To: weirds@ietf.org
> Sent: Monday, August 26, 2013 11:34:25 PM
> Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05

> >I believe most people doing an RDAP search for "se*" would expect to get
> >the whole list. With NFC normalization, they will only get
> > semaine
> > semblant

> Unfortunately, this is a tarpit. While the French consider e and =EF=BF=
=BD to
> be approximately the same, the Swedes consider a, =EF=BF=BD, and =EF=BF=
=BD to be as
> different as a, b, and c.

> I think the least bad we can do is to say that searches are against
> NFC strings, and if you want to find accented characters, you have
> to search for them.

> R's,
> John

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

------=_Part_311612_752278053.1377594999595
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


I see the whole point now. I would rather agree with John's solution wh=
ich is unambiguous to me...

kr

Pieter

Pieter Vandepitte
Software Engineer
+32 16 29 89 27
www.dnsbelgium.be


From: "John Levine" <johnl@taugh.com>
To: <=
/b>weirds@ietf.org
Sent: Monday, August 26, 2013 11:34:25 PM
<=
b>Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05<=
br>
>I believe most people doing an RDAP search for "se*" would expec=
t to get 
>the whole list. With NFC normalization, they will only get=

>     semaine
>     semblant

Unfort=
unately, this is a tarpit.  While the French consider e and =EF=BF=BD =
to
be approximately the same, the Swedes consider a, =EF=BF=BD, and =EF=
=BF=BD to be as
different as a, b, and c.

I think the least bad w=
e can do is to say that searches are against
NFC strings, and if you wan=
t to find accented characters, you have
to search for them.

R's,<=
br>John

_______________________________________________
weirds ma=
iling list
weirds@ietf.org
https://www.ietf.org/mailman/listinfo/weir=
ds


------=_Part_311612_752278053.1377594999595--

From marc.blanchet@viagenie.ca  Tue Aug 27 05:51:59 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA39E11E8319 for ; Tue, 27 Aug 2013 05:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Level: 
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnbxqM1lxf1A for ; Tue, 27 Aug 2013 05:51:59 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 166FB11E8318 for ; Tue, 27 Aug 2013 05:51:41 -0700 (PDT)
Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 700DA415A1; Tue, 27 Aug 2013 08:51:40 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet 
In-Reply-To: 
Date: Tue, 27 Aug 2013 08:51:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Ernie Dainow 
X-Mailer: Apple Mail (2.1508)
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 12:51:59 -0000

Le 2013-08-26 =E0 17:47, Ernie Dainow  a =E9crit :

> In 4.0 draft-ietf-weirds-rdap-query-06
>    ... When comparing entity names, servers SHOULD use the =
normalization rules
>    and code points specified by [I-D.ietf-precis-nickname] to =
determine
>    partial matches.
> =09
> I don't think the normalization rules referred to are appropriate for =
RDAP entity searches. The process in [I-D.ietf-precis-nickname] is =
designed to produce unique names in order to avoid conflict of =
identifiers in chat rooms or other applications. As such, it species a =
restricted set of Unicode characters, the FreeformClass. But an Entity =
name, such as the name of a Registrar, may be any Unicode string.

do you really mean it?  Unicode contains a lot of stuff that makes no =
sense for an entity.  Actually, the precis framework and the nickname =
part should allow any entity name to be written. It would be useful to =
see a contrary case.

Marc.

> Restricting names to a subset of Unicode means that it may not be =
possible to enter a valid name of a contact or organization.
>=20
> -Ernie
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds


From olaf@NLnetLabs.nl  Tue Aug 27 07:29:58 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF211E8197 for ; Tue, 27 Aug 2013 07:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6ALGpRepE2J for ; Tue, 27 Aug 2013 07:29:55 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E111E81A6 for ; Tue, 27 Aug 2013 07:29:54 -0700 (PDT)
Received: from dhcp-69.nlnetlabs.nl (dhcp-69.nlnetlabs.nl [213.154.224.69]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7REToPF012653 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 16:29:51 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl)
Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl
DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7REToPF012653
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1377613793; bh=p90Ni890twV2ZMIPZyLLZfLpJGFohWS+1Gr0awMbdLg=; h=Date:From:To:CC:Subject; b=Gz7RP7gUYKKttR2mSfEHMIVSV4dze5hjajXwEwpT+UK3WppiNBAkPOm5rtL0nu4aE UNe49X88gTeQToHfukr8lL49ZcojhjPJWfuhtq4Dgi+o2z2aOAvt5dAw6JzjiL6unU qPI4gGkK5CPNl6W9b1RmDws+Y0v7WTXIP9F8CFY4=
Message-ID: <521CB7DB.9030302@NLnetLabs.nl>
Date: Tue, 27 Aug 2013 16:29:47 +0200
From: Olaf Kolkman 
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: "weirds@ietf.org" 
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C4EB471C332A5823BE660DE"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Tue, 27 Aug 2013 16:29:51 +0200 (CEST)
Cc: "draft-ietf-weirds-using-http.all@tools.ietf.org" 
Subject: [weirds] Status: draft-ietf-weirds-using-http-07
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 27 Aug 2013 14:29:58 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0C4EB471C332A5823BE660DE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Colleagues,

To make sure we are all in sync on the status of this document.

The high level summary is: it is back at the WG.

The longer explanation:

We had some IESG pushback on draft-ietf-weirds-using-http-07. The high
level issue is that as a stand-alone document the document doesn't
provide sufficient context for the assessment of the full protocol
interactions. Reviewers (and hence implementers, is the argument) simply
lack context.

As far as I parse the IESG communication on this there doesn't seem to
be any major flaw except the lack of that context. The way that can be
solved is almost editorial: some normative references and connecting text=
=2E

That said, the IESG wants to see the document resubmitted in combination
with the query, json-response and the security document.

=46rom a WG perspective: we do not have to spend significant energy on th=
e
document since we should not need to revisit its content, except for the
minor issues that came up in the AD review.
The http document will be put on the shelf until the other documents are
done to and there will not be an explicit new working group last call,
unless Murray and I feel the changes are more than context-editorial.

--Olaf

Also see
https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ballot/343468=
/


--------------enig0C4EB471C332A5823BE660DE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJSHLfcAAoJEFRqER47aqpkIZQP/1UUhjloBOOR63zJG+wvH4qK
ZFLXlhfUcQNxq8WUQqBtcvAdVH//xQ/6vdeRJNHGC7GU330PgbaBe1jAIvple8d1
rSHQ8n/2OdTs8NnRLxxsuPyqyoKusQj7xHmzJwbNsrqXsbrH9QUzadxPRG+TlQ8W
7L/Wh6ayzf8Zr40gCWTlELJO+/zxrLj1jGFjWU0Ito2o7/HuwOyJzlVBkKonBbA4
4Y7sxiPbNfGSiBw2Swg6SlNNSLwGxu/2aUGHgrKYTIzswNskBbVCb9mn16K06Pk9
tKhMYxUJF9FvEIQlPp/Gnh2G1nTpxDEsGD4K9wK2NPFqu+pQr/KM9Lg8I4T1mO9g
LLyAepIiiJzJDQHfVsqLPs3PpEimlCaWagOctFVicbu63CdjETg2SJRYb9qwRJMJ
ofyC2KD6wSt+9dSOkpLWkukxu2levDelzK92tYx/45O4RFczZFtDAyQVxbh7+ZIj
4VLZGWjbT0mX7cMo6L+wYLx4i/5THylQsNepk1PxXyZ4SRgALO0lKE2XCRUKs4uJ
PUmC7/dLTjrkO+RbHvA0Hs5NkTroFamN6StzvjXkqUqzoUtQbveismyytlSe2WZP
dZY8PUt6dQufqL8W5qKxXIOjfVw/KD1Egn8v2MZuK4WN+U4rBCF3b/VKDCsSf1Dq
mtjyQy0WgitDyd9ysqiW
=DNb6
-----END PGP SIGNATURE-----

--------------enig0C4EB471C332A5823BE660DE--

From edainow@afilias.info  Tue Aug 27 07:51:07 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF09521F9D38 for ; Tue, 27 Aug 2013 07:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V93M0bmB1YNh for ; Tue, 27 Aug 2013 07:51:02 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88421F9D23 for ; Tue, 27 Aug 2013 07:51:02 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VEKbl-0002SO-5a for weirds@ietf.org; Tue, 27 Aug 2013 14:51:01 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VEKbl-0001Zq-5J for weirds@ietf.org; Tue, 27 Aug 2013 14:51:01 +0000
Received: by mail-ob0-f177.google.com with SMTP id f8so4735729obp.8 for ; Tue, 27 Aug 2013 07:50:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=mrTeaTxnxZ/9oFlL6nXzaij/dkW4lwMrwwpUtJ0A4x0=; b=MgwTmiYtBb/Pk7fQP25EVNMUHO3/E3rjyy66Ea3Jsu2shQqK3DScR+kWNVpFlAxLp5 ubOKBX08P/lWJWgZrX7zxPhC+0Bic7wk5anAXa341uCWYWP5Q4sUcqLmRQm3kOQK1R4+ T9TX0XrU2+IKnvM2i5ENCWvXVfm2M/0x9MGCp1M6oB35KarsB/cNVp5YXli33V0DGZ2N ad9FM7RloZxV3nmx07xOMnB70oDcrNmztwPO7qIp9lAGIwGWQNWWzsHNy6XQy/DqJxyb SwfQ2O7YmP8VL4lkAjbhlfS8xFq1fWaf/xJaEs0kqalhlbxg3JHPwekBQG2OjuTByo9G rrjQ==
X-Gm-Message-State: ALoCoQnS8KoljdoswyYHrvCtbXZAeDyQxihgx6wv4q9gsalP+I/efN30W7iNgney1awIRDUGLMlMr5DO8qHM8W96JTQL9onTzzWIAsl3fHU0aLYqQZSYgPRuRF5pDq7My74VvDMCB4ZO
X-Received: by 10.60.52.101 with SMTP id s5mr1546613oeo.56.1377615056133; Tue, 27 Aug 2013 07:50:56 -0700 (PDT)
X-Received: by 10.60.52.101 with SMTP id s5mr1546606oeo.56.1377615056006; Tue, 27 Aug 2013 07:50:56 -0700 (PDT)
Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id z5sm19906265obg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 07:50:55 -0700 (PDT)
Message-ID: <521CBCCA.4070906@afilias.info>
Date: Tue, 27 Aug 2013 10:50:50 -0400
From: Ernie Dainow 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Marc Blanchet 
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030509020902060802060108"
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 14:51:07 -0000

This is a multi-part message in MIME format.
--------------030509020902060802060108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 8/27/2013 8:51 AM, Marc Blanchet wrote:
> Le 2013-08-26 à 17:47, Ernie Dainow  a écrit :
>
>> In 4.0 draft-ietf-weirds-rdap-query-06
>>     ... When comparing entity names, servers SHOULD use the normalization rules
>>     and code points specified by [I-D.ietf-precis-nickname] to determine
>>     partial matches.
>> 	
>> I don't think the normalization rules referred to are appropriate for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is designed to produce unique names in order to avoid conflict of identifiers in chat rooms or other applications. As such, it species a restricted set of Unicode characters, the FreeformClass. But an Entity name, such as the name of a Registrar, may be any Unicode string.
> do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would be useful to see a contrary case.
I don't have a contrary case at hand. But since the approach we have 
been taking with RDAP is to support legacy Whois, there may be any kind 
of name already registered in service providers databases. RFC 5733, 
Extensible Provisioning Protocol (EPP) Contact Mapping, states in 2.3
     Individual and organizational names MAY be provided in either
     UTF-8 [RFC3629 ] or a subset of 
UTF-8 that can be represented in 7-bit ASCII
Unless we want to redefine what is allowed in the registration process, 
we should not restrict search.

-Ernie


--------------030509020902060802060108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 8/27/2013 8:51 AM, Marc Blanchet
      wrote:

    

    

      
Le 2013-08-26 à 17:47, Ernie Dainow <edainow@afilias.info> a écrit :



      

        
In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
	
I don't think the normalization rules referred to are appropriate for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is designed to produce unique names in order to avoid conflict of identifiers in chat rooms or other applications. As such, it species a restricted set of Unicode characters, the FreeformClass. But an Entity name, such as the name of a Registrar, may be any Unicode string.


      

      
do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would be useful to see a contrary case.

    

    I don't have a contrary case at hand. But since the approach we have
    been taking with RDAP is to support legacy Whois, there may be any
    kind of name already registered in service providers databases. RFC
    5733, Extensible Provisioning Protocol (EPP) Contact Mapping, states
    in 2.3

        Individual and organizational names MAY be provided in either 

        UTF-8 [RFC3629]
    or a subset of UTF-8 that can be represented in 7-bit ASCII

    Unless we want to redefine what is allowed in the registration
    process, we should not restrict search.

    

    -Ernie

    

  


--------------030509020902060802060108--

From marc.blanchet@viagenie.ca  Tue Aug 27 08:41:36 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4621721E80E6 for ; Tue, 27 Aug 2013 08:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omUHCrB7sPMu for ; Tue, 27 Aug 2013 08:41:35 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A221E80E5 for ; Tue, 27 Aug 2013 08:41:35 -0700 (PDT)
Received: from [IPv6:2620::230:c000:950:fd4:84ac:2e69] (unknown [IPv6:2620:0:230:c000:950:fd4:84ac:2e69]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D571641581; Tue, 27 Aug 2013 11:41:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC190860-132F-4C63-B2BE-55E343F9B3DF"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet 
In-Reply-To: <521CBCCA.4070906@afilias.info>
Date: Tue, 27 Aug 2013 11:41:33 -0400
Message-Id: 
References:   <521CBCCA.4070906@afilias.info>
To: Ernie Dainow 
X-Mailer: Apple Mail (2.1508)
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 15:41:36 -0000

--Apple-Mail=_DC190860-132F-4C63-B2BE-55E343F9B3DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Le 2013-08-27 =E0 10:50, Ernie Dainow  a =E9crit :

> On 8/27/2013 8:51 AM, Marc Blanchet wrote:
>> Le 2013-08-26 =E0 17:47, Ernie Dainow  a =E9crit =
:
>>=20
>>> In 4.0 draft-ietf-weirds-rdap-query-06
>>>    ... When comparing entity names, servers SHOULD use the =
normalization rules
>>>    and code points specified by [I-D.ietf-precis-nickname] to =
determine
>>>    partial matches.
>>> =09
>>> I don't think the normalization rules referred to are appropriate =
for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is =
designed to produce unique names in order to avoid conflict of =
identifiers in chat rooms or other applications. As such, it species a =
restricted set of Unicode characters, the FreeformClass. But an Entity =
name, such as the name of a Registrar, may be any Unicode string.
>> do you really mean it?  Unicode contains a lot of stuff that makes no =
sense for an entity.  Actually, the precis framework and the nickname =
part should allow any entity name to be written. It would be useful to =
see a contrary case.
> I don't have a contrary case at hand. But since the approach we have =
been taking with RDAP is to support legacy Whois, there may be any kind =
of name already registered in service providers databases. RFC 5733, =
Extensible Provisioning Protocol (EPP) Contact Mapping, states in 2.3
>     Individual and organizational names MAY be provided in either=20
>     UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in =
7-bit ASCII
> Unless we want to redefine what is allowed in the registration =
process, we should not restrict search.

The more the repertoire is large, including all kind of funny glyphs, =
the more complicated is to do good search and good results. So it is the =
advantage of everybody to leave out the ones that makes no sense.  For =
example, there are all sorts of punctuation, spaces, etc... that without =
any restriction or any profile (such as the precis work), will make the =
search on both client and server side more complicated and less useful =
from the user point of view.=20

Marc.

>=20
> -Ernie
>=20


--Apple-Mail=_DC190860-132F-4C63-B2BE-55E343F9B3DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

edainow@afilias.info> a =
=E9crit :

 =20
    
 =20
  

   =20
    
On 8/27/2013 8:51 AM, Marc Blanchet
      wrote:

    

    

      
Le 2013-08-26 =E0 17:47, Ernie Dainow <edainow@afilias.info> a =
=E9crit :



      

        
In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization =
rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
=09
I don't think the normalization rules referred to are appropriate for =
RDAP entity searches. The process in [I-D.ietf-precis-nickname] is =
designed to produce unique names in order to avoid conflict of =
identifiers in chat rooms or other applications. As such, it species a =
restricted set of Unicode characters, the FreeformClass. But an Entity =
name, such as the name of a Registrar, may be any Unicode string.


      

      
do you really mean it?  Unicode contains a lot of =
stuff that makes no sense for an entity.  Actually, the precis framework =
and the nickname part should allow any entity name to be written. It =
would be useful to see a contrary case.

    

    I don't have a contrary case at hand. But since the approach we have
    been taking with RDAP is to support legacy Whois, there may be any
    kind of name already registered in service providers databases. RFC
    5733, Extensible Provisioning Protocol (EPP) Contact Mapping, states
    in 2.3

        Individual and organizational names MAY be =
provided in either 

        UTF-8 [RFC3629]
    or a subset of UTF-8 that can be represented in 7-bit ASCII

    Unless we want to redefine what is allowed in the registration
    process, we should not restrict =
search.

The more the =
repertoire is large, including all kind of funny glyphs, the more =
complicated is to do good search and good results. So it is the =
advantage of everybody to leave out the ones that makes no sense. =
 For example, there are all sorts of punctuation, spaces, etc... =
that without any restriction or any profile (such as the precis work), =
will make the search on both client and server side more complicated and =
less useful from the user point of =
view. 

Marc.


    

    -Ernie

    

  




=

--Apple-Mail=_DC190860-132F-4C63-B2BE-55E343F9B3DF--

From edainow@afilias.info  Tue Aug 27 10:48:01 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD311E83C5 for ; Tue, 27 Aug 2013 10:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw4cHkRQk6Ks for ; Tue, 27 Aug 2013 10:47:56 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2311E83A1 for ; Tue, 27 Aug 2013 10:47:54 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VENMu-0005Vy-3V for weirds@ietf.org; Tue, 27 Aug 2013 17:47:52 +0000
Received: from mail-ve0-f177.google.com ([209.85.128.177]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VENMt-0000eQ-6M for weirds@ietf.org; Tue, 27 Aug 2013 17:47:52 +0000
Received: by mail-ve0-f177.google.com with SMTP id cz11so3342702veb.36 for ; Tue, 27 Aug 2013 10:47:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=1oQimmQm1XoI0GXxu0inl0PZlc7DfDwZE5htO/Ma3mU=; b=N9cBhl/suO/gh0+GF5RtrxaFcgIRZyMpk8/dGaCs+lLMfC9LDbYdzQ9JbwTYax6m4y A45b7VxBU3qXSNxUMd5npvs7t9FWzxoeqL/QhtawRuoHb40D2gqXfaHjUbmvrK4WE4Li yL1YRqIV4rqzEIZgg/ydo1wgCi0srPMV7SlrFy3+7nlE7m8Qnk+X0KTbdsg+Rue99Ys9 c9wzmkVF246pVRHBfL2m9leGHd9/pYgiu2FkHsq7StVhn98mlVeRt8pDYkJ/0Vzbe+my wBgjC5sk6qFeTqi3Yf5k31zOkEx7jILghlk/Qh5ed3AMPBZqpnUJZmcgmQ7JtSMtvIlm r6jw==
X-Gm-Message-State: ALoCoQm2QWDQSOXV6m13OGbVkEFNCw+QgbIXFPujS4ZgkO+LDBcIPSETMgxlz+nrP5NPYZzn/AXmc2Yz6JKLkGazWL7H/FJ2jGhyee46UiwSYEUrxHB+EpjjK4xi8PNcVIMBxnZ23Dm+
X-Received: by 10.221.44.136 with SMTP id ug8mr21193145vcb.13.1377625666557; Tue, 27 Aug 2013 10:47:46 -0700 (PDT)
X-Received: by 10.221.44.136 with SMTP id ug8mr21193082vcb.13.1377625665432; Tue, 27 Aug 2013 10:47:45 -0700 (PDT)
Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id xi5sm4107740vdb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 10:47:44 -0700 (PDT)
Message-ID: <521CE63B.104@afilias.info>
Date: Tue, 27 Aug 2013 13:47:39 -0400
From: Ernie Dainow 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Marc Blanchet 
References:   <521CBCCA.4070906@afilias.info> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050601040605070104030701"
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 17:48:01 -0000

This is a multi-part message in MIME format.
--------------050601040605070104030701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 8/27/2013 11:41 AM, Marc Blanchet wrote:
> Le 2013-08-27 à 10:50, Ernie Dainow  > a écrit :
>
>> On 8/27/2013 8:51 AM, Marc Blanchet wrote:
>>> Le 2013-08-26 à 17:47, Ernie Dainow  a écrit :
>>>
>>>> In 4.0 draft-ietf-weirds-rdap-query-06
>>>>     ... When comparing entity names, servers SHOULD use the normalization rules
>>>>     and code points specified by [I-D.ietf-precis-nickname] to determine
>>>>     partial matches.
>>>> 	
>>>> I don't think the normalization rules referred to are appropriate for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is designed to produce unique names in order to avoid conflict of identifiers in chat rooms or other applications. As such, it species a restricted set of Unicode characters, the FreeformClass. But an Entity name, such as the name of a Registrar, may be any Unicode string.
>>> do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would be useful to see a contrary case.
>> I don't have a contrary case at hand. But since the approach we have 
>> been taking with RDAP is to support legacy Whois, there may be any 
>> kind of name already registered in service providers databases. RFC 
>> 5733, Extensible Provisioning Protocol (EPP) Contact Mapping, states 
>> in 2.3
>>     Individual and organizational names MAY be provided in either
>>     UTF-8 [RFC3629 ] or a subset 
>> of UTF-8 that can be represented in 7-bit ASCII
>> Unless we want to redefine what is allowed in the registration 
>> process, we should not restrict search.
>
> The more the repertoire is large, including all kind of funny glyphs, 
> the more complicated is to do good search and good results. So it is 
> the advantage of everybody to leave out the ones that makes no sense. 
>  For example, there are all sorts of punctuation, spaces, etc... that 
> without any restriction or any profile (such as the precis work), will 
> make the search on both client and server side more complicated and 
> less useful from the user point of view.
>
Suppose a company registered as "A&P Big Names" where & is some obscure 
Unicode point not included in FreeformClass. If an RDAP user does a 
search for "A&*" they get an error, search string invalid. They now may 
try a search for "A*". They will probably get a truncated list, since 
all registries that support search limit the size to 50 or so entries. 
So with[I-D.ietf-precis-nickname] normalization, the user may not have 
any way to find an entity name.

I don't see how removing this normalization makes search more 
complicated. On the contrary it makes it easier; for the user, as this 
example shows; and for the server because it does not have to do a 
normalization check on the search string.

-Ernie

--------------050601040605070104030701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 8/27/2013 11:41 AM, Marc Blanchet
      wrote:

    

    

      
      

        
Le 2013-08-27 à 10:50, Ernie Dainow <edainow@afilias.info>
          a écrit :

        

        

          
          

            
On 8/27/2013 8:51 AM, Marc
              Blanchet wrote:

            

            

              
Le 2013-08-26 à 17:47, Ernie Dainow <edainow@afilias.info> a écrit :



              

                
In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
	
I don't think the normalization rules referred to are appropriate for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is designed to produce unique names in order to avoid conflict of identifiers in chat rooms or other applications. As such, it species a restricted set of Unicode characters, the FreeformClass. But an Entity name, such as the name of a Registrar, may be any Unicode string.


              

              
do you really mean it?  Unicode contains a lot of stuff that makes no sense for an entity.  Actually, the precis framework and the nickname part should allow any entity name to be written. It would be useful to see a contrary case.

            

            I don't have a contrary case at hand. But since the approach
            we have been taking with RDAP is to support legacy Whois,
            there may be any kind of name already registered in service
            providers databases. RFC 5733, Extensible Provisioning
            Protocol (EPP) Contact Mapping, states in 2.3

                Individual and organizational names MAY be provided in
            either 

                UTF-8 [RFC3629] or a subset of UTF-8 that can be
            represented in 7-bit ASCII

            Unless we want to redefine what is allowed in the
            registration process, we should not restrict search.

          

        

        


        

        
The more the repertoire is large, including all kind of
          funny glyphs, the more complicated is to do good search and
          good results. So it is the advantage of everybody to leave out
          the ones that makes no sense.  For example, there are all
          sorts of punctuation, spaces, etc... that without any
          restriction or any profile (such as the precis work), will
          make the search on both client and server side more
          complicated and less useful from the user point of view. 

        


        

      

    

    Suppose a company registered as "A&P Big Names" where & is
    some obscure Unicode point not included in FreeformClass. If an RDAP
    user does a search for "A&*" they get an error, search string
    invalid. They now may try a search for "A*". They will probably get
    a truncated list, since all registries that support search limit the
    size to 50 or so entries. So with[I-D.ietf-precis-nickname]
    normalization, the user may not have any way to find an entity name.

    

    I don't see how removing this normalization makes search more
    complicated. On the contrary it makes it easier; for the user, as
    this example shows; and for the server because it does not have to
    do a normalization check on the search string.

    

    -Ernie

  


--------------050601040605070104030701--

From marc.blanchet@viagenie.ca  Tue Aug 27 11:01:38 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8240821E8084 for ; Tue, 27 Aug 2013 11:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.765
X-Spam-Level: 
X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev+D0urJba2H for ; Tue, 27 Aug 2013 11:01:29 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0711E81B5 for ; Tue, 27 Aug 2013 11:01:26 -0700 (PDT)
Received: from h115.viagenie.ca (h115.viagenie.ca [206.123.31.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9C39C47104; Tue, 27 Aug 2013 14:01:15 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D120DE3-53A8-4078-85C0-00C9C02457FD"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet 
In-Reply-To: <521CE63B.104@afilias.info>
Date: Tue, 27 Aug 2013 14:01:09 -0400
Message-Id: <58274F77-626F-429B-B725-E5E2CB80F41A@viagenie.ca>
References:   <521CBCCA.4070906@afilias.info>  <521CE63B.104@afilias.info>
To: Ernie Dainow 
X-Mailer: Apple Mail (2.1508)
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Entity name search
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Aug 2013 18:01:39 -0000

--Apple-Mail=_3D120DE3-53A8-4078-85C0-00C9C02457FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2013-08-27 =E0 13:47, Ernie Dainow  a =E9crit :

>=20
> On 8/27/2013 11:41 AM, Marc Blanchet wrote:
>> Le 2013-08-27 =E0 10:50, Ernie Dainow  a =E9crit =
:
>>=20
>>> On 8/27/2013 8:51 AM, Marc Blanchet wrote:
>>>> Le 2013-08-26 =E0 17:47, Ernie Dainow  a =
=E9crit :
>>>>=20
>>>>> In 4.0 draft-ietf-weirds-rdap-query-06
>>>>>    ... When comparing entity names, servers SHOULD use the =
normalization rules
>>>>>    and code points specified by [I-D.ietf-precis-nickname] to =
determine
>>>>>    partial matches.
>>>>> =09
>>>>> I don't think the normalization rules referred to are appropriate =
for RDAP entity searches. The process in [I-D.ietf-precis-nickname] is =
designed to produce unique names in order to avoid conflict of =
identifiers in chat rooms or other applications. As such, it species a =
restricted set of Unicode characters, the FreeformClass. But an Entity =
name, such as the name of a Registrar, may be any Unicode string.
>>>> do you really mean it?  Unicode contains a lot of stuff that makes =
no sense for an entity.  Actually, the precis framework and the nickname =
part should allow any entity name to be written. It would be useful to =
see a contrary case.
>>> I don't have a contrary case at hand. But since the approach we have =
been taking with RDAP is to support legacy Whois, there may be any kind =
of name already registered in service providers databases. RFC 5733, =
Extensible Provisioning Protocol (EPP) Contact Mapping, states in 2.3
>>>     Individual and organizational names MAY be provided in either=20
>>>     UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in =
7-bit ASCII
>>> Unless we want to redefine what is allowed in the registration =
process, we should not restrict search.
>>=20
>> The more the repertoire is large, including all kind of funny glyphs, =
the more complicated is to do good search and good results. So it is the =
advantage of everybody to leave out the ones that makes no sense.  For =
example, there are all sorts of punctuation, spaces, etc... that without =
any restriction or any profile (such as the precis work), will make the =
search on both client and server side more complicated and less useful =
from the user point of view.=20
>>=20
> Suppose a company registered as "A&P Big Names" where & is some =
obscure Unicode point not included in FreeformClass. If an RDAP user =
does a search for "A&*" they get an error, search string invalid. They =
now may try a search for "A*". They will probably get a truncated list, =
since all registries that support search limit the size to 50 or so =
entries. So with[I-D.ietf-precis-nickname] normalization, the user may =
not have any way to find an entity name.

nickname is one of the profile of precis. One can define a new profile =
based on the framework to fill its needs. That is the whole purpose of =
the precis framework.  So don't stick on precis-nickname. My point is =
that we ought to have some profile that defines what is possible, we =
can't accept everything.

>=20
> I don't see how removing this normalization makes search more =
complicated. On the contrary it makes it easier; for the user, as this =
example shows; and for the server because it does not have to do a =
normalization check on the search string.

normalization seems to me absolutely necessary. Moreover it is not =
enough. Therefore, I don't see other solution than defining a precis =
profile, if the current ones are not useful. (I'm happy to start a draft =
on this if people agree with the idea).  The next question is then who =
implements it: the server has to, the remaining question is how much the =
client shall do.

Marc.

>=20
> -Ernie


--Apple-Mail=_3D120DE3-53A8-4078-85C0-00C9C02457FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

edainow@afilias.info> a =
=E9crit :

 =20
    
 =20
  

    

    
On 8/27/2013 11:41 AM, Marc Blanchet
      wrote:

    

    

      
      

        
Le 2013-08-27 =E0 10:50, Ernie Dainow <edainow@afilias.info>
          a =E9crit :

        

        

          
          

            
On 8/27/2013 8:51 AM, Marc
              Blanchet wrote:

            

            

              
Le 2013-08-26 =E0 17:47, Ernie Dainow <edainow@afilias.info> a =
=E9crit :



              

                
In 4.0 draft-ietf-weirds-rdap-query-06
   ... When comparing entity names, servers SHOULD use the normalization =
rules
   and code points specified by [I-D.ietf-precis-nickname] to determine
   partial matches.
=09
I don't think the normalization rules referred to are appropriate for =
RDAP entity searches. The process in [I-D.ietf-precis-nickname] is =
designed to produce unique names in order to avoid conflict of =
identifiers in chat rooms or other applications. As such, it species a =
restricted set of Unicode characters, the FreeformClass. But an Entity =
name, such as the name of a Registrar, may be any Unicode string.


              

              
do you really mean it?  Unicode contains a =
lot of stuff that makes no sense for an entity.  Actually, the precis =
framework and the nickname part should allow any entity name to be =
written. It would be useful to see a contrary case.

            

            I don't have a contrary case at hand. But since the approach
            we have been taking with RDAP is to support legacy Whois,
            there may be any kind of name already registered in service
            providers databases. RFC 5733, Extensible Provisioning
            Protocol (EPP) Contact Mapping, states in 2.3

                Individual and organizational names MAY =
be provided in
            either 

                UTF-8 [RFC3629] or a subset of UTF-8 that can be
            represented in 7-bit ASCII

            Unless we want to redefine what is allowed in the
            registration process, we should not restrict search.

          

        

        


        

        
The more the repertoire is large, including all kind of
          funny glyphs, the more complicated is to do good search and
          good results. So it is the advantage of everybody to leave out
          the ones that makes no sense.  For example, there are all
          sorts of punctuation, spaces, etc... that without any
          restriction or any profile (such as the precis work), will
          make the search on both client and server side more
          complicated and less useful from the user point of =
view. 

        


        

      

    

    Suppose a company registered as "A&P Big Names" where & is
    some obscure Unicode point not included in FreeformClass. If an RDAP
    user does a search for "A&*" they get an error, search string
    invalid. They now may try a search for "A*". They will probably get
    a truncated list, since all registries that support search limit the
    size to 50 or so entries. So with[I-D.ietf-precis-nickname]
    normalization, the user may not have any way to find an entity =
name.

nickname is one of the =
profile of precis. One can define a new profile based on the framework =
to fill its needs. That is the whole purpose of the precis framework. =
 So don't stick on precis-nickname. My point is that we ought to =
have some profile that defines what is possible, we can't accept =
everything.


    

    I don't see how removing this normalization makes search more
    complicated. On the contrary it makes it easier; for the user, as
    this example shows; and for the server because it does not have to
    do a normalization check on the search =
string.

normalization seems to =
me absolutely necessary. Moreover it is not enough. Therefore, I don't =
see other solution than defining a precis profile, if the current ones =
are not useful. (I'm happy to start a draft on this if people agree with =
the idea).  The next question is then who implements it: the server =
has to, the remaining question is how much the client shall =
do.

Marc.


    

    -Ernie

  




=

--Apple-Mail=_3D120DE3-53A8-4078-85C0-00C9C02457FD--

From edainow@afilias.info  Tue Aug 27 13:55:17 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7E11E81FB for ; Tue, 27 Aug 2013 13:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEHV3g+2S-C5 for ; Tue, 27 Aug 2013 13:55:02 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC2711E81F0 for ; Tue, 27 Aug 2013 13:55:02 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1VEQI2-00064o-3s for weirds@ietf.org; Tue, 27 Aug 2013 20:55:02 +0000
Received: from mail-lb0-f175.google.com ([209.85.217.175]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VEQI2-0006Wm-3J for weirds@ietf.org; Tue, 27 Aug 2013 20:55:02 +0000
Received: by mail-lb0-f175.google.com with SMTP id y6so3007892lbh.20 for ; Tue, 27 Aug 2013 13:54:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=T9Zn5cqJNtmrQEGcOhafnpzOChqHiGauv0vG9O3JabA=; b=cn4GWQH49noMqAMHFwlCaGwUPO8YplKs5s34vwBTbekrTlNIjGgY/bFP0aOtqdJLGJ G9kuaT+nJ/UOUs+564S/v4x06f8x+4bPnx2sYybxewsz+k56kxcK2AiIg7L5ajtCni9S x1JhskWzRT36mqyhaoXS31QHr8MDiwFq+KdrHXf8E5Ja7PuqYFjgSjadIOfhlA9wq08n qgPHBw8O7HHfqfZi6hhrH3AUjXZ3o6+zEKLExAh3wsW6x0+gPnx3OvfPPY/+9L78Cn47 sv+N6+pXRP0RQhj1F+gZw1LOn8/qTv6CDCX+IXnGXxSVAMwXznkzswpAOdlHVJWl81Hn UYRA==
X-Received: by 10.152.203.233 with SMTP id kt9mr4030882lac.29.1377636895702; Tue, 27 Aug 2013 13:54:55 -0700 (PDT)
X-Gm-Message-State: ALoCoQmHzd+9Tt71gasdNBk2BS6WGDbmCNjY8eLIKP37Epju4nn9/8Ark+rdJOCHhqBGGN8AHieiPI8m/M+s18Ynb+aeHjc/fJ920d5y15REajywSheYWjw6/Oa3zxzf0+i9V6BMOkMY
MIME-Version: 1.0
X-Received: by 10.152.203.233 with SMTP id kt9mr4030874lac.29.1377636895599; Tue, 27 Aug 2013 13:54:55 -0700 (PDT)
Received: by 10.112.202.129 with HTTP; Tue, 27 Aug 2013 13:54:55 -0700 (PDT)
Date: Tue, 27 Aug 2013 16:54:55 -0400
Message-ID: 
From: Ernie Dainow 
To: "weirds@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11345984cabfca04e4f415b9
Subject: [weirds] Variants search results
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 27 Aug 2013 20:55:17 -0000

--001a11345984cabfca04e4f415b9
Content-Type: text/plain; charset=ISO-8859-1

Current drafts don't specify anything about handling variants on a domain
search. If an RDAP user is searching for a domain, they are probably
interested in names that are "taken" because they are variants, as well as
registered names. There are different ways this could be handled.

1) Integrate variants into the domain search result. If a result is a
variant rather than a registered domain, it should be indicated as such,
for example by adding the variantNames array in the result list:
     "domains" :
     [
       {
         "handle" : "1-XXXX",
 "ldhName" : "xn--fo1-cka.example",
 "unicodeName" : "foo1.example"
         "variantNames" :
         [
           {
             "ldhName" : "xn--fo2-cka.example",
             "unicodeName" : "foo2.example"
           },
   ...
  ],

It's possible that the search pattern matches the domain and not the
variant, or vice versa. Several actions are possible here:
a) The same full result (domain and all variants), as would be returned in
a domain lookup, is returned in either case.
b) If the search pattern matches the domain but not the variant, the
variant is not returned.
c) If the search pattern matches the variant but not the domain, I think it
is necessary to return the parent domain as well as the variant. Otherwise
the user cannot follow up with other searches or lookups to get more
information about the registration.

2) Have a separate search query specifically for variants. This may make
the results more straightforward than 1), but may be less convenient for
the user who has to remember to send two queries if they are interested in
variants in the result.

3) no variants, leave for a later RDAP release with "advanced" search

thoughts?

-Ernie

--001a11345984cabfca04e4f415b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Current drafts don't specify anything about handl=
ing variants on a domain search. If an RDAP user is searching for a domain,=
 they are probably interested in names that are "taken" because t=
hey are variants, as well as registered names. There are different ways thi=
s could be handled.



1) Integrate variants into the domain search result. If=
 a result is a variant rather than a registered domain, it should be indica=
ted as such, for example by adding the variantNames array in the result lis=
t:


=A0 =A0 =A0"domains" :
=A0 =A0 =A0[
=A0 =
=A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0"handle" : "1-XXXX=
",
	=A0&qu=
ot;ldhName" : "xn--fo1-cka.example",


	=A0"unicodeNam=
e" : "foo1.example"
=A0 =A0 =A0 =A0 =A0"varia=
ntNames" :
=A0 =A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =
=A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0"ldhName" : "x=
n--fo2-cka.example",


=A0 =A0 =A0 =A0 =A0 =A0 =A0"unicodeName" : "foo2.exampl=
e"
=A0 =A0 =A0 =A0 =A0 =A0},
	=A0 =A0...
	=A0 ],



It's possible that the search pattern matches the d=
omain and not the variant, or vice versa. Several actions are possible here=
:
a) The same full result (domain and all variants), as would be =
returned in a domain lookup, is returned in either case.


b) If the search pattern matches the domain but not the variant, the v=
ariant is not returned.
c) If the search pattern matches the vari=
ant but not the domain, I think it is necessary to return the parent domain=
 as well as the variant. Otherwise the user cannot follow up with other sea=
rches or lookups to get more information about the registration.


		 =A0
2) =
Have a separate search query specifically for variants. This may make the r=
esults more straightforward than 1), but may be less convenient for the use=
r who has to remember to send two queries if they are interested in variant=
s in the result.



3) no variants, leave for a later RDAP release with &qu=
ot;advanced" search

thoughts?

<=
/div>
-Ernie



--001a11345984cabfca04e4f415b9--

From mail@edmon.asia  Tue Aug 27 17:51:42 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8046611E8241 for ; Tue, 27 Aug 2013 17:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOjqhye4EsMT for ; Tue, 27 Aug 2013 17:51:37 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 69C4A11E8116 for ; Tue, 27 Aug 2013 17:51:36 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id kp13so5455425pab.7 for ; Tue, 27 Aug 2013 17:51:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=DWR31bBXNJZHXgg15B3drRprEvHEY0PYbZWuHe2pakY=; b=JxVIgtraB/BAsMiQgPlvcJuiLUe0GBY0cCNyYtdOB9uizrKBx4d6g5ktHHwoU9ypMr s5rBWUE//+R8wT1h//Fs/ijUfN9rOI1nZseWlfmwEw9oP+SppQOKDXN4e0UjcWPnAvSC f27pL4Uefxo4wIOCENvk/xrhEeQPih4OZAD8mXK7x2KQbrffCgJE3Q48FWIbMcPmr6ni ijBvb9Tjk6z0FOse6UY/lStRZ05xaKy8VBm+J+IL5CiRkRBO8KAM/H6x53KZaiQNDAz/ p801tN2IzHQRTuZ5vHZr1VX+FWLUIGaisZpFc4Ermz5MvnNer5KolpVCSKkWh5uDahEo Xgdg==
X-Gm-Message-State: ALoCoQkNxGSqabaqhfvPQAtcR2h9e5cKp0RiQTDoBbPt4WOWXISI311nrpHWiJQ+9vno1u52GC+o
X-Received: by 10.66.251.166 with SMTP id zl6mr12022275pac.164.1377651095959;  Tue, 27 Aug 2013 17:51:35 -0700 (PDT)
Received: from VAIO (123202234237.ctinets.com. [123.202.234.237]) by mx.google.com with ESMTPSA id ot4sm29833994pac.17.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 17:51:34 -0700 (PDT)
From: "Edmon Chung" 
To: "'Ernie Dainow'" , 
References: 
In-Reply-To: 
Date: Wed, 28 Aug 2013 08:51:42 +0800
Message-ID: <02dd01cea388$c555b010$50011030$@asia>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DE_01CEA3CB.D378F010"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6jZ75NAEe7lZp+S/Sco2OuyU+NggAINE2g
Content-Language: en-ca
Subject: Re: [weirds] Variants search results
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 28 Aug 2013 00:51:43 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02DE_01CEA3CB.D378F010
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In a registry perspective, I think 1. The same full result, makes most sense
as the Primary IDN and its IDN Variants are considered one allocation.

Edmon

 

 

 

From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of
Ernie Dainow
Sent: Wednesday, August 28, 2013 4:55 AM
To: weirds@ietf.org
Subject: [weirds] Variants search results

 

Current drafts don't specify anything about handling variants on a domain
search. If an RDAP user is searching for a domain, they are probably
interested in names that are "taken" because they are variants, as well as
registered names. There are different ways this could be handled.

 

1) Integrate variants into the domain search result. If a result is a
variant rather than a registered domain, it should be indicated as such, for
example by adding the variantNames array in the result list:

     "domains" :

     [

       {

         "handle" : "1-XXXX",

           "ldhName" : "xn--fo1-cka.example",

           "unicodeName" : "foo1.example"

         "variantNames" :

         [

           {

             "ldhName" : "xn--fo2-cka.example",

             "unicodeName" : "foo2.example"

           },

             ...

            ],

 

It's possible that the search pattern matches the domain and not the
variant, or vice versa. Several actions are possible here:

a) The same full result (domain and all variants), as would be returned in a
domain lookup, is returned in either case.

b) If the search pattern matches the domain but not the variant, the variant
is not returned.

c) If the search pattern matches the variant but not the domain, I think it
is necessary to return the parent domain as well as the variant. Otherwise
the user cannot follow up with other searches or lookups to get more
information about the registration.

                       

2) Have a separate search query specifically for variants. This may make the
results more straightforward than 1), but may be less convenient for the
user who has to remember to send two queries if they are interested in
variants in the result.

 

3) no variants, leave for a later RDAP release with "advanced" search

 

thoughts?

 

-Ernie

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6612 - Release Date: 08/27/13


------=_NextPart_000_02DE_01CEA3CB.D378F010
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















In
a registry perspective, I think 1. The same full result, makes most =
sense as
the Primary IDN and its IDN Variants are considered one =
allocation.



Edmon



 



 



 












From:=
 =
weirds-bounces@ietf.org
[mailto:weirds-bounces@ietf.org] On Behalf Of Ernie Dainow

Sent: Wednesday, August 28, 2013 4:55 AM

To: weirds@ietf.org

Subject: [weirds] Variants search results









 









Current drafts don't specify anything about =
handling
variants on a domain search. If an RDAP user is searching for a domain, =
they
are probably interested in names that are "taken" because they =
are
variants, as well as registered names. There are different ways this =
could be
handled.









 









1) Integrate variants into the domain search =
result. If a
result is a variant rather than a registered domain, it should be =
indicated as
such, for example by adding the variantNames array in the result =
list:









     "domains" =
:









     [









       {









        =
 "handle" :
"1-XXXX",









          =
 "ldhName" :
"xn--fo1-cka.example",









          =
 "unicodeName" :
"foo1.example"









        =
 "variantNames" :









         [









          =
 {









           
 "ldhName" : =
"xn--fo2-cka.example",









           
 "unicodeName" : "foo2.example"









          =
 },









          =
   ...









          =
  ],









 









It's possible that the search pattern matches the =
domain and
not the variant, or vice versa. Several actions are possible =
here:









a) The same full result (domain and all variants), =
as would
be returned in a domain lookup, is returned in either =
case.









b) If the search pattern matches the domain but not =
the
variant, the variant is not returned.









c) If the search pattern matches the variant but =
not the
domain, I think it is necessary to return the parent domain as well as =
the
variant. Otherwise the user cannot follow up with other searches or =
lookups to
get more information about the registration.









         &=
nbsp;            =
 









2) Have a separate search query specifically for =
variants.
This may make the results more straightforward than 1), but may be less
convenient for the user who has to remember to send two queries if they =
are
interested in variants in the result.









 









3) no variants, leave for a later RDAP release with
"advanced" search









 









thoughts?









 









-Ernie









 


















No
virus found in this message.

Checked by AVG - www.avg.com

Version: 2013.0.3392 / Virus Database: 3211/6612 - Release Date: =
08/27/13












------=_NextPart_000_02DE_01CEA3CB.D378F010--


From zhoulinlin@cnnic.cn  Wed Aug 28 02:13:44 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11921E80B2 for ; Wed, 28 Aug 2013 02:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Burl0CQdZFQr for ; Wed, 28 Aug 2013 02:13:39 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 04E7321E8087 for ; Wed, 28 Aug 2013 02:13:38 -0700 (PDT)
X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn
Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 28 Aug 2013 17:13:31 +0800
From: "Linlin Zhou" 
To: "'John Levine'" , 
References: <521BC58B.4030403@afilias.info> <20130826213425.82624.qmail@joyce.lan>
In-Reply-To: <20130826213425.82624.qmail@joyce.lan>
Date: Wed, 28 Aug 2013 17:13:29 +0800
Message-ID: <019901cea3ce$dc9a1900$95ce4b00$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6ipCgDbtqNiC1CR7iUHwRt1VvqOgBJvU9Q
Content-Language: zh-cn
Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Aug 2013 09:13:44 -0000

Store the data in databases with the NFC normalization form and search =
for "abc*" or "ab=C3=A7*" also in NFC, I feel this is the most =
straightforward way for this issue.

Regards,
Linlin

> -----Original Message-----
> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On =
Behalf Of
> John Levine
> Sent: Tuesday, August 27, 2013 5:34 AM
> To: weirds@ietf.org
> Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response-05
>=20
> >I believe most people doing an RDAP search for "se*" would expect to
> >get the whole list. With NFC normalization, they will only get
> >     semaine
> >     semblant
>=20
> Unfortunately, this is a tarpit.  While the French consider e and  to =
be
> approximately the same, the Swedes consider a, , and  to be as =
different as a,
> b, and c.
>=20
> I think the least bad we can do is to say that searches are against =
NFC strings,
> and if you want to find accented characters, you have to search for =
them.
>=20
> R's,
> John


From superuser@gmail.com  Thu Aug 29 11:40:59 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507EA21E8053 for ; Thu, 29 Aug 2013 11:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level: 
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDlTKSgCD6JR for ; Thu, 29 Aug 2013 11:40:58 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id E8ACF11E8131 for ; Thu, 29 Aug 2013 11:40:57 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id c11so779908wgh.27 for ; Thu, 29 Aug 2013 11:40:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0f0Gfdh29rWmzr8PPvrmSmctQ+qjQan1v94AVEsd+yE=; b=D+hiVMH146eLDl7tDZ/lUmwWNT7XrkRVoC96JZInEKH1gtHhDY9sCov7IKJwTFp8l0 IVcQoGo+HjRVSL5zVbJH7shKxYlqSMLdt4gnuSdeq3wjnUYRglO+fzx3WpGmad//i1ek oHzDYTGD4zHMYwrifZawTwFa65tN/bltRI9TA1DJEJsCZGMPTxOLQG3NQEzsvKpLuMIY sT/Hn6bdtU1EdrPfaN84DJk8FiR5Uhi6k6rqsWnp0fH9jbMEsEQolH69poomVWrdHTJC JhcO44SIuhRfWW6q2yAWygygVzPFZQi3N51FVDieBHVyVWZpG2azdKR3N0ca62qTmcV3 A69Q==
MIME-Version: 1.0
X-Received: by 10.180.184.107 with SMTP id et11mr16164208wic.60.1377801657081;  Thu, 29 Aug 2013 11:40:57 -0700 (PDT)
Received: by 10.180.75.144 with HTTP; Thu, 29 Aug 2013 11:40:57 -0700 (PDT)
In-Reply-To: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net>
References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net>
Date: Thu, 29 Aug 2013 11:40:57 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: "weirds@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c227ee57679f04e51a7222
Subject: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 18:40:59 -0000

--001a11c227ee57679f04e51a7222
Content-Type: text/plain; charset=ISO-8859-1

FYI, this is likely to be adopted by APPSAWG.  It may affect our URI
specification stuff, which I think drew a DISCUSS during IESG evaluation.

-MSK

---------- Forwarded message ----------
From: Mark Nottingham 
Date: Wed, Aug 28, 2013 at 9:03 PM
Subject: Standardising Structure in URIs
To: Apps Discuss 
Cc: Murray Kucherawy , Salvatore Loreto <
salvatore.loreto@ericsson.com>, Barry Leiba 


I started this draft during the Berlin meeting, and since have had a lot of
positive feedback.

Would the APPSAWG be interested in taking it on as a WG document?

Regards,


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for
draft-nottingham-uri-get-off-my-lawn-02.txt
> Date: 29 August 2013 2:01:29 PM AEST
> To: Mark Nottingham 
>
>
> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
>
> Filename:      draft-nottingham-uri-get-off-my-lawn
> Revision:      02
> Title:                 Standardising Structure in URIs
> Creation date:         2013-08-29
> Group:                 Individual Submission
> Number of pages: 8
> URL:
http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02.txt
> Status:
http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn
> Htmlized:
http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02
> Diff:
http://www.ietf.org/rfcdiff?url2=draft-nottingham-uri-get-off-my-lawn-02
>
> Abstract:
>   Sometimes, it is attractive to add features to protocols or
>   applications by specifying a particular structure for URIs (or parts
>   thereof).  This document cautions against this practice in standards
>   (sometimes called "URI Squatting").
>
>
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

--
Mark Nottingham   http://www.mnot.net/

--001a11c227ee57679f04e51a7222
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


FYI, this is likely to be adopted by APPSAWG.=A0 It m=
ay affect our URI specification stuff, which I think drew a DISCUSS during =
IESG evaluation.

-MSK


---------- Forwarded message ----------
From: Mark Nottingham <mnot@mnot.net>
Date: Wed, Aug 28, 2013 at 9:03 PM
S=
ubject: Standardising Structure in URIs

To: Apps Discuss <discuss@apps.=
ietf.org>
Cc: Murray Kucherawy <superuser@gmail.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Bar=
ry Leiba <barryleiba@computer=
.org>



I started this draft during the Berlin meeting, and since have had =
a lot of positive feedback.



Would the APPSAWG be interested in taking it on as a WG document?



Regards,





Begin forwarded message:



> From: internet-drafts@ietf=
.org

> Subject: New Version Notification for draft-nottingham-uri-get-off-my-=
lawn-02.txt

> Date: 29 August 2013 2:01:29 PM AEST

> To: Mark Nottingham <mnot@mnot.net=
>

>

>

> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt

> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.

>

> Filename: =A0 =A0 =A0draft-nottingham-uri-get-off-my-lawn

> Revision: =A0 =A0 =A002

> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Standardising Structure in URIs=


> Creation date: =A0 =A0 =A0 =A0 2013-08-29

> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission

> Number of pages: 8

> URL: =A0 =A0 =A0 =A0 =A0 =A0 http:/=
/www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02.txt

> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.=
ietf.org/doc/draft-nottingham-uri-get-off-my-lawn

> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/h=
tml/draft-nottingham-uri-get-off-my-lawn-02

> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.=
ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-lawn-02

>

> Abstract:

> =A0 Sometimes, it is attractive to add features to protocols or

> =A0 applications by specifying a particular structure for URIs (or par=
ts

> =A0 thereof). =A0This document cautions against this practice in stand=
ards

> =A0 (sometimes called "URI Squatting").

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretariat

>



--

Mark Nottingham =A0 http=
://www.mnot.net/











--001a11c227ee57679f04e51a7222--

From andy@arin.net  Thu Aug 29 12:34:47 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C111E8155 for ; Thu, 29 Aug 2013 12:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level: 
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbqttdJabOmJ for ; Thu, 29 Aug 2013 12:34:43 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B748811E814C for ; Thu, 29 Aug 2013 12:34:42 -0700 (PDT)
Received: by smtp2.arin.net (Postfix, from userid 323) id 684D621368F; Thu, 29 Aug 2013 15:34:42 -0400 (EDT)
Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 7370321367F; Thu, 29 Aug 2013 15:34:41 -0400 (EDT)
Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 29 Aug 2013 15:34:35 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 15:34:35 -0400
From: Andy Newton 
To: "Murray S. Kucherawy" , "weirds@ietf.org" 
Thread-Topic: [weirds] Fwd: Standardising Structure in URIs
Thread-Index: AQHOpOdRgi8YK4PS80uIvGyBrehO8pmsk8MA
Date: Thu, 29 Aug 2013 19:34:34 +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.3.6.130613
x-originating-ip: [10.1.1.56]
Content-Type: multipart/alternative; boundary="_000_CE4519C827EFBandyarinnet_"
MIME-Version: 1.0
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 19:34:47 -0000

--_000_CE4519C827EFBandyarinnet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is it possible we can get the draft author to address our specifications? I=
 agree with some of the content of that draft, but other bits seem to say "=
THOU MUST use URI Templates". That is an issue that has been discussed a co=
uple of times here, but it seems to add little utility and causes more comp=
lexity on the client in addition to additional roundtrips.

-andy

From: "Murray S. Kucherawy" >
Date: Thursday, August 29, 2013 2:40 PM
To: "weirds@ietf.org" >
Subject: [weirds] Fwd: Standardising Structure in URIs

FYI, this is likely to be adopted by APPSAWG.  It may affect our URI specif=
ication stuff, which I think drew a DISCUSS during IESG evaluation.

-MSK

---------- Forwarded message ----------
From: Mark Nottingham >
Date: Wed, Aug 28, 2013 at 9:03 PM
Subject: Standardising Structure in URIs
To: Apps Discuss >
Cc: Murray Kucherawy >, Sal=
vatore Loreto >, Barry Leiba >


I started this draft during the Berlin meeting, and since have had a lot of=
 positive feedback.

Would the APPSAWG be interested in taking it on as a WG document?

Regards,


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-nottingham-uri-get-off-my-law=
n-02.txt
> Date: 29 August 2013 2:01:29 PM AEST
> To: Mark Nottingham >
>
>
> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
>
> Filename:      draft-nottingham-uri-get-off-my-lawn
> Revision:      02
> Title:                 Standardising Structure in URIs
> Creation date:         2013-08-29
> Group:                 Individual Submission
> Number of pages: 8
> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-uri=
-get-off-my-lawn-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-nottingham-uri-get=
-off-my-lawn
> Htmlized:        http://tools.ietf.org/html/draft-nottingham-uri-get-off-=
my-lawn-02
> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-=
get-off-my-lawn-02
>
> Abstract:
>   Sometimes, it is attractive to add features to protocols or
>   applications by specifying a particular structure for URIs (or parts
>   thereof).  This document cautions against this practice in standards
>   (sometimes called "URI Squatting").
>
>
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

--
Mark Nottingham   http://www.mnot.net/







--_000_CE4519C827EFBandyarinnet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <9DEA122BBC6C8D40862ABE3F8C86359A@corp.arin.net>
Content-Transfer-Encoding: quoted-printable







Is it possible we can get the draft author to address our specificatio=
ns? I agree with some of the content of that draft, but other bits seem to =
say "THOU MUST use URI Templates". That is an issue that has been=
 discussed a couple of times here, but it
 seems to add little utility and causes more complexity on the client in ad=
dition to additional roundtrips.







-andy









From: "Murray S. Kucherawy&quo=
t; <superuser@gmail.com>
Date: Thursday, August 29, 2013 2:4=
0 PM

To: "weirds@ietf.org" <=
weirds@ietf.org>

Subject: [weirds] Fwd: Standardisin=
g Structure in URIs

















FYI, this is likely to be adopted by APPSAWG.  It may affect our =
URI specification stuff, which I think drew a DISCUSS during IESG evaluatio=
n.





-MSK







---------- Forwarded message ----------

From: Mark Nottingham &=
lt;mnot@mnot.net>

Date: Wed, Aug 28, 2013 at 9:03 PM

Subject: Standardising Structure in URIs

To: Apps Discuss <discuss@apps.=
ietf.org>

Cc: Murray Kucherawy <superuser@g=
mail.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Barry Leiba <barryleiba@computer.org>





I started this draft during the Berlin meeting, and since have had a lot of=
 positive feedback.



Would the APPSAWG be interested in taking it on as a WG document?



Regards,





Begin forwarded message:



> From: internet-drafts@ietf=
.org

> Subject: New Version Notification for draft-nottingham-uri-get-off-my-=
lawn-02.txt

> Date: 29 August 2013 2:01:29 PM AEST

> To: Mark Nottingham <mnot@mnot.net=
>

>

>

> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt

> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.

>

> Filename:      draft-nottingham-uri-get-off-my-lawn

> Revision:      02

> Title:                 Standar=
dising Structure in URIs

> Creation date:         2013-08-29

> Group:                 Individ=
ual Submission

> Number of pages: 8

> URL:             
http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02=
.txt

> Status:          http=
://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn

> Htmlized:        http://tool=
s.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02

> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-l=
awn-02

>

> Abstract:

>   Sometimes, it is attractive to add features to protocols or

>   applications by specifying a particular structure for URIs (or =
parts

>   thereof).  This document cautions against this practice in=
 standards

>   (sometimes called "URI Squatting").

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at 
tools.ietf.org.

>

> The IETF Secretariat

>



--

Mark Nottingham   h=
ttp://www.mnot.net/





































--_000_CE4519C827EFBandyarinnet_--

From superuser@gmail.com  Thu Aug 29 12:35:31 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4336621F9C13 for ; Thu, 29 Aug 2013 12:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level: 
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aplk58iCkzXg for ; Thu, 29 Aug 2013 12:35:30 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE2F21F9BB6 for ; Thu, 29 Aug 2013 12:35:29 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id l12so962239wiv.13 for ; Thu, 29 Aug 2013 12:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SOSfG+jjA2iKUSXhjuFCfpC1xXVdzqDn90S+dBP79JA=; b=0w6RY0ysxBtNF/1Lw2xHZZ0WjShrI/EDEfzN2t4MrThh4r3Sp0Pkv6jhzLUIGb6HND KAd/h8bjIPQqlb707tnblfk+aNtVErSEaXjeN2HFPJ3jK+NHH+bhPyBdbi8B795spJP5 8ZPfh787z/QVShOaDOfngBSeILQmstwoGWqWyByEg9KqTbQWXioZ2KdfxC3es9026wUj vrHYlZ5JaSL9+ny/QGd99Xe/Rq7NJfOzC+30CPBJtEYQCJLxQAZD3+JoSxpn4/kKgbg9 Z78wm1ZNy6fwH4ljOS51CGvYFMGah9btx8t4wcKtEXY0Ez11ItYMacdo1q3NK2Ilt4+o 804w==
MIME-Version: 1.0
X-Received: by 10.180.189.9 with SMTP id ge9mr1350078wic.52.1377804929116; Thu, 29 Aug 2013 12:35:29 -0700 (PDT)
Received: by 10.180.75.144 with HTTP; Thu, 29 Aug 2013 12:35:29 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 29 Aug 2013 12:35:29 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Andy Newton 
Content-Type: multipart/alternative; boundary=001a11c343025eb11d04e51b35a7
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 19:35:31 -0000

--001a11c343025eb11d04e51b35a7
Content-Type: text/plain; charset=ISO-8859-1

As it will be a working group item, it's certainly open for discussion.  If
you'd like to broach the topic on apps-discuss now, please feel free to do
so.

-MSK


On Thu, Aug 29, 2013 at 12:34 PM, Andy Newton  wrote:

>  Is it possible we can get the draft author to address our
> specifications? I agree with some of the content of that draft, but other
> bits seem to say "THOU MUST use URI Templates". That is an issue that has
> been discussed a couple of times here, but it seems to add little utility
> and causes more complexity on the client in addition to additional
> roundtrips.
>
>  -andy
>
>   From: "Murray S. Kucherawy" 
> Date: Thursday, August 29, 2013 2:40 PM
> To: "weirds@ietf.org" 
> Subject: [weirds] Fwd: Standardising Structure in URIs
>
>    FYI, this is likely to be adopted by APPSAWG.  It may affect our URI
> specification stuff, which I think drew a DISCUSS during IESG evaluation.
>
>  -MSK
>
> ---------- Forwarded message ----------
> From: Mark Nottingham 
> Date: Wed, Aug 28, 2013 at 9:03 PM
> Subject: Standardising Structure in URIs
> To: Apps Discuss 
> Cc: Murray Kucherawy , Salvatore Loreto <
> salvatore.loreto@ericsson.com>, Barry Leiba 
>
>
> I started this draft during the Berlin meeting, and since have had a lot
> of positive feedback.
>
> Would the APPSAWG be interested in taking it on as a WG document?
>
> Regards,
>
>
> Begin forwarded message:
>
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for
> draft-nottingham-uri-get-off-my-lawn-02.txt
> > Date: 29 August 2013 2:01:29 PM AEST
> > To: Mark Nottingham 
> >
> >
> > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt
> > has been successfully submitted by Mark Nottingham and posted to the
> > IETF repository.
> >
> > Filename:      draft-nottingham-uri-get-off-my-lawn
> > Revision:      02
> > Title:                 Standardising Structure in URIs
> > Creation date:         2013-08-29
> > Group:                 Individual Submission
> > Number of pages: 8
> > URL:
> http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn
> > Htmlized:
> http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-nottingham-uri-get-off-my-lawn-02
> >
> > Abstract:
> >   Sometimes, it is attractive to add features to protocols or
> >   applications by specifying a particular structure for URIs (or parts
> >   thereof).  This document cautions against this practice in standards
> >   (sometimes called "URI Squatting").
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>
>
>

--001a11c343025eb11d04e51b35a7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


As it will be a working group item, it's certainly ope=
n for discussion.=A0 If you'd like to broach the topic on apps-discuss =
now, please feel free to do so.

-MSK



On Thu, Aug 29, 2013 at 12:34 PM, Andy N=
ewton <andy@arin.net> wrote:








Is it possible we can get the draft author to address our specificatio=
ns? I agree with some of the content of that draft, but other bits seem to =
say "THOU MUST use URI Templates". That is an issue that has been=
 discussed a couple of times here, but it
 seems to add little utility and causes more complexity on the client in ad=
dition to additional roundtrips.







-andy










From: "Murray S. Kucherawy&quo=
t; <superuser@g=
mail.com>

Date: Thursday, August 29, 2013 2:4=
0 PM

To: "weirds@ietf.org" <weirds@ietf.org>

Subject: [weirds] Fwd: Standardisin=
g Structure in URIs

















FYI, this is likely to be adopted by APPSAWG.=A0 It may affect our URI=
 specification stuff, which I think drew a DISCUSS during IESG evaluation.<=
br>




-MSK







---------- Forwarded message ----------

From: Mark Nottingham &=
lt;mnot@mnot.net>=


Date: Wed, Aug 28, 2013 at 9:03 PM

Subject: Standardising Structure in URIs

To: Apps Discuss <discuss@apps.ietf.org>

Cc: Murray Kucherawy <superuser@gmail.com>, Salvatore Loreto <salvatore.loreto@ericsson.=
com>, Barry Leiba <barryleiba@computer.org>






I started this draft during the Berlin meeting, and since have had a lot of=
 positive feedback.



Would the APPSAWG be interested in taking it on as a WG document?



Regards,





Begin forwarded message:



> From: in=
ternet-drafts@ietf.org

> Subject: New Version Notification for draft-nottingham-uri-get-off-my-=
lawn-02.txt

> Date: 29 August 2013 2:01:29 PM AEST

> To: Mark Nottingham <mnot@mnot.net>

>

>

> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt

> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.

>

> Filename: =A0 =A0 =A0draft-nottingham-uri-get-off-my-lawn

> Revision: =A0 =A0 =A002

> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Standardising Structure in URIs=


> Creation date: =A0 =A0 =A0 =A0 2013-08-29

> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission

> Number of pages: 8

> URL: =A0 =A0 =A0 =A0 =A0 =A0 
http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02=
.txt

> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.=
ietf.org/doc/draft-nottingham-uri-get-off-my-lawn

> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/h=
tml/draft-nottingham-uri-get-off-my-lawn-02

> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.=
ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-lawn-02

>

> Abstract:

> =A0 Sometimes, it is attractive to add features to protocols or

> =A0 applications by specifying a particular structure for URIs (or par=
ts

> =A0 thereof). =A0This document cautions against this practice in stand=
ards

> =A0 (sometimes called "URI Squatting").

>

>

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at 
tools.ietf.org.

>

> The IETF Secretariat

>



--

Mark Nottingham =A0 http=
://www.mnot.net/










































--001a11c343025eb11d04e51b35a7--

From johnl@iecc.com  Thu Aug 29 13:30:54 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C789821E80BB for ; Thu, 29 Aug 2013 13:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.612
X-Spam-Level: 
X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnS434FMgso1 for ; Thu, 29 Aug 2013 13:30:50 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4172321F9CA8 for ; Thu, 29 Aug 2013 13:30:48 -0700 (PDT)
Received: (qmail 84398 invoked from network); 29 Aug 2013 20:30:28 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Aug 2013 20:30: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:mime-version:content-type:content-transfer-encoding; s=521faf64.xn--hew.k1308; i=johnl@user.iecc.com; bh=lHak6etM6xIwt8JUKvr8YdyBnIbWTAi5I/K6ZrPqgLU=; b=q5xwgvMuPLRhyrREuvthMrgiLwQClA9F4ZeLG7xWwoUOUH3hXkrhl0taBXn7b0i6wejzssYmyp9FGFEZ0VrT3/g8mDEmcDhs65Boa6Rlk074JEIxvgnSouEXPnVI/7e3xGcOZ3iZob8llMGtZyRsm674YJw3MEwlU61UoVg6Kn+W1dJjmfZiLWAEKuteXuN+sPMDumwxNH9O1FhEafHglQe8zhIHQ8KI7MGVqOVF78bck1GAH10zAAyao0n55jKP
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=521faf64.xn--hew.k1308; olt=johnl@user.iecc.com; bh=lHak6etM6xIwt8JUKvr8YdyBnIbWTAi5I/K6ZrPqgLU=; b=GPXNigwIYWgSGD9KPoP68FoCrIWZsOjYZDPwyhGa6mk7d9OAsrwYROk2eCfuDJtBmSb1lHAW2kD6klQ8tRhrQeua6Lc/VRmcOFwAP9VHYSRh+jhCTUrOptsl2ntQI6Xs0QyfPZ+xWYSyOui0fjW9FZuN+ycQKyge5GTvpaO3Wd5PWOlsykVxlEAZe/YLIJ/ao9OuSZv1zbyCV18ac7LK5pnoVrFVyDF61gOuy2JfQdVZQ0ZEwOwcHStZwqSEh9RL
Date: 29 Aug 2013 20:30:06 -0000
Message-ID: <20130829203006.18517.qmail@joyce.lan>
From: "John Levine" 
To: weirds@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 20:30:54 -0000

>Is it possible we can get the draft author to address our specifications? I agree with some of the content of
>that draft, but other bits seem to say "THOU MUST use URI Templates". That is an issue that has been discussed a
>couple of times here, but it seems to add little utility and causes more complexity on the client in addition to
>additional roundtrips.

I hope so, but I'm not holding my breath.

Templates are great when you have existing services, or stuff that's
not very well specified, and want to build a consistent interface on
top of them.  But we're not doing that, since there are no existing
WEIRDS servers and the range of what it'll be used for is quite
narrow. (The beta servers, though very useful, don't count since
they're for testing, not officially for production.)

I fear a religious argument along the lines of "someone might need to
use a different URL format", "there's no reason to do that, these are
all new and most are built from of the Chinese prototype", "yeah, but
someone MIGHT need to use a different format", etc. ...

R's,
John

From superuser@gmail.com  Thu Aug 29 13:37:40 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1D611E815F for ; Thu, 29 Aug 2013 13:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level: 
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAg7R+Ro8M0j for ; Thu, 29 Aug 2013 13:37:39 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2555711E8159 for ; Thu, 29 Aug 2013 13:37:38 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id t60so907826wes.3 for ; Thu, 29 Aug 2013 13:37:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6v/qTUwR5n+pY+/or4CcqXml/rb2LWAV6EMFVKK3t24=; b=Y9CnJ0zcWKN4kBRLviha7+2gxSm43gfgtYGo5SGzMa2LjFY1o1Ys7Ci+onsDCLYmaS CwluJJO3Qe+CyNPS1eXmqHKZgrU4TR9RTW8EryqPYSal/d6l6H9Sq7H1lYyqrey7U79r WOwupTLZGoxoYYyZxZffJPwSS0aL6viNYk3mpt4Dx3h6zpNsytG3LReQx6VcZ1JbF06n HZnQbsIZxnpMWVO8nT7U5vWi2AvAKP+fglUIz/1ZrcR2kWI4FoD3gcui9cCVM8H8J5NK wzgpn2/oLfIKrr8VBmyKip/+29zXgw9Nstg/G02FIkFpQz7p2dzewjG12aigQYauEYDB zBnw==
MIME-Version: 1.0
X-Received: by 10.180.184.107 with SMTP id et11mr16540199wic.60.1377808658292;  Thu, 29 Aug 2013 13:37:38 -0700 (PDT)
Received: by 10.180.75.144 with HTTP; Thu, 29 Aug 2013 13:37:38 -0700 (PDT)
In-Reply-To: <20130829203006.18517.qmail@joyce.lan>
References:  <20130829203006.18517.qmail@joyce.lan>
Date: Thu, 29 Aug 2013 13:37:38 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: John Levine 
Content-Type: multipart/alternative; boundary=001a11c227eea5682704e51c133f
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 20:37:40 -0000

--001a11c227eea5682704e51c133f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 29, 2013 at 1:30 PM, John Levine  wrote:

> >Is it possible we can get the draft author to address our specifications?
> I agree with some of the content of
> >that draft, but other bits seem to say "THOU MUST use URI Templates".
> That is an issue that has been discussed a
> >couple of times here, but it seems to add little utility and causes more
> complexity on the client in addition to
> >additional roundtrips.
>
> I hope so, but I'm not holding my breath.
>
> Templates are great when you have existing services, or stuff that's
> not very well specified, and want to build a consistent interface on
> top of them.  But we're not doing that, since there are no existing
> WEIRDS servers and the range of what it'll be used for is quite
> narrow. (The beta servers, though very useful, don't count since
> they're for testing, not officially for production.)
>
> I fear a religious argument along the lines of "someone might need to
> use a different URL format", "there's no reason to do that, these are
> all new and most are built from of the Chinese prototype", "yeah, but
> someone MIGHT need to use a different format", etc. ...
>
>
Emphatically "no hat" here:

It seems to me that the people pushing Mark's position (including Mark, of
course) are a lot more entrenched in web architecture than this group is,
at least in terms of what we're chartered to work on.  Pushing back on the
way they say it should be done would be (to my mind) like SMTP people
telling TCP people that they're doing it wrong; we're making use of
mechanisms they provide for our purposes, so we should probably follow
their lead.

More simply: If web experts have concluded (I presume based on experience
and/or evidence) that the extra round trip and client complexity is
architecturally the right way to do it, how come we want to fight them on
that point?

-MSK

--001a11c227eea5682704e51c133f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Aug 29, 2013 at 1:30 PM, John Levine <johnl@taugh.c=
om> wrote:


>Is it possible we can get the draft author to address=
 our specifications? I agree with some of the content of

>that draft, but other bits seem to say "THOU MUST use URI Template=
s". That is an issue that has been discussed a

>couple of times here, but it seems to add little utility and causes mor=
e complexity on the client in addition to

>additional roundtrips.




I hope so, but I'm not holding my breath.



Templates are great when you have existing services, or stuff that's
not very well specified, and want to build a consistent interface on

top of them. =A0But we're not doing that, since there are no existing
WEIRDS servers and the range of what it'll be used for is quite

narrow. (The beta servers, though very useful, don't count since

they're for testing, not officially for production.)



I fear a religious argument along the lines of "someone might need to<=
br>
use a different URL format", "there's no reason to do that, t=
hese are

all new and most are built from of the Chinese prototype", "yeah,=
 but

someone MIGHT need to use a different format", etc. ...



Emphatically "no hat" here:<=
br>
It seems to me that the people pushing Mark's positio=
n (including Mark, of course) are a lot more entrenched in web architecture=
 than this group is, at least in terms of what we're chartered to work =
on.=A0 Pushing back on the way they say it should be done would be (to my m=
ind) like SMTP people telling TCP people that they're doing it wrong; w=
e're making use of mechanisms they provide for our purposes, so we shou=
ld probably follow their lead.


More simply: If web experts have concluded (I presume based on experien=
ce and/or evidence) that the extra round trip and client complexity is arch=
itecturally the right way to do it, how come we want to fight them on that =
point?


-MSK


--001a11c227eea5682704e51c133f--

From andy@arin.net  Thu Aug 29 13:54:42 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB81121E804D for ; Thu, 29 Aug 2013 13:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrordq4zGtXc for ; Thu, 29 Aug 2013 13:54:37 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3F13A11E817B for ; Thu, 29 Aug 2013 13:54:01 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id 974311651FF; Thu, 29 Aug 2013 16:53:57 -0400 (EDT)
Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 122B61651F5; Thu, 29 Aug 2013 16:53:57 -0400 (EDT)
Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 29 Aug 2013 16:53:56 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.131]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 16:52:29 -0400
From: Andy Newton 
To: "Murray S. Kucherawy" , John Levine 
Thread-Topic: [weirds] Fwd: Standardising Structure in URIs
Thread-Index: AQHOpOdRgi8YK4PS80uIvGyBrehO8pmsk8MAgABSlACAAAIbAP//wR2A
Date: Thu, 29 Aug 2013 20:52:28 +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.3.6.130613
x-originating-ip: [10.1.1.56]
Content-Type: multipart/alternative; boundary="_000_CE452AA327F0Dandyarinnet_"
MIME-Version: 1.0
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 20:54:43 -0000

--_000_CE452AA327F0Dandyarinnet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From: "Murray S. Kucherawy" >
Date: Thursday, August 29, 2013 4:37 PM
To: John Levine >
Cc: "weirds@ietf.org" >
Subject: Re: [weirds] Fwd: Standardising Structure in URIs

More simply: If web experts have concluded (I presume based on experience a=
nd/or evidence) that the extra round trip and client complexity is architec=
turally the right way to do it, how come we want to fight them on that poin=
t?

Because those are real considerations which they have not addressed, at lea=
st not in that document.

-andy

--_000_CE452AA327F0Dandyarinnet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <09A2245FFD9E544BAA8F270C66912C8F@corp.arin.net>
Content-Transfer-Encoding: quoted-printable









From: "Murray S. Kucherawy&quo=
t; <superuser@gmail.com>
Date: Thursday, August 29, 2013 4:3=
7 PM

To: John Levine <johnl@taugh.com>

Cc: "weirds@ietf.org" <=
weirds@ietf.org>

Subject: Re: [weirds] Fwd: Standard=
ising Structure in URIs










More
 simply: If web experts have concluded (I presume based on experience and/o=
r evidence) that the extra round trip and client complexity is architectura=
lly the right way to do it, how come we want to fight them on that point?








Because those are real considerations which they have not addressed, a=
t least not in that document. 







-andy




--_000_CE452AA327F0Dandyarinnet_--

From johnl@taugh.com  Thu Aug 29 13:55:51 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AA221F94FD for ; Thu, 29 Aug 2013 13:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJgywIuasx6R for ; Thu, 29 Aug 2013 13:55:32 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A49811E817F for ; Thu, 29 Aug 2013 13:55:02 -0700 (PDT)
Received: (qmail 89755 invoked from network); 29 Aug 2013 20:55:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=15e9a.521fb524.k1308; bh=6kEpYWNFuXIxtr1UZRLYy77xKY7p6MHykVp60hnaXng=; b=oBM2VS7A+zUGYuIce/9KuMd72bnjV6VkE0KU30P26ap9N+lJaXNoMSpfNaoow9Mgt6AxHwrBcYs5TyPHnlZPDIuH6BRAp9ymK3mj6FDUjTVOYonR0r4l1rViynJYDcbhd/LkjEk3FdVganSpeUjAjdK0DpIwbeVgTDub3NxW9kEpp8BiqynpvBoy58Y7KI0lQVCaY9Zn1zpvBOw7agbBLHjbvxezktgUesKPEILJNUb8RDaorMm6SNCf50YP/49X
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=15e9a.521fb524.k1308; bh=6kEpYWNFuXIxtr1UZRLYy77xKY7p6MHykVp60hnaXng=; b=CYuaDhn/R4ZGEW0Ch8TE9X0CSo8LGC6oGroJpUwsXi5kJFL5KYdolAIUjaMdsyF1ED3qUDHrfBZrGjIFzMeOQxPE+dlCqn5HrZHdT4mDucPjKlUpnMtsLFX7bBNNgSFJeYphDK1HzeirLVqz393MGpg5cWfUz/7tIqfvHMPq7DDMGVw/kUi3MvBFJmSY7Gb2qVboZ6vxWPJmVtPKSfUQQkx5e32Sqi0dUr4HSeQfd7WqXmpMKVT0y7i2+80/PbPj
Received: (ofmipd 127.0.0.1); 29 Aug 2013 20:54:37 -0000
Date: 29 Aug 2013 16:54:59 -0400
Message-ID: 
From: "John R Levine" 
To: "Murray S. Kucherawy" 
In-Reply-To: 
References:  <20130829203006.18517.qmail@joyce.lan> 
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] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 20:55:51 -0000

> More simply: If web experts have concluded (I presume based on experience
> and/or evidence) that the extra round trip and client complexity is
> architecturally the right way to do it, how come we want to fight them on
> that point?

I've looked at the arguments, and templates are a brilliant solution to a 
problem we don't have.

The only way I can imagine they'd be useful for WEIRDS is if someone later 
decided to embed into some larger existing service.  And even if they did 
that, they could still add the templates for the larger service, which 
would map some generic queries into the WEIRDS URLs, and WEIRDS could 
ignore them.


From superuser@gmail.com  Thu Aug 29 14:35:20 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63E21F9F0E for ; Thu, 29 Aug 2013 14:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level: 
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfCqov3f5mSI for ; Thu, 29 Aug 2013 14:35:19 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17A21F9EA8 for ; Thu, 29 Aug 2013 14:35:19 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id e12so132316wgh.9 for ; Thu, 29 Aug 2013 14:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1cuJSNqIyX8QqJNT1oKRGBvWmOxxYoGwErZGBVGgouE=; b=b9PnTatVsJIffKz3C0ZTHoAEVY4eu4shqqpNfgSz0MI1u6j72WpvfrTOCnXaKHYrMk ZEgg/KdS9A6PlfAeSLw+LSWsZ9VIsNvyXumC3RXLeA6bNa9PJ5U/6yN+HnNp2swnSNW8 KJDX8iMZS7I520K6XvoaS9M0Z2VFKltjYlq2KB/pgPeyvCMG2Wsi6VhMkJa/khjPZ14p y2WOQyQtHn3SQpp1pS32Ho3kAsVC5gmiRbIgqIL0bJDOBygT3dKDbZJWDQKloImuvNZ3 prxDNuzEQFzGn2V0CsINZ7+GB3jpzCTq4LQOjhRS1M6E6oXr1sQiOE2ZWxqxXgRsmtP2 l1fA==
MIME-Version: 1.0
X-Received: by 10.194.241.137 with SMTP id wi9mr92435wjc.50.1377812118724; Thu, 29 Aug 2013 14:35:18 -0700 (PDT)
Received: by 10.180.75.144 with HTTP; Thu, 29 Aug 2013 14:35:18 -0700 (PDT)
In-Reply-To: 
References:  <20130829203006.18517.qmail@joyce.lan>  
Date: Thu, 29 Aug 2013 14:35:18 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: John R Levine 
Content-Type: multipart/alternative; boundary=089e0141a52ce7669404e51ce162
Cc: "weirds@ietf.org" 
Subject: Re: [weirds] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 21:35:20 -0000

--089e0141a52ce7669404e51ce162
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 29, 2013 at 1:54 PM, John R Levine  wrote:

>
> I've looked at the arguments, and templates are a brilliant solution to a
> problem we don't have.
>

I guess I'm missing how the arguments don't apply to us, or how we're
different from any other web application that's tried to do this.  Why is
WEIRDS special in this way?

-MSK

--089e0141a52ce7669404e51ce162
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Aug 29, 2013 at 1:54 PM, John R Levine <johnl@tau=
gh.com> wrote:




I've looked at the arguments, and templates are a brilliant solution to=
 a problem we don't have.

I guess I=
'm missing how the arguments don't apply to us, or how we're di=
fferent from any other web application that's tried to do this.=A0 Why =
is WEIRDS special in this way?


-MSK


--089e0141a52ce7669404e51ce162--

From johnl@taugh.com  Thu Aug 29 15:06:57 2013
Return-Path: 
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F111221E809B for ; Thu, 29 Aug 2013 15:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level: 
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNLUaBczfNxf for ; Thu, 29 Aug 2013 15:06:56 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EECB221E8091 for ; Thu, 29 Aug 2013 15:06:51 -0700 (PDT)
Received: (qmail 3462 invoked from network); 29 Aug 2013 22:06:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d85.521fc5f4.k1308; bh=7vXzXvWnewQ7YfFI5qkScKigiHxeHmcDBKR9o9BruNE=; b=krldCfo1RZXTcOq34Y86UAdndMsbdnAibGkdY5/wFnCIgy4Dn/50MDZtTc1KC70XyGyCjH1aj6SY+RZ6InCwoP3WemIstr0zWW/tzJcMcrWIzRsly3wRWGPQuN4rwn1Zk9QRVaBNt9l0f+BpqRirjycT65JcwYgpuJ0LhHqu7hNthLJ4B8XpZWrgDBxkKJhxWvYxVdJsKKaI14SWVwBhInffjf20KYEe9oO6aYgnvBp4tggULUpW1DmXvWIgngux
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d85.521fc5f4.k1308; bh=7vXzXvWnewQ7YfFI5qkScKigiHxeHmcDBKR9o9BruNE=; b=sTmJ5Uc32mKL8o7L4Ow6W5HpjGHHdr/8mE8Y4J0XmxEcJhwAfat7WHhLr5FTf2IG3K8NDhWmHY1CH1wI2bO2zCCFXO1ed5RLhWEOmXrY1lIhiCpVoCS0P0vMhjL+2NdVNrvZIU6lUD7lX/xwaxTU+za91PAQXubrRIsBDtSdKpuig3M22yCiMZ/mdz9BFZiy5IJlNyYOXQGrd8cPhNZvyJZsYyLuZOmp08N+tYstwo9zXfHfIs4ThwLa7AghidRE
Received: (ofmipd 127.0.0.1); 29 Aug 2013 22:06:22 -0000
Date: 29 Aug 2013 18:06:44 -0400
Message-ID: 
From: "John R Levine" 
To: "Murray S. Kucherawy" 
In-Reply-To: 
References:  <20130829203006.18517.qmail@joyce.lan>   
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] Fwd: Standardising Structure in URIs
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 29 Aug 2013 22:06:57 -0000

>> I've looked at the arguments, and templates are a brilliant solution to a
>> problem we don't have.
>
> I guess I'm missing how the arguments don't apply to us, or how we're
> different from any other web application that's tried to do this.  Why is
> WEIRDS special in this way?

We have an unusual application with no installed base, and little chance 
that there are other services that are not WEIRDS but would want a 
compatible interface.  If we thought it were important to layer WEIRDS on 
top of the existing registrar web WHOIS servers, templates might be 
helpful, but a) for political reasons they are likely to implement WEIRDS 
directly, and b) the exsting ones are all horrible.

I also have to say that the level of theological rigidity in the web 
services area is as bad as it is in other areas we've encountered.

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