From Ed.Lewis@neustar.biz Thu Nov 1 05:55:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E821F8C40 for ; Thu, 1 Nov 2012 05:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb5pVPVN9kFC for ; Thu, 1 Nov 2012 05:55:50 -0700 (PDT) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB5021F8DAA for ; Thu, 1 Nov 2012 05:55:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F33C858EB2; Thu, 1 Nov 2012 08:55:49 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 4B96258EB0; Thu, 1 Nov 2012 08:55:48 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D69F12F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6959A1@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D69F12F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 1 Nov 2012 08:50:58 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Requirements: Data Integrity X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 12:55:51 -0000 >> -----Original Message----- >> From: Murray S. Kucherawy [mailto:superuser@gmail.com] >> Sent: Sunday, October 21, 2012 12:14 AM >> To: Hollenbeck, Scott >> Cc: weirds@ietf.org >> Subject: Re: [weirds] Security Requirements: Data Integrity >> >> On Mon, Oct 15, 2012 at 7:07 AM, Hollenbeck, Scott >> wrote: >> > Data integrity ("The property that data has not been changed, >> >destroyed, or lost in an unauthorized or accidental manner") is another >> >security service ... Murray: >> Could this be the same as, or related to, ICANN's vague "validation" >> requirement? At 11:18 +0000 10/22/12, Hollenbeck, Scott wrote: >I think people will conflate the two, but that's not really what I'm getting >it. I'm approaching the integrity question from the perspective of protecting >the client-server data exchange. I'm having a hard time figuring out how to >cast the data validation thing as a security requirement. It sounds like more >of a policy or data use requirement/need to me. I agree with Scott. "Data integrity" only means "Garbage-In Garbage Out" across the system, ICANN's call for validation is "No Garbage." For example: In DNSSEC, the signature there protects data from the time it was given to the DNS zone administrator to the DNS client. In no way does DNSSEC ensure the data given to the administrator was correct. I.e., if you add a server at 259.20.31.399 but tell the admin it's 259.31.20.399, DNSSEC won't fix that but make sure everyone gets the mistake. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Thu Nov 1 06:16:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA0B21F87D4 for ; Thu, 1 Nov 2012 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6dejq2jy2T3 for ; Thu, 1 Nov 2012 06:16:06 -0700 (PDT) Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by ietfa.amsl.com (Postfix) with ESMTP id B0CA921F8600 for ; Thu, 1 Nov 2012 06:16:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp49.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 027A7190636; Thu, 1 Nov 2012 09:16:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp49.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id B57F6190373; Thu, 1 Nov 2012 09:16:02 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20121029072710.0b17f8c0@resistor.net> References: <6.2.5.6.2.20121028234221.0aa95780@resistor.net> <6.2.5.6.2.20121029072710.0b17f8c0@resistor.net> Date: Thu, 1 Nov 2012 09:12:07 -0400 To: SM From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: weirds@ietf.org Subject: Re: [weirds] Security Requirements: Non-repudiation X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 13:16:07 -0000 At 7:59 -0700 10/29/12, SM wrote: >>This is all very interesting, but I think John's point still stands: this >>is scope creep. Are we also gonna specify cert hierarchies for validating >>signed objects? Develop a PKIX profile? Define cert path validation? In as much as the protocol the WEIRDS WG is developing is a data access protocol, trying to attach any feature that relates to the accuracy and hence the ability to prevent denouncing a historical value of the data would be out of scope. At least when it comes to accessing the data. Alluded to earlier in this thread, if an organization wanted to provide non-repudiation of accesses (both writes and reads) to data, logs of ephemeral actions would need to be maintained, these logs would need to have data integrity protection. This is all well and good, if needed, but not something that is part of the data access protocol. There's a difference between end-to-end security and hop-by-hop security just as there's a difference between "securing" static data and dynamic events. For end-to-end, we have things like digital signature, for hop-by-hop we have things like TLS/SSL. For static data, there's data integrity for events there's non-repudiation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Thu Nov 1 06:20:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E721F8BC8 for ; Thu, 1 Nov 2012 06:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.289 X-Spam-Level: X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZLZSBxndHDp for ; Thu, 1 Nov 2012 06:20:08 -0700 (PDT) Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by ietfa.amsl.com (Postfix) with ESMTP id 443C221F8BC6 for ; Thu, 1 Nov 2012 06:20:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp49.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id CCEA11904F0; Thu, 1 Nov 2012 09:20:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp49.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 7979719061A; Thu, 1 Nov 2012 09:20:07 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6AA4E8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6AA4E8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 1 Nov 2012 09:19:50 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Service Summary X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 13:20:08 -0000 At 14:24 +0000 10/30/12, Hollenbeck, Scott wrote: >Data Integrity: we have not identified a requirement to provide this >service. There may, however, be a requirement to provide some sort >of response element that confirms that an element has been >"validated" or "verified", which some people will likely confuse >with a data integrity service. QUESTION: how do we want to approach >this? I would suggest dividing this in two. Data Integrity: Data Accuracy: a field the carries ancillary information indicating whether and when a value was out-of-band validated/verified. I'd categorize the former as a security-related requirement of the effort, the latter as a data-feature requirement. PS - In the back of my mind is again DNS. DNS is not a client-server protocol, it is a client-cache-server protocol. The intermediate cache is a core element to the protocol, hence we do have, in DNSSEC-thought, to deal with the difference between end-to-end and hop-by-hop security. In DNSSEC, data integrity is not channel security because the cache could mess with the data. Channel security is not transitive - as in A=B, B=C, ergo A=C. For DNS A=B and B=C might still yield A=/=C. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From shollenbeck@verisign.com Thu Nov 1 07:05:09 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE76B21F8CB1 for ; Thu, 1 Nov 2012 07:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv+qHJNvWPd9 for ; Thu, 1 Nov 2012 07:05:09 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 54A9921F8CAB for ; Thu, 1 Nov 2012 07:05:08 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUJKBk9Ui8qWdqG4iAeYpsfU9m3xu7mFQ@postini.com; Thu, 01 Nov 2012 07:05:09 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA1E57bt031917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 10:05:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 1 Nov 2012 10:05:06 -0400 From: "Hollenbeck, Scott" To: Edward Lewis Thread-Topic: [weirds] Security Service Summary Thread-Index: Ac22ps+5gETdCpDsRhqVrN0bv4NG6gBrkmUAAAbTYxA= Date: Thu, 1 Nov 2012 14:05:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AB295@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6AA4E8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Service Summary X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:05:10 -0000 > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] > Sent: Thursday, November 01, 2012 9:20 AM > To: Hollenbeck, Scott > Cc: weirds@ietf.org > Subject: Re: [weirds] Security Service Summary >=20 > At 14:24 +0000 10/30/12, Hollenbeck, Scott wrote: >=20 > >Data Integrity: we have not identified a requirement to provide this > >service. There may, however, be a requirement to provide some sort of > >response element that confirms that an element has been "validated" or > >"verified", which some people will likely confuse with a data > integrity > >service. QUESTION: how do we want to approach this? >=20 > I would suggest dividing this in two. >=20 > Data Integrity: information, such as the registry database, would provide ancillary > data like a digital signature to allow verification that the data > received originated with the true source> >=20 > Data Accuracy: a field the carries ancillary information indicating > whether and when a value was out-of-band validated/verified. >=20 > I'd categorize the former as a security-related requirement of the > effort, the latter as a data-feature requirement. Agreed. I'll split the topics for discussion in Atlanta. Scott From Ed.Lewis@neustar.biz Thu Nov 1 07:25:54 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597321F8DB4 for ; Thu, 1 Nov 2012 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XYG9OKc9Y+n for ; Thu, 1 Nov 2012 07:25:54 -0700 (PDT) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1321F8DB1 for ; Thu, 1 Nov 2012 07:25:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B97355922A; Thu, 1 Nov 2012 10:25:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 2BD0259222; Thu, 1 Nov 2012 10:25:52 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D692DC3@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D692DC3@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Date: Thu, 1 Nov 2012 10:18:54 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Requirements: Authorization X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:25:54 -0000 What I didn't see in the thread was any requirements that the protocol allow the client to determine if the origin of the response was authorized to provide the data. Use case - ithe server for .malicious is not authorized to originate information about neither the IETF.ORG registration nor the 133.0.0.0/8 IPv4 address range. Ways to combat this is to declare an authorization model for the protocol and to require any data integrity protection to identify the source of the protection, like the signature. From DNSSEC (my favorite reference), RFC 3008 (yes, it's obsolete but the history of it is germain) confined the signer field in the RRSIG to be the name of the management zone responsible for the data. Prior to that we had an open authorization model but found it to be unmanageable. And inside the RRSIG there is a pair of fields that identify the key used to generate/verify the signature which provides a like of the data integrity to the source. From that the verifier can judge whether the data originated with the correct authority. Note - originating and redistributing data are two different things. In DNS we have caches that respond with data for which they are not authorized to originate. The "problem" though is not restricted to caches in DNS, I've seen a number of organizations scrape or grab copies of authorized data and then redistribute the data. To "combat" the latter, or at least limit any damage that might result, defense against replay is needed, which is usually tied to a (signed) wall clock reading. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Thu Nov 1 07:35:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2833F21F8C7D for ; Thu, 1 Nov 2012 07:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT0tntLKctSA for ; Thu, 1 Nov 2012 07:35:40 -0700 (PDT) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by ietfa.amsl.com (Postfix) with ESMTP id 690FE21F87FB for ; Thu, 1 Nov 2012 07:35:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0629559299; Thu, 1 Nov 2012 10:35:40 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id F0D3E5929D; Thu, 1 Nov 2012 10:35:38 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D692D97@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D692D97@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Date: Thu, 1 Nov 2012 10:35:24 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Requirements: Authentication X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:35:41 -0000 At 12:49 +0000 10/8/12, Hollenbeck, Scott wrote: >From "Inventory of WHOIS Service Requirements Final Report": > >Define an authentication framework for WHOIS that is able to >accommodate anonymous access as well as verification of identities >using a range of authentication methods and credential services. > >From RFC 3707: > >Entities accessing the service (users) MUST be provided a mechanism >for passing credentials to a server for the purpose of >authentication. > >The protocol MUST provide a mechanism capable of employing many >authentication types and capable of extension for future >authentication types. > >These are basically saying the same thing. Are there any other >requirements for authentication? First, looking at the thread, the statements above only say the protocol has to convey claims of identity, not evaluate them. Talk about "federating" and things like single-sign on are back end operations that a server might use to make decisions on what goes into a reply. The set up and management of a federated framework ought to be (in my opinion) performed out-of-band relative to the WEIRDS WG protocol. I'm going to "brainstorm" another requirement. It might be totally out of scope...this is an exercise is seeing if all paths of communication are considered: If any two "servers" of the WEIRDS WG protocol ever need to coordinate, the two administrations/servers would need to be able to mutually authenticate. Here I am conidering any cooperation between numbering servers that might be be related in the CIDR sense of one being more specific than the other, or in the name servers where the servers are related because they represent the same economy (think postal code) but use different scripts. Again - there might not be any need for that if the scope of the protocol excludes that interaction. I don't believe there is a need for a server to authenticate to a client, outside of any source authenticity that is provided as part of data integrity or replay prevention. IOW, we don't need to authenticate the channel from the server to the client although there are other requirements protecting the data sent. (The requirements Scott presented relate to authenticating the channel from the client to the server.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From sm@resistor.net Thu Nov 1 07:43:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8160121F8A96 for ; Thu, 1 Nov 2012 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7JFEQJnr8Rl for ; Thu, 1 Nov 2012 07:43:44 -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 C70B321F8A67 for ; Thu, 1 Nov 2012 07:43:44 -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 qA1EhRn2012128; Thu, 1 Nov 2012 07:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351781011; bh=F7vs53dNI2aTogzpldLDzOwKVB7B0Zi73j6EZyVr9k0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=attzvInqg0ZRlS8pRyVBLHmBEYrRyt8alOIrJ9X2Pohm34YAJB0XLm0LfVx9ucNq4 i3mCza5DjEZV9tEjqV/VxPRiKJx6oMPy6/zGh+q/iufDZiRxZfBWbanYzhrRaJkziy I51Tb3xFdf3rHNKEhcGtuzIhp3J8tBSg0pThD6oc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351781011; i=@resistor.net; bh=F7vs53dNI2aTogzpldLDzOwKVB7B0Zi73j6EZyVr9k0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qIuTUTY6VKoEkzUal0O2i42yXSUptjSfovkN+uZOY1o63QRrnhLQ60fCpWhjwhex3 RMG/MdCM6j8flYItia7IVZMOMhkUY8ZXDpmtgSDGf0m/nqs49h5zfsjXMAH5ar/B6s X6VX2K4dzfQv2ukaXF/yus7I3DUlK6pLyPQfr4C0= Message-Id: <6.2.5.6.2.20121101071925.09d7b2f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Nov 2012 07:23:54 -0700 To: Edward Lewis From: SM In-Reply-To: References: <831693C2CDA2E849A7D7A712B24E257F0D6959A1@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D69F12F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Security Requirements: Data Integrity X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:43:45 -0000 At 05:50 01-11-2012, Edward Lewis wrote: >I agree with Scott. "Data integrity" only means "Garbage-In Garbage >Out" across the system, ICANN's call for validation is "No Garbage." Yes. Data validation is a non-technical requirement. Regards, -sm From olaf@NLnetLabs.nl Thu Nov 1 07:52:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E576B21F85CB for ; Thu, 1 Nov 2012 07:52:47 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id newqXWmamTLC for ; Thu, 1 Nov 2012 07:52:47 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 831F721F8D36 for ; Thu, 1 Nov 2012 07:52:41 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id qA1EpxY4080837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 15:52:01 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl qA1EpxY4080837 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1351781525; bh=OuWlNlTw08dX9DnHJcJ39mS7SGEOyU8WgusWfcAJvcI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Ugx2iGuuE0p16K/S8SiiVQqIqefkxRyJ8nJ1EsZDMGQNX2lj5UTUz3Q2QFsYAY6uf QWGdQN59FBfkIT1bgpaOJjljX2ZBbW2WORwaciaj0W7WuTdwH1B98sTrpK9LSu3zUG +fgOSU4tcC5bvP7iSd4l347PZqI8sW64gbtQE1is= Content-Type: multipart/alternative; boundary="Apple-Mail=_ED9E9A5D-5EE1-4401-822D-EC7E179C806A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 1 Nov 2012 15:52:02 +0100 Message-Id: <08D7E735-E9C3-42A1-BD19-38E2B1E1063C@NLnetLabs.nl> References: To: James Mitchell X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 01 Nov 2012 15:52:04 +0100 (CET) Cc: Peter Koch , "weirds@ietf.org" Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:52:48 -0000 --Apple-Mail=_ED9E9A5D-5EE1-4401-822D-EC7E179C806A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2012, at 3:25 AM, James Mitchell = wrote: > Any work on internationalized registration data should consider the > changes required to EPP interfaces to allow capture of language > information. I am sympathetic to that idea, but IMHO changes to EPP are out of scope = for this working group. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_ED9E9A5D-5EE1-4401-822D-EC7E179C806A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii james.mitchell@ausregist= ry.com.au> wrote:
Any work on internationalized = registration data should consider the
changes required to EPP = interfaces to allow capture of language

Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_ED9E9A5D-5EE1-4401-822D-EC7E179C806A-- From Ed.Lewis@neustar.biz Thu Nov 1 09:14:34 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2121F8F8F for ; Thu, 1 Nov 2012 09:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.851 X-Spam-Level: X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiXpd1jHVCl1 for ; Thu, 1 Nov 2012 09:14:33 -0700 (PDT) Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0921F8F8E for ; Thu, 1 Nov 2012 09:14:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id BCD793C0022; Thu, 1 Nov 2012 12:14:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 20ADC3C023B; Thu, 1 Nov 2012 12:14:32 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> Date: Thu, 1 Nov 2012 12:14:28 -0400 To: Ning Kong From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:14:34 -0000 At 12:04 +0800 10/12/12, Ning Kong wrote: >Any thoughts or comments on this topic are appreciated. Having read the thread, I had a few thoughts (of course). First, there was mention of "translation." I think translation is completely out of scope. No part of the WEIRDS WG protocol elements should be attempting to *convert* one language or script to another. What I mean is, if I look up a 133.310.259.12 I get some information in Japanese and I get some information in English. I do not expect the Japanese information to be translated into English by either the server or client of the protocol. The fact that there is English information in addition is external (out-of-band) to the protocol - it's just other data carried to the WEIRDS WG protocol. For the most part, conveying the A-label and U-label for domain names (that includes name servers) and sticking to standards for Postal Codes* (I am only aware of the standards there through stories from others), most of the critical information will be covered. Yes, remarks are not covered but I am not sure that they are all that important in the use cases I imagine. What is important would be the names inside contacts. I.e., it's really helpful that I see the pinyin for Ning's name. ;) I doubt that this protocol development work can drive what data a registry collects, in a sense this protocol is the tail of the dog. What should be provided is a way for the protocol to indicate as much about the language and encoding used when the information is conveyed. Note - I'm avoiding talking about language tags, etc., and what is "displayed" at a client because I think we first have to consider the problem to be solved. At times in the development of IDN, the problem got more complex because "translation" is a more general problem than just representing a script in a DNS label. Another note - in an earlier reply to Ning I expressed the problem I have with every trying to solve the issue of internationalization in a general sense just based on the signs seen on Beijing roadways. E.g., a sign with the Han characters for "GongDaQiao" and below that "GONGDA BRIDGE". The way the sign is rendered mixes scripts, I would have expected GONGDAQIAO or a something like "Polytechnic University Bridge" to be rendered in letters. The "natural world"'s mixing of scripts - just between Han and pinyin - is tough to crystalize into a computer protocol. So - avoid translation in the data access protocol! * - I've sent postcards internationally that only had a street name, city, state, country in letters, in addition to digits for zip code and house number. The use case I have in mind is a card from Germany sent to Chinese-speaking friends living in the US. The address had to be in "ASCII" so that the German mail handling system could hand it off to the US system. From what I've been told, French is also an official postal address language. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From sm@resistor.net Thu Nov 1 10:48:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CF221F90DF for ; Thu, 1 Nov 2012 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_50=0.001, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKsIwv4qBKJ6 for ; Thu, 1 Nov 2012 10:48:24 -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 54ABD21F90D7 for ; Thu, 1 Nov 2012 10:48:22 -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 qA1HmGUt014290; Thu, 1 Nov 2012 10:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351792101; bh=C3cSPLlufbKjaLCgMsnidzyEa2SMV52cuavzKiLVO9g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LZj4XlvorOJr8FmCwuU5XxptM0PthpocYuLKpgYPSUrZigF3i6WluHuG/enp6jMo1 xc8nEhfURBGV8ld+H4W7HM4zTKRCcgdkjIBf4whTV79qaWtklPB7c0uIrSpTPYPMu2 WKsoG+lPdkwZmaSFjt+Y9+Ih+uFZFFF+4uSLq+vc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351792101; i=@resistor.net; bh=C3cSPLlufbKjaLCgMsnidzyEa2SMV52cuavzKiLVO9g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pQF5TcoVI6PMc79z2Prx6n45pv4lZLCvnzSGiRO9Uik5m6LJc0868tDsyk94OYJSy urVQ3nI6A8SPbJImE+feAasYknOYF40d8gE259ZuvANnsqP4QpN1Vng0cMwc3kBBw/ qI7z2UN85i7IKHU8NQi9h32VfTCLkQTQ0ddncM8A= Message-Id: <6.2.5.6.2.20121101094348.064ae730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Nov 2012 10:45:26 -0700 To: Edward Lewis From: SM In-Reply-To: References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:48:26 -0000 Hi Ed, At 09:14 01-11-2012, Edward Lewis wrote: >* - I've sent postcards internationally that=20 >only had a street name, city, state, country in=20 >letters, in addition to digits for zip code and=20 >house number. The use case I have in mind is a=20 >card from Germany sent to Chinese-speaking=20 >friends living in the US. The address had to be=20 >in "ASCII" so that the German mail handling=20 >system could hand it off to the US system. From=20 >what I've been told, French is also an official postal address language. People might consider Whois as important as it is=20 a valuable source of information for DMCA=20 notices. :-) Such notices are generally sent by=20 email as it is the cheapest alternative for=20 businesses which rely on this critical property=20 available through Whois. I don't know how=20 important postal addresses are. Anyway, it's=20 easier to send a letter to .com and .org to seize=20 a domain name. For number resources, it is easier to send a letter to the= RIR. Domain names or email addresses is not a=20 significant internationalization issue as there=20 are existing specifications for that. The text=20 quoted above highlights the internationalization=20 issue when it comes to postal=20 addresses. Currently, that information is=20 unstructured. As an example, here's what I get for jprs.jp: Domain Information: [B%I%a%$%s>pJs] [Domain Name] JPRS.JP [BEPO?] B3t<02quBV] Active [B:G=3D*99?7] 2012/03/01 01:05:01 (JST) Contact Information: [B8x3+O"MmAk8}] [BL>A0] B3t<02q?@ED;0CzL\8BHV1B9f B@iBeED%U%!!<%9%H%S%kEl4[ 13F [Postal Address] Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065, JAPAN [BEEOCHV9f] 03-5215-8451 [FAXBHV9f] 03-5215-8452 and for denic.de: Domain: denic.de Nserver: ns1.denic.de 2001:608:6:6:0:0:0:11 81.91.170.1 Nserver: ns2.denic.de 193.171.255.36 Nserver: ns3.denic.de 87.233.175.19 Status: connect Changed: 2010-06-18T09:06:50+02:00 [Tech-C] Type: PERSON Name: Business Services Organisation: DENIC eG Address: Kaiserstra=DFe 75-77 PostalCode: 60329 City: Frankfurt CountryCode: DE Phone: +49 69 27235 272 Fax: +49 69 27235 234 Email: dbs@denic.de Remarks: Information:http://www.denic.de Changed: 2010-12-15T12:00:30+01:00 [Zone-C] Type: PERSON Name: Business Services Organisation: DENIC eG Address: Kaiserstra=DFe 75-77 PostalCode: 60329 City: Frankfurt CountryCode: DE Phone: +49 69 27235 272 Fax: +49 69 27235 234 Email: dbs@denic.de Remarks: Information:http://www.denic.de Changed: 2010-12-15T12:00:30+01:00 and for cnnic.cn: Domain Name: cnnic.cn ROID: 20030310s10001s00012956-cn Domain Status: serverDeleteProhibited Domain Status: serverUpdateProhibited Domain Status: serverTransferProhibited Registrant ID: s1255673574881 Registrant: =E4=B8=AD=E5 egistrant Contact Email: servicei@cnnic.cn Sponsoring Registrar: =E5=8C=97=E4=BA=AC=E4=B8=AD=E7=A7=91=E4=B8=89=E6=96=B9= =E7=BD=91=E7=BB=E6=8A=80=E6=AF=E6=89=E9=99=90=E5 =AC=E5=B8 Name Server: a.cnnic.cn Name Server: b.cnnic.cn Name Server: c.cnnic.cn Name Server: d.cnnic.cn Name Server: e.cnnic.cn Registration Date: 2003-03-10 19:06:34 Expiration Date: 2018-03-10 19:06:34 DNSSEC: unsigned It was mentioned that [1]: "There is a possibility some element has data by multiple languages (such as Japanese and English) and the other element has data by a single language (such as Japanese)." If the Whois output (see above) was rendered in=20 ASCII there would be loss of information. It is=20 going to be complicated to solve the postcard=20 problem. Getting into translation [2] might=20 create other issues. It might help if people=20 commented on what they mean by "internationalization". Regards, -sm 1. http://www.ietf.org/mail-archive/web/weirds/current/msg01769.html 2. http://www.ietf.org/mail-archive/web/weirds/current/msg01810.html=20 From shollenbeck@verisign.com Thu Nov 1 10:56:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B4D21F8992 for ; Thu, 1 Nov 2012 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.199 X-Spam-Level: X-Spam-Status: No, score=-7.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmu9RmYYhHD2 for ; Thu, 1 Nov 2012 10:56:52 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9721F899D for ; Thu, 1 Nov 2012 10:56:44 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUJK33IwvV8XG8WvngDbXIKfsPj6jqyQY@postini.com; Thu, 01 Nov 2012 10:56:52 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qA1HueDa013600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 13:56:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 1 Nov 2012 13:56:40 -0400 From: "Hollenbeck, Scott" To: SM Thread-Topic: [weirds] Internationalization Issues Thread-Index: AQHNuEv9bbUl1mHLxEGP6t78je4yiZfVg88A//+/HEA= Date: Thu, 1 Nov 2012 17:56:39 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AB581@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> In-Reply-To: <6.2.5.6.2.20121101094348.064ae730@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:56:53 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of SM > Sent: Thursday, November 01, 2012 1:45 PM > To: Edward Lewis > Cc: weirds@ietf.org > Subject: Re: [weirds] Internationalization Issues >=20 > Anyway, it's easier to send a letter to .com and .org to seize a domain n= ame. This is off-topic, but it takes much more than a letter to take down a .com= domain. Scott From Ed.Lewis@neustar.biz Thu Nov 1 11:57:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC03221F8824 for ; Thu, 1 Nov 2012 11:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.058 X-Spam-Level: X-Spam-Status: No, score=-103.058 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E47AmGbpE6if for ; Thu, 1 Nov 2012 11:57:57 -0700 (PDT) Received: from smtp141.dfw.emailsrvr.com (smtp141.dfw.emailsrvr.com [67.192.241.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1560321F881C for ; Thu, 1 Nov 2012 11:57:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A5A152982DA; Thu, 1 Nov 2012 14:57:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 228CB2983A0; Thu, 1 Nov 2012 14:57:45 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20121101094348.064ae730@resistor.net> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> Date: Thu, 1 Nov 2012 14:57:32 -0400 To: SM From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:57:58 -0000 I think one my points was too subtle. At 10:45 -0700 11/1/12, SM wrote: Looking at these two introductory statements: >Such notices are generally sent by email as it is the cheapest alternative >for businesses which rely on this critical property available through Whois. >Domain names or email addresses is not a significant internationalization >issue as there are existing specifications for that. If the implication is that while we have email and DNS standards for this but we lack postal standards, I'd point to the Universal Postal Union. Wikipedia has more information about them that I can give you. From what I've seen, I'd say they have already established postal standards for addressing that would fit the use case you mention. Perhaps the current state of the way WhoIs displays addresses could be described as "a mess" there are already standards defined. Registries ought to be collecting addresses in such a way to conform with what ever applicable standards exist. That "ought to" is not a responsibility of the WEIRDS WG, the protocol under development is not the place to make registries be compliant. The protocol ought to be able to assume that addresses be able to be represented in an already defined standard format. The point is - email, domain name, and postal addresses already have internationalized forms and that covers most of what we need to provide. Remarks, no, that is not covered. Remarks and what ever else not covered, I would bet, is not enough to require that the protocol under discussion here include any translation function. GIGO is probably all that is needed, relying on existing standards and collection/retention practices. The latter - I can't say "for sure." There might be a compelling reason to weave translation into this protocol, but I really doubt it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From sm@resistor.net Thu Nov 1 13:03:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CDB21F91E7 for ; Thu, 1 Nov 2012 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK710hX74edl for ; Thu, 1 Nov 2012 13:03:38 -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 CFDEB21F8D31 for ; Thu, 1 Nov 2012 13:03:27 -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 qA1K3LRd015286; Thu, 1 Nov 2012 13:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351800206; bh=DVNjHg7wgDyModqXjAx64koTV4uzVoekEZIFuA+F1CE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QcBwgok1SXkijBAUOmZGA5MHAEft6Rzr78uN2nVWyA4wPo/UlSyvbOv4P32yCPD9+ cgQigsmPD8UHI55IhVK8rQW165YkMPKFDZEmmSRcIgI08//nRzNG+OVyWUihqZZO17 quUdLaspAKDqufZIEEkE1OkQzuMCY3O+kOzaqY5w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351800206; i=@resistor.net; bh=DVNjHg7wgDyModqXjAx64koTV4uzVoekEZIFuA+F1CE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1mqZpY3SAtRm1xYyDk90pVWh+bGpovZsW2SQ8lY8fgJviTgDHO9nS0+c6iAVmzpNo bIVfoZPVwo9A8RzoeB92s4D1kliDCajMumpHs6oawiSWGQUcaBJmeoknBWLfbv5oJZ 5hb7u4BvaBJH9yQ4RTum/CzTQ+RbrLPCcX01sMHs= Message-Id: <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Nov 2012 13:02:30 -0700 To: Edward Lewis From: SM In-Reply-To: References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 20:03:39 -0000 Hi Ed, At 11:57 01-11-2012, Edward Lewis wrote: >If the implication is that while we have email and DNS standards for >this but we lack postal standards, I'd point to the Universal Postal >Union. Wikipedia has more information about them that I can give >you. From what I've seen, I'd say they have already established >postal standards for addressing that would fit the use case you mention. I read the Universal Postal Union practices. For example, let's say that one of the postal addresses should be written in English. I don't know whether someone outside this working group will not like that. The postcard example is somewhat straight-forward. There is an origin; there is a destination. In the case of Whois there isn't one destination. This is where language negotiation comes in. The protocol can do that. You still need the data in that language. >Perhaps the current state of the way WhoIs displays addresses could >be described as "a mess" there are already standards defined. >Registries ought to be collecting addresses in Yes. > such a way to conform with what ever applicable standards > exist. That "ought to" is not a responsibility of the WEIRDS WG, > the protocol under development is not the place to make registries > be compliant. The protocol ought to be able to assume that > addresses be able to be represented in an already defined standard format. I cannot tell registries what to do. :-) I am trying to look at this differently. The question I would ask is: tell "us" how you want to do it. It might then be clearer to identify what the protocol should do instead of designing a protocol with its set of constraints. >The point is - email, domain name, and postal addresses already have >internationalized forms and that covers most of what we need to >provide. Remarks, no, that is not Steve Sheng mentioned the following [1]: "- Registrant Name: Local language with language-script tags (e.g. Using tags as defined by RFC 5646) - Registrant contact information: local language with language-script tags One issues that is in active discussion within ICANN is in the case a registrant submit information in his/her local language/script, whether there should a requirement to translate and transliterate (into latin) this information. The policy community is starting a policy development process on that." There isn't a mention of a standard for postal addresses. The language issue is mentioned. I prefer to look at this from a different angle (I commented on that above). Regards, -sm 1. http://www.ietf.org/mail-archive/web/weirds/current/msg01763.html From Ed.Lewis@neustar.biz Thu Nov 1 13:36:48 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C185A21F8AEB for ; Thu, 1 Nov 2012 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZtBPjih4j2O for ; Thu, 1 Nov 2012 13:36:47 -0700 (PDT) Received: from smtp181.iad.emailsrvr.com (smtp181.iad.emailsrvr.com [207.97.245.181]) by ietfa.amsl.com (Postfix) with ESMTP id 85A5E21F896E for ; Thu, 1 Nov 2012 13:36:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp58.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D81CE3082F9; Thu, 1 Nov 2012 16:36:44 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp58.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 1AF253081F2; Thu, 1 Nov 2012 16:36:43 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> Date: Thu, 1 Nov 2012 16:36:28 -0400 To: SM From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-860320292==_ma============" Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 20:36:49 -0000 --============_-860320292==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 13:02 -0700 11/1/12, SM wrote: >I cannot tell registries what to do. :-) I am trying to look at this >differently. The question I would ask is: tell "us" how you want to do it. It's clear that the protocol will not drive what registries do (or have been doing). However, the protocol does not need to parrot exactly what is in the registries' internal databases. The protocol design would be wise to look to existing standards from relevant experts and build around that. Acquiescence to the mess that appears now will only perpetuate the problem we have now with freeform WhoIs. If the protocol has a strict standard to implement, the implementers of the code that reads the registry database will have to do some conversion - stopping short of translation. I do know that if a relevant standard becomes required on a registry implementation, the registry will re-tool and comply. >There isn't a mention of a standard for postal addresses. The language >issue is mentioned. I prefer to look at this from a different angle >(I commented on that above). Whether the quoted passage was from an ICANN document or discussion or just appeared in a message purporting this, the IETF isn't beholden to that requirement. The IETF listens to requirements (even from ICANN) but that doesn't mean we have to settle for what is decided elsewhere. I sound like I'm advocating that we ignore ICANN but I do not intend to, just stating that the IETF is independent. As part of the independence, we need to see if what we produce is technically sound. In the policy sphere there are many interests that push for a compromise, and that is fine. But in the technical sphere what rules is whether a design point is solid - will the solution scale, will the solution be nimble, etc. This is where I get the "look at the UPU standards" as a recommendation. No matter what information the registries do collect, no matter what the regulator (ICANN or not) requires, if the addresses are going to matter when sending postal mail, internationally, then what is marshalled in the WEIRDS WG protocol has to be a super-set of the information needed to address an envelope. The thread topic is internationalization. The long plank I've been walking on is to assume that a registry will want to supply an address in what ever "colloquial" form them want as well as a form compatible with international mailing. And that would be the basis for a requirement for the WEIRDS WG protocol. That the protocol allow for the marshalling of an address in registry-specific string and/or in an international form. The reason for this - I am thinking of how to simplify the implementation of the client. I don't want to see clients need to have huge case statements (if it is from "US.", I display this way, if it is from "XN--P1AI." I do it that way and so on). My desire is to constrain the protocol to what is needed, so as to avoid the "mess" we have now. --- Here's some background on my angst here. I was investigating a case of cache poisoning not too long ago. (Yes, cache poisoning, but it wasn't an attack.) During the investigation I came across two domain names. The two names were registered in a place far, far away, and with a street address that was hard for me to grok. I did notice though that the cellphone number of the two domain names was the same, so I could conclude there was a relationship between the two domain names. How that related to the cache poisoning isn't important, the problem where was trying to determine if two registrations were from the same person/entity/organization or possible a pair of antagonists working in close proximity. Had there been a "standard way" to present the addresses, I might have seen the relationship sooner. As I mentioned it wasn't until my eyes slipped down to the telephone numbers that I could uncover a clue. Would a standard have helped? I bet it would, perhaps not, but I bet it would. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! --============_-860320292==_ma============ Content-Type: text/html; charset="us-ascii" Re: [weirds] Internationalization Issues
At 13:02 -0700 11/1/12, SM wrote:

>I cannot tell registries what to do. :-)  I am trying to look at this
>differently.  The question I would ask is: tell "us" how you want to do it.

It's clear that the protocol will not drive what registries do (or have been doing).  However, the protocol does not need to parrot exactly what is in the registries' internal databases.

The protocol design would be wise to look to existing standards from relevant experts and build around that.  Acquiescence to the mess that appears now will only perpetuate the problem we have now with freeform WhoIs.

If the protocol has a strict standard to implement, the implementers of the code that reads the registry database will have to do some conversion - stopping short of translation.  I do know that if a relevant standard becomes required on a registry implementation, the registry will re-tool and comply.

>There isn't a mention of a standard for postal addresses.  The language
>issue is mentioned.  I prefer to look at this from a different angle
>(I commented on that above).

Whether the quoted passage was from an ICANN document or discussion or just appeared in a message purporting this, the IETF isn't beholden to that requirement.  The IETF listens to requirements (even from ICANN) but that doesn't mean we have to settle for what is decided elsewhere.  I sound like I'm advocating that we ignore ICANN but I do not intend to, just stating that the IETF is independent.

As part of the independence, we need to see if what we produce is technically sound.  In the policy sphere there are many interests that push for a compromise, and that is fine.  But in the technical sphere what rules is whether a design point is solid - will the solution scale, will the solution be nimble, etc.  This is where I get the "look at the UPU standards" as a recommendation.

No matter what information the registries do collect, no matter what the regulator (ICANN or not) requires, if the addresses are going to matter when sending postal mail, internationally, then what is marshalled in the WEIRDS WG protocol has to be a super-set of the information needed to address an envelope.

The thread topic is internationalization.  The long plank I've been walking on is to assume that a registry will want to supply an address in what ever "colloquial" form them want as well as a form compatible with international mailing.  And that would be the basis for a requirement for the WEIRDS WG protocol.  That the protocol allow for the marshalling of an address in registry-specific string and/or in an international form.

The reason for this - I am thinking of how to simplify the implementation of the client.  I don't want to see clients need to have huge case statements (if it is from "US.", I display this way, if it is from "XN--P1AI." I do it that way and so on).  My desire is to constrain the protocol to what is needed, so as to avoid the "mess" we have now.

---

Here's some background on my angst here.  I was investigating a case of cache poisoning not too long ago.  (Yes, cache poisoning, but it wasn't an attack.)  During the investigation I came across two domain names. The two names were registered in a place far, far away, and with a street address that was hard for me to grok.  I did notice though that the cellphone number of the two domain names was the same, so I could conclude there was a relationship between the two domain names.  How that related to the cache poisoning isn't important, the problem where was trying to determine if two registrations were from the same person/entity/organization or possible a pair of antagonists working in close proximity.

Had there been a "standard way" to present the addresses, I might have seen the relationship sooner.  As I mentioned it wasn't until my eyes slipped down to the telephone numbers that I could uncover a clue.  Would a standard have helped?  I bet it would, perhaps not, but I bet it would.


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

2012...time to reuse those 1984 calendars!
--============_-860320292==_ma============-- From johnl@iecc.com Thu Nov 1 17:17:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E321F9888 for ; Thu, 1 Nov 2012 17:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.363 X-Spam-Level: X-Spam-Status: No, score=-111.363 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJOqxTI3HiNz for ; Thu, 1 Nov 2012 17:17:39 -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 51D8321F988F for ; Thu, 1 Nov 2012 17:17:39 -0700 (PDT) Received: (qmail 65519 invoked from network); 2 Nov 2012 00:17:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Nov 2012 00:17:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50931122.xn--9vv.k1211; i=johnl@user.iecc.com; bh=9AvUWYDDUOvx7jwqfTCyANjU+SeWOanBdDrto00F9a0=; b=YxPd/9w4mt3OMQ8xVtCjDJVdd/m7UFjBJdjDJm6L/G8nwxpFFrCdnKUxWoHnBDtFRyIh9qWUwv82EXUCvywZXHkqturpkSNZR5SNksUgwXkdgVwmykXMkjNLIRKlp5vNBG7g1K0D2TDVhgGBViK+WbSfrWGNNMAV0GclteExSN0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50931122.xn--9vv.k1211; olt=johnl@user.iecc.com; bh=9AvUWYDDUOvx7jwqfTCyANjU+SeWOanBdDrto00F9a0=; b=Cf3PtYrjMAG1LbpsfEPt0oTZ7CCqEuTcxetkUQxh0A6rOOOlvCZ0reGK6mP4PoZwrs3rvTfujam6D9dIcYKtWJj2pI+P2wjwyoIDDz7QkQgQLxQ6+qmPDYdzuQFXL4XxyWEpUpGnCh5EjZwEpH0bfM6c5QoAl9ba9l9pewOtWWg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Nov 2012 00:17:16 -0000 Message-ID: <20121102001716.57862.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Security Requirements: Authentication X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 00:17:40 -0000 >If any two "servers" of the WEIRDS WG protocol ever need to >coordinate, the two administrations/servers would need to be able to >mutually authenticate. I don't see why server A would need to authenticate server B, since it'll just be sending a note to the client to ask server B, but it would be nice if the client could use the same credentials. That's what we mean by federated authentication. There's certainly no need to invent something new, just include existing schemes, notably OAuth, in the list of ones to use. R's, John From johnl@iecc.com Thu Nov 1 17:22:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33421F9766 for ; Thu, 1 Nov 2012 17:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.572 X-Spam-Level: X-Spam-Status: No, score=-111.572 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IQxaCIhorSF for ; Thu, 1 Nov 2012 17:22:08 -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 C538E21F8FDB for ; Thu, 1 Nov 2012 17:22:07 -0700 (PDT) Received: (qmail 66949 invoked from network); 2 Nov 2012 00:22:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Nov 2012 00:22:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5093122f.xn--3zv.k1211; i=johnl@user.iecc.com; bh=yzxYRmiGZgD57i+HpAG6UN/2gKFOAU25ndL5Ld3dGdw=; b=Ynek8VYbhVYXKzivpPY3i4+omzJrFx6YoX+8vvTsrvkKRhLt7rUCVpxOvIMIvj73CObxCpzRZK4gIxyP7Pc7eovbmBLEThOQuHJplKfO91n1/eggCo8bKWyP7EkmvbA6Z3GNbJv6Vd9854xAhLho/+tifhD1Lxc7t5HqGoWAqSA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5093122f.xn--3zv.k1211; olt=johnl@user.iecc.com; bh=yzxYRmiGZgD57i+HpAG6UN/2gKFOAU25ndL5Ld3dGdw=; b=Sw8apjVn3yHQQk8HVyWU5V6jEO7Jn1aXPTKyH3MBbsDPy7NTmA3D55K0DNuCJjpmqPXPG/92vNEh00JnjJYHPzSMJaCJZVspI++7vM7AzoAN3OjYv4FfMzV7exZer+adFzs7CC9evWy6YABgglDCE2FbwRxhUCROcAN9I+ctDpY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Nov 2012 00:21:45 -0000 Message-ID: <20121102002145.58033.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Security Requirements: Authorization X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 00:22:08 -0000 >Use case - ithe server for .malicious is not authorized to originate >information about neither the IETF.ORG registration nor the >133.0.0.0/8 IPv4 address range. > >Ways to combat this is to declare an authorization model for the >protocol and to require any data integrity protection to identify >the source of the protection, like the signature. This is isomorphic to the bootstrapping problem. A highly effective way to avoid getting bad information from the wrong server is to know which is the right server or servers for each question, and ask only those servers. Since I think we all agree that we need to solve the boostrap problem, how about if we just do that and not invent something else that will only benefit people get their bootstrap wrong? R's, John From bje@apnic.net Thu Nov 1 18:07:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C745221F8882 for ; Thu, 1 Nov 2012 18:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-Rnoj1cP4lR for ; Thu, 1 Nov 2012 18:07:57 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 6578221F866E for ; Thu, 1 Nov 2012 18:07:54 -0700 (PDT) Received: from dynamic207.apnic.net (dynamic207.apnic.net [203.119.42.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D151CB6877; Fri, 2 Nov 2012 11:07:52 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_676F80BA-93CF-4A7D-A623-725ADAC47E1A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Fri, 2 Nov 2012 11:07:52 +1000 Message-Id: <719DC433-418B-48FE-9DCE-A6ABE2A8676A@apnic.net> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 01:07:57 -0000 --Apple-Mail=_676F80BA-93CF-4A7D-A623-725ADAC47E1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 02/11/2012, at 6:36 AM, Edward Lewis wrote: > It's clear that the protocol will not drive what registries do (or = have been doing). However, the protocol does not need to parrot exactly = what is in the registries' internal databases. The WG is neither chartered nor able to fix problems with the contents = of registries. If the protocol cannot carry existing information, it = will carry none at all. I sympathise with your use case for more useful = address information, but the right venue to try to force registries to = get better data is ICANN (or the RIR processes), not the IETF. I do = recognise the difficulty of that task - which is why I don't think we = should attempt to force the unenforceable via a protocol decision. The questions about i18n that I see before the WG are: 1) Can the protocol carry information in more than one language or = script? 2) Should there be a mechanism for indicating to the client what = language or script is in use, and at what granularity? 3) Should there be a mechanism for allowing the client to indicate = preferred languages for the response? I don't think there are any useful questions about what should happen to = the data. If a registry only has data in one language, that's the = language it's going to send that data in, no matter what the client asks = for, or what the protocol specification dictates. #1 is trivial - the de facto character encoding for RDAP responses is = UTF-8, which can encode a pretty broad range of things, and servers may = signal an alternative character set if they prefer. For #2, there is the HTTP header, which is meta-data and semantically = indicates the best language for consumption of the data, rather than the = language the data is necessarily in, or there is a language tag in the = response, either for the entire response, or parts thereof, and I don't = think I've seen any other suggestions. For #3, there is the HTTP request and response headers, again = semantically subtle, and URI query parts. I will put up a strawman and suggest that the using-http draft adopts = something along these lines: --- snip --- 4.2.1 Indication of preferred language A client MAY include a query parameter to indicate preferred language = for responses. A server MAY choose to take that into consideration when = preparing a response. The format of the language query parameter is: lang=3D --- snip --- And that the json-response draft adopts something along these lines: --- snip --- 3. Common Data Types =85 lang: An RFC 5646 language tag indicating the primary language of = the object =85 --- snip --- With the "lang" attribute added to each object type defined. Thoughts? Byron --Apple-Mail=_676F80BA-93CF-4A7D-A623-725ADAC47E1A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDIwMTA3NTNaMCMGCSqGSIb3DQEJBDEWBBR4 UESpqaZb4/S2LgI0dw81ljwwfjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBceJrr/lSB/Ura sMMkF0nQTNtiX4OOuZZQ4bWhFul/CjMZuGqSM/dWDcNiDlHV5yskknojxldbJAcUPdPnSarQL2qu DAp0Wt+XvMyLbbljWte6qFkGx++LXfTC9uc+1hVHwECJTaO6Ubum2vHRxi+Y7+c68fLzt3d5/BXk SChGCRp7Va7YAABpFj4b9vk7o8+zDlqXEiK1CNin9GrwL6OJeN00HrCcIAFgsGwroKnurn388/ng DWRo74IfWhdvA7UbQhwd2OOq2Rl1c7gHDgHxqBgQhmoLDmGw+bkdEkdVHEGiydzEYUCqtSx8vEyB v8u7+2YNNH+3tdq/lV5LQCi+AAAAAAAA --Apple-Mail=_676F80BA-93CF-4A7D-A623-725ADAC47E1A-- From andy@arin.net Fri Nov 2 03:31:42 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73421F99BF for ; Fri, 2 Nov 2012 03:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z47qVTdhlMdK for ; Fri, 2 Nov 2012 03:31:41 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4CADA21F99BB for ; Fri, 2 Nov 2012 03:31:41 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 8C4CF1652C0; Fri, 2 Nov 2012 06:31:40 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9D0DD1652BD; Fri, 2 Nov 2012 06:31:39 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 2 Nov 2012 06:30:51 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Fri, 2 Nov 2012 06:30:29 -0400 From: Andy Newton To: Byron Ellacott , Edward Lewis Thread-Topic: [weirds] Internationalization Issues Thread-Index: Ac2oJlgRtaHIIukgTomzDF6pihPMsgQRyacAAAMtTgAAAoSgAAACRNkAAAEvsAAACXqBAAALRGuA Date: Fri, 2 Nov 2012 10:30:28 +0000 Message-ID: In-Reply-To: <719DC433-418B-48FE-9DCE-A6ABE2A8676A@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: <45347C98F2B5C740B2E8FE5E7E57C2C8@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 10:31:42 -0000 On 11/1/12 9:07 PM, "Byron Ellacott" wrote: >On 02/11/2012, at 6:36 AM, Edward Lewis wrote: > >> It's clear that the protocol will not drive what registries do (or have >>been doing). However, the protocol does not need to parrot exactly what >>is in the registries' internal databases. > >The WG is neither chartered nor able to fix problems with the contents of >registries. If the protocol cannot carry existing information, it will >carry none at all. I sympathise with your use case for more useful >address information, but the right venue to try to force registries to >get better data is ICANN (or the RIR processes), not the IETF. I do >recognise the difficulty of that task - which is why I don't think we >should attempt to force the unenforceable via a protocol decision. I am in 100% agreement here. Registries already have content and they will only be able to give that content out in the form they have it. Forcing registries down a data clean-up effort or through some data transformation effort seems like a non-starter. > >The questions about i18n that I see before the WG are: > >1) Can the protocol carry information in more than one language or script? > >2) Should there be a mechanism for indicating to the client what language >or script is in use, and at what granularity? > >3) Should there be a mechanism for allowing the client to indicate >preferred languages for the response? I agree with this. > >I don't think there are any useful questions about what should happen to >the data. If a registry only has data in one language, that's the >language it's going to send that data in, no matter what the client asks >for, or what the protocol specification dictates. > >#1 is trivial - the de facto character encoding for RDAP responses is >UTF-8, which can encode a pretty broad range of things, and servers may >signal an alternative character set if they prefer. > >For #2, there is the HTTP header, which is meta-data and semantically >indicates the best language for consumption of the data, rather than the >language the data is necessarily in, or there is a language tag in the >response, either for the entire response, or parts thereof, and I don't >think I've seen any other suggestions. > >For #3, there is the HTTP request and response headers, again >semantically subtle, and URI query parts. > >I will put up a strawman and suggest that the using-http draft adopts >something along these lines: > >--- snip --- >4.2.1 Indication of preferred language > >A client MAY include a query parameter to indicate preferred language for >responses. A server MAY choose to take that into consideration when >preparing a response. The format of the language query parameter is: > > lang=3D >--- snip --- I don't think we should be using query parameters where there is already an HTTP header for the purpose. Other than that, I like this. > >And that the json-response draft adopts something along these lines: > >--- snip --- >3. Common Data Types >=8A > lang: An RFC 5646 language tag indicating the primary language of >the object >=8A >--- snip --- > >With the "lang" attribute added to each object type defined. Again, 100% agreement. -andy From Ed.Lewis@neustar.biz Fri Nov 2 06:15:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9565D21F8A08 for ; Fri, 2 Nov 2012 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8rJtBORSrSe for ; Fri, 2 Nov 2012 06:15:56 -0700 (PDT) Received: from smtp151.iad.emailsrvr.com (smtp151.iad.emailsrvr.com [207.97.245.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9934F21F89E0 for ; Fri, 2 Nov 2012 06:15:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp35.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C37472C8402; Fri, 2 Nov 2012 09:15:52 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp35.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 00E302C804F; Fri, 2 Nov 2012 09:15:49 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 Nov 2012 09:13:51 -0400 To: Andy Newton From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "weirds@ietf.org" Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 13:15:57 -0000 At 10:30 +0000 11/2/12, Andy Newton or Byron Ellacott wrote: >I am in 100% agreement here. Registries already have content and they will >only be able to give that content out in the form they have it. Forcing >registries down a data clean-up effort or through some data transformation >effort seems like a non-starter. My point still hasn't been made. Developing the server for a registry won't cause the registry to reform it's data collection activities. But the server doesn't have to be GIGO with regards to what's in the database. >>4.2.1 Indication of preferred language >> >>A client MAY include a query parameter to indicate preferred language for >>responses. A server MAY choose to take that into consideration when >>preparing a response. The format of the language query parameter is: >> >> lang= >>--- snip --- In DNSSEC we have a similar problem, instead of human language though it was cryptographic algorithm and hash. Nowadays the problem has largely disappeared because most zones are signed with just one algorithm but when designing the protocol we imagined a zone might be signed with a collection of algorithms and the client could pick and choose which to use. In DNSSEC we had to avoid any sort of negotiation. To date DNS has punted the solution, primarily because the operators have eliminated the problem (by signing with just one algorithm, eliminating choice). There is a proposal to allow clients to specify what algorithm to use, but that is a proposal that is going nowhere because it causes as many problems as it solves. Ultimately what I'm saying is: Don't try to reinterpret (such as translate) data in the protocol. Limit the amount of negotiation for the content (like, no round trips for that) Make sure there's a conduit for an established international address format This effort won't force registries to come to a common collection method, but the protocol can restrict the ways in which data is carried. "Liberal in what you accept, conservative in what you send" applies here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From johnl@iecc.com Fri Nov 2 08:29:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C259321F8B96 for ; Fri, 2 Nov 2012 08:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.781 X-Spam-Level: X-Spam-Status: No, score=-111.781 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoRi9n5FPbCn for ; Fri, 2 Nov 2012 08:29:14 -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 9995E21F8AAF for ; Fri, 2 Nov 2012 08:29:14 -0700 (PDT) Received: (qmail 10450 invoked from network); 2 Nov 2012 15:29:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Nov 2012 15:29: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:vbr-info; s=5093e6c9.xn--3zv.k1211; i=johnl@user.iecc.com; bh=fBHJcj5W9vgbNqHKAcMiyUG82Gmzy15xlNUzgN2fzkY=; b=nkCMLjJ8yb2i4koZColgTCreVFnvkMm+xfjcymxRd8UM4TO8PsPNA3EGT67iirLmzOmjkZgK2vNiy2vO7kkPjT8UFb/HlNYZQUsWtpP33qqJ0Gn+9BENSa5QL97iRdeX283rgu1+veemrx2w3/zmZxwXxSXEtnD2KtSKnSj+gCw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5093e6c9.xn--3zv.k1211; olt=johnl@user.iecc.com; bh=fBHJcj5W9vgbNqHKAcMiyUG82Gmzy15xlNUzgN2fzkY=; b=opNLY3ClNHi+/yOlQ1UdL+/yc5LuvoisQTF8neWroKcUpMSLfMKEyYdTnwV3F4PzpT690BLqeHk8k3QjUOmJbMbJT6P1Prq1/kScSGEHM9OPntTznkH+9PpQcWOQM3CakRbRHhGDUPPFdvk1BIRYgVjckitcatk6a8JTNsaCLS0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Nov 2012 15:28:51 -0000 Message-ID: <20121102152851.92298.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:29:15 -0000 >Don't try to reinterpret (such as translate) data in the protocol. >Limit the amount of negotiation for the content (like, no round trips for that) >Make sure there's a conduit for an established international address format HTTP already has the Accept-Language request header, and Content-Language entity header. Are those adequte for what WEIRDS needs? If not, why not? From Ed.Lewis@neustar.biz Fri Nov 2 08:42:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788C21F8BDB for ; Fri, 2 Nov 2012 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipHuBo5v7EyH for ; Fri, 2 Nov 2012 08:42:10 -0700 (PDT) Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) by ietfa.amsl.com (Postfix) with ESMTP id E2EA821F8BBC for ; Fri, 2 Nov 2012 08:42:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 881C7170742; Fri, 2 Nov 2012 11:42:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 647B9170240; Fri, 2 Nov 2012 11:42:08 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20121102152851.92298.qmail@joyce.lan> References: <20121102152851.92298.qmail@joyce.lan> Date: Fri, 2 Nov 2012 11:42:00 -0400 To: John Levine From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:42:11 -0000 At 15:28 +0000 11/2/12, John Levine wrote: >HTTP already has the Accept-Language request header, and >Content-Language entity header. Are those adequte for what WEIRDS >needs? If not, why not? I don't know. And here is why I don't know. I have seen this problem pop up which would make me say no. (Perhaps this doesn't apply.) In DNS there is the TXT record which is widely assumed to hold a string. In some software developments, allocating a String type will call into play UTF encoding libraries, etc. When a customer inadvertently inserts a non-printable (in ASCII) character in the TXT record, extra processing is done deep in the software stack and, well, chaos ensues. The question is whether that functionality of the assume solution tool is beneficial to the problem to be solved or not. It could be that the features of the tool are overkill for the problem to be solved. (Low probability, but that's where my doubt would lie.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From johnl@taugh.com Fri Nov 2 09:29:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66011E80CC for ; Fri, 2 Nov 2012 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04XLdQQct727 for ; Fri, 2 Nov 2012 09:29:24 -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 BE6B311E80B8 for ; Fri, 2 Nov 2012 09:29:22 -0700 (PDT) Received: (qmail 32232 invoked from network); 2 Nov 2012 16:29:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7de7.5093f4e1.k1211; bh=ZPEdPUoyHHgvNbWNI51FDK6Z/iO6aqCInQb3Mfs5Hu0=; b=RvFgFanPd5h/SOdpvoLgzOzQsswX702b5r8uk1+P87I5ucPNsXIDcYExCluD2hrpV8pLm881IgScefQX3BWjq/Vh5ehGS8aaE4Pw30PyH+g0A6dlYKdf+XU8tfz/CvpHKnhKi7Zc3xcsfNfe/QnwbVzo4ySftARCZCrKzauEarE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7de7.5093f4e1.k1211; bh=ZPEdPUoyHHgvNbWNI51FDK6Z/iO6aqCInQb3Mfs5Hu0=; b=CILQpy1uHZAxqI1zqXhj0ksmaYaGLpnsZtuCttfs5+6mIm5ik87/noyNoosOT2GKyDKMI6fe7UGFBZvgg9cN5AVJBxS0emxohQ4rUXAyoZhNoG+hpop3/PGCa+WmusNlukHKEfSGqIH0AQ7uz8MoKQ4/roB+XHNUfe7gL/sk8QA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 2 Nov 2012 16:28:59 -0000 Date: 2 Nov 2012 12:29:20 -0400 Message-ID: From: "John R Levine" To: "Edward Lewis" In-Reply-To: References: <20121102152851.92298.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1533723345-1351873761=:92999" Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:29:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1533723345-1351873761=:92999 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> HTTP already has the Accept-Language request header, and >> Content-Language entity header. Are those adequte for what WEIRDS >> needs? If not, why not? > > I don't know. And here is why I don't know. > > ... In some software developments, allocating a String type will > call into play UTF encoding libraries, etc. When a customer inadvertently > inserts a non-printable (in ASCII) character in the TXT record, extra > processing is done deep in the software stack and, well, chaos ensues. ... The DNS suffers from a design environment where the only language was English, and the only code was ASCII, so all I18N had to be shoehorned in later via a mountain of kludges. The web is a decade newer, and it probably also helps that it was designed in Switzerland, where people routinely use two or three languages every day, and in the 1990s there were way too many extended ASCII variants. So every web request specifically says what languages and codes it can handle, and every web resposne says what language it's in and what code it uses. This really works; set your browser's preferred language to French or German, and a lot of web pages will look different when you visit them. We don't need the web's full flexible language glory, so we can specify a subset to use. In particular, I see no reason for WEIRDS to use any code other than UTF-8, keeping in mind that ASCII is a proper subset of UTF-8. The language negotiation works well and I see no point to trying to invent something else. For stuff like postal address formats, the best we can do it point people at external standards and encourage them to use those formats. If they don't, I expect most of us would be willing to take our chances with whatever formats the registries and registrars can provide. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1533723345-1351873761=:92999 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDIxNjI5 MjBaMCMGCSqGSIb3DQEJBDEWBBThs8TpXNu8LCn6qzceboCjnxg6SDB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQClTw/o84x/5DLjsoSHMu1hHpFjmNjJSnc2Av/+YKSzS5H8GmPNDe344dS/ vQfaaqOIQiBrEWsWvKKK6iE5R1zAnZ91DSasfdKSV1hC2g+DCJwXTX3WJKmt lfvbtVhI8ICUcnWKixn8aX2Qwk0OB/9youibXkD+SaHwrEfkmPBhwdfw8WF3 evc/B0FwLBf2yiWAMbf4mgtpYBBPwlNjkUvrDKCMaBmJLMyf5cGkLvTWmSss 5tgmqhiOyZfAbSt07zp5YQ0mQx/j+59JQy7+ICNQopXLjVSv3OmDnCdnte4I 5PXOioKo64RXnCHIN2Ic1617yzPKFbs/9LmDSGRxHy3P --3825401791-1533723345-1351873761=:92999-- From fobispo@isc.org Sat Nov 3 20:30:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE221F8AD1 for ; Sat, 3 Nov 2012 20:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDVNMqCRWX2k for ; Sat, 3 Nov 2012 20:30:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B7AFF21F8ACA for ; Sat, 3 Nov 2012 20:30:18 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4AB21CA03A; Sun, 4 Nov 2012 03:30:11 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 15C76216C80; Sun, 4 Nov 2012 03:30:11 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Sat, 3 Nov 2012 20:30:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121102152851.92298.qmail@joyce.lan> To: John R Levine X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 03:30:19 -0000 Hi All, DNS doesn't care about languages, it only cares about labels which are = composed of bytes. the problem is with client libraries, and how to = collect the user input into the proper byte representation. The IDN implementation is there to normalize how the data is marshaled = into the DNS. Regards, On Nov 2, 2012, at 9:29 AM, John R Levine wrote: > The DNS suffers from a design environment where the only language was = English, and the only code was ASCII, so all I18N had to be shoehorned = in later via a mountain of kludges. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From fobispo@isc.org Sat Nov 3 20:39:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2721F9481 for ; Sat, 3 Nov 2012 20:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gw0Ek5NBVgR for ; Sat, 3 Nov 2012 20:39:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76721F9492 for ; Sat, 3 Nov 2012 20:39:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9A9275FA15E; Sun, 4 Nov 2012 03:39:18 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A7D71216C3D; Sun, 4 Nov 2012 03:39:16 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Sat, 3 Nov 2012 20:39:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C0E6D6E-5083-4F99-BD77-58BFE42C4557@isc.org> References: To: Andy Newton X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 03:39:30 -0000 This is why I think it's prudent to have WEIRDS match the capabilities = of EPP and its extension mechanisms. We are not going to be able to solve registry data problems, we just = need to focus on registry data representation to serve the purpose of a = modern whois suitable for consumption of both machines and human beings. Registries (at least name registries using EPP), collect data in = "international" format, that is, with US-ASCII only and in "localized" = form using UTF-8. There is no point on having a way to query in a = particular language because we are limited to what the registry has, so = at most, we should be able to specify the response in 'international' = form or in 'localized' form if available, and at most, we just just turn = on the UTF-8 encoding to make sure that whatever is parsing it, encodes = it into the proper format. It makes no difference if we provide a label saying 'this is in spanish' = or 'this is in french', at the end, the data will have to be consumed = equally. Regards On Nov 2, 2012, at 3:30 AM, Andy Newton wrote: >> The WG is neither chartered nor able to fix problems with the = contents of >> registries. If the protocol cannot carry existing information, it = will >> carry none at all. I sympathise with your use case for more useful >> address information, but the right venue to try to force registries = to >> get better data is ICANN (or the RIR processes), not the IETF. I do >> recognise the difficulty of that task - which is why I don't think we >> should attempt to force the unenforceable via a protocol decision. >=20 >=20 > I am in 100% agreement here. Registries already have content and they = will > only be able to give that content out in the form they have it. = Forcing > registries down a data clean-up effort or through some data = transformation > effort seems like a non-starter. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From superuser@gmail.com Sat Nov 3 22:25:40 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5E21F960C for ; Sat, 3 Nov 2012 22:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkhI4PPNbY5g for ; Sat, 3 Nov 2012 22:25:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8105B21F9481 for ; Sat, 3 Nov 2012 22:25:39 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3698429lbo.31 for ; Sat, 03 Nov 2012 22:25:38 -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=8/9gn6qFiH4mZOJhmIN8Pg69oN9+Bcg9XJZTzm9sHN0=; b=TyEYMqA8gAxaIfqNKkU+WB/Gbyj5v9F7m8LXL1lcNZ+Lv/Dw4cniFrI0iVbamTE5+s /jcmcYtqKWr0DcmyKG20hwX19HJ39kmzXhYnvY3sug8lPoHvnZfOvygoep+Kyapf4nUs LfKbKoVGPV/YkRI79daANPkknOkqCcS9QfeWOZR6osNxdOmFp8QWQUivcjR6dgyCAJ/r Sutu2wSoWXCHFPhlNfAynFCB2jItngpY2KqhPPBzoCfCpp/K9jlDH4DkxT7Wo1TjOxJr 959fqYwZjiKTgnZpPjnlglOL0pDDrcGt5Xw1AJVtD1aWfAZ26BODdC3g198FUip3KxIf BVvA== MIME-Version: 1.0 Received: by 10.112.47.228 with SMTP id g4mr2393044lbn.21.1352006738420; Sat, 03 Nov 2012 22:25:38 -0700 (PDT) Received: by 10.112.83.232 with HTTP; Sat, 3 Nov 2012 22:25:38 -0700 (PDT) Date: Sat, 3 Nov 2012 22:25:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=bcaec554ddfe60a52304cda4994a Subject: [weirds] Presentations for Monday X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 05:25:40 -0000 --bcaec554ddfe60a52304cda4994a Content-Type: text/plain; charset=ISO-8859-1 Anybody who has an agenda slot for Monday and has slides but has not yet submitted a slide deck, please do so ASAP. We will likely not accept new slide decks for use during Monday's meeting after about noon on Monday. Please also note that we will probably rework the agenda slightly to focus on issues rather than on documents. We will post here when a revised agenda becomes available. Thanks, and see you all Monday afternoon. -MSK, co-chair --bcaec554ddfe60a52304cda4994a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anybody who has an agenda slot for Monday and has slides but has not yet submitted a slide deck, please do so ASAP.=A0 We will likely not accept=20 new slide decks for use during Monday's meeting after about noon on Mon= day.

Please also note that we will probably rework the agenda slight= ly to focus on issues rather than on documents.=A0 We will post here when a= revised agenda becomes available.

Thanks, and see you all Monday afternoon.

-MSK, co-chair --bcaec554ddfe60a52304cda4994a-- From superuser@gmail.com Sun Nov 4 11:59:01 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8279921F85AE for ; Sun, 4 Nov 2012 11:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiFDIqodPWeE for ; Sun, 4 Nov 2012 11:59:01 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C688121F85DA for ; Sun, 4 Nov 2012 11:58:58 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so3918062lam.31 for ; Sun, 04 Nov 2012 11:58:57 -0800 (PST) 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=vqThb/jNWnqm4d0j+qhO+8mLJ0sPm9AuTrtbYUBpK6M=; b=FExiW1PN3Gg9+hP9G9cLXzmBFipw4Xd6T0RdBPmopndqYfgy41kDq/qrhhnyYdNLn6 HGWX8lbJBDt3KrlwXd5oKU6fjZLGL6Ri0wJ1lH0jP4OTvsVrgtASzivz/23eavN56Xw2 VGf/KbSULvJwVj3LikGi1w5keKnxAWRVDxVeGRsOmzNCeSTQ+StmflGhSkcvOv1H1Mdr vzX5QD/PNV+IGnpDCaJTO5xBAkwgh2vR5uqrdBD4GrvhUPnOoKWPK/tnZtOeFa1utK4y is5Zj9fKv3iGs1Xlz0+s3DsbxBgowdkcU3Ei+4qKuqjpj0yJQ11ten6iZp538BdWrDpi YSmA== MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr7205657lab.16.1352059137735; Sun, 04 Nov 2012 11:58:57 -0800 (PST) Received: by 10.112.83.232 with HTTP; Sun, 4 Nov 2012 11:58:57 -0800 (PST) Date: Sun, 4 Nov 2012 14:58:57 -0500 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=f46d04083adb9ebdaf04cdb0cca2 Subject: [weirds] Agenda updated X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 19:59:01 -0000 --f46d04083adb9ebdaf04cdb0cca2 Content-Type: text/plain; charset=ISO-8859-1 Olaf and I have updated the meeting's agenda to reflect the presentations we've received that relate to specific document issues. I will be uploading the received presentations later this evening. The resultant trimming of the agenda has left us with a lot of open space. Thus, presenters need not feel constrained by the size of the time slot you have, though if the slot you have feels too small please do let us know and we can make a better allocation. Accordingly, there's a sizeable AOB slot at the end. We'll let people use that time as needed for other topics that may be of interest to the WG, but in a less structured way. -MSK and Olaf --f46d04083adb9ebdaf04cdb0cca2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Olaf and I have updated the meeting's agenda to reflect the presentatio= ns we've received that relate to specific document issues.=A0 I will be= uploading the received presentations later this evening.

The result= ant trimming of the agenda has left us with a lot of open space.=A0 Thus, p= resenters need not feel constrained by the size of the time slot you have, = though if the slot you have feels too small please do let us know and we ca= n make a better allocation.

Accordingly, there's a sizeable AOB slot at the end.=A0 We'll l= et people use that time as needed for other topics that may be of interest = to the WG, but in a less structured way.

-MSK and Olaf
--f46d04083adb9ebdaf04cdb0cca2-- From Ed.Lewis@neustar.biz Sun Nov 4 12:47:14 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF9E21F88E6 for ; Sun, 4 Nov 2012 12:47:14 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZyyxa+iW45n for ; Sun, 4 Nov 2012 12:47:14 -0800 (PST) Received: from smtp153.ord.emailsrvr.com (smtp153.ord.emailsrvr.com [173.203.6.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA1F21F88E5 for ; Sun, 4 Nov 2012 12:47:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 64A2419808F; Sun, 4 Nov 2012 15:47:13 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 8D981198086; Sun, 4 Nov 2012 15:47:12 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20121102152851.92298.qmail@joyce.lan> Date: Sun, 4 Nov 2012 15:47:05 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 20:47:14 -0000 At 12:29 -0400 11/2/12, John R Levine wrote: >For stuff like postal address formats, ... When a thread begins to spin it's wheels, it's good to go back to the originating question. Ning's original question was whether section 12 of http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 is sufficient or should the text in section 7 of http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought back and augmented. I think section 12 of the newer document should say more. I do prefer extending what is in section 7 of the older text. It's hard to say if (much) more text is needed. Besides A and U-labels and IRI to URI, there should be something that talks about the other data (contract address, names, phone numbers) just to be clear on what is and what isn't considered. The text really ought to discourage any translation or other manipulation within elements of the protocol. And whether negotiation for language is a good idea or to be discouraged. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From francisco.arias@icann.org Sun Nov 4 14:30:37 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493F121F8787 for ; Sun, 4 Nov 2012 14:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzNzPcbq+Y-x for ; Sun, 4 Nov 2012 14:30:36 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 806FA21F8785 for ; Sun, 4 Nov 2012 14:30:36 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sun, 4 Nov 2012 14:30:35 -0800 From: Francisco Arias To: Peter Koch Date: Sun, 4 Nov 2012 14:30:25 -0800 Thread-Topic: [weirds] Security Requirements: Non-repudiation Thread-Index: Ac263AIERXC/X6nkS0yFliUjErdRIg== Message-ID: In-Reply-To: <20121022144317.GK9485@x28.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Security Requirements: Non-repudiation X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Nov 2012 22:30:37 -0000 On 10/22/12 7:43 AM, "Peter Koch" wrote: >There are TLD registries that offer "signed whois" today. Given that >this is >a third party attestation to some extent, I'm not sure it really falls >into the 'non-repudiation' category. Hi Peter, Which TLD registries offer "signed Whois"? Regards, __ Francisco. From nkong@cnnic.cn Sun Nov 4 23:13:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27CE21F8618 for ; Sun, 4 Nov 2012 23:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pU5V14p9PiB for ; Sun, 4 Nov 2012 23:13:21 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8C43D21F860D for ; Sun, 4 Nov 2012 23:13:15 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Nov 2012 15:13:01 +0800 From: "Ning Kong" To: "'Edward Lewis'" , References: <20121102152851.92298.qmail@joyce.lan> In-Reply-To: Date: Mon, 5 Nov 2012 15:12:55 +0800 Message-ID: <005701cdbb24$fc980390$f5c80ab0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMDQoYS8e1dbeQo35WYDx9+5TSgswKW1XFWAk2qcBYAoZKsuJVDkheg Content-Language: zh-cn Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 07:13:22 -0000 Hi Edward, > When a thread begins to spin it's wheels, it's good to go back to the > originating question. Thanks, Edward. > Ning's original question was whether section 12 of > http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 is sufficient or > should the text in section 7 of > http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought back and > augmented. The second link should be http://tools.ietf.org/html/draft-sheng-weirds-icann-rws-dnrd-01 > The text really ought to discourage any translation or other manipulation > within elements of the protocol. And whether negotiation for language is a > good idea or to be discouraged. I'm also curious whether negotiation for character code is a good idea or to be discouraged. This requirement was raised by Kentaro Mori [1]. [1] http://www.ietf.org/mail-archive/web/weirds/current/msg01769.html Cheers, Ning From zhoulinlin@cnnic.cn Sun Nov 4 23:42:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D977421F8AFC for ; Sun, 4 Nov 2012 23:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjQbqTvp1Wtd for ; Sun, 4 Nov 2012 23:42:35 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 6589021F8B13 for ; Sun, 4 Nov 2012 23:42:33 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Nov 2012 15:42:24 +0800 From: "Linlin Zhou" To: "'Byron Ellacott'" , "'Edward Lewis'" References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> <719DC433-418B-48FE-9DCE-A6ABE2A8676A@apnic.net> In-Reply-To: <719DC433-418B-48FE-9DCE-A6ABE2A8676A@apnic.net> Date: Mon, 5 Nov 2012 15:42:23 +0800 Message-ID: <00b701cdbb29$187a64a0$496f2de0$@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: Ac24lpeA1GiDyXgUTwivkXzMErOXaACkcccQ Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 07:42:36 -0000 Hi Byron, I have a question. Why is it necessary to add lang attribute to each object? IMHO, an attribute to a response record is enough. Could you elaborate it? Thanks. Linlin > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Byron Ellacott > Sent: Friday, November 02, 2012 9:08 AM > To: Edward Lewis > Cc: weirds@ietf.org > Subject: Re: [weirds] Internationalization Issues > > On 02/11/2012, at 6:36 AM, Edward Lewis wrote: > > > It's clear that the protocol will not drive what registries do (or have been doing). > However, the protocol does not need to parrot exactly what is in the registries' > internal databases. > > The WG is neither chartered nor able to fix problems with the contents of > registries. If the protocol cannot carry existing information, it will carry none at > all. I sympathise with your use case for more useful address information, but > the right venue to try to force registries to get better data is ICANN (or the RIR > processes), not the IETF. I do recognise the difficulty of that task - which is why I > don't think we should attempt to force the unenforceable via a protocol decision. > > The questions about i18n that I see before the WG are: > > 1) Can the protocol carry information in more than one language or script? > > 2) Should there be a mechanism for indicating to the client what language or > script is in use, and at what granularity? > > 3) Should there be a mechanism for allowing the client to indicate preferred > languages for the response? > > I don't think there are any useful questions about what should happen to the > data. If a registry only has data in one language, that's the language it's going to > send that data in, no matter what the client asks for, or what the protocol > specification dictates. > > #1 is trivial - the de facto character encoding for RDAP responses is UTF-8, which > can encode a pretty broad range of things, and servers may signal an alternative > character set if they prefer. > > For #2, there is the HTTP header, which is meta-data and semantically indicates > the best language for consumption of the data, rather than the language the data > is necessarily in, or there is a language tag in the response, either for the entire > response, or parts thereof, and I don't think I've seen any other suggestions. > > For #3, there is the HTTP request and response headers, again semantically > subtle, and URI query parts. > > I will put up a strawman and suggest that the using-http draft adopts something > along these lines: > > --- snip --- > 4.2.1 Indication of preferred language > > A client MAY include a query parameter to indicate preferred language for > responses. A server MAY choose to take that into consideration when > preparing a response. The format of the language query parameter is: > > lang= > --- snip --- > > And that the json-response draft adopts something along these lines: > > --- snip --- > 3. Common Data Types > . > lang: An RFC 5646 language tag indicating the primary language of the > object . > --- snip --- > > With the "lang" attribute added to each object type defined. > > Thoughts? > > Byron From zhoulinlin@cnnic.cn Mon Nov 5 00:25:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73821F841A for ; Mon, 5 Nov 2012 00:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgL6VdSYRy1Q for ; Mon, 5 Nov 2012 00:25:08 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 56C5C21F8202 for ; Mon, 5 Nov 2012 00:25:03 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Nov 2012 16:24:47 +0800 From: "Linlin Zhou" To: "'Edward Lewis'" , "'Andy Newton'" References: In-Reply-To: Date: Mon, 5 Nov 2012 16:24:47 +0800 Message-ID: <00b801cdbb2f$049b3530$0dd19f90$@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: Ac24/DvoDRN4+mhiS+WogpNhgoAbTgCMiTRg Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 08:25:08 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Edward Lewis > Sent: Friday, November 02, 2012 9:14 PM > To: Andy Newton > Cc: weirds@ietf.org > Subject: Re: [weirds] Internationalization Issues > > At 10:30 +0000 11/2/12, Andy Newton or Byron Ellacott wrote: > > ... > Ultimately what I'm saying is: > > Don't try to reinterpret (such as translate) data in the protocol. > Limit the amount of negotiation for the content (like, no round trips for that) > Make sure there's a conduit for an established international address format > > This effort won't force registries to come to a common collection method, but > the protocol can restrict the ways in which data is carried. "Liberal in what you > accept, conservative in what you send" > applies here. Object inventory did some data collection work. Maybe we can find some useful representation ways or results based on these data. Regards, Linlin From francisco.arias@icann.org Mon Nov 5 12:49:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FE621F84DF for ; Mon, 5 Nov 2012 12:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lhM6HEnsaIA for ; Mon, 5 Nov 2012 12:49:50 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E466421F84D8 for ; Mon, 5 Nov 2012 12:49:50 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 5 Nov 2012 12:49:47 -0800 From: Francisco Arias To: "weirds@ietf.org" Date: Mon, 5 Nov 2012 12:49:43 -0800 Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query-00 Thread-Index: Ac27lxdFydu5ruHgSVqNyZXGXnK0EA== Message-ID: In-Reply-To: <6.2.5.6.2.20120928070525.0b79b210@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 20:49:51 -0000 Hi Andy and Scott, I have the following comments/questions on the draft-ietf-weirds-rdap-query-00 draft. - 2.1. IP Network Path Segment Specification: you may want to include an example for IPv6. Isn't there missing text about representation of IPv6 address in URLs? - 2.2. Autonomous System Path Segment Specification: doesn't say in which format the AS has to be, shouldn't it say? - 2.3. Domain Path Segment Specification: specifies A-label format, I think U-label format should be allowed too. This is and internationalization issue. - 3. Extensibility: why do we need to have the "custom_" prefix? I'd think is enough to require the path segments to be unique, perhaps an IANA registry? Regards, __ Francisco. From shollenbeck@verisign.com Mon Nov 5 12:57:18 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D4821F8744 for ; Mon, 5 Nov 2012 12:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnlSxba+zPIO for ; Mon, 5 Nov 2012 12:57:17 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9321F873D for ; Mon, 5 Nov 2012 12:56:56 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUJgoGCzpfn8ud0SoAR3q6YLkA8l6Q22Q@postini.com; Mon, 05 Nov 2012 12:57:17 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA5KuqAt003008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 15:56:52 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 15:56:51 -0500 From: "Hollenbeck, Scott" To: Francisco Arias , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query-00 Thread-Index: Ac27lxdFydu5ruHgSVqNyZXGXnK0EAAAEz/A Date: Mon, 5 Nov 2012 20:56:51 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AD8EF@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <6.2.5.6.2.20120928070525.0b79b210@elandnews.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 20:57:18 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Francisco Arias > Sent: Monday, November 05, 2012 3:50 PM > To: weirds@ietf.org > Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 >=20 > Hi Andy and Scott, >=20 > I have the following comments/questions on the > draft-ietf-weirds-rdap-query-00 draft. >=20 > - 2.1. IP Network Path Segment Specification: you may want to include > an example for IPv6. Isn't there missing text about representation of > IPv6 address in URLs? >=20 > - 2.2. Autonomous System Path Segment Specification: doesn't say in > which format the AS has to be, shouldn't it say? I'll let Andy talk to these. > - 2.3. Domain Path Segment Specification: specifies A-label format, I > think U-label format should be allowed too. This is and > internationalization issue. Yes, it's an i18n issue, and they way we propose to address it is to keep t= he protocol simple and specify *one* format that can be easily converted as= needed. > - 3. Extensibility: why do we need to have the "custom_" prefix? I'd > think is enough to require the path segments to be unique, perhaps an > IANA registry? We use "custom_" as an example. It's not there as a mandate. Scott From aservin@lacnic.net Mon Nov 5 13:07:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C685E21F8626 for ; Mon, 5 Nov 2012 13:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0JJOhg-zNl2 for ; Mon, 5 Nov 2012 13:07:01 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6D84E21F85FC for ; Mon, 5 Nov 2012 13:06:53 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org [130.129.22.242]) by mail.lacnic.net.uy (Postfix) with ESMTP id 707FF308445 for ; Mon, 5 Nov 2012 19:06:52 -0200 (UYST) Message-ID: <50982A67.70603@lacnic.net> Date: Mon, 05 Nov 2012 16:06:47 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 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] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:07:02 -0000 On 05/11/2012 15:49, Francisco Arias wrote: > Hi Andy and Scott, > > I have the following comments/questions on the > draft-ietf-weirds-rdap-query-00 draft. > > - 2.1. IP Network Path Segment Specification: you may want to include an > example for IPv6. Isn't there missing text about representation of IPv6 > address in URLs? > > - 2.2. Autonomous System Path Segment Specification: doesn't say in which > format the AS has to be, shouldn't it say? > > Francisco, I think we should add something, at least that representation according to rfc5952 (not sure if that is the correct one to refer). So far whois supports several representation, i.e: 2800::/48 2800:0:0::/48 2800:0::0/48 About ASNs. At least for us (LACNIC) it appears to be a matter of policy: Chapter 3, Policy Manual http://www.lacnic.net/en/web/lacnic/manual-3 "16-bit AS numbers were defined in RFC 1930 and integers ranging from 0 to 65535 will be used for their identification. Likewise, 32-bit AS numbers were defined by RFC 4893 and integers ranging from 0 to 4294967295 will be used for their identification. In both cases the "asplain" decimal value representation defined in RFC 5396 will be used." So, I would leave this open or to use "asplain" if all the RIRs support the same format. Regards, as From francisco.arias@icann.org Mon Nov 5 13:09:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4CD21F8BB4 for ; Mon, 5 Nov 2012 13:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZN86JlHNpxf for ; Mon, 5 Nov 2012 13:09:27 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id EB05C21F8ACC for ; Mon, 5 Nov 2012 13:09:26 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Nov 2012 13:09:26 -0800 From: Francisco Arias To: "weirds@ietf.org" Date: Mon, 5 Nov 2012 13:09:21 -0800 Thread-Topic: [weirds] Comments on draft-ietf-weirds-using-http-00 Thread-Index: Ac27mdYYzwK+rAm1SKeS29cfAZUo0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:09:28 -0000 Hi Andy, Byron, and Ning, I have the following comments/questions on the draft-ietf-weirds-using-http-00 draft. - 10. Common Datatypes: for email addresses there is a potential internationalization issue. With the approval of the EAI standards, don't we need to support internationalized email addresses? - 10. Common Datatypes: is RFC 791 the right spec for IPv4 textual representation? Regards, __ Francisco. From andy@arin.net Mon Nov 5 13:17:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96E921F85FC for ; Mon, 5 Nov 2012 13:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9libIf7+mDiS for ; Mon, 5 Nov 2012 13:17:04 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5421F8643 for ; Mon, 5 Nov 2012 13:17:04 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 73BF321364E; Mon, 5 Nov 2012 16:17:01 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id ABEA121360D; Mon, 5 Nov 2012 16:17:00 -0500 (EST) 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.283.3; Mon, 5 Nov 2012 16:16:57 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 16:15:58 -0500 From: Andy Newton To: Francisco Arias , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-rdap-query-00 Thread-Index: AQHNnZCNNYd1tFvc/0qNdYj2kVtAepfcRtqA//+zioA= Date: Mon, 5 Nov 2012 21:15:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6B7D6D7068DF164C84892350ED22DE98@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-rdap-query-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:17:05 -0000 On 11/5/12 3:49 PM, "Francisco Arias" wrote: >Hi Andy and Scott, > >I have the following comments/questions on the >draft-ietf-weirds-rdap-query-00 draft. > >- 2.1. IP Network Path Segment Specification: you may want to include an >example for IPv6. Isn't there missing text about representation of IPv6 >address in URLs? IPv6 addresses in the authority part of a URL must have square brackets around it so as to allow parsing to distinguish between the IPv6 address bytes and the colon for the port number. But these are in the path, so it is unneeded. > >- 2.2. Autonomous System Path Segment Specification: doesn't say in which >format the AS has to be, shouldn't it say? I guess we should specify AS Plain, but the other form has been deprecated=8A at least I thought. > >- 2.3. Domain Path Segment Specification: specifies A-label format, I >think U-label format should be allowed too. This is and >internationalization issue. The explanation is in Appendix C of JSON-Response. http://tools.ietf.org/html/draft-ietf-weirds-json-response-00#appendix-C > >- 3. Extensibility: why do we need to have the "custom_" prefix? I'd >think is enough to require the path segments to be unique, perhaps an IANA >registry? "custom_" is an example. The short identifier token should be that used in the IANA registry setup in the Using HTTP draft. -andy From andy@arin.net Mon Nov 5 13:18:38 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1B21F843E for ; Mon, 5 Nov 2012 13:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu4WcjW99xTl for ; Mon, 5 Nov 2012 13:18:38 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 49CED21F843D for ; Mon, 5 Nov 2012 13:18:38 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id B2367165131; Mon, 5 Nov 2012 16:18:37 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 5C99F16512D; Mon, 5 Nov 2012 16:18:37 -0500 (EST) 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.283.3; Mon, 5 Nov 2012 16:18:34 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 16:17:36 -0500 From: Andy Newton To: Francisco Arias , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-using-http-00 Thread-Index: Ac27mdYYzwK+rAm1SKeS29cfAZUo0QAASekA Date: Mon, 5 Nov 2012 21:17:36 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:18:38 -0000 On 11/5/12 4:09 PM, "Francisco Arias" wrote: >- 10. Common Datatypes: for email addresses there is a potential >internationalization issue. With the approval of the EAI standards, don't >we need to support internationalized email addresses? Good question. We should bring this up during the session today. > >- 10. Common Datatypes: is RFC 791 the right spec for IPv4 textual >representation? Yes, I think there is a better reference using in the JSON response draft. I'll go hunt it down. -andy From francisco.arias@icann.org Mon Nov 5 13:20:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3550521F847C for ; Mon, 5 Nov 2012 13:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R3BbNjjUlgE for ; Mon, 5 Nov 2012 13:20:52 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id C96F721F8468 for ; Mon, 5 Nov 2012 13:20:52 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Nov 2012 13:20:52 -0800 From: Francisco Arias To: Andy Newton , "weirds@ietf.org" Date: Mon, 5 Nov 2012 13:20:47 -0800 Thread-Topic: [weirds] Comments on draft-ietf-weirds-using-http-00 Thread-Index: Ac27m28gqHu5S0oSR8iCJ2uBShdY7Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-using-http-00 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:20:53 -0000 On 11/5/12 4:17 PM, "Andy Newton" wrote: >>- 10. Common Datatypes: is RFC 791 the right spec for IPv4 textual >>representation? > >Yes, I think there is a better reference using in the JSON response draft. >I'll go hunt it down. Reading the json-response draft I found the following text: "IPv4 addresses: The representation of IPv4 addresses in this document uses the dotted-decimal notation described in [RFC1166]." Regards, __ Francisco. From ajs@anvilwalrusden.com Mon Nov 5 13:32:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AB221F87EB for ; Mon, 5 Nov 2012 13:32:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hoRKSh4fA-6 for ; Mon, 5 Nov 2012 13:32:06 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3292021F87EE for ; Mon, 5 Nov 2012 13:32:06 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0750D8A031 for ; Mon, 5 Nov 2012 21:32:03 +0000 (UTC) Date: Mon, 5 Nov 2012 16:31:45 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121105213144.GA70287@mx1.yitter.info> References: <20121102152851.92298.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:32:07 -0000 Dear colleagues, On Sun, Nov 04, 2012 at 03:47:05PM -0500, Edward Lewis wrote: > I think section 12 of the newer document should say more. > It's hard to say if (much) more text is needed. One thing that I think _is_ needed is a rule about normalization form. Simply saying "Use UTF-8" is inadequate for some of the data, because two encodings of the same normalized string might not match binary. U-labels and A-labels hide this for us, because U-labels are already required to be in NFC. So, I would like the text at least to say that any input or output MUST use Normalization Form $N. There is a legitimate question about what $N ought to be. It could be that we need more than one form: perhaps input is different from output. NFKC loses information in a round trip, but maximizes matching. What would be nice is to do NFKC for input to maximize the chances of a match, and NFC in return transmission to maximize the chances that data is never lost. A requirement along these lines maximizes our chances of building something compatible with future query patterns that we might want to support. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Mon Nov 5 13:55:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A002621F85B6 for ; Mon, 5 Nov 2012 13:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.886 X-Spam-Level: X-Spam-Status: No, score=-111.886 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73QjD1c-6a2i for ; Mon, 5 Nov 2012 13:55:34 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8521F8461 for ; Mon, 5 Nov 2012 13:55:33 -0800 (PST) Received: (qmail 21459 invoked from network); 5 Nov 2012 21:55:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Nov 2012 21:55:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509835d4.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=rT5XirgDslYmwPbyDUjeYhc6BHbjb5qrbzM83KoKGrY=; b=jiDwTUAbvVVyBsXtUNrv6rdMkkGrqNrch57F8I895ZvqDWZbcXaL7G4QznZkN/bwOkSdNHrkcDyNwTI2IEpdLqCHw4EuZUYkMebdyEuxetwHM9dkjB1cUDHlnd6tTRlXt0eMmudLjwI2VBQsN6bGDy8xwuMJaI+FLrpu0DpuimE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509835d4.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=rT5XirgDslYmwPbyDUjeYhc6BHbjb5qrbzM83KoKGrY=; b=TwlOl2eBCKpo2n4ldkf/zMmxbKOIMg6yNdbjI0cgA/ipbb7nHwWyM1ycscFQiIJZwtsbkrQIODB0VwpyTODtaybp/tPlwrkOhQKRcbdDGxYNqzMZQ5Ndr+yvkW2HJ5DfvNnK3ZXxZwCMRGOce4yndaUgZukpv4vkcZq1ZrPg2gg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Nov 2012 21:55:10 -0000 Message-ID: <20121105215510.52872.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:55:36 -0000 >Ning's original question was whether section 12 of >http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 is >sufficient or should the text in section 7 of >http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought >back and augmented. The current text looks fine to me. There's little reason to use anything other than UTF-8 for this work. >It's hard to say if (much) more text is needed. Besides A and >U-labels and IRI to URI, there should be something that talks about >the other data (contract address, names, phone numbers) just to be >clear on what is and what isn't considered. We're better off burning those bridges as we get to them. For the contact data, that's not just an i18n issue. There are plenty of non-standard ways to write addresses in the United States using only ASCII characters. I'm not opposed to having the data model say something about physical address formats, but it's more than roman vs other characters. It's also not clear to me who if anyone in this group understands the issue well enough to write a reasonable spec. R's, John From johnl@iecc.com Mon Nov 5 13:56:34 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9726121F8661 for ; Mon, 5 Nov 2012 13:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.92 X-Spam-Level: X-Spam-Status: No, score=-111.92 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvXgiFsh1Nfs for ; Mon, 5 Nov 2012 13:56:33 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E113321F8461 for ; Mon, 5 Nov 2012 13:56:32 -0800 (PST) Received: (qmail 21701 invoked from network); 5 Nov 2012 21:56:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Nov 2012 21:56:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5098360f.xn--yuvv84g.k1211; i=johnl@user.iecc.com; bh=OtO/I63Tcqk02KVI5tQ2Ag0IruB08DW0KeHhOTTEw+c=; b=IxhklDcdy3bAblWYWpa2GQwbv2gjlEkuXF0nEhnQ7PcMk84xUzQsu7ooHOXUS0zumH2N3z3ztUxTClNcO6T/J7zrvOAS7R9ZuE+f4c1hu7sp9wJDLAOb7aFSVk88A2Q5BdZtkf02Ybw5jq0SBrmmcYAM2PpOMF7vHFEF8NZxY0I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5098360f.xn--yuvv84g.k1211; olt=johnl@user.iecc.com; bh=OtO/I63Tcqk02KVI5tQ2Ag0IruB08DW0KeHhOTTEw+c=; b=eBITw0mxMPHR4TWpabY3lajSQNXumpb4pWc+9bw9Ki7XgXNVS0zP0vaiCUh8UrOD2DCizghfefRQxL55GgH1QDttvVB+U67r8jcYX8dA74a1lsr2A7AmVwEU18Ye/7sfpTmtIfk7n5UeyLbrD/WcqDOrNq7S245+XM+09djqFpw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Nov 2012 21:56:09 -0000 Message-ID: <20121105215609.52924.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20121105213144.GA70287@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:56:34 -0000 >So, I would like the text at least to say that any input or output >MUST use Normalization Form $N. What if it's someone's name or address and doesn't have a normalized form? From francisco.arias@icann.org Mon Nov 5 14:20:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0B21F86A1 for ; Mon, 5 Nov 2012 14:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1llYVT+Vw2pA for ; Mon, 5 Nov 2012 14:20:24 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32B21F84E6 for ; Mon, 5 Nov 2012 14:20:24 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 5 Nov 2012 14:20:15 -0800 From: Francisco Arias To: "weirds@ietf.org" Date: Mon, 5 Nov 2012 14:20:10 -0800 Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27o7qF9wnShljEQOOC4HSUHYSddQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US 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 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:20:25 -0000 Hi Andy, and Scott, I have the following comments/questions on the draft-ietf-weirds-json-response draft. - 3. Common Data Types: shouldn't we have a standard format for phone numbers as in EPP? - 4.2. The DNR Entity Object Class, 5. The Nameserver Object Class, and 6.2. The DNR Domain Object Class: why do we need the port43 element? - 6.2. The DNR Domain Object Class: the description for the element 'sponsoredBy' seems to imply that there are "IANA approved registrars"; it should be changes to say that there is an IANA registry for ICANN-accredited registrars for gTLDs or something like that. - 6.2. The DNR Domain Object Class: the variants also need an status. It is quite common to have a "base" domain name that could active in the DNS that has a number of variants that are blocked or whitheld (i.e., not active in the DNS). - 6.2. The DNR Domain Object Class: you may want to add the element(s) 'roles' to the entity example. - 6.2. The DNR Domain Object Class: is missing the U-label element and possibly IDNA version. - Appendix A. Suggested Values: why not to simply reference EPP and other applicable standards? - Appendix C. IDN Query and Response Model: I think the portrait of IDN variants is not correct, I'd suggest deleting this. There is an interesting discussion of variants at http://www.icann.org/en/topics/idn/idn-vip-integrated-issues-final-clean-20 feb12-en.pdf if you are interested, but I don't think this Appendix is needed. Regards, __ Francisco. From francisco.arias@icann.org Mon Nov 5 14:25:50 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7C11E809A for ; Mon, 5 Nov 2012 14:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD38TE9nyhQo for ; Mon, 5 Nov 2012 14:25:48 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id D250D11E8099 for ; Mon, 5 Nov 2012 14:25:46 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Nov 2012 14:25:46 -0800 From: Francisco Arias To: "weirds@ietf.org" Date: Mon, 5 Nov 2012 14:25:40 -0800 Thread-Topic: Validated registration data (Re: [weirds] validate, was ICANN 45 report) Thread-Index: Ac27pIA7BbPsv+jmQ++FG1NuDKTlxA== Message-ID: In-Reply-To: <20121020101558.3621.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] Validated registration data (Re: validate, was ICANN 45 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: Mon, 05 Nov 2012 22:25:50 -0000 I agree with John that validation can mean different things and I don't think there is anything to do for us here. Validation of registration data is beyond the protocol work. Regarding the work on this area in ICANN, as others pointed out it is still a work in progress, so there are not yet definitive requirements. I don't know about ccTLDs. In any case, I suspect at the end the requirement would be to add data elements in the response (e.g., the validated date, URI to the validation procedure) but nothing in the protocol itself. Regards, __ Francisco. On 10/20/12 6:15 AM, "John Levine" wrote: >>> How does one "validate" a domain name, name server, or IP address, or >>is this really about contact information? >> >>I had the same question at first but it looks like that's been >>clarified here. I suggest that in our reply definition we include a >>very precise explanation of what "validate" means in this context. > >The problem is that it can mean a very wide variety of things: > >* Check that an IP is routed, that an appropriate server answers, >and/or that an appropriate server has the right DNS records for a >delegated domain. > >* Check that an alleged phone number is syntactically valid, e.g., >has the right number of digits and that that prefix digits are >in use. > >* Call the phone number and see who answers, either mechanically >by having a robot read off a code that the registrant types into a >web page, or by humans talking to whoever answers. > >* Check that an alleged email address is syntactically valid and has >appropriate DNS records, will accept a message, accepts a message and >doesn't bounce, and/or that someone clicks a URL in the message. > >* Check that a postal address is valid, in countries where it's >possible to do that. > >* Mail something to the postal address with a verification code to >enter. > >etc. etc. > >I know people who do all these things for various sorts of signup >verifications. And there are doubtless more that I haven't seen. > >We could try and come up with a set of categories, i.e., syntax valid, >semantics valid, contact verified, but it sounds to me like an area >where we don't know what we're doing. So unless someone offers an >actual implementation of something more than a validation date, I'd >rather not guess. > >--=20 >Regards, >John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for >Dummies", >Please consider the environment before reading this e-mail. http://jl.ly >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From francisco.arias@icann.org Mon Nov 5 14:29:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0442211E8097 for ; Mon, 5 Nov 2012 14:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTgMgdmDKWlt for ; Mon, 5 Nov 2012 14:29:25 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id CFDA821F8445 for ; Mon, 5 Nov 2012 14:29:23 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 5 Nov 2012 14:29:23 -0800 From: Francisco Arias To: "weirds@ietf.org" Date: Mon, 5 Nov 2012 14:29:18 -0800 Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27pQD02eQy7WNkRISdl3hWPcPleg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US 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 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:29:26 -0000 On 11/5/12 5:20 PM, "Francisco Arias" wrote: >- 6.2. The DNR Domain Object Class: the variants also need an status. It >is quite common to have a "base" domain name that could active in the DNS >that has a number of variants that are blocked or whitheld (i.e., not >active in the DNS). Forgot to mention the need for an URI to the Label Generation Rules (aka IDN tables) for the registry that resulted in the variants. __ Francisco. From francisco.arias@icann.org Mon Nov 5 14:34:34 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34C21F86CB for ; Mon, 5 Nov 2012 14:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq+mmVjbxkXW for ; Mon, 5 Nov 2012 14:34:31 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id DD2DA21F8590 for ; Mon, 5 Nov 2012 14:34:30 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 5 Nov 2012 14:34:30 -0800 From: Francisco Arias To: "Hollenbeck, Scott" , "weirds@ietf.org" Date: Mon, 5 Nov 2012 14:34:23 -0800 Thread-Topic: [weirds] Security Service Summary Thread-Index: Ac27pbgTBjIqRpVTQ92P3pHfCYg7qA== Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6AA4E8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Security Service Summary X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:34:34 -0000 Hi Scott, Please see below. On 10/30/12 7:24 AM, "Hollenbeck, Scott" wrote: >Authentication: We have a requirement to specify an HTTP-based >authentication mechanism. QUESTION: which one? HTTP basic? HTTP digest? >HTTP basic could be used with https (see data confidentiality below). Why only one authentication mechanism? >Availability: we have a DDoS security consideration that can be addresses >with a normative reference to RFC 4732. We have a requirement to support >query and display of contact entities for abuse reporting. Regarding the abuse contact, I don't think this is an Availability requirement. I think that is only a data element in the response. >RFC 3707 says that when a value in an answer to a query is given, the >protocol MUST be capable of tagging the value with the following labels: > >1. do not redistribute >2. special access granted > >QUESTION: Is this a requirement for RDAP? I haven't seen the need for this, therefore I'd suggest this is not a requirement for RDAP. >Data Integrity: we have not identified a requirement to provide this >service. There may, however, be a requirement to provide some sort of >response element that confirms that an element has been "validated" or >"verified", which some people will likely confuse with a data integrity >service. QUESTION: how do we want to approach this? As I said in another email the "validated" or "verified" elements are just that, there is no procotol work here and no security requirement. >Non-repudiation: we have not identified a requirement to provide this >service. I'm not aware of this being used by a registry but Peter mentioned there were some registries. __ Francisco. From ajs@anvilwalrusden.com Mon Nov 5 14:42:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C520721F84E2 for ; Mon, 5 Nov 2012 14:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu7t93LvN+Q2 for ; Mon, 5 Nov 2012 14:42:04 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DE42521F84B5 for ; Mon, 5 Nov 2012 14:42:03 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2F3578A031 for ; Mon, 5 Nov 2012 22:42:03 +0000 (UTC) Date: Mon, 5 Nov 2012 17:41:55 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121105224155.GD70287@mx1.yitter.info> References: <20121105213144.GA70287@mx1.yitter.info> <20121105215609.52924.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121105215609.52924.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:42:05 -0000 On Mon, Nov 05, 2012 at 09:56:09PM -0000, John Levine wrote: > >So, I would like the text at least to say that any input or output > >MUST use Normalization Form $N. > > What if it's someone's name or address and doesn't have a normalized > form? Sorry, I guess I wasn't clear enough: I mean Unicode normalization. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ray.Bellis@nominet.org.uk Mon Nov 5 14:53:33 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C607821F856E for ; Mon, 5 Nov 2012 14:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+69tt35Jwce for ; Mon, 5 Nov 2012 14:53:33 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id EF97821F854F for ; Mon, 5 Nov 2012 14:53:31 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=ylVvKI+KGEu7CJR8vSqGK0RI9epvsz5BdVg5Y1Tn/XjFXchflbaoSvyi o6+iH2JtP539q2AjU5z8xodjfnjZXtBpifSRehD7CgOkhWf+VoBW/8E3U lbcNjskeEhWUVeY; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352156012; x=1383692012; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20Comments=20on=20draft-ietf-w eirds-json-response|Date:=20Mon,=205=20Nov=202012=2022:53 :21=20+0000|Message-ID:=20<6E24EDBC-F621-4A65-BC2D-DF6271 88CBF4@nominet.org.uk>|To:=20Francisco=20Arias=20|CC:=20"weirds@ietf.org=20Group"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20|References:=20; bh=g7tBD9TNdscPDV+N34zjWpm96YAi9O8UuHrlUY7dD/Q=; b=qLyI9pbdfi9PDZMQv6f6n3+6FEa/3BhrF5oXL05khNAtSXbKI/5Ok0Rk 1e9hXfXhENBwonjav8EWh+MaQzZ+XgqFI0KEVyyipc9+sQHtDkOEcNoas lkIR09yL0R4nvmm; X-IronPort-AV: E=Sophos;i="4.80,718,1344207600"; d="scan'208";a="36542847" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Nov 2012 22:53:23 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Mon, 5 Nov 2012 22:53:23 +0000 From: Ray Bellis To: Francisco Arias Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27o7qF9wnShljEQOOC4HSUHYSddQABJ/uA Date: Mon, 5 Nov 2012 22:53:21 +0000 Message-ID: <6E24EDBC-F621-4A65-BC2D-DF627188CBF4@nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Mon, 05 Nov 2012 22:53:33 -0000 On 5 Nov 2012, at 17:20, Francisco Arias wrote: > - 3. Common Data Types: shouldn't we have a standard format for phone > numbers as in EPP? The standard formats for phone numbers are in E.123 Good luck trying to get end users to supply them in that format, though... Ray From bje@apnic.net Mon Nov 5 15:10:51 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6821F8552 for ; Mon, 5 Nov 2012 15:10:51 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjaHxD+wY0zS for ; Mon, 5 Nov 2012 15:10:50 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id E368421F8449 for ; Mon, 5 Nov 2012 15:10:48 -0800 (PST) Received: from [IPv6:2001:dc0:a000:6:9438:b406:c381:c486] (unknown [IPv6:2001:dc0:a000:6:9438:b406:c381:c486]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 174B1B68D1; Tue, 6 Nov 2012 09:10:47 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_7DA4E17D-E9ED-4D6F-9D49-A4DD1B7058DD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: <00b701cdbb29$187a64a0$496f2de0$@cn> Date: Tue, 6 Nov 2012 09:10:46 +1000 Message-Id: <83EF0F32-0395-4E60-A826-A0A7D3C8632C@apnic.net> References: <01b701cda82e$bf9c0e90$3ed42bb0$@cnnic.cn> <6.2.5.6.2.20121101094348.064ae730@resistor.net> <6.2.5.6.2.20121101120347.0b4239d8@resistor.net> <719DC433-418B-48FE-9DCE-A6ABE2A8676A@apnic.net> <00b701cdbb29$187a64a0$496f2de0$@cn> To: Linlin Zhou X-Mailer: Apple Mail (2.1499) Cc: 'Edward Lewis' , weirds@ietf.org Subject: Re: [weirds] Internationalization Issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 23:10:51 -0000 --Apple-Mail=_7DA4E17D-E9ED-4D6F-9D49-A4DD1B7058DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Linlin, It isn't necessary, I think. I put up a proposal to see who is in = favour or against various attributes of it, rather than to suggest it = was necessary or important to go that specific direction. Byron On 05/11/2012, at 5:42 PM, Linlin Zhou wrote: > Hi Byron, >=20 > I have a question. Why is it necessary to add lang attribute to each = object? > IMHO, an attribute to a response record is enough. Could you elaborate = it? > Thanks. >=20 > Linlin >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf > Of >> Byron Ellacott >> Sent: Friday, November 02, 2012 9:08 AM >> To: Edward Lewis >> Cc: weirds@ietf.org >> Subject: Re: [weirds] Internationalization Issues >>=20 >> On 02/11/2012, at 6:36 AM, Edward Lewis wrote: >>=20 >>> It's clear that the protocol will not drive what registries do (or = have > been doing). >> However, the protocol does not need to parrot exactly what is in the > registries' >> internal databases. >>=20 >> The WG is neither chartered nor able to fix problems with the = contents of >> registries. If the protocol cannot carry existing information, it = will > carry none at >> all. I sympathise with your use case for more useful address = information, > but >> the right venue to try to force registries to get better data is = ICANN (or > the RIR >> processes), not the IETF. I do recognise the difficulty of that task = - > which is why I >> don't think we should attempt to force the unenforceable via a = protocol > decision. >>=20 >> The questions about i18n that I see before the WG are: >>=20 >> 1) Can the protocol carry information in more than one language or = script? >>=20 >> 2) Should there be a mechanism for indicating to the client what = language > or >> script is in use, and at what granularity? >>=20 >> 3) Should there be a mechanism for allowing the client to indicate > preferred >> languages for the response? >>=20 >> I don't think there are any useful questions about what should happen = to > the >> data. If a registry only has data in one language, that's the = language > it's going to >> send that data in, no matter what the client asks for, or what the > protocol >> specification dictates. >>=20 >> #1 is trivial - the de facto character encoding for RDAP responses is > UTF-8, which >> can encode a pretty broad range of things, and servers may signal an > alternative >> character set if they prefer. >>=20 >> For #2, there is the HTTP header, which is meta-data and semantically > indicates >> the best language for consumption of the data, rather than the = language > the data >> is necessarily in, or there is a language tag in the response, either = for > the entire >> response, or parts thereof, and I don't think I've seen any other > suggestions. >>=20 >> For #3, there is the HTTP request and response headers, again = semantically >> subtle, and URI query parts. >>=20 >> I will put up a strawman and suggest that the using-http draft adopts > something >> along these lines: >>=20 >> --- snip --- >> 4.2.1 Indication of preferred language >>=20 >> A client MAY include a query parameter to indicate preferred language = for >> responses. A server MAY choose to take that into consideration when >> preparing a response. The format of the language query parameter is: >>=20 >> lang=3D >> --- snip --- >>=20 >> And that the json-response draft adopts something along these lines: >>=20 >> --- snip --- >> 3. Common Data Types >> . >> lang: An RFC 5646 language tag indicating the primary language of = the >> object . >> --- snip --- >>=20 >> With the "lang" attribute added to each object type defined. >>=20 >> Thoughts? >>=20 >> Byron >=20 >=20 --=20 Byron Ellacott email: bje@apnic.net Technical Director, APNIC sip: bje@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. --Apple-Mail=_7DA4E17D-E9ED-4D6F-9D49-A4DD1B7058DD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDUyMzEwNDZaMCMGCSqGSIb3DQEJBDEWBBTY Fgjbjd4X9U0Nqr7TUyPeVk0NqDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAXe2DUv4D/xSK7 H9Ob3fN60IWPgV0yzCGvAkSEDOyhEx2AYIAS+aXcbV4SVHIqtF50JzcduIJGVrk50VacyB37QAFf UIpLWnSW8kPhR31uuLeejd2C3IcUXnSMtMirmi7yjovdc6g2K6lYQu0dPwIRlSBRXSGg5iG3/Vkj 4QEp1iIrb3QI82IkRQRzfVHrMgWUIPJY7313ZAkPf7AWK+n3Ix67JKU05mfd1U4I9/Kv2kwNIhL4 je91c8pxBqli0K/WQtz3a1aRyAVGiMQ+siwNee2Ks+R5QnIUynmNg0YGogmUW+QbVVb7M9jFqObk 0zMNwm4A3LgRV1VAPf7Lm2UhAAAAAAAA --Apple-Mail=_7DA4E17D-E9ED-4D6F-9D49-A4DD1B7058DD-- From shollenbeck@verisign.com Mon Nov 5 17:57:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE6611E80D1 for ; Mon, 5 Nov 2012 17:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-6MRWjVszTr for ; Mon, 5 Nov 2012 17:57:12 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4711E80A5 for ; Mon, 5 Nov 2012 17:56:49 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUJhuYWcWMwijGdWWsbfNEYTVSMhLO9Ts@postini.com; Mon, 05 Nov 2012 17:57:12 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qA61uk00007491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 20:56:46 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 20:56:45 -0500 From: "Hollenbeck, Scott" To: Ray Bellis , Francisco Arias Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27o7qF9wnShljEQOOC4HSUHYSddQABJ/uAAAYSKaA= Date: Tue, 6 Nov 2012 01:56:44 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6ADCA0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <6E24EDBC-F621-4A65-BC2D-DF627188CBF4@nominet.org.uk> In-Reply-To: <6E24EDBC-F621-4A65-BC2D-DF627188CBF4@nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Tue, 06 Nov 2012 01:57:13 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Ray Bellis > Sent: Monday, November 05, 2012 5:53 PM > To: Francisco Arias > Cc: weirds@ietf.org Group > Subject: Re: [weirds] Comments on draft-ietf-weirds-json-response >=20 >=20 > On 5 Nov 2012, at 17:20, Francisco Arias > wrote: >=20 > > - 3. Common Data Types: shouldn't we have a standard format for > phone > > numbers as in EPP? >=20 > The standard formats for phone numbers are in E.123 >=20 > Good luck trying to get end users to supply them in that format, > though... EPP references E.164. ITU spec consistency aside, it's a good question. Whi= le this seems like a Good Thing, the practical issue is that doing so would= require formatting that (as Ray noted) might require validation or transla= tion on the back end. I'm inclined to allow a server operator to return thi= s in the whatever format they have archived. Scott From superuser@gmail.com Mon Nov 5 20:21:33 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4911E80E3 for ; Mon, 5 Nov 2012 20:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VPdC1Uvenhg for ; Mon, 5 Nov 2012 20:21:31 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81511E80DE for ; Mon, 5 Nov 2012 20:21:28 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so13040lam.31 for ; Mon, 05 Nov 2012 20:21:28 -0800 (PST) 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=oOoeC1/ahVQqP78grc+h30O0plO2Ov/vltPwdl7QP0s=; b=GekEJZIiHw5/PtdOd58sOPXkhsED0RG4msYtlLD6CgpmbsB+m8i8cIL1Wjx4NUDszs +UjbsfQ6ZI0/hvnZU2YaEspCcBw8nlqQfUCaKLct3jBKnOUkXBscHedTJRwOrIjr7lxp PSfE0352IcnA80pjclFv/izzu7y8/miXIXsLy7S0EjvuD7IrShulyuRRVr+T/4pEefKP hZzefgXW7KKyh2OP+G/clv+4IuVbaYYWLqyICOteZ/BEupjVpFMEQKkkFUyhtDxtbdTu Tk7bnv3DxKtVki7k/rs1f7q/SPe5Bt1eXm6lDn6NKXJjhPJQ7pAo+O/NNSld5GVhyNMH 11SA== MIME-Version: 1.0 Received: by 10.112.100.129 with SMTP id ey1mr4768605lbb.10.1352175688127; Mon, 05 Nov 2012 20:21:28 -0800 (PST) Received: by 10.112.83.232 with HTTP; Mon, 5 Nov 2012 20:21:28 -0800 (PST) Date: Mon, 5 Nov 2012 23:21:28 -0500 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=14dae9d7172490954204cdcbef5e Subject: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 04:21:33 -0000 --14dae9d7172490954204cdcbef5e Content-Type: text/plain; charset=ISO-8859-1 I'd like to continue the internationalization discussion started during the meeting today. It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would provide the answers in whatever language(s) they have; the client will make use of that reply in whatever way it sees fit. Is there any specific objection to that approach for this work? (And have I captured the proposal properly?) -MSK --14dae9d7172490954204cdcbef5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to continue the internationalization discussion started during= the meeting today.

It's our read that the people talking on the= topic were warm to the idea that the query syntax would not include a prov= ision for requesting a response in a specific language, and the servers wou= ld provide the answers in whatever language(s) they have; the client will m= ake use of that reply in whatever way it sees fit.

Is there any specific objection to that approach for this work?=A0 (And= have I captured the proposal properly?)

-MSK
--14dae9d7172490954204cdcbef5e-- From peter@denic.de Mon Nov 5 20:27:32 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8CF21F85D6 for ; Mon, 5 Nov 2012 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTYYoq7+sigQ for ; Mon, 5 Nov 2012 20:27:31 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22A21F85BA for ; Mon, 5 Nov 2012 20:27:31 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TVal8-0000lx-7y; Tue, 06 Nov 2012 05:27:30 +0100 Received: from localhost by x27.adm.denic.de with local id 1TVal8-0001dH-4X; Tue, 06 Nov 2012 05:27:30 +0100 Date: Tue, 6 Nov 2012 05:27:30 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20121106042730.GS2347@x28.adm.denic.de> References: <20121022144317.GK9485@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Security Requirements: Non-repudiation X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 04:27:32 -0000 On Sun, Nov 04, 2012 at 02:30:25PM -0800, Francisco Arias wrote: > Which TLD registries offer "signed Whois"? at the risk of it looking like a plug, but since Francisco asked: The idea is to enable the client (party) to prove to a third party that a domain had certain (contact or holder) information at a particular point in time. I'm not offering this as a requirement for weirds, though. As discussed before, this cannot be achieved simply by authenticating the server through the use of TLS/https. -Peter From sm@resistor.net Mon Nov 5 23:09:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516D521F84A8 for ; Mon, 5 Nov 2012 23:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33hpBr9ZdwBI for ; Mon, 5 Nov 2012 23:09:56 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B5321F84A4 for ; Mon, 5 Nov 2012 23:09:56 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA679nFm019941 for ; Mon, 5 Nov 2012 23:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352185795; bh=dstlLYAbg81GQHgdJnyrhGlonDo+jnEdJMvF3sY8t5k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=bNo1RKLAgJdp9ALesRfRF1O0Am5PRyQPHWei/PJLLhxWohXzk3q2plsXuoYuhiPJQ oNPed3aYbmiwzcNAXi9vySibJUVdhsmjKFILHt2bi1nki/t4sB2HTBj1l4vlb1ihAm Ct1InB3yfxeMOwX2YDV79kUmPk2pUOg5A4fA53nU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352185795; i=@resistor.net; bh=dstlLYAbg81GQHgdJnyrhGlonDo+jnEdJMvF3sY8t5k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=l6L+afRNdyLELGff//DKCURviyrpvtxp1QjQX0Bje5emp3x8ayOvrj8Kgo+xtU/KJ b3OcF7v0xaEn6jMe2d873uimA8nDxzBYQbVbUrgJjkFfXKucYE1lIDvPdn5DdMdofL XRf1OVI2cdnbiqWO7kwGf2Hnns6oestR0Y6/9faA= Message-Id: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Nov 2012 22:38:04 -0800 To: weirds@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 07:09:57 -0000 At 20:21 05-11-2012, Murray S. Kucherawy wrote: >I'd like to continue the internationalization discussion started >during the meeting today. > >It's our read that the people talking on the topic were warm to the >idea that the query syntax would not include a provision for >requesting a response in a specific language, and the servers would >provide the answers in whatever language(s) they have; the client >will make use of that reply in whatever way it sees fit. Ok. Does the above mean no RFC 2119 key words for the request or the response? Regards, -sm From jaap@NLnetLabs.nl Mon Nov 5 23:46:47 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AC921F87DF for ; Mon, 5 Nov 2012 23:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9KEgZl42yGb for ; Mon, 5 Nov 2012 23:46:47 -0800 (PST) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 354D421F879B for ; Mon, 5 Nov 2012 23:46:46 -0800 (PST) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id qA67gGA0027279; Tue, 6 Nov 2012 08:42:17 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201211060742.qA67gGA0027279@bela.nlnetlabs.nl> To: Ray Bellis In-reply-to: <6E24EDBC-F621-4A65-BC2D-DF627188CBF4@nominet.org.uk> References: <6E24EDBC-F621-4A65-BC2D-DF627188CBF4@nominet.org.uk> Comments: In-reply-to Ray Bellis message dated "Mon, 05 Nov 2012 22:53:21 +0000." Date: Tue, 06 Nov 2012 08:42:16 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bela.nlnetlabs.nl [127.0.0.1]); Tue, 06 Nov 2012 08:42:23 +0100 (CET) Cc: "weirds@ietf.org Group" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Tue, 06 Nov 2012 07:46:48 -0000 On 5 Nov 2012, at 17:20, Francisco Arias wrote: > - 3. Common Data Types: shouldn't we have a standard format for phone > numbers as in EPP? The standard formats for phone numbers are in E.123 Good luck trying to get end users to supply them in that format, though... E.123 defines "Notation for national and international telephone numbers, e-mail addresses and Web addresses". It is really about how one prints these things on paper. The forma is ill-suited for anything else. I'll dig up some old mail I wrote about this subject some time ago later to day. jaap From superuser@gmail.com Tue Nov 6 04:30:06 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EA521F88D8 for ; Tue, 6 Nov 2012 04:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BObDeQsUU2rD for ; Tue, 6 Nov 2012 04:30:05 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 119D921F88D5 for ; Tue, 6 Nov 2012 04:30:04 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so346056lam.31 for ; Tue, 06 Nov 2012 04:30:04 -0800 (PST) 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=guFoUSQ1qQ1H3zgho/rxjtqeP9b0cV+g9Vh4NY5lugA=; b=Fhc921UpePUblKYA7jIojlrsUI0+zoYcg+gwBMxUaCLCsGTC291mwT+WNzEF7jWD8j 4/D/e/Vguygk8K9/TUyuJ4v97/vhqa30UqVCyYW6OWw2MqAPA1Ni71yAsY+4dcN8YC7p nCCuzHT2x42BzzIJ3Kp2uFSkW02/AjfNMlb+r5LAm3nwZct1LWDgB34tCeZOh5hp26Fq wCX3KeO7nswMagJvW+6lBWnj19Nj+y2sjqX8SruGd+NqsWUiz6LTNyZMoIEf46Xoxz8M maVEElGYUfPBZwlWFBf8v8fjAoF7ugVX2Al8max9XXPJzb9YmSDx+ATq81t4iT+bEiOO L58w== MIME-Version: 1.0 Received: by 10.112.40.42 with SMTP id u10mr435963lbk.124.1352205003832; Tue, 06 Nov 2012 04:30:03 -0800 (PST) Received: by 10.112.83.232 with HTTP; Tue, 6 Nov 2012 04:30:03 -0800 (PST) In-Reply-To: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> Date: Tue, 6 Nov 2012 07:30:03 -0500 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=e0cb4efe30f4eabdda04cdd2c23e Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 12:30:06 -0000 --e0cb4efe30f4eabdda04cdd2c23e Content-Type: text/plain; charset=ISO-8859-1 Hi SM, I believe it means there's no normative language in terms of the query, because language selection is simply not part of the query. The response I'm less sure about because I'm not an i18n expert and don't know what would be appropriate; if the language of a returned object needs to be explicit, then SHOULD or MUST seems reasonable, otherwise a MAY (explicit or implied) would be fine. I leave that to the editors and the WG to sort out. -MSK On Tue, Nov 6, 2012 at 1:38 AM, SM wrote: > At 20:21 05-11-2012, Murray S. Kucherawy wrote: > >> I'd like to continue the internationalization discussion started during >> the meeting today. >> >> It's our read that the people talking on the topic were warm to the idea >> that the query syntax would not include a provision for requesting a >> response in a specific language, and the servers would provide the answers >> in whatever language(s) they have; the client will make use of that reply >> in whatever way it sees fit. >> > > Ok. > > Does the above mean no RFC 2119 key words for the request or the response? > > Regards, > -sm > ______________________________**_________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/**listinfo/weirds > --e0cb4efe30f4eabdda04cdd2c23e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi SM,

I believe it means there's no normative language in terms= of the query, because language selection is simply not part of the query.= =A0 The response I'm less sure about because I'm not an i18n expert= and don't know what would be appropriate; if the language of a returne= d object needs to be explicit, then SHOULD or MUST seems reasonable, otherw= ise a MAY (explicit or implied) would be fine.=A0 I leave that to the edito= rs and the WG to sort out.

-MSK


O= n Tue, Nov 6, 2012 at 1:38 AM, SM <sm@resistor.net> wrote:
=
At 20:21 05-11-2012, Murray S. Kucherawy wrote:
I'd like to continue the internationalization discussion started during= the meeting today.

It's our read that the people talking on the topic were warm to the ide= a that the query syntax would not include a provision for requesting a resp= onse in a specific language, and the servers would provide the answers in w= hatever language(s) they have; the client will make use of that reply in wh= atever way it sees fit.

Ok.

Does the above mean no RFC 2119 key words for the request or the response?<= br>
Regards,
-sm
_______________________________________________
weirds mailing list
weirds@ietf.org = https://www.ietf.org/mailman/listinfo/weirds

--e0cb4efe30f4eabdda04cdd2c23e-- From shollenbeck@verisign.com Tue Nov 6 04:45:28 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0648121F88D6 for ; Tue, 6 Nov 2012 04:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ztlAeGYvy9P for ; Tue, 6 Nov 2012 04:45:27 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id B96DD21F8724 for ; Tue, 6 Nov 2012 04:45:25 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUJkGZdJVgSUYiUtnC7L5syfWi03THp4e@postini.com; Tue, 06 Nov 2012 04:45:26 PST 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 qA6CjMPp007472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 07:45:22 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Tue, 6 Nov 2012 07:45:21 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , "weirds@ietf.org" Thread-Topic: [weirds] Proposal for internationalization question Thread-Index: AQHNu9Y2J+btLieSEUOw2v6ZPwoSM5fcwV+g Date: Tue, 6 Nov 2012 12:45:20 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6ADDE8@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_831693C2CDA2E849A7D7A712B24E257F0D6ADDE8BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 12:45:28 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F0D6ADDE8BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this approach. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Murray S. Kucherawy Sent: Monday, November 05, 2012 11:21 PM To: weirds@ietf.org Subject: [weirds] Proposal for internationalization question I'd like to continue the internationalization discussion started during the= meeting today. It's our read that the people talking on the topic were warm to the idea th= at the query syntax would not include a provision for requesting a response= in a specific language, and the servers would provide the answers in whate= ver language(s) they have; the client will make use of that reply in whatev= er way it sees fit. Is there any specific objection to that approach for this work? (And have = I captured the proposal properly?) -MSK --_000_831693C2CDA2E849A7D7A712B24E257F0D6ADDE8BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this approach.<= o:p>

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Monday, November 05, 2012 11:21 PM
To: weirds@ietf.org
Subject: [weirds] Proposal for internationalization question

 

I'd like to continue the internationalization discus= sion started during the meeting today.

It's our read that the people talking on the topic were warm to the idea th= at the query syntax would not include a provision for requesting a response= in a specific language, and the servers would provide the answers in whate= ver language(s) they have; the client will make use of that reply in whatever way it sees fit.

Is there any specific objection to that approach for this work?  (And = have I captured the proposal properly?)

-MSK

--_000_831693C2CDA2E849A7D7A712B24E257F0D6ADDE8BRN1WNEXMBX01vc_-- From Ed.Lewis@neustar.biz Tue Nov 6 06:28:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDEB21F88C4 for ; Tue, 6 Nov 2012 06:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.482 X-Spam-Level: X-Spam-Status: No, score=-104.482 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbTS6eHYRdF4 for ; Tue, 6 Nov 2012 06:28:51 -0800 (PST) Received: from smtp201.iad.emailsrvr.com (smtp201.iad.emailsrvr.com [207.97.245.201]) by ietfa.amsl.com (Postfix) with ESMTP id A31D221F8468 for ; Tue, 6 Nov 2012 06:28:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp40.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0DEAA35030D; Tue, 6 Nov 2012 09:28:51 -0500 (EST) X-Virus-Scanned: OK Received: by smtp40.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 9744435016C; Tue, 6 Nov 2012 09:28:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 6 Nov 2012 09:28:20 -0500 To: "weirds@ietf.org" From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-859910366==_ma============" Cc: ed.lewis@neustar.biz Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:28:52 -0000 --============_-859910366==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 23:21 -0500 11/5/12, Murray S. Kucherawy wrote: I'd like to continue the internationalization discussion started during the meeting today. It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would provide the answers in whatever language(s) they have; the client will make use of that reply in whatever way it sees fit. Is there any specific objection to that approach for this work? (And have I captured the proposal properly?) I agree with this. The query should not have the option to select the language/script/whatever it wants. The response should include whatever is available. From a protocol engineering perspective, this eliminates the need to consider various error states - such as the query asking for blah and the server doesn't have blah - despite otherwise having a match for the queried object. Fewer possible error states is just good. From a data reality perspective, negotiating for a specific language is over engineering. In the physical world, contact information is often exchanged via business cards. These cards have two sides (I've never seen a business card with more ;)). One side has a "native" version, the other side is either blank or has a "lettered" side. That seems to be sufficient, the point here, while it is possible to get all complicated and everything - the problem to solve is so constrained we just need a simple solution. A client if free to suppress any entries it feels can't be displayed or are undesirable, but at least then the client can make that determination. PS - at the mic, someone suggested looking at vcard...I think that is a good lead. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! --============_-859910366==_ma============ Content-Type: text/html; charset="us-ascii" Re: [weirds] Proposal for internationalization question
At 23:21 -0500 11/5/12, Murray S. Kucherawy wrote:
I'd like to continue the internationalization discussion started during the meeting today.

It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would provide the answers in whatever language(s) they have; the client will make use of that reply in whatever way it sees fit.
Is there any specific objection to that approach for this work?  (And have I captured the proposal properly?)

I agree with this.  The query should not have the option to select the language/script/whatever it wants.  The response should include whatever is available.

From a protocol engineering perspective, this eliminates the need to consider various error states - such as the query asking for blah and the server doesn't have blah - despite otherwise having a match for the queried object.  Fewer possible error states is just good.

From a data reality perspective, negotiating for a specific language is over engineering.  In the physical world, contact information is often exchanged via business cards.  These cards have two sides (I've never seen a business card with more ;)).  One side has a "native" version, the other side is either blank or has a "lettered" side.  That seems to be sufficient, the point here, while it is possible to get all complicated and everything - the problem to solve is so constrained we just need a simple solution.

A client if free to suppress any entries it feels can't be displayed or are undesirable, but at least then the client can make that determination.


PS - at the mic, someone suggested looking at vcard...I think that is a good lead.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
--============_-859910366==_ma============-- From aservin@lacnic.net Tue Nov 6 06:41:09 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D2F21F8606 for ; Tue, 6 Nov 2012 06:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw5DhsvQ-YCc for ; Tue, 6 Nov 2012 06:41:08 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 899A621F84D3 for ; Tue, 6 Nov 2012 06:41:08 -0800 (PST) Received: from [130.129.22.238] (dhcp-16ee.meeting.ietf.org [130.129.22.238]) by mail.lacnic.net.uy (Postfix) with ESMTP id 255F430844D; Tue, 6 Nov 2012 12:41:08 -0200 (UYST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Arturo Servin Date: Tue, 6 Nov 2012 09:42:18 -0500 To: "Murray S. Kucherawy" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:41:09 -0000 I think you have captured the proposal. I have no objection following this p= ath. Regards, as Sent from my mobile device (please excuse typoss and brevit.) On 5 Nov 2012, at 23:21, "Murray S. Kucherawy" wrote: > I'd like to continue the internationalization discussion started during th= e meeting today. >=20 > It's our read that the people talking on the topic were warm to the idea t= hat the query syntax would not include a provision for requesting a response= in a specific language, and the servers would provide the answers in whatev= er language(s) they have; the client will make use of that reply in whatever= way it sees fit. >=20 > Is there any specific objection to that approach for this work? (And have= I captured the proposal properly?) >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From marc.blanchet@viagenie.ca Tue Nov 6 06:46:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7E21F88C4 for ; Tue, 6 Nov 2012 06:46:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjBiOUAR+uRT for ; Tue, 6 Nov 2012 06:46:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFBC21F8848 for ; Tue, 6 Nov 2012 06:46:03 -0800 (PST) Received: from [IPv6:2001:df8::80:a078:744c:328e:1c67] (unknown [IPv6:2001:df8:0:80:a078:744c:328e:1c67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9F5EE400D5; Tue, 6 Nov 2012 09:46:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Tue, 6 Nov 2012 09:46:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1283) Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:46:03 -0000 Le 2012-11-05 =E0 23:21, Murray S. Kucherawy a =E9crit : > I'd like to continue the internationalization discussion started = during the meeting today. >=20 > It's our read that the people talking on the topic were warm to the = idea that the query syntax would not include a provision for requesting = a response in a specific language, and the servers would provide the = answers in whatever language(s) they have; the client will make use of = that reply in whatever way it sees fit. I would add that the response should be (optionally) tagged if that = information is available in the registry. Marc. >=20 > Is there any specific objection to that approach for this work? (And = have I captured the proposal properly?) >=20 > -MSK > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From carlosm3011@gmail.com Tue Nov 6 06:48:45 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842F621F8928 for ; Tue, 6 Nov 2012 06:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhVhnMyW2WMw for ; Tue, 6 Nov 2012 06:48:45 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E630321F88A1 for ; Tue, 6 Nov 2012 06:48:44 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so241999dan.31 for ; Tue, 06 Nov 2012 06:48:44 -0800 (PST) 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=/MhJKDdeIreNWtdOWIiRmSsTUdN2zho7v6RaBu6gfdo=; b=dyMt5Ku2FPqg/QTz03KgCTSPyikJ0/J87aHcu6pJN6QzZ6gZPmfbc2nemE0NdAEIih zRiYlqO6v1Td+S9USjbIp7tiL+wT3l8+xXXIDjVt6W+GlMp9d0WG2k8fEmNKVY3MYYjF /WUTevfD63cStkCgtg7urJh5jQE/zwkYkvj08hVf/lNto1KSnygVD4azTVIxOil2pQeI dQ0tZGHXMKOADALvTHed8VRbyGkFsC1QMUV/6dNbra29Clg4QNBGUMRG7jYJodeecsuF tpo3RQbqWlWdNR+LgBhmai8wYY21tGQ1eFIPL/W0hPnMPGTFJiLvUF8NGDWLL7DYWxw5 LWYg== Received: by 10.66.84.196 with SMTP id b4mr3266336paz.41.1352213324704; Tue, 06 Nov 2012 06:48:44 -0800 (PST) Received: from ?IPv6:2001:df8:0:16:1949:57c3:7543:b6bc? ([2001:df8:0:16:1949:57c3:7543:b6bc]) by mx.google.com with ESMTPS id pq9sm11575085pbc.1.2012.11.06.06.48.42 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 06:48:43 -0800 (PST) Message-ID: <50992349.3000905@gmail.com> Date: Tue, 06 Nov 2012 09:48:41 -0500 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Arturo Servin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:48:45 -0000 +1 On 11/6/2012 9:42 AM, Arturo Servin wrote: > > I think you have captured the proposal. I have no objection following this path. > > Regards, > as > > Sent from my mobile device > (please excuse typoss and brevit.) > > > On 5 Nov 2012, at 23:21, "Murray S. Kucherawy" wrote: > >> I'd like to continue the internationalization discussion started during the meeting today. >> >> It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would provide the answers in whatever language(s) they have; the client will make use of that reply in whatever way it sees fit. >> >> Is there any specific objection to that approach for this work? (And have I captured the proposal properly?) >> >> -MSK >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From marc.blanchet@viagenie.ca Tue Nov 6 06:49:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA5921F893F for ; Tue, 6 Nov 2012 06:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pelJ3xA5+z5g for ; Tue, 6 Nov 2012 06:49:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 791BF21F8928 for ; Tue, 6 Nov 2012 06:49:34 -0800 (PST) Received: from [IPv6:2001:df8::80:a078:744c:328e:1c67] (unknown [IPv6:2001:df8:0:80:a078:744c:328e:1c67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B562F400D5; Tue, 6 Nov 2012 09:49:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_290BE9CF-A4E5-4900-8DC2-A313467A66BE" From: Marc Blanchet In-Reply-To: Date: Tue, 6 Nov 2012 09:49:32 -0500 Message-Id: References: To: Edward Lewis X-Mailer: Apple Mail (2.1283) Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:49:35 -0000 --Apple-Mail=_290BE9CF-A4E5-4900-8DC2-A313467A66BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-11-06 =E0 09:28, Edward Lewis a =E9crit : > At 23:21 -0500 11/5/12, Murray S. Kucherawy wrote: > I'd like to continue the internationalization discussion started = during the meeting today. >=20 > PS - at the mic, someone Simon Perreault > suggested looking at vcard...I think that is a good lead. for references: RFC6350 vCard Format Specification. RFC6351 xCard: vCard XML Representation "A JavaScript Object Notation (JSON) Representation for vCard", Raghurama Bhat, Peter Saint-Andre, 6-Jun-12, Regards, Marc. > --=20 > = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis =20 > NeuStar You can leave a voice message at = +1-571-434-5468 >=20 > 2012...time to reuse those 1984 calendars! > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_290BE9CF-A4E5-4900-8DC2-A313467A66BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Le 2012-11-06 =E0 09:28, Edward Lewis = a =E9crit :

At = 23:21 -0500 11/5/12, Murray S. Kucherawy wrote:
I'd like to = continue the internationalization discussion started during the meeting = today.

PS - at the mic, = someone

Simon = Perreault

= suggested looking at vcard...I think that is a good = lead.

for = references:
RFC6350 vCard Format = Specification.
RFC6351 xCard: vCard XML = Representation

  "A JavaScript Object = Notation (JSON) Representation for vCard",
  Raghurama = Bhat, Peter Saint-Andre, 6-Jun-12,
  = <draft-bhat-vcarddav-json-00.txt>

Reg= ards, Marc.

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

2012...time to reuse those 1984 = calendars!
_______________________________________________
weirds = mailing list
weirds@ietf.org
https://www.ietf.org= /mailman/listinfo/weirds

= --Apple-Mail=_290BE9CF-A4E5-4900-8DC2-A313467A66BE-- From johnl@iecc.com Tue Nov 6 07:12:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC321F8992 for ; Tue, 6 Nov 2012 07:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.948 X-Spam-Level: X-Spam-Status: No, score=-111.948 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueccwGoaVBCh for ; Tue, 6 Nov 2012 07:12:57 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2110A21F898A for ; Tue, 6 Nov 2012 07:12:56 -0800 (PST) Received: (qmail 59905 invoked from network); 6 Nov 2012 15:12:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Nov 2012 15:12:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509928ee.xn--hew.k1211; i=johnl@user.iecc.com; bh=bJSLbs91HYXxbT++/JgHFyW5btzHOkFEMBiYb1OE8kI=; b=qcy2s+BC3bEEVSQWXv+ixG3HyDirswS8rBaVx5VjjklpeJqxk44v9QuwLPXZRzj/3Th+Ti5w25PobXGXfVe9DENO/BKQRdyqu5RtEOvOxHbFuoLXsZryZWgXq4kh+yQtTOF4PkAOUNubvGWFPZ6NQ7p5RIsBHvGHQ2DTSLTMaNo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509928ee.xn--hew.k1211; olt=johnl@user.iecc.com; bh=bJSLbs91HYXxbT++/JgHFyW5btzHOkFEMBiYb1OE8kI=; b=LgXR9zoB7dOZrNUvrofShIY+/OoX4yxF+/eImQRd3J/Q5Hy9iCn7jJX0V7aBV/3d+3yMpT10I2aQbmqStPQo/rZw1WUZkTkRFGdboKXBFDO1Jqgz2WmC6J78YU9rWcUsGJLT8P+BJ7qRoSBRXbYg/5y7IO78y1Zpn0jSagMX9Sc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Nov 2012 15:12:24 -0000 Message-ID: <20121106151224.4104.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:12:58 -0000 >> Does the above mean no RFC 2119 key words for the request or the response? I think the intent is that the server SHOULD return the response in all languages it has available, and MUST tag each version with the correct language. This specifically does not mean that any server is required to support any particular language, but every server MUST support at least one language so it's able to return any results at all. Maybe I meant language+script where I said language above. The reason the SHOULD is not a MUST is because there might be situations where the server could use other clues to trim the set of languages it returns. I agree this gets us out of Klensin's rathole where there are potentially infinite numbers of languages one might ask for. In practice, it's hard to envision servers usefully returning more than three or four versions, e.g., central Asian languages that have been written in Arabic, Cyrillic, and Roman scripts. In most cases there'd be only one or two. R's, John From peter@denic.de Tue Nov 6 07:56:14 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99AA21F8A33 for ; Tue, 6 Nov 2012 07:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppwq9SAZGiNk for ; Tue, 6 Nov 2012 07:56:13 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D721F8A11 for ; Tue, 6 Nov 2012 07:56:13 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TVlVb-0004iz-Al; Tue, 06 Nov 2012 16:56:11 +0100 Received: from localhost by x27.adm.denic.de with local id 1TVlVb-0003WJ-7J; Tue, 06 Nov 2012 16:56:11 +0100 Date: Tue, 6 Nov 2012 16:56:11 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20121106155611.GI2347@x28.adm.denic.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:56:14 -0000 On Mon, Nov 05, 2012 at 11:21:28PM -0500, Murray S. Kucherawy wrote: > It's our read that the people talking on the topic were warm to the idea > that the query syntax would not include a provision for requesting a > response in a specific language, and the servers would provide the answers > in whatever language(s) they have; the client will make use of that reply > in whatever way it sees fit. > > Is there any specific objection to that approach for this work? (And have > I captured the proposal properly?) I believe you missed the part where it was demonstrated that the notion of language is particularly useless in the context of names. Let us try to avoid this by agreeing that an object might have multiple representations that are "tagged" and that the consensus in the room was that for this tagging there would be no server side selection/filtering but rather the client MUST be prepared to receive multiple instances (representations) of the same object which MUST be tagged if there is more than one and MAY be tagged if it is a single one. Any further processing is up to the client and may be a user interface issue that escapes protocol standardization. Translation of syntax elements like record/field names ought to be out of scope as should be the 'translation' of names (Peter->Pierre->Pedro->Pjotr) or other elements (street->straat->straße). The level of equivalence between two or more representations of an object the protocol should be agnostic about since this is a matter of policy the respective repository/registry will be operated under. -Peter From sm@resistor.net Tue Nov 6 09:02:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0561E21F8B44 for ; Tue, 6 Nov 2012 09:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEn7f-yZYMBf for ; Tue, 6 Nov 2012 09:02:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EA921F8A76 for ; Tue, 6 Nov 2012 09:02:54 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA6H2nxe004965 for ; Tue, 6 Nov 2012 09:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352221373; bh=lj/lM07qt7EMyRDtkbyZkcGvTlZZ7JrXlqSPc/00gsQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=IG5s6sNnCmEnfy2Dp8TjOvCATNxyKXf5GxZb6L7HRwwYba/X+nCqTIyIS1oWl2H84 q9v+R3x2ZIx2O40c87ZJEUuZjUFxq3kRHhgTM/l+ceOiAxp+rI8Ks8QknssafQPM5P ItEpqNAmiBFyhsYVjYDNcmx2chh2RuFmKZsKdQiQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352221373; i=@resistor.net; bh=lj/lM07qt7EMyRDtkbyZkcGvTlZZ7JrXlqSPc/00gsQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=c2Je3alnoUeCvt/ki6pNL6edIhil+R3N7OUqUzPDVnQDW1gT9pp0Dvl5wZ8y4XdgE U9Kxyo4h8DJHN2CiR4MmLVSlHH9xbrOaRVEdVaIRvCJeGXEFtgrdKMW8H1IkYoMiRP BUqSwp302zGak77vLSO0a1Kkek5Ume8cBfSLgd/g= Message-Id: <6.2.5.6.2.20121106083650.09ac7d90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Nov 2012 09:01:57 -0800 To: weirds@ietf.org From: SM In-Reply-To: <20121106151224.4104.qmail@joyce.lan> References: <20121106151224.4104.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:02:56 -0000 At 07:12 06-11-2012, John Levine wrote: >Maybe I meant language+script where I said language above. The problem is getting into a definition of language. I would have asked the question: what do you mean by language? After yesterday's WG session I prefer not to ask that question. >The reason the SHOULD is not a MUST is because there might be >situations where the server could use other clues to trim the set of >languages it returns. I'll comment below. >I agree this gets us out of Klensin's rathole where there are >potentially infinite numbers of languages one might ask for. In >practice, it's hard to envision servers usefully returning more than >three or four versions, e.g., central Asian languages that have been >written in Arabic, Cyrillic, and Roman scripts. In most cases there'd >be only one or two. Yes. At 07:56 06-11-2012, Peter Koch wrote: >I believe you missed the part where it was demonstrated that the notion >of language is particularly useless in the context of names. Let us try >to avoid this by agreeing that an object might have multiple representations >that are "tagged" and that the consensus in the room was that for this >tagging there would be no server side selection/filtering but rather >the client MUST be prepared to receive multiple instances (representations) >of the same object which MUST be tagged if there is more than one >and MAY be tagged if it is a single one. Any further processing is >up to the client and may be a user interface issue that escapes protocol >standardization. I prefer this approach. In the above "we" moved from language to representations. There should be some text about that so that the second "MUST" can be understood. The difference between this approach compared to the one suggested by John Levine is that there isn't any server-side filtering. In my view the problem is not being solved. I doubt that the problem can be solved within a realistic time frame (see John Levine's comment above). I don't think that the requirement resolves the concern of the director of the ICANN Board about law enforcement agencies and trademarks. However, if that concern is important to the ICANN Board, law enforcement agencies or trademark vendors, they have the opportunity, in my humble opinion, to discuss the matter on this mailing list. Regards, -sm From fobispo@isc.org Tue Nov 6 09:09:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F11821F8698 for ; Tue, 6 Nov 2012 09:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtsevYpDZdFk for ; Tue, 6 Nov 2012 09:09:11 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1421F855C for ; Tue, 6 Nov 2012 09:09:11 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id C6FF8CA2F7; Tue, 6 Nov 2012 17:09:05 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [149.20.66.30] (unknown [149.20.66.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4565D216C3D; Tue, 6 Nov 2012 17:09:05 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Tue, 6 Nov 2012 09:09:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:09:12 -0000 On Nov 6, 2012, at 4:30 AM, Murray S. Kucherawy = wrote: > Hi SM, >=20 > I believe it means there's no normative language in terms of the = query, because language selection is simply not part of the query. And not part of the data repository either. > The response I'm less sure about because I'm not an i18n expert and = don't know what would be appropriate; if the language of a returned = object needs to be explicit, then SHOULD or MUST seems reasonable, = otherwise a MAY (explicit or implied) would be fine. I leave that to = the editors and the WG to sort out. International + Localized information should fulfill most EPP = registries. Having an explicit language associated to the response = object is either going to force registries to return non-accurate data, = or run into a very complex validation problem down the line. >=20 Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From sm@resistor.net Tue Nov 6 09:50:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D6E21F8894 for ; Tue, 6 Nov 2012 09:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlnHfXBIZsPN for ; Tue, 6 Nov 2012 09:50:30 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1621F88B1 for ; Tue, 6 Nov 2012 09:50:29 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA6HoOg7009685; Tue, 6 Nov 2012 09:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352224229; bh=tj86DCzSaH2T6qeMN/0fZoBi30ilkHXFtmmQJ4WOlAc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YPh/u5HqH3rppJRHsy81O/TlpEMocDLv67Usex5dDUvR9eDy/wyWQ0Etea1a/42J7 KfkXWIlDd6Qw3IytAItd/0QxKpIjk6+W9KLhirZx/Elx17UIqvU9xwDml227pKkozD iPb0jTSUgDR+/++OkOIFMEKEoOSXeFWALcggg0rE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352224229; i=@resistor.net; bh=tj86DCzSaH2T6qeMN/0fZoBi30ilkHXFtmmQJ4WOlAc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ref/ny6f3Ky19VXEFhkybEHXpfMSVUiZ+GgCEfwIOKXwg0fM2Mx4E3NGmdEqRCMCh Ov8tN4nYGaVawTIu7qPfFeIvbaeclUbUPHSfeEElfSabHrOjzsXyNGimLH+I9k/cIN UAbiukZQXTcfASQef9yLmtMp7kd2DJ5gl6Np0Sxg= Message-Id: <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Nov 2012 09:50:17 -0800 To: Francisco Obispo From: SM In-Reply-To: <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:50:30 -0000 Hi Francisco, At 09:09 06-11-2012, Francisco Obispo wrote: >International + Localized information should fulfill most EPP >registries. Having an explicit language associated to the response >object is either going to force registries to return non-accurate >data, or run into a very complex validation problem down the line. Yes. Here's the alternative as I see it. If I send you a UTF-8 text without any hint you'll have to go and figure out what to do with it. If I understood what you said about, the following would be an issue: "multiple instances (representations) of the same object which MUST be tagged if there is more than one and MAY be tagged if it is a single one." [1] There is a "MAY" in there which removes the explicit language association. The problem would be the "more than one" case. I don't see any other way out of that. Regards, -sm 1. http://www.ietf.org/mail-archive/web/weirds/current/msg01863.html From fobispo@isc.org Tue Nov 6 09:59:48 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1821F8928 for ; Tue, 6 Nov 2012 09:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcKzWNt-ymm0 for ; Tue, 6 Nov 2012 09:59:48 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB9B21F8906 for ; Tue, 6 Nov 2012 09:59:48 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 34DCB5FA6C1; Tue, 6 Nov 2012 17:59:37 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [149.20.66.30] (unknown [149.20.66.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2322A216C3D; Tue, 6 Nov 2012 17:59:31 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> Date: Tue, 6 Nov 2012 09:59:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> To: SM X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:59:48 -0000 On Nov 6, 2012, at 9:50 AM, SM wrote: > Hi Francisco, > At 09:09 06-11-2012, Francisco Obispo wrote: >> International + Localized information should fulfill most EPP = registries. Having an explicit language associated to the response = object is either going to force registries to return non-accurate data, = or run into a very complex validation problem down the line. >=20 > Yes. >=20 > Here's the alternative as I see it. If I send you a UTF-8 text = without any hint you'll have to go and figure out what to do with it. = If I understood what you said about, the following would be an issue: >=20 > "multiple instances (representations) of the same object which MUST > be tagged if there is more than one and MAY be tagged if it is a > single one." [1] >=20 > There is a "MAY" in there which removes the explicit language = association. The problem would be the "more than one" case. I don't = see any other way out of that. >=20 Yes, I believe this will be an issue, now, what difference does it make = if the information is in one language or another? (in terms of user = experience), In our registry system we mandate an 'international' = version of the contact, and we allow an optional localized version. We = don't collect any language tag to describe the data because EPP lacks = the ability to do so. So in our case, we will always have a us-ascii version of it and an = optional localized (utf-8). In a whois system response in a system that is UTF-8 aware, we should = respond with as much information as possible, not limit it because we're = missing a language tag, or a specific field, in this case the more = information the better. So to solve the problem I would suggest making the "MUST" a "MAY" as = well, or simply stating multiple "localized" versions. Francisco > Regards, > -sm >=20 > 1. http://www.ietf.org/mail-archive/web/weirds/current/msg01863.html > =20 Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From ajs@anvilwalrusden.com Tue Nov 6 10:19:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA721F8A6B for ; Tue, 6 Nov 2012 10:19:39 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaCFhqlZ6Uhz for ; Tue, 6 Nov 2012 10:19:39 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB6F21F8A6A for ; Tue, 6 Nov 2012 10:19:39 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E15958A031 for ; Tue, 6 Nov 2012 18:19:36 +0000 (UTC) Date: Tue, 6 Nov 2012 13:19:32 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121106181931.GB70893@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:19:39 -0000 Dear colleagues, On Mon, Nov 05, 2012 at 11:21:28PM -0500, Murray S. Kucherawy wrote: > It's our read that the people talking on the topic were warm to the idea > that the query syntax would not include a provision for requesting a > response in a specific language, and the servers would provide the answers > in whatever language(s) they have; the client will make use of that reply > in whatever way it sees fit. I'm fine with this approach, but I think that if the server has any information about the language, script, or whatnot, it SHOULD use language tags as defined by RFC 5646. This nicely gets us both "language" and "script" (and actually, a bunch of other stuff too, if someone is foolish enough to use that). These language tags provide a way for a client to do useful things with the output. If there is not such tag, then if a client wants to do something useful, it has to guess, and that's a bad idea. It seems to me that we might want both the ability to place one tag on the entire response, and also a tag on various parts. This way, if a repository only ever has one language and script it can just say that once in a response; but at the same time a repository that has different kinds of stuff in the same response can identify each part accordingly. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@resistor.net Tue Nov 6 10:46:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09521F88B5 for ; Tue, 6 Nov 2012 10:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EypcqJ+5Jziv for ; Tue, 6 Nov 2012 10:46:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8442E21F88A1 for ; Tue, 6 Nov 2012 10:46:40 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA6IkYbo013669; Tue, 6 Nov 2012 10:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352227599; bh=TEbFnKXuEu9kbe+lNz/YyDw5rNiRi6pahjK3FbTzwyA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PrV/i4akAL6RVX6OX7AFpwhJiZkZiEyjZnJqb8clCqnhsTBfk0EqAFiN8Q2DM8JF4 7kFNQ32TQgD9+6bPl36rDQdc8oWl+NSi3baPKb4SuB/4AoZDF0WmqPD5aZie6xiJzR iHyeOwA2+rl2wu3UWPGWo+ECbmkBYr7amucHiNt4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352227599; i=@resistor.net; bh=TEbFnKXuEu9kbe+lNz/YyDw5rNiRi6pahjK3FbTzwyA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sNE0WyhqeQQk+/pcrscPW0PUzApJty+KX44ufWBsIK+VzNsZh+D4pVp36xJeMwY3o BDH4HA80YFGYtB7eRap+Ve+z6J4Cu313PzRrNc9dHKMFHoJn9sWG22S4jebEcna8EV oFh8OQRo5mQnlaYvqXLV6+ohOpdNcnA9GBdPCirM= Message-Id: <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Nov 2012 10:45:19 -0800 To: Francisco Obispo From: SM In-Reply-To: References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:46:41 -0000 Hi Francisco, At 09:59 06-11-2012, Francisco Obispo wrote: >Yes, I believe this will be an issue, now, what difference does it >make if the information is in one language or another? (in terms of >user experience), In our registry system we mandate an >'international' version of the contact, and we allow an optional >localized version. We don't collect any language tag to describe the >data because EPP lacks the ability to do so. Ok. Although it has been mentioned that EPP is out of scope it's unlikely that the discussion will go far if that part is ignored. >So in our case, we will always have a us-ascii version of it and an >optional localized (utf-8). > >In a whois system response in a system that is UTF-8 aware, we >should respond with as much information as possible, not limit it >because we're missing a language tag, or a specific field, in this >case the more information the better. > >So to solve the problem I would suggest making the "MUST" a "MAY" as >well, or simply stating multiple "localized" versions. How about changing the first MUST to a SHOULD? The above should be possible with that. You might run into problems outside the working group as people have their own interpretation of a "SHOULD". If a "MAY" is used the working group is not encouraging future behavior. Regards, -sm From fobispo@isc.org Tue Nov 6 10:49:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33A821F8906 for ; Tue, 6 Nov 2012 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFtxmkB34X7h for ; Tue, 6 Nov 2012 10:49:03 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6715721F88B5 for ; Tue, 6 Nov 2012 10:49:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 258C35FA6CC; Tue, 6 Nov 2012 18:48:51 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [149.20.66.30] (unknown [149.20.66.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6FC72216C80; Tue, 6 Nov 2012 18:48:50 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> Date: Tue, 6 Nov 2012 10:48:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> To: SM X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:49:04 -0000 +1 On Nov 6, 2012, at 10:45 AM, SM wrote: > How about changing the first MUST to a SHOULD? The above should be = possible with that. You might run into problems outside the working = group as people have their own interpretation of a "SHOULD". If a "MAY" = is used the working group is not encouraging future behavior. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From peter@denic.de Tue Nov 6 10:59:54 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D308121F8A9B for ; Tue, 6 Nov 2012 10:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QT10vqiZYYN for ; Tue, 6 Nov 2012 10:59:54 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 55B8821F8A18 for ; Tue, 6 Nov 2012 10:59:54 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TVoNN-0005iA-IH; Tue, 06 Nov 2012 19:59:53 +0100 Received: from localhost by x27.adm.denic.de with local id 1TVoNN-0006IZ-EU; Tue, 06 Nov 2012 19:59:53 +0100 Date: Tue, 6 Nov 2012 19:59:53 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20121106185953.GC20432@x28.adm.denic.de> References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:59:54 -0000 On Tue, Nov 06, 2012 at 10:45:19AM -0800, SM wrote: > How about changing the first MUST to a SHOULD? The above should be > possible with that. You might run into problems outside the working > group as people have their own interpretation of a "SHOULD". If a I doubt this makes sense because it would leave the client confused. -Peter From fneves@registro.br Tue Nov 6 11:21:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE9B21F8A6F for ; Tue, 6 Nov 2012 11:21:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aduuiTGVFx3K for ; Tue, 6 Nov 2012 11:21:05 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id D491C21F8772 for ; Tue, 6 Nov 2012 11:21:04 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id B24ABE04A1; Tue, 6 Nov 2012 17:21:01 -0200 (BRST) Date: Tue, 6 Nov 2012 17:21:01 -0200 From: Frederico A C Neves To: "Murray S. Kucherawy" Message-ID: <20121106192101.GF72175@registro.br> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 19:21:05 -0000 Murray, On Mon, Nov 05, 2012 at 11:21:28PM -0500, Murray S. Kucherawy wrote: > I'd like to continue the internationalization discussion started during the > meeting today. > > It's our read that the people talking on the topic were warm to the idea > that the query syntax would not include a provision for requesting a > response in a specific language, and the servers would provide the answers > in whatever language(s) they have; the client will make use of that reply > in whatever way it sees fit. > > Is there any specific objection to that approach for this work? (And have > I captured the proposal properly?) I support this approach with the added comments from Peter's and Andrew's messages. <20121106155611.GI2347@x28.adm.denic.de> <20121106181931.GB70893@mx1.yitter.info> > > -MSK > Fred From ajs@anvilwalrusden.com Tue Nov 6 11:22:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D437B21F84E8 for ; Tue, 6 Nov 2012 11:22:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeX8CnV+Eh-0 for ; Tue, 6 Nov 2012 11:22:26 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5721F8B2F for ; Tue, 6 Nov 2012 11:22:25 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 666188A031 for ; Tue, 6 Nov 2012 19:22:24 +0000 (UTC) Date: Tue, 6 Nov 2012 14:22:19 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121106192216.GB70939@mx1.yitter.info> References: <6.2.5.6.2.20121105223531.0b3de898@resistor.net> <72830F2D-0C3C-488C-966D-E54A0E9F897D@isc.org> <6.2.5.6.2.20121106093937.0b5b78d0@resistor.net> <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20121106101856.06d76fd8@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 19:22:27 -0000 On Tue, Nov 06, 2012 at 10:45:19AM -0800, SM wrote: > How about changing the first MUST to a SHOULD? The above should be > possible with that. You might run into problems outside the working > group as people have their own interpretation of a "SHOULD". If a > "MAY" is used the working group is not encouraging future behavior. If we say "MUST", someone who doesn't have a tag can always use "und": Type: language Subtag: und Description: Undetermined Added: 2005-10-16 Scope: special Alternatively, we could specify explicitly that any untagged data implicitly uses the und languge subtag, and proceed that way. But I do think that we need to make it possible for a server to provide data that a client can use in this or that way, and without a language tag that is difficult in some circumstances. A -- Andrew Sullivan ajs@anvilwalrusden.com From galvin+weirds@elistx.com Tue Nov 6 13:23:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888C321F847F for ; Tue, 6 Nov 2012 13:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+bY0VmjKqMd for ; Tue, 6 Nov 2012 13:23:39 -0800 (PST) Received: from ee01.elistx.com (ee01.elistx.com [67.155.182.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E121F8476 for ; Tue, 6 Nov 2012 13:23:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by elistx.com (PMDF V6.3-2x2 #31965) with ESMTP id <0MD30011Q4NVG4@elistx.com> for weirds@ietf.org; Tue, 06 Nov 2012 16:21:31 -0500 (EST) Date: Tue, 06 Nov 2012 16:24:13 -0500 From: Jim Galvin In-reply-to: To: weirds@ietf.org Message-id: <0C35E04EEA6056291B8112F2@dhcp-4771.meeting.ietf.org> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline References: Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:23:40 -0000 I very much support this approach. I also agree with others in this thread who have pointed out that the=20 response, however, should be tagged appropriately. This may or may not = imply that the data itself, in its actual repository, is tagged. But=20 the data in the response needs to be tagged, which includes deciding=20 there's an implicit default tag. Tagging should be granular enough such that it can be applied to=20 individual elements, for some appropriate definition of element. Jim -- On November 5, 2012 11:21:28 PM -0500 "Murray S. Kucherawy"=20 wrote regarding [weirds] Proposal for=20 internationalization question -- > I'd like to continue the internationalization discussion started > during the meeting today. > > It's our read that the people talking on the topic were warm to the > idea that the query syntax would not include a provision for > requesting a response in a specific language, and the servers would > provide the answers in whatever language(s) they have; the client > will make use of that reply in whatever way it sees fit. > > Is there any specific objection to that approach for this work?=C2=A0 > (And have I captured the proposal properly?) > > -MSK From johnl@iecc.com Tue Nov 6 13:47:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77BE21F8A6B for ; Tue, 6 Nov 2012 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.99 X-Spam-Level: X-Spam-Status: No, score=-111.99 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 754-J4BWNGao for ; Tue, 6 Nov 2012 13:47:41 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E921F8C40 for ; Tue, 6 Nov 2012 13:47:34 -0800 (PST) Received: (qmail 53501 invoked from network); 6 Nov 2012 21:47:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Nov 2012 21:47:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50998574.xn--9vv.k1211; i=johnl@user.iecc.com; bh=g5PqdfFP/jYVj/fG+a57KJsERnxuvJYTyu2OkunnKn0=; b=AMTtBjno/5jpbGpjxDdXEnGGu74pwy195I1GgNvMYZnjeyAzbGyqF9JFFTZJyQs7KuZDeHmHkb2/bN8Yg/v9SolU6WAD/1kaabwh3wc6IR9YYjvV5FyrzYCOsbuMig+fsLlAOwhWYhImW+2M3O9v67unRBtcmZY7Aqv0Aw4VE0o= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50998574.xn--9vv.k1211; olt=johnl@user.iecc.com; bh=g5PqdfFP/jYVj/fG+a57KJsERnxuvJYTyu2OkunnKn0=; b=PV0W/KdhH/IK94TIxxS5EY9JPffTK/C0rw2wmh89rDw5pOHP9Iee6hgQlLy5AmG1eVGOtb0uoTHbT5aSPzyvcsyltizZkDkErBOVFbLF+3OZ7T3LJywRNPJVDlOnQE7uCzz9ytWD2UNymapiS72DgrtG35R8dhP0JiVEw8JPNwE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Nov 2012 21:47:10 -0000 Message-ID: <20121106214710.10696.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <0C35E04EEA6056291B8112F2@dhcp-4771.meeting.ietf.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:47:41 -0000 >Tagging should be granular enough such that it can be applied to >individual elements, for some appropriate definition of element. Can you give some examples where it would be useful to have a single response with some elements in one language and some in another? Also, if you agree that the server should return responses in whatever languages it has, if a server has 16 fields, each of which has versions in two languages (imagine all of the fields of a group of names and addresses), does that mean the server should return 65,536 responses? Assuming that's not what you had in mind, how many responses should it return? R's, John From fobispo@isc.org Tue Nov 6 13:54:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02F621F8B81 for ; Tue, 6 Nov 2012 13:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oMohUXyqpgb for ; Tue, 6 Nov 2012 13:54:57 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 83F3D21F8B7E for ; Tue, 6 Nov 2012 13:54:44 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5F6A55FA6F5; Tue, 6 Nov 2012 21:54:33 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9977F216C80; Tue, 6 Nov 2012 21:54:31 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <20121106214710.10696.qmail@joyce.lan> Date: Tue, 6 Nov 2012 13:54:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121106214710.10696.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:54:58 -0000 If someone went through the trouble of filling out this information, the = least the registry can do is to offer that information ;-) I don't think that will be the case though, I'm actually reluctant to = bring EPP to the discussion again, but it is our input protocol, and as = it is written, it only allows one "international" and one of type "loc", = so even though we want to decouple the two protocols because not all = registries use EPP, I think it's not feasible to ask more than what EPP = can currently offer because implementing it would not be = straightforward, but even if that was the case, the registry will have = to "validate" the languages and that by itself can be problematic. I like the approach where we have the "undefined" language as a tag = where you don't have it, remember that we've made all the fields = 'optional', so this is should be compatible with that. Francisco On Nov 6, 2012, at 1:47 PM, "John Levine" wrote: > Also, if you agree that the server should return responses in whatever > languages it has, if a server has 16 fields, each of which has > versions in two languages (imagine all of the fields of a group of > names and addresses), does that mean the server should return 65,536 > responses? Assuming that's not what you had in mind, how many > responses should it return? Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From steve.sheng@icann.org Tue Nov 6 13:58:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00C621F84D2 for ; Tue, 6 Nov 2012 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9zdpjb5rfJO for ; Tue, 6 Nov 2012 13:58:23 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB1C21F84F8 for ; Tue, 6 Nov 2012 13:58:19 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 6 Nov 2012 13:58:18 -0800 From: Steve Sheng To: Peter Koch , "weirds@ietf.org" Date: Tue, 6 Nov 2012 13:58:19 -0800 Thread-Topic: [weirds] Proposal for internationalization question Thread-Index: Ac28adRtwngCH9JUTJyRyfWo1VSUnA== Message-ID: In-Reply-To: <20121106155611.GI2347@x28.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435055099_3621443" MIME-Version: 1.0 Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 21:58:26 -0000 --B_3435055099_3621443 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi,=20 -----Original Message----- From: Peter Koch Date: Tuesday, November 6, 2012 7:56 AM To: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question >Translation of syntax elements like record/field names ought to be out of >scope >as should be the 'translation' of names (Peter->Pierre->Pedro->Pjotr) >or other elements (street->straat->stra=DFe). >The level of equivalence between two or more representations of an object >the >protocol should be agnostic about since this is a matter of policy the >respective repository/registry will be operated under. I would like to strongly support Peter's point that whether a internet registry provides localized content is a matter of policy and out of scope for the working group. Several options exist for how to publish the internationalized contact information in Whois: Option 1: Publish No internationalized registration data (status quo, but unlikely given today's environment) Option 2: Publish Internationalized contact data + translation of the internationalized contact data Option 3: Publish Internationalized contact data + transliteration of the internationalized contact data Option 4: Publish Internationalized data only, no additional requirements There are pros and cons, feasibility and cost implications for each option, and which one to select is a matter of either local ccTLD policy or ICANN policy.=20 For generic TLDs, there is an upcoming ICANN policy effort to determine which option to choose (see http://gnso.icann.org/en/resolutions/#20121017-5), and we welcome anyone interested to participate. The implication for protocol I see is if policy end up choosing 2 - 4, the internationalized data needs to be tagged for end user clients to better consume this information. Kind regards,=20 Steve --B_3435055099_3621443 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFBHKHpPRFGs7FyGJP6tlEzM0nEuRMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwNjIxNTgxOVowDQYJ KoZIhvcNAQEBBQAEggEArT/4qJUhrV94rg2OtZHXt/AL8cdN8sVdAewn4ilNIMgxxebcnqKN idZOey/yvG8AUZAWY05ke2uxBId3ZBH4OmoDopd8PMZE+Kxj2Nn+9xP4qhqQoscqTppXgY4n rS2Ysdc1flZbwKKrUhPBTo5oCNxEYhzuorF4fdC2L9042lAqpGgpX6hhbUwEItEguNU+QIWO DEH5607LXCoA85csRHdjTDmPvtJPoLFIm63mrQuC8GZIwrDVc20EIcEfaSSacxV5TW+AZm5A xGOrh3ppR/GRuI6LuSM9XXRHxUVNIiDx9dNDOd/9grPw0vDapduARjN/f6Re4sB8MrbIhIqO eQ== --B_3435055099_3621443-- From ajs@anvilwalrusden.com Tue Nov 6 14:08:48 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C344021F8ADD for ; Tue, 6 Nov 2012 14:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzLerviD9BgR for ; Tue, 6 Nov 2012 14:08:48 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0021F89B3 for ; Tue, 6 Nov 2012 14:08:47 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 709258A031 for ; Tue, 6 Nov 2012 22:08:45 +0000 (UTC) Date: Tue, 6 Nov 2012 17:08:36 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121106220836.GA71119@mx1.yitter.info> References: <0C35E04EEA6056291B8112F2@dhcp-4771.meeting.ietf.org> <20121106214710.10696.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121106214710.10696.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:08:48 -0000 On Tue, Nov 06, 2012 at 09:47:10PM -0000, John Levine wrote: > Can you give some examples where it would be useful to have a single > response with some elements in one language and some in another? If contact data is stored in two languages and everything else is not so taggged (perhaps only contact data has an internationalized form), then the server would return one response with (say) the und- tag and the portion of the response that has the other tag. > Also, if you agree that the server should return responses in whatever > languages it has, if a server has 16 fields, each of which has > versions in two languages (imagine all of the fields of a group of > names and addresses), does that mean the server should return 65,536 > responses? Assuming that's not what you had in mind, how many > responses should it return? No, it returns one response with all the fields in both versions. That's what I understood by "send everything and let the client sort it out". A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Nov 6 14:13:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601721F8B9D for ; Tue, 6 Nov 2012 14:13:08 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5thyyG65yyM for ; Tue, 6 Nov 2012 14:13:07 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AA91F21F8B69 for ; Tue, 6 Nov 2012 14:13:05 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DC42F8A031 for ; Tue, 6 Nov 2012 22:13:01 +0000 (UTC) Date: Tue, 6 Nov 2012 17:12:57 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121106221257.GB71119@mx1.yitter.info> References: <20121106214710.10696.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:13:08 -0000 On Tue, Nov 06, 2012 at 01:54:30PM -0800, Francisco Obispo wrote: > and as it is written, it only allows one "international" and one of > type "loc", so even though we want to decouple the two protocols I think it is plain that, if the internationalization and localization concerns are real ones, that feature of EPP almost certainly needs to be reconsidered. We can't do anything about that here, but we can build a protocol that can cope with a more sophisticated system. As John Klensin was saying at the mic, one of the things we have learned over recent years is "just use UTF-8 and you're done" is not actually very good advice. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@taugh.com Tue Nov 6 14:42:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4298E21F8B8C for ; Tue, 6 Nov 2012 14:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIVcMr3wTpSo for ; Tue, 6 Nov 2012 14:42:11 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F305221F8A60 for ; Tue, 6 Nov 2012 14:42:10 -0800 (PST) Received: (qmail 67013 invoked from network); 6 Nov 2012 22:42:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=105c3.50999241.k1211; bh=0xPMb4whjbo+aIU+aeRz/RoTDZX4QgZ3yjYLFhjkoIY=; b=y/CVEb2a6zqSAgFJdr9Auzor+QcY4cR6AwadZUwpKDw4G9RfXkurmXWtKdivOpffHscWPU4GK+PSEFeyCf2I1BUsv+CJOhUnNPD3BNiPw4hLcUrrIaw8Wil8jaZLn9zXTAtCs/IftQcHU7ctAp7M4vFvyemni1D6VfWFHtKmkaE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=105c3.50999241.k1211; bh=0xPMb4whjbo+aIU+aeRz/RoTDZX4QgZ3yjYLFhjkoIY=; b=D7MIri6z6r3gnmgMDEARjPDssaw55dk4DhhX7DT6QuVyHd8Z9Twgl59aep8g07ASALhC2naAtVWOuyrOUJkAPCLPq0ujo4ONT6PI+k9wV3R8TwTofbGp8CuvpFhtcxi3F1DSlXwm0gDlZR/SkQEG20q6pqkweLu9KJwDn4yGx4o= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 6 Nov 2012 22:41:47 -0000 Date: 6 Nov 2012 17:42:09 -0500 Message-ID: From: "John R Levine" To: "Francisco Obispo" In-Reply-To: References: <20121106214710.10696.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] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:42:12 -0000 > If someone went through the trouble of filling out this information, the > least the registry can do is to offer that information ;-) Of course. But realistically, you're going to have a name in all Japanese or all English, not one with even numbered fields in Japanese and odd numbered fields in English. The question here is whether one language tag (possibly "und") for the whole response is adequate, or whether indvidual parts need separate tags. I strongly prefer the former. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From fobispo@isc.org Tue Nov 6 14:46:48 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613121F8B32 for ; Tue, 6 Nov 2012 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtXJgLN4uPNg for ; Tue, 6 Nov 2012 14:46:48 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F07D421F8B2F for ; Tue, 6 Nov 2012 14:46:47 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9E3EACA33D; Tue, 6 Nov 2012 22:46:34 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.105] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 82679216C7B; Tue, 6 Nov 2012 22:46:34 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: <20121106221257.GB71119@mx1.yitter.info> Date: Tue, 6 Nov 2012 14:46:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD2434B-F415-476B-9CEB-05C04DC66FBA@isc.org> References: <20121106214710.10696.qmail@joyce.lan> <20121106221257.GB71119@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:46:48 -0000 I agree with you. My point is that we are going down the list of things = that would be really nice to have in the output, that were never = considered in the input. If we need to reconsider the input, I'm all for that, and lets get it = done. Francisco On Nov 6, 2012, at 2:12 PM, Andrew Sullivan = wrote: > I think it is plain that, if the internationalization and localization > concerns are real ones, that feature of EPP almost certainly needs to > be reconsidered. We can't do anything about that here, but we can > build a protocol that can cope with a more sophisticated system. Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From ajs@anvilwalrusden.com Tue Nov 6 14:52:59 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFAE21F8BBE for ; Tue, 6 Nov 2012 14:52:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4QP-sSKvfkI for ; Tue, 6 Nov 2012 14:52:58 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF521F8B69 for ; Tue, 6 Nov 2012 14:52:58 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A5E968A031 for ; Tue, 6 Nov 2012 22:52:48 +0000 (UTC) Date: Tue, 6 Nov 2012 17:52:44 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121106225243.GC71119@mx1.yitter.info> References: <20121106214710.10696.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 22:52:59 -0000 On Tue, Nov 06, 2012 at 05:42:09PM -0500, John R Levine wrote: > The question here is whether one language tag (possibly "und") for > the whole response is adequate, or whether indvidual parts need > separate tags. I strongly prefer the former. The plan that emerged in the meeting yesterday was "client can't request stuff, server sends everything and then the client does something sensible." This means that, if the server has more than one tagged dataset, you need to be able to tell which part is which kind of thing. Some kinds of data won't be different at all, and you don't need that kind of response. In a contact, for instance, in almost every case you're not going to have different languages for the phone number. So there's no reason to send that twice. A -- Andrew Sullivan ajs@anvilwalrusden.com From peter@denic.de Tue Nov 6 15:08:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2021F8604 for ; Tue, 6 Nov 2012 15:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppm1WEhclvaK for ; Tue, 6 Nov 2012 15:08:26 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id D177521F85F4 for ; Tue, 6 Nov 2012 15:08:25 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.17]) by office.denic.de with esmtp id 1TVsFt-00071I-0d; Wed, 07 Nov 2012 00:08:25 +0100 Received: from localhost by x27.adm.denic.de with local id 1TVsFs-0001Y0-TV; Wed, 07 Nov 2012 00:08:24 +0100 Date: Wed, 7 Nov 2012 00:08:24 +0100 From: Peter Koch To: weirds@ietf.org Message-ID: <20121106230824.GF20432@x28.adm.denic.de> References: <20121106214710.10696.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 23:08:27 -0000 The level of detail we're approaching right now and here may already be to deep. On Tue, Nov 06, 2012 at 05:42:09PM -0500, John R Levine wrote: > The question here is whether one language tag (possibly "und") for the > whole response is adequate, or whether indvidual parts need separate tags. > I strongly prefer the former. "Language" is still the wrong term. Other than that, having the tags per field rather than per object would need a use case. Also it would allow for corner cases where there is no consistent representation available over a full object (1st field "A" and "B", 2nd tagged "B" and "C" and 3rd tagged "A" and "C"). The overhead of resending common fields might be operationally negligible. So, "+.9". -Peter From nkong@cnnic.cn Tue Nov 6 23:53:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EFB21F8792 for ; Tue, 6 Nov 2012 23:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUerFR-gPeRm for ; Tue, 6 Nov 2012 23:53:58 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 7466B21F878D for ; Tue, 6 Nov 2012 23:53:57 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 07 Nov 2012 15:53:53 +0800 From: "Ning Kong" To: "'Andrew Sullivan'" , References: <20121106181931.GB70893@mx1.yitter.info> In-Reply-To: <20121106181931.GB70893@mx1.yitter.info> Date: Wed, 7 Nov 2012 15:53:43 +0800 Message-ID: <01de01cdbcbd$03bf4540$0b3dcfc0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHboDL3WfgLu5cxTUvkY/JeJyxq1QIVrzQQl7GHVFA= Content-Language: zh-cn Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 07:53:58 -0000 +1 It seems like that you have the similar idea as the 7.3 section of draft-sheng-weirds-icann-rws-dnrd-01. > I'm fine with this approach, but I think that if the server has any information > about the language, script, or whatnot, it SHOULD use language tags as > defined by RFC 5646. This nicely gets us both "language" and "script" (and > actually, a bunch of other stuff too, if someone is foolish enough to use that). > > These language tags provide a way for a client to do useful things with the > output. If there is not such tag, then if a client wants to do something useful, > it has to guess, and that's a bad idea. > > It seems to me that we might want both the ability to place one tag on the > entire response, and also a tag on various parts. This way, if a repository > only ever has one language and script it can just say that once in a response; > but at the same time a repository that has different kinds of stuff in the same > response can identify each part accordingly. From nkong@cnnic.cn Wed Nov 7 00:11:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD8521F878D for ; Wed, 7 Nov 2012 00:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp2cZoQCm9yh for ; Wed, 7 Nov 2012 00:11:20 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 39F4221F868F for ; Wed, 7 Nov 2012 00:11:18 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 07 Nov 2012 16:11:08 +0800 From: "Ning Kong" To: "'Francisco Obispo'" , "'Andrew Sullivan'" References: <20121106214710.10696.qmail@joyce.lan> <20121106221257.GB71119@mx1.yitter.info> <2BD2434B-F415-476B-9CEB-05C04DC66FBA@isc.org> In-Reply-To: <2BD2434B-F415-476B-9CEB-05C04DC66FBA@isc.org> Date: Wed, 7 Nov 2012 16:10:57 +0800 Message-ID: <01e801cdbcbf$6c912780$45b37680$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJTg2nAbpQMLf3BhHjUKdjm/jWeeQLPW1b2AawxFMwBnlRp6Zahp+7A Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 08:11:20 -0000 > I agree with you. My point is that we are going down the list of things that > would be really nice to have in the output, that were never considered in the > input. > > If we need to reconsider the input, I'm all for that, and lets get it done. Count me in, please. From zhoulinlin@cnnic.cn Wed Nov 7 00:38:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5EB21F85CB for ; Wed, 7 Nov 2012 00:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvJkEIOwQCYs for ; Wed, 7 Nov 2012 00:38:43 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2FA6921F85BF for ; Wed, 7 Nov 2012 00:38:41 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 07 Nov 2012 16:38:31 +0800 From: "Linlin Zhou" To: "'John R Levine'" , "'Francisco Obispo'" References: <20121106214710.10696.qmail@joyce.lan> In-Reply-To: Date: Wed, 7 Nov 2012 16:38:31 +0800 Message-ID: <004601cdbcc3$44df6c70$ce9e4550$@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: Ac28cYTcsWIozFRkR9eHEJM1SBA2OAATRzaw Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 08:38:43 -0000 > The question here is whether one language tag (possibly "und") for the whole > response is adequate, or whether indvidual parts need separate tags. > I strongly prefer the former. > I support one tag for each response which is a simple solution in my opinion. Although it may have duplicated information, such as telephone number or fax number. The latter one of tags for each object may cause some complexity. Until now I have no better idea about how to structure the response format. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I > dropped the toothpaste", said Tom, crestfallenly. Linlin From shollenbeck@verisign.com Wed Nov 7 07:18:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7621F8BDF for ; Wed, 7 Nov 2012 07:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.988 X-Spam-Level: X-Spam-Status: No, score=-4.988 tagged_above=-999 required=5 tests=[AWL=-1.389, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iMuXNB0bOaT for ; Wed, 7 Nov 2012 07:18:06 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8BE21F8BAE for ; Wed, 7 Nov 2012 07:18:06 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUJp7rabQ9yPpMM10SsOVCioHt/K+eCC5@postini.com; Wed, 07 Nov 2012 07:18:06 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA7FI2sS019647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Nov 2012 10:18:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 10:18:02 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: Thoughts on Names Redirection Thread-Index: Ac28+xOKqOg4J8nJQsSjgsOdi1Fryg== Date: Wed, 7 Nov 2012 15:18:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@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] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:18:07 -0000 As requested by Carlos during the meeting... I agree with the sentiment in the room that there isn't much of an issue fo= r the com/net thin registry model. Verisign has referral info for all of th= e registrars we work with, though the specific info we collect (currently w= e have a URL to a web page that may or may not be dedicated to providing wh= ois service) will probably need to be changed to support this service. With= appropriate info collected from registrars we can redirect as needed. A more interesting case involves redirects for objects managed by other ser= vice providers. I believe there is an opportunity here for both TLD operato= rs and RDAP proxies to receive requests, determine an appropriate redirect = using service discovery techniques, and then respond with that redirect. Th= is would provide a more user-friendly operational experience than a 404 res= ponse. The challenge with this second case is that we haven't made any decisions a= bout service discovery. It would be difficult to document an approach in th= e redirect draft without being able to explain how service discovery works. Carlos, I'm willing to contribute text as needed. Scott From jyee@afilias.info Wed Nov 7 07:37:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520821F8C01 for ; Wed, 7 Nov 2012 07:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jikR7KoOpmey for ; Wed, 7 Nov 2012 07:37:36 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 483A821F8BFF for ; Wed, 7 Nov 2012 07:37:36 -0800 (PST) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1TW7h1-0006W6-6D for weirds@ietf.org; Wed, 07 Nov 2012 15:37:27 +0000 Received: from mail-oa0-f70.google.com ([209.85.219.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1TW7h1-0007gL-5y for weirds@ietf.org; Wed, 07 Nov 2012 15:37:27 +0000 Received: by mail-oa0-f70.google.com with SMTP id k14so5399910oag.1 for ; Wed, 07 Nov 2012 07:37:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oPwfh0XPEewowmyR1414VwDjxs4B9QS5QAAfTnXcSoA=; b=BJUW4wiC41X621yWhQalnw2fCk7WmFT99jFB+boGfswPR6eMC2p5Mt0EdtSTatmhmt Xqed53jNL4ufJoZb5iEGB6u2MdQd94UE7x3NKfAqBx1DlDmSshPVKtZIVBn6s6/B2jaq qwKV4UQKEUtS5T1iowKRoefajLfZiItotdYRnWUi4c7po5rp2ZL2mLERSGt5MjYI4Lp6 cmPzflBmkrI/3co9PoUBokuvqyxiRkVaUVAGJCKQ4e3LuF/VbgyFzClE8BGM+sAU2Mqz kAmeN6sDJsD3UnJA74UWJOcm0arlDT22V7UiwcjIEAdljOP1kYprWwELKIUGAPxotmMD 6i7w== Received: by 10.60.26.234 with SMTP id o10mr2306785oeg.85.1352302642415; Wed, 07 Nov 2012 07:37:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.26.234 with SMTP id o10mr2306784oeg.85.1352302642321; Wed, 07 Nov 2012 07:37:22 -0800 (PST) Received: by 10.60.26.233 with HTTP; Wed, 7 Nov 2012 07:37:22 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Nov 2012 10:37:22 -0500 Message-ID: From: Joseph Yee To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnvClb2EQVSPFsJ5RoU3lXsz9aMPrGZKZbGcSlpqVUBeVVDuObejPIj2ME22Z1QuA4oXMWeum/fT65ueL7cydro+bB5ulW4z03ItJn9A3JX3nfRetXiUtx/SPqoBFsEZhuaLGWO Cc: "weirds@ietf.org" Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:37:37 -0000 On Mon, Nov 5, 2012 at 11:21 PM, Murray S. Kucherawy wrote: > I'd like to continue the internationalization discussion started during the > meeting today. > > It's our read that the people talking on the topic were warm to the idea > that the query syntax would not include a provision for requesting a > response in a specific language, and the servers would provide the answers > in whatever language(s) they have; the client will make use of that reply in > whatever way it sees fit. > > Is there any specific objection to that approach for this work? (And have I > captured the proposal properly?) I support this approach. Regarding how to tag response, one tag for the whole response is more practical. Tagging per line is very close to impractical. Most of the time, only the user (or registrant who buys the domain name in name registry) know the exact language/script, and I doubt that any form asks for both contact and the language associate with it. I don't mind (but strongly prefer not to) "embedded" tagging, but it must be optional (and default to response's value if absent). I agreed with Andrew that using the tags from RFC 5646, we shouldn't create new tags here. Joseph > > -MSK > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From ajs@anvilwalrusden.com Wed Nov 7 08:04:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0021F87EA for ; Wed, 7 Nov 2012 08:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qWb85XZDq0i for ; Wed, 7 Nov 2012 08:04:10 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C3ACE21F8C04 for ; Wed, 7 Nov 2012 08:04:06 -0800 (PST) Received: from mx1.yitter.info (dhcp-13cd.meeting.ietf.org [130.129.19.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3BD4B8A031 for ; Wed, 7 Nov 2012 16:04:06 +0000 (UTC) Date: Wed, 7 Nov 2012 11:03:59 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20121107160359.GK74706@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:04:11 -0000 On Wed, Nov 07, 2012 at 10:37:22AM -0500, Joseph Yee wrote: > I support this approach. Regarding how to tag response, one tag for > the whole response is more practical. Just to be clear, then: The example we actually have is registries that use "two languages". To state it more neutrally, we have some repositories that have data that is associated with the same identifier, and that is encoded in two different ways. The general case is for data that is associated with the same identifier, and is encoded in N ways. If the WG picks "one tag for whole response", then it is necessary to send two responses for a single query, and to duplicate all the data in common between those two responses. The client (which IIRC was often supposed to be "web browser parsing response") needs to be able to handle these two responses in some way. If the WG picks "tags that apply to following data until next tag", then it's possible to return one complete response, and then when you get to the bits that have more than one (tagged) encoding, you just return multiple entries of those bits, each with its relevant tag. To me, the first if these is much easier for implementers of servers, but may duplicate a lot of data. The second of these reduces duplication of data, but perhaps makes the processing more complicated. With two encodings, the trade-off isn't really worth it. With more than two, we might find it is worth it. Unfortunately, given the poor internationalization support to date, I don't think actual whois implementations provide us any kind of guidance about what people want. All I know is that many, many people have complained about internationalization here, and I'll be surprised if every repository is forever nailed to two encodings of the data. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Wed Nov 7 08:06:01 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429E721F8C31 for ; Wed, 7 Nov 2012 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.006 X-Spam-Level: X-Spam-Status: No, score=-112.006 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0aE9YNQ4NVd for ; Wed, 7 Nov 2012 08:06:00 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 884DF21F8C4C for ; Wed, 7 Nov 2012 08:05:55 -0800 (PST) Received: (qmail 99717 invoked from network); 7 Nov 2012 16:05:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Nov 2012 16:05:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509a86e1.xn--9vv.k1211; i=johnl@user.iecc.com; bh=X8ADlOneoSzl917LhyTlprwn0rehc1ubEi4ug++JJwU=; b=N3khhrr9xvE0Uct5R4wwXAJjwQNCoz/MHum3gfv94ttkfciWFNfhrx5vjzV6/+oCVpnDxJN1/on+IshSnbjpZqC6X9seA1thAHXFkg+55FS4iIbFUFp5uFEsKYpv7l5420+s+fQ1TQ7k5x5/hBelsvWa4ul3R+8YvSEgjurQ5fA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509a86e1.xn--9vv.k1211; olt=johnl@user.iecc.com; bh=X8ADlOneoSzl917LhyTlprwn0rehc1ubEi4ug++JJwU=; b=dYqmAl6jenico4iYL+GrliCLQpBiZBvYNBzg/igl7kj6ernfyNFFfQDzOluWzckr6Zyz8f4I9Vp+kWEbpRtDEhmvN7MpQuNITT7ZBUqIGkJc4FgPh49wJmnG66a/s7U5ofcv+UYJ/wTk9DVink2Vam0HxeUPFceF2L+IpDoVRU8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Nov 2012 16:05:30 -0000 Message-ID: <20121107160530.16905.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] bootstrap and authoritative path, was Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:06:01 -0000 >A more interesting case involves redirects for objects managed by other >service providers. ... >The challenge with this second case is that we haven't made any >decisions about service discovery. It would be difficult to document an >approach in the redirect draft without being able to explain how service >discovery works. Here are three issues: A) Courtesy redirects for clients who start at the wrong server B) Service discovery, how to find the initial server for a query C) Server authorization, does a server have the real answer to a query They're all actually the same issue. If you know how to find the right initial server, you don't have to worry about courtesy redirects or authorization, since you know you have a valid chain of redirects to whatever server has the answer. For authorization, if you had some way to tell which servers are allowed to answer what questions, you'd just ask those servers, so it's the same as service discovery. For courtesy redirects, if we had service discovery, we wouldn't need it. Or if we like the current arrangement with the RIRs, where each RIR has authoritative redirects for the whole IP space (enough that there's a non-looping chain to the answer for any IP), we've solved the discovery and authorization problem. I don't feel strongly about how we solve this (give or take the implementability problems we discussed in Vancouver), but we do need to keep in mind that we need to consider all three at the same time. R's, John From johnl@iecc.com Wed Nov 7 08:11:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF91121F8C44 for ; Wed, 7 Nov 2012 08:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.02 X-Spam-Level: X-Spam-Status: No, score=-112.02 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHXBoOEN-hBX for ; Wed, 7 Nov 2012 08:11:01 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 06DA321F8C21 for ; Wed, 7 Nov 2012 08:11:00 -0800 (PST) Received: (qmail 1062 invoked from network); 7 Nov 2012 16:11:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Nov 2012 16:11:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=509a8814.xn--yuvv84g.k1211; i=johnl@user.iecc.com; bh=znMhdhBgi8BisqcEGVXEMRwusxVlsKWZpFlsjcdyu9g=; b=Yq/E42bRvUN3XDz8eGNFMXxE93gU4s18liR2hYdvpsS8sKeRw4/As9p+7Az0UjoBlyQ8AOgOQnykMxkckIwvHtJYoZVCZ5Zv/mKnsj1aJsMv7CPAeCLZrFGzKS1ahSZiPoH547EumltCOZpx4ItZG6MPxv4ktCfyAHKf7k5W/Ck= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=509a8814.xn--yuvv84g.k1211; olt=johnl@user.iecc.com; bh=znMhdhBgi8BisqcEGVXEMRwusxVlsKWZpFlsjcdyu9g=; b=jVdL87HrUND40vs435omG6XBNfIa/YxNYlb4G5IFKEVRJMZAO8D09NDfEIDyvKf8Kw406KQNOqp/Tw8qqSDjvVM2Pxa704V72veM5WWdMPP3R2qQxEXh/7R8p8HC9zsskrLQM5SGGneOyfEuvUo/yG9NOfwAElA+xsvFxr5v9fs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Nov 2012 16:10:38 -0000 Message-ID: <20121107161038.17084.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [weirds] Non-repudiation and JOSE X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:11:02 -0000 I'm sitting in the JOSE working group session. The stuff they're doing is more complex than what I'd like, but if you want to sign a block of JSON, they're defining how to do it. I would NOT suggest adding non-repudiation to the WEIRDS work, but if someone thinks it's important, go figure out JOSE and write an draft that says what signatures to wrap around what answers. Note that JOSE is not transparent. If a client isn't expecting JOSE signed data, it won't be able to find the payload even if it doesn't care about the signature, so this would need extra query option to say that the client wants a signed response. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From shollenbeck@verisign.com Wed Nov 7 08:17:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9743A21F8C2A for ; Wed, 7 Nov 2012 08:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4nA5Qj3L9db for ; Wed, 7 Nov 2012 08:17:43 -0800 (PST) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id E037A21F8C22 for ; Wed, 7 Nov 2012 08:17:42 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUJqJprzjc1KKwhE1GydMCzhZux/rECDB@postini.com; Wed, 07 Nov 2012 08:17:43 PST 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 qA7GHdgl021765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Nov 2012 11:17:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 11:17:39 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] Non-repudiation and JOSE Thread-Index: AQHNvQKNxWv+YyCeTECZkvjI6YJgYJfei3ow Date: Wed, 7 Nov 2012 16:17:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AEBFD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121107161038.17084.qmail@joyce.lan> In-Reply-To: <20121107161038.17084.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] Non-repudiation and JOSE X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:17:43 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John Levine > Sent: Wednesday, November 07, 2012 11:11 AM > To: weirds@ietf.org > Subject: [weirds] Non-repudiation and JOSE >=20 > I'm sitting in the JOSE working group session. The stuff they're doing > is more complex than what I'd like, but if you want to sign a block of > JSON, they're defining how to do it. Definitely. I'm currently citing JOSE drafts in the security draft in the c= ontext of other security services, but if someone wants to provide non-repu= diation with proof or origin or proof of delivery there's definitely work i= n progress to make it possible. Scott From galvin+weirds@elistx.com Wed Nov 7 08:50:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D92C21F8C6A for ; Wed, 7 Nov 2012 08:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A26u7FtzeK9x for ; Wed, 7 Nov 2012 08:50:26 -0800 (PST) Received: from ee01.elistx.com (ee01.elistx.com [67.155.182.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A621F8C5A for ; Wed, 7 Nov 2012 08:50:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by elistx.com (PMDF V6.3-2x2 #31965) with ESMTP id <0MD40042FMOCJY@elistx.com> for weirds@ietf.org; Wed, 07 Nov 2012 11:48:13 -0500 (EST) Date: Wed, 07 Nov 2012 11:50:59 -0500 From: Jim Galvin In-reply-to: <20121106214710.10696.qmail@joyce.lan> To: weirds@ietf.org Message-id: <0B5463A10FA8DE38D72BBB34@dhcp-4771.meeting.ietf.org> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline References: <20121106214710.10696.qmail@joyce.lan> Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 16:50:27 -0000 -- On November 6, 2012 9:47:10 PM +0000 John Levine wrote regarding Re: [weirds] Proposal for internationalization question -- > > Tagging should be granular enough such that it can be applied to > > individual elements, for some appropriate definition of element. > > Can you give some examples where it would be useful to have a single > response with some elements in one language and some in another? The simple example is a domain name in one "language" and the contact information in a different "language", including different contact information sets in different "languages". > Also, if you agree that the server should return responses in whatever > languages it has, I agree this is an option and I agree this is where our discussions should start. The client should be responsible for implementing whatever policy that is important to it for "filtering" the response(s). > if a server has 16 fields, each of which has > versions in two languages (imagine all of the fields of a group of > names and addresses), does that mean the server should return 65,536 > responses? Assuming that's not what you had in mind, how many > responses should it return? If the WG agreed protocol action is that all matching information should be returned then yes, 65,536 responses should be returned. However, clearly as an operational principle that's just silly. As engineers we should think a bit more about what is the right answer here. I don't know yet if the number of responses should be limited nor what that number should be if it is limited. I'm still wondering if we'll ever have a situation like you describe. Jim From Ed.Lewis@neustar.biz Wed Nov 7 09:55:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C121F8889 for ; Wed, 7 Nov 2012 09:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b73ScWHH7YcC for ; Wed, 7 Nov 2012 09:55:22 -0800 (PST) Received: from smtp171.iad.emailsrvr.com (smtp171.iad.emailsrvr.com [207.97.245.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4537A21F887F for ; Wed, 7 Nov 2012 09:55:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 93988118D61; Wed, 7 Nov 2012 12:55:21 -0500 (EST) X-Virus-Scanned: OK Received: by smtp27.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 38E4E118E7F; Wed, 7 Nov 2012 12:55:21 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 7 Nov 2012 12:55:16 -0500 To: "weirds@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 17:55:23 -0000 At 15:18 +0000 11/7/12, Hollenbeck, Scott wrote: >A more interesting case involves redirects for objects managed by other >service providers. Looking at this is from the perspective of a protocol engineer, the question is a little different. Here's the basic question form: What is the response to a query for which I have no information? Here's a subdivision of that question to home in on the topic of redirection. (a) What is the response to a query for which I have no information - and I think I am the authority? (b) What is the response to a query for which I have no information - and I think that I know who the authority is? (c) What is the response to a query for which I have no information - and I can't determine who the authority is? This isn't about "name redirection," it's about query redirection. It's possible that an IPvX address has been reallocated "downstream" or the domain name's details are at a registrar. (One of the ways name and numbers seem different but are not to the protocol.) The redirection comes into play in the above questions "b" and "c" form. In these two situations the server is advised to respond with something that will at least make the client stop asking the server and at best help the client select a different server to contact. To protect the server, the protocol response for (b) and (c) should result in no extra processing on the server (and no state retained). I.e., no DNS-like recursion nor anything like a CNAME or DNAME "chasing." In the case that the server knows a "downstream" has the answer, the response should include that location. In all other cases the server should respond with something that is not larger than the query. (In DNS, the "root referral" response given when lame was used as an amplification tool by DDoS.) To protect the client, the client has to perform so-called loop detection. The client is free to maintain state as it is chasing information and part of the state should include whatever is necessary to realize it's "chasing it's own tail." The example I usually resort to - and just because it's a working example - is the DNS. For CNAME, servers limit chains of CNAMEs to 5 (it's in the RFCs), but if this protocol does not do anything like "chasing CNAMEs" this is not needed in the server. I'll repeat that I think the server should do nothing like "chasing CNAMEs". In DNS all the client does is recognize that a loop was in play and knows to stop. For this protocol, I'd recommend the client be the only one involved in loop detection and management. These are my thoughts phrased as requirement and design points - I am not implying any particular implementation detail. And I'm not giving thought to the "bootstrap" problem. Other advice - it doesn't matter why a query arrives at a server. It only matters how the server response and how the client reacts to the response. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From shollenbeck@verisign.com Wed Nov 7 10:20:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52621F8C3D for ; Wed, 7 Nov 2012 10:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnOezxTOUcGI for ; Wed, 7 Nov 2012 10:20:35 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id E484821F8C25 for ; Wed, 7 Nov 2012 10:20:33 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUJqmcc0QiRnap+yVer2QOORwYNIkE/V2@postini.com; Wed, 07 Nov 2012 10:20:35 PST 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 qA7IKUmM015123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 13:20:30 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 13:20:29 -0500 From: "Hollenbeck, Scott" To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] Thoughts on Names Redirection Thread-Index: AQHNvRER+10n5FCZNkCAJp1q5S0cIZferjCg Date: Wed, 7 Nov 2012 18:20:29 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AECA3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:20:36 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Edward Lewis > Sent: Wednesday, November 07, 2012 12:55 PM > To: weirds@ietf.org > Cc: ed.lewis@neustar.biz > Subject: Re: [weirds] Thoughts on Names Redirection >=20 > At 15:18 +0000 11/7/12, Hollenbeck, Scott wrote: >=20 > >A more interesting case involves redirects for objects managed by > other > >service providers. >=20 > Looking at this is from the perspective of a protocol engineer, the > question is a little different. >=20 > Here's the basic question form: > What is the response to a query for which I have no information? >=20 > Here's a subdivision of that question to home in on the topic of > redirection. >=20 > (a) What is the response to a query for which I have no information - > and I think I am the authority? > (b) What is the response to a query for which I have no information - > and I think that I know who the authority is? > (c) What is the response to a query for which I have no information - > and I can't determine who the authority is? >=20 > This isn't about "name redirection," it's about query redirection. Of course. I used "Names Redirection" in the subject to focus the discussio= n in the service provider context since the discussion in the room was that= there is no issue here for RIRs. Scott From Ed.Lewis@neustar.biz Wed Nov 7 10:39:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D781321F8B71 for ; Wed, 7 Nov 2012 10:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGgJ+8yMzp+o for ; Wed, 7 Nov 2012 10:39:10 -0800 (PST) Received: from smtp137.dfw.emailsrvr.com (smtp137.dfw.emailsrvr.com [67.192.241.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1D521F8B3A for ; Wed, 7 Nov 2012 10:39:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp30.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 0CC99348792; Wed, 7 Nov 2012 13:39:10 -0500 (EST) X-Virus-Scanned: OK Received: by smtp30.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id BD238348784; Wed, 7 Nov 2012 13:39:07 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6AECA3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D6AEB1F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F0D6AECA3@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 7 Nov 2012 13:39:03 -0500 To: "weirds@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 18:39:11 -0000 At 18:20 +0000 11/7/12, Hollenbeck, Scott wrote: >Of course. I used "Names Redirection" in the subject to focus the discussion >in the service provider context since the discussion in the room was that >there is no issue here for RIRs. That thought crossed my mind, but the considerations for names are also considerations for numbers when viewing this as a single protocol. Not all queries are made in earnest, neither are all responses. Applying this idea to the protocol at hand, even if we assume all traffic is carried over TLS protected streams (meaning we can discard message insertion and message alteration in-flight), it is still possible that the response might lead to a "loop." It might be through some one misconfiguring where downstream numbers are covered by another server. Perhaps it's an SQL injection, or an operational mistake, I'm not really trying to get deep into how this happens here - I'm just trying to say "I postulate that it's possible." Even if "it is not possible" the client interacting with the names servers and the numbers server might be the same code, same code path. If the client is written assuming that it will only ever connect to the numbers and then later to the names, it could be vulnerable if it lacks any management of loops. PS - I'd like to stamp out the notion that names and numbers are different with respect to this protocol. But that isn't what this thread is about. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From johnl@iecc.com Wed Nov 7 16:37:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEF021F86E4 for ; Wed, 7 Nov 2012 16:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.042 X-Spam-Level: X-Spam-Status: No, score=-112.042 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLw-oncFmxIt for ; Wed, 7 Nov 2012 16:37:55 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 411A121F88F4 for ; Wed, 7 Nov 2012 16:37:54 -0800 (PST) Received: (qmail 13907 invoked from network); 8 Nov 2012 00:37:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Nov 2012 00:37:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509afedf.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=Pv3uT5cbk47nLwT6NQe8E8Jps+yvYInrNflQ5Cg6Eaw=; b=MUimSvsjgcythOo8hpfpRzgetJETYf1aCWeck7TZ53jwv/xHp2eoOBS1+yMG7iSnyOtHNpfq1nxCsq+82MCU3PAnyFWiqIKtIJIc7QUaV89Hqm/bgxbfp2I6HMVrjYA7ZmHLaww8pyXc9IHCuDLqTCgF8gH1YYt7UTgj6htOnxY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509afedf.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=Pv3uT5cbk47nLwT6NQe8E8Jps+yvYInrNflQ5Cg6Eaw=; b=ZsQA8+zbKpxgE/kVWxegruRyJlNCPsaxMW55G5rhb0lZcIIBPqg5nmzN4LTkyDiAX6Me7AjGWjcZkyzhEjdXnsfxFpQBJr2sVWPiBgPH+r8RaPVjVKGzfF4v4Jg0i668m3cmfgO6H/TWrdBQuqZurzZOELayFD1Xk9TwLNQHetE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Nov 2012 00:37:29 -0000 Message-ID: <20121108003729.34915.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 00:37:56 -0000 >message insertion and message alteration in-flight), it is still >possible that the response might lead to a "loop." Sure, but if we assume they're done via http 302 redirects, it's a familiar problem, and clients already deal with it. R's, John From carlosm3011@gmail.com Wed Nov 7 16:44:37 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9ABD21F8485 for ; Wed, 7 Nov 2012 16:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbPyWGm9FivJ for ; Wed, 7 Nov 2012 16:44:37 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4FB921F85C7 for ; Wed, 7 Nov 2012 16:44:30 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1686007pbb.31 for ; Wed, 07 Nov 2012 16:44:30 -0800 (PST) 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=WGM7xJ4mFuOxuaoaqVtoWv18KoFacADicn2S80Jx0ds=; b=Kjm1r+hfUVd9rPnGoWgUiImqHeKN/6UYwrTHCYRI0zpXMrZWIrjnFg4b5M2UGsAMkB jJ36moGDI8jZkKENvHllQFLA0uzT72fYys7tIfEy3EGSNfiz8gLlZz7c2YKZykjOQtiJ L7HOXj3PdVcC9ofBxR9jl/2dezgEmWuQUZPdOU3dcA/Wkx+Fi4AZPYEe/DptNa/HWamB cYypLAo4nOW465EpUuv1Rv4yw5T+iXQIFGtawtdqLrclgNERQNUqxYvhu1MiVu+5+hPD 7q4XZj+vQErzRftBlHdIkU4qqBpmPEhTHLK6mYViLQDuG1d0yS62AJ+C0S91P1j7c2Z5 aQYA== Received: by 10.68.193.228 with SMTP id hr4mr12264993pbc.95.1352335470548; Wed, 07 Nov 2012 16:44:30 -0800 (PST) Received: from ?IPv6:2001:df8:0:16:7446:9947:e80f:60f4? ([2001:df8:0:16:7446:9947:e80f:60f4]) by mx.google.com with ESMTPS id ug6sm6817525pbc.4.2012.11.07.16.44.28 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 16:44:29 -0800 (PST) Message-ID: <509B006B.1010300@gmail.com> Date: Wed, 07 Nov 2012 19:44:27 -0500 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: John Levine References: <20121108003729.34915.qmail@joyce.lan> In-Reply-To: <20121108003729.34915.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ed.Lewis@neustar.biz, weirds@ietf.org Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 00:44:38 -0000 The question that I tried to bring up during last Tuesday session is whether we believe that such loops represent a risk for _servers_ , rather tan clients. I'm not saying they do, maybe they don't, I just want to have the views of the ML on the issue. regards Carlos On 11/7/2012 7:37 PM, John Levine wrote: >> message insertion and message alteration in-flight), it is still >> possible that the response might lead to a "loop." > > Sure, but if we assume they're done via http 302 redirects, it's a > familiar problem, and clients already deal with it. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From johnl@taugh.com Wed Nov 7 17:00:13 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB5321F89B5 for ; Wed, 7 Nov 2012 17:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPu4UbqO3oAm for ; Wed, 7 Nov 2012 17:00:13 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A514421F894D for ; Wed, 7 Nov 2012 17:00:12 -0800 (PST) Received: (qmail 18462 invoked from network); 8 Nov 2012 01:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=481d.509b041b.k1211; bh=lkMx/iuw2+rUCzXvD0/ZRef2qqWfZXXbks/A2n/EO+4=; b=gwLcw+NOgSgHu1MYX+ZEN4yRDfRSG0iMv2/Cp7ErgMJdQK1Sh5NlF+cJdlDJ+YxfULXpIQ5LDgUhuBFB0IYzmhN03ng3nveXdJBJbWXq7JC9ttMWOQRb2Bxj/4qKM8pqSjDjC8i4Mz7bwoQTGQyLVmhyTdcuDYIPugJuXGfGmyE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=481d.509b041b.k1211; bh=lkMx/iuw2+rUCzXvD0/ZRef2qqWfZXXbks/A2n/EO+4=; b=xCfIlSL87SkJX8zMPHhFCgvy7g1mMD90t+9msmwxw/CeHFQBEsxkImCvY9bLky9xegnACn9YI3ixnOzLzXHLjZIoQ4T56l5sYHftBaQFQYwkk69GqgS9soxX+5txTQRkkwk8egq/LXNf3TnAgt2M6yllcY+MPNseArkS2GHpQI0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 8 Nov 2012 00:59:49 -0000 Date: 7 Nov 2012 20:00:11 -0500 Message-ID: From: "John R Levine" To: "Carlos M. martinez" In-Reply-To: <509B006B.1010300@gmail.com> References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> 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] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 01:00:13 -0000 > The question that I tried to bring up during last Tuesday session is > whether we believe that such loops represent a risk for _servers_ , > rather than clients. Seems unlikely. If people use existing clients and client libraries, they have loop breaking code. Conversely, a sufficiently hostile or broken client can flood you with requests no matter what you do, so you'd better be prepared for it, just like any other server on the public Internet. Redirects are fairly common on the web in general. I can think of some cases where clients were hammering on my server, but I don't recally any of them being 302 loops. R's, John From shollenbeck@verisign.com Wed Nov 7 17:16:12 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A521F8B14 for ; Wed, 7 Nov 2012 17:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZlQAxAt9ze6 for ; Wed, 7 Nov 2012 17:16:12 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1268521F8A12 for ; Wed, 7 Nov 2012 17:16:09 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUJsH2b/zpb2EJGdYBzGb1AWEyAlbowWh@postini.com; Wed, 07 Nov 2012 17:16:12 PST 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 qA81G5wE006672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 20:16:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 20:16:04 -0500 From: "Hollenbeck, Scott" To: John R Levine Thread-Topic: [weirds] Thoughts on Names Redirection Thread-Index: AQHNvUlNngSWkvB6O0afIR7V4Aq/bpffbaiAgAAEZYD//7A8AA== Date: Thu, 8 Nov 2012 01:16:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6AEFE0@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 01:16:12 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John R Levine > Sent: Wednesday, November 07, 2012 8:00 PM > To: Carlos M. martinez > Cc: weirds@ietf.org > Subject: Re: [weirds] Thoughts on Names Redirection >=20 > > The question that I tried to bring up during last Tuesday session is > > whether we believe that such loops represent a risk for _servers_ , > > rather than clients. >=20 > Seems unlikely. If people use existing clients and client libraries, > they have loop breaking code. Conversely, a sufficiently hostile or > broken client can flood you with requests no matter what you do, so > you'd better be prepared for it, just like any other server on the > public Internet. >=20 > Redirects are fairly common on the web in general. I can think of some > cases where clients were hammering on my server, but I don't recally > any of them being 302 loops. I'm struggling to see how this is a new problem, too. If we use standard ht= tp redirects, clients and servers would just do what they normally do. Scott From sm@resistor.net Wed Nov 7 17:31:44 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB17021F883E for ; Wed, 7 Nov 2012 17:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9IAeQqQDogF for ; Wed, 7 Nov 2012 17:31:44 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4566D21F883B for ; Wed, 7 Nov 2012 17:31:44 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA81Va5X026610; Wed, 7 Nov 2012 17:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352338301; bh=AKGni0zgkB1e8Hu1dIG6hWBc8AOF5ztkEd5Bl1HxbWo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lKpMT2Vd0tTGGWyHZnB5g1BYxrR/kIILItZLj03l0ncnsGK1sQvCoEQG5wX+2YkzH YLW1OHWsm/dUAdNrdKMl7kKb7R9hB3C1caS48rOkdLbjR6OS5vDHMUrn3hM3j6Kvc1 pFPGn8OXEJhl/rBYa1V8H5UNjbotIrggAbvRL6PA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352338301; i=@resistor.net; bh=AKGni0zgkB1e8Hu1dIG6hWBc8AOF5ztkEd5Bl1HxbWo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=n/QviGdOzpCK2DMQfznIyeQ65kwt9Y5Eu6xwe6owttrLT2k64Qyav+16sJnEOnbsy foHOKkODEOVTAbR1QfiWbwjAcMEKW2TPP+6XKmIHqXoDKR8EgHQ+63EIdFaMFHlfxp VBGuwZa52BTzkRIO1yLbkBajl9GeEiSQCAkAgj58= Message-Id: <6.2.5.6.2.20121107172400.0b23a680@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Nov 2012 17:31:31 -0800 To: "Carlos M. martinez" From: SM In-Reply-To: <509B006B.1010300@gmail.com> References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 01:31:44 -0000 Hi Carlos, At 16:44 07-11-2012, Carlos M. martinez wrote: >The question that I tried to bring up during last Tuesday session is >whether we believe that such loops represent a risk for _servers_ , >rather tan clients. I think that there is ample discussion of the issue in the HTTP specifications. I don't see it as an additional risk as the mitigation techniques are already known. Regards, -sm From andy@arin.net Thu Nov 8 04:41:39 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDC121F8B17 for ; Thu, 8 Nov 2012 04:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0T2l5QROjpD for ; Thu, 8 Nov 2012 04:41:38 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4221F8B0D for ; Thu, 8 Nov 2012 04:41:38 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id D8BC51651BC; Thu, 8 Nov 2012 07:41:37 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 4A19D165066; Thu, 8 Nov 2012 07:41:37 -0500 (EST) 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.283.3; Thu, 8 Nov 2012 07:41:24 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 07:40:32 -0500 From: Andy Newton To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Proposal for internationalization question Thread-Index: AQHNu9ZLodgbnz0ryUWmgSkpH3vNVZfe17MAgAAHcICAAQWlgA== Date: Thu, 8 Nov 2012 12:40:30 +0000 Message-ID: In-Reply-To: <20121107160359.GK74706@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Proposal for internationalization question X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 12:41:39 -0000 On 11/7/12 11:03 AM, "Andrew Sullivan" wrote: >The second of these reduces duplication of data, but perhaps makes the >processing more complicated. With two encodings, the trade-off isn't >really worth it. With more than two, we might find it is worth it. >Unfortunately, given the poor internationalization support to date, I >don't think actual whois implementations provide us any kind of >guidance about what people want. All I know is that many, many people >have complained about internationalization here, and I'll be surprised >if every repository is forever nailed to two encodings of the data. This is where I get hosed. What do you mean by "encodings" in the above? Isn't that totally different than a language tag? I would think that multiple encodings (as I understand that term) would not only be problematic but nearly impossible. While multiple language tags would be relatively trivial. -andy From Ed.Lewis@neustar.biz Thu Nov 8 09:37:38 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D569F21F8552 for ; Thu, 8 Nov 2012 09:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J70n1gBF8UUC for ; Thu, 8 Nov 2012 09:37:38 -0800 (PST) Received: from smtp191.dfw.emailsrvr.com (smtp191.dfw.emailsrvr.com [67.192.241.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE621F879C for ; Thu, 8 Nov 2012 09:37:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 81BE53C83DA; Thu, 8 Nov 2012 12:37:37 -0500 (EST) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 12BDD3C8308; Thu, 8 Nov 2012 12:37:36 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <509B006B.1010300@gmail.com> References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> Date: Thu, 8 Nov 2012 12:37:33 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 17:37:38 -0000 The best that can be done is make the client responsible for loop management and then you've eliminated this from being a problem on the server. If the underlying transport (HTTP) manages it, that much better. Of course, traffic flooding (DoS) is still a problem. A traffic flood could be a result of mismanaging a loop (as has been the case in at least one example), but flooding problems are much more general. Under the title of "it doesn't matter why a query arrived, you have to deal with it," whether the flood is from a loop or some other cause (perhaps intentional) ... cutting out some steps ... the server doesn't need to worry about loops (if the protocol places the onus on the client to do this). In DNS, the protocol does not place the onus on the client, so servers are the ones that do loop management. I'd call that a design flaw in DNS, one not to be copied elsewhere. (It's not a fatal or serious flaw, nonetheless the DNS protocol could have been better defined here.) At 19:44 -0500 11/7/12, Carlos M. martinez wrote: >The question that I tried to bring up during last Tuesday session is >whether we believe that such loops represent a risk for _servers_ , >rather tan clients. > >I'm not saying they do, maybe they don't, I just want to have the views >of the ML on the issue. > >regards > >Carlos > >On 11/7/2012 7:37 PM, John Levine wrote: >>> message insertion and message alteration in-flight), it is still >>> possible that the response might lead to a "loop." >> >> Sure, but if we assume they're done via http 302 redirects, it's a >> familiar problem, and clients already deal with it. >> >> R's, >> John >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >> >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From johnl@iecc.com Thu Nov 8 11:05:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8C21F84EA for ; Thu, 8 Nov 2012 11:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.06 X-Spam-Level: X-Spam-Status: No, score=-112.06 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrTUqaKZHT1s for ; Thu, 8 Nov 2012 11:05:40 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4221F8531 for ; Thu, 8 Nov 2012 11:05:39 -0800 (PST) Received: (qmail 41458 invoked from network); 8 Nov 2012 19:05:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Nov 2012 19:05:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509c0281.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=/YG1hf4FSqDH7dUwQJwqfo40cG+iIA6yrG6VnZhZV6w=; b=E+nuxVEuxGTs+JmrY3dKyGebzo8r5+RvN1zdx+ZPB2kW/Jx+cnCTIIQEjknrdXAV1dxONc13Om0FHsHG93q4pR7uS/JLhyvMOoJOnpUvydWRFKpSvMCK1rpJbuW283P5U4wyk88Y0vs2Qu1mqZvRB6rt/EPE2tnlqYQD6DO0F+c= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509c0281.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=/YG1hf4FSqDH7dUwQJwqfo40cG+iIA6yrG6VnZhZV6w=; b=IxGXi1uqLz3QVU1MaLCRlooKahly3DvqxOMmkapUVdbEm4ANkuFzIFatdifOIph5foMNyY3ZSARJFmzFg3VzyhsZ/RJ93/p7+xTwoUjNQrkYZJwJxfS+ZjVMsaNIeePVIx+dKj3eISMxLDDeWkyYokf8X4r6cSFGzBNwR9w7fbU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Nov 2012 19:05:15 -0000 Message-ID: <20121108190515.4061.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Thoughts on Names Redirection X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Nov 2012 19:05:41 -0000 >In DNS, the protocol does not place the onus on the client, so >servers are the ones that do loop management. Huh? How does a server deal with NS or CNAME loops? R's, John From Ed.Lewis@neustar.biz Fri Nov 9 07:58:13 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605EA21F86E3 for ; Fri, 9 Nov 2012 07:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.923 X-Spam-Level: X-Spam-Status: No, score=-103.923 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoB6zFSegY0T for ; Fri, 9 Nov 2012 07:58:12 -0800 (PST) Received: from smtp121.dfw.emailsrvr.com (smtp121.dfw.emailsrvr.com [67.192.241.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E021F86EF for ; Fri, 9 Nov 2012 07:58:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id D83E278186; Fri, 9 Nov 2012 10:58:11 -0500 (EST) X-Virus-Scanned: OK Received: by smtp2.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 35290780EF; Fri, 9 Nov 2012 10:58:11 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <509B006B.1010300@gmail.com> References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> Date: Fri, 9 Nov 2012 10:58:07 -0500 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-859645805==_ma============" Cc: Ed.Lewis@neustar.biz Subject: [weirds] draft-zhou-weirds-dnrd-ap-object-inventory-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:58:13 -0000 --============_-859645805==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I was a bit surprised by what's in this draft. In the sense that I would have expected that every object would have a registrant, I'm surprised. Of the 118 whois services contacted, all of them domain name registries, there were 118 domain names found and just 65 registrant names. My expectation is that the most significant report of a whois is the registrant name. I wonder if the low count is due to the specific name queried or misinterpretation of results. Given what is in section 6 ("Limitations") is there a plan to re-run this survey? In a re-run I would encourage the survey to be one of intent of the registry as opposed to what is seen. By that I mean, looking for nic.cctld might be a very objective, "fair" means to discover how the various TLDs differ, but it is likely (as noted) misleading. There's no domain name guaranteed to be in all TLDs (except maybe Google ;)), but relying on one name isn't that important. I'd rather see the set of labels used at a registry than what is used for a particular name across all registries. And there's no reason this survey can't include the number registries. Of course there's no google.10.in-addr.arpa, but as I mentioned it's not about a common query across all servers - it's about what servers return. I'd be interested in knowing: What number (or % of all registries) have running whois? What number display the object name (100%?)? What number indicate a registrant (or admin)? What is the label? What number have admin/tech/abuse/billing/other contacts? (For other, what's common?) How are names (personal, entity) represented (letters/local script)? How is contact information rendered (postal, email, telephone)? And so on. I do like the counting of "how many labels" are used for entries. In 5.1, there is this break down: # (1) About 5% of data elements are supported by over 111 (90%) # registries. # # (2) About 30% of data elements are supported by over 44 (35%) # registries. # # (3) About 60% of data elements are supported by over 32 (26%) # registries. # # (4) About 90% of data elements are supported by over 14 (11%) # registries. Is this subject to teh limitation in 6? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! --============_-859645805==_ma============ Content-Type: text/html; charset="us-ascii" draft-zhou-weirds-dnrd-ap-object-inventory-00.txt
I was a bit surprised by what's in this draft.  In the sense that I would have expected that every object would have a registrant, I'm surprised.

Of the 118 whois services contacted, all of them domain name registries, there were 118 domain names found and just 65 registrant names.  My expectation is that the most significant report of a whois is the registrant name.  I wonder if the low count is due to the specific name queried or misinterpretation of results.

Given what is in section 6 ("Limitations") is there a plan to re-run this survey?  In a re-run I would encourage the survey to be one of intent of the registry as opposed to what is seen.

By that I mean, looking for nic.cctld might be a very objective, "fair" means to discover how the various TLDs differ, but it is likely (as noted) misleading.  There's no domain name guaranteed to be in all TLDs (except maybe Google ;)), but relying on one name isn't that important.

I'd rather see the set of labels used at a registry than what is used for a particular name across all registries.

And there's no reason this survey can't include the number registries.  Of course there's no google.10.in-addr.arpa, but as I mentioned it's not about a common query across all servers - it's about what servers return.

I'd be interested in knowing:

What number (or % of all registries) have running whois?
What number display the object name (100%?)?
What number indicate a registrant (or admin)?  What is the label?
What number have admin/tech/abuse/billing/other contacts?
(For other, what's common?)
How are names (personal, entity) represented (letters/local script)?
How is contact information rendered (postal, email, telephone)?

And so on.

I do like the counting of "how many labels" are used for entries.

In 5.1, there is this break down:

#   (1)  About 5% of data elements are supported by over 111 (90%)
#        registries.
#
#   (2)  About 30% of data elements are supported by over 44 (35%)
#        registries.
#
#   (3)  About 60% of data elements are supported by over 32 (26%)
#        registries.
#
#   (4)  About 90% of data elements are supported by over 14 (11%)
#        registries.
Is this subject to teh limitation in 6?


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

2012...time to reuse those 1984 calendars!
--============_-859645805==_ma============-- From johnl@iecc.com Fri Nov 9 13:06:27 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AA421F87CC for ; Fri, 9 Nov 2012 13:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.016 X-Spam-Level: X-Spam-Status: No, score=-112.016 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTgSbdITQfGY for ; Fri, 9 Nov 2012 13:06:24 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C8A1221F8773 for ; Fri, 9 Nov 2012 13:06:16 -0800 (PST) Received: (qmail 85503 invoked from network); 9 Nov 2012 21:06:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Nov 2012 21:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509d7047.xn--yuvv84g.k1211; i=johnl@user.iecc.com; bh=vG6paChYUB6MLaBBsB9CSCoTUR0p9c+tMxEEn1LFlZA=; b=VCfQFBq45k1E3i8HI4xpE6hPayZpwS7FJmI2FcsRS0BWH6X0fOn2NXTjKvLxqyPp2xzbgpwlxtOiCoIdmw6Ezl1YJLGm5UkDyas4MqN99P6yWKynX/7tALUoKdEdY9+nhw1nbl744LOq2/ZAmXLtz/TxF0S41yI8su58nmm279E= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=509d7047.xn--yuvv84g.k1211; olt=johnl@user.iecc.com; bh=vG6paChYUB6MLaBBsB9CSCoTUR0p9c+tMxEEn1LFlZA=; b=VX1EC1BG+jtXQrq3LHWUqpN/7PGMKAdrVujJvXKff7OOvl3M+9xICjqMtzG/Rtrdfy5FO/DTvAljmOHE36KkLB6UY+2iVbjEY100mKOIAi9wsTcIM/epXFlWKKZ0GZUkbNo0ZH7d/Mxa1yIOf7tjA1YSQxuXW8EE2WuSF6nALME= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Nov 2012 21:05:52 -0000 Message-ID: <20121109210552.2972.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] draft-zhou-weirds-dnrd-ap-object-inventory-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 21:06:27 -0000 >Of the 118 whois services contacted, all of them domain name >registries, there were 118 domain names found and just 65 registrant >names. My expectation is that the most significant report of a whois >is the registrant name. I wonder if the low count is due to the >specific name queried or misinterpretation of results. It sounds right to me. Unless you have some sort of enhanced access, a lot of ccTLD registries simply confirm the existence of a name without providing any details, e.g.: $ whois cafe.de [whois.denic.de] Domain: cafe.de Status: connect -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From zhoulinlin@cnnic.cn Wed Nov 14 01:11:00 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4287E21F84B6 for ; Wed, 14 Nov 2012 01:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co5CApTV2GPI for ; Wed, 14 Nov 2012 01:10:56 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id E179521F8480 for ; Wed, 14 Nov 2012 01:10:48 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 14 Nov 2012 17:10:36 +0800 From: "Linlin Zhou" To: "'Edward Lewis'" , References: <20121108003729.34915.qmail@joyce.lan> <509B006B.1010300@gmail.com> In-Reply-To: Date: Wed, 14 Nov 2012 17:10:33 +0800 Message-ID: <003501cdc247$e7a047c0$b6e0d740$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01CDC28A.F5C387C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2+kwskRbnizHA2T32r4y3qqS3BiADrJVpg Content-Language: zh-cn Subject: Re: [weirds] draft-zhou-weirds-dnrd-ap-object-inventory-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:11:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0036_01CDC28A.F5C387C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Edward, My feedback is as below. From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Edward Lewis Sent: Friday, November 09, 2012 11:58 PM To: weirds@ietf.org Cc: Ed.Lewis@neustar.biz Subject: [weirds] draft-zhou-weirds-dnrd-ap-object-inventory-00.txt I was a bit surprised by what's in this draft. In the sense that I would have expected that every object would have a registrant, I'm surprised. Of the 118 whois services contacted, all of them domain name registries, there were 118 domain names found and just 65 registrant names. My expectation is that the most significant report of a whois is the registrant name. I wonder if the low count is due to the specific name queried or misinterpretation of results. [Linlin] I think there may be several reasons for that only 65 registries have registrant name. 1. The response does not contain registrant, such as ".as". The following is the response from .as for querying nic.as. Name: nic.as Registered by: AS Domain Registry Nameservers: dca.ns.gdns.net (130.94.25.65) phx.ns.gdns.net (216.69.168.151) cmh.ns.gdns.net (76.10.212.82) 2. IDN response, such as ".cl". Our program does not know how to classify the IDN responses. I think maybe we could do it manually in the future. 3. Some responses are in the following format. There's no sub object name for registrant name. Registrant: AM NIC Isaakian 28, 3rd Floor Yerevan, 375009 AM [Linlin] Given what is in section 6 ("Limitations") is there a plan to re-run this survey? In a re-run I would encourage the survey to be one of intent of the registry as opposed to what is seen. [Linlin] If the WG think this analysis is useful, we would consider re-running it. I do think that there are still many improvements we could do the next step. [Linlin] By that I mean, looking for nic.cctld might be a very objective, "fair" means to discover how the various TLDs differ, but it is likely (as noted) misleading. There's no domain name guaranteed to be in all TLDs (except maybe Google ;)), but relying on one name isn't that important. I'd rather see the set of labels used at a registry than what is used for a particular name across all registries. And there's no reason this survey can't include the number registries. Of course there's no google.10.in-addr.arpa, but as I mentioned it's not about a common query across all servers - it's about what servers return. [Linlin] Good suggestion. [Linlin] I'd be interested in knowing: What number (or % of all registries) have running whois? What number display the object name (100%?)? What number indicate a registrant (or admin)? What is the label? What number have admin/tech/abuse/billing/other contacts? (For other, what's common?) How are names (personal, entity) represented (letters/local script)? How is contact information rendered (postal, email, telephone)? [Linlin] Thank you for your advice. I think some of the results we could get based on the data we already have. I will consider your requirements and update in the next version. [Linlin] And so on. I do like the counting of "how many labels" are used for entries. In 5.1, there is this break down: # (1) About 5% of data elements are supported by over 111 (90%) # registries. # # (2) About 30% of data elements are supported by over 44 (35%) # registries. # # (3) About 60% of data elements are supported by over 32 (26%) # registries. # # (4) About 90% of data elements are supported by over 14 (11%) # registries. Is this subject to teh limitation in 6? [Linlin] The cumulative distribution analysis just shows the result that only a few registries support all the public objects, most of the registries support just parts of all the objects. I think this is a trend chart, the limitations affect a little. [Linlin] -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! ------=_NextPart_000_0036_01CDC28A.F5C387C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-zhou-weirds-dnrd-ap-object-inventory-00.txt=

Thanks = Edward,

 =

My = feedback is as below.

 =

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Edward Lewis
Sent: Friday, November 09, 2012 11:58 = PM
To: weirds@ietf.org
Cc: = Ed.Lewis@neustar.biz
Subject: [weirds] = draft-zhou-weirds-dnrd-ap-object-inventory-00.txt

 

I was a bit surprised by what's in this draft.  In the = sense that I would have expected that every object would have a = registrant, I'm surprised.

 

Of the 118 whois services = contacted, all of them domain name registries, there were 118 domain = names found and just 65 registrant names.  My expectation is that = the most significant report of a whois is the registrant name.  I = wonder if the low count is due to the specific name queried or = misinterpretation of results.

 =

[Linlin]

I think = there may be several reasons for that only 65 registries have registrant = name.

 =

1. The = response does not contain registrant, such as “.as”. The = following is the response from .as for querying = nic.as.

Name: =            = nic.as

Registered = by:   AS Domain Registry

Nameservers= :     dca.ns.gdns.net = (130.94.25.65)

  = ;            =           phx.ns.gdns.net = (216.69.168.151)

  = ;            =    =             &= nbsp;     cmh.ns.gdns.net = (76.10.212.82)

2. IDN = response, such as “.cl”. Our program does not know how to = classify the IDN responses. I think maybe we could do it manually in the = future.

3. Some = responses are in the following format. There’s no sub object name = for registrant name.

Registrant:=

  = ;    AM NIC

  = ;    Isaakian 28, 3rd Floor

  = ;    Yerevan,  375009

  = ;    AM

[Linlin]

 =

Given what is in section 6 ("Limitations") is = there a plan to re-run this survey?  In a re-run I would encourage = the survey to be one of intent of the registry as opposed to what is = seen.

 

[Linlin]

If the WG = think this analysis is useful, we would consider re-running it. I do = think that there are still many improvements we could do the next = step.

[Linlin]

 =

By = that I mean, looking for nic.cctld might be a very objective, = "fair" means to discover how the various TLDs differ, but it = is likely (as noted) misleading.  There's no domain name guaranteed = to be in all TLDs (except maybe Google ;)), but relying on one name = isn't that important.

 

I'd rather see the set of labels = used at a registry than what is used for a particular name across all = registries.

 

And there's no reason this survey = can't include the number registries.  Of course there's no = google.10.in-addr.arpa, but as I mentioned it's not about a common query = across all servers - it's about what servers = return.

 

[Linlin]

Good = suggestion.

[Linlin]

 =

I'd = be interested in knowing:

 

What number (or % of all = registries) have running whois?

What number display the object name = (100%?)?

What number indicate a registrant (or admin)?  What is = the label?

What number have admin/tech/abuse/billing/other = contacts?

(For other, what's = common?)

How are names (personal, entity) represented (letters/local = script)?

How is contact information rendered (postal, email, = telephone)?

 =

[Linlin]

Thank you = for your advice. I think some of the results we could get based on the = data we already have. I will consider your requirements and update in = the next version.

[Linlin]

And so on.

 

I do like the counting of "how = many labels" are used for = entries.

 

In 5.1, there is this break = down:

 

#   (1)  About 5% of = data elements are supported by over 111 = (90%)
#        = registries.
#
#   (2)  About 30% of data elements = are supported by over 44 = (35%)
#        = registries.
#
#   (3)  About 60% of data elements = are supported by over 32 = (26%)
#        = registries.
#
#   (4)  About 90% of data elements = are supported by over 14 = (11%)
#        = registries.

Is this subject to teh limitation in = 6?

 

 =

[Linlin]

The = cumulative distribution analysis just shows the result that only a few = registries support all the public objects, most of the registries = support just parts of all the objects. I think this is a trend chart, = the limitations affect a little.

[Linlin]

 

--

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

2012...time to reuse = those 1984 = calendars!

------=_NextPart_000_0036_01CDC28A.F5C387C0-- From alexandrsergeyev@gmail.com Wed Nov 14 06:16:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEF021F85B3 for ; Wed, 14 Nov 2012 06:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTPIwTY+xkoh for ; Wed, 14 Nov 2012 06:16:08 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3821F8528 for ; Wed, 14 Nov 2012 06:16:07 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hj6so452408wib.13 for ; Wed, 14 Nov 2012 06:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6nrS02+m/GnndyCJSPepyTz6j7k35yS2WZcu11Fho70=; b=Cts6zP1pyhNR26XZaZlOVK7ffdpT/8XWgZO7n6Ykev1a+D01DoCk7xq7rBmHqN/dr0 dEvwCL0/0IF5tgliAOPcRFM9r/XK4Ih87K/zntEAKXq2uvSy6YkXYyP3vzL+/z8Vg4Yx 6p42Zq4WfhyhKYItgzCyTSNm3hrSYogtHT/eemcRUcxsU7up6sMJEL2DAYLuPJEp6zDW U9S8+mxzspwJZt21IxfrjMvvnwUbQV5Xffej99Sd3k+VJowzcCxCVd2EneIidEu032m/ vhhznHSmBqnK3E6mmvy3HfpdlNPdunNTBJmgwE6tAL2//74aUMeYiAaXazWhTNSMNp7g UYfw== MIME-Version: 1.0 Received: by 10.216.45.144 with SMTP id p16mr1784126web.170.1352902566603; Wed, 14 Nov 2012 06:16:06 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.216.159.211 with HTTP; Wed, 14 Nov 2012 06:16:06 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 09:16:06 -0500 X-Google-Sender-Auth: DzCEImQfbWYdEnsmKN94n8VupEU Message-ID: From: Alex Sergeyev To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=0016e6dbdf49e5e9d504ce752cf8 Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 14:16:08 -0000 --0016e6dbdf49e5e9d504ce752cf8 Content-Type: text/plain; charset=UTF-8 I'd like to add my opinion on the draft-ietf-weirds-json-response-00 We plan to change our (Dyn Inc) implementation to follow this document soon, it's a solid document. Few notes: * I agree with previously stated point on telephone numbers, at least better examples (not 999-999-999-99) and some recommendations could be made in WEIRDS. * "variants" element has no example and it might be something that needs an URI sub-elements too (some variants could have information that is not represented by another variant, some might be "reserved" vs "active" and so on). * I think it's confusing to have "status" property to be used as "array or string", section 5 example has "string" and page before - "array". I would suggest to make it consistent. * I also would suggest some synonym for field "names" (in entity object). Some long_key would also work better. Right now it is not really easy to make mistake but replacing it could add some error-resiliency. * My other personal wish as a consumer of that document is to have IPv6 examples whenever IP addresses are mentioned. * I'm wondering why RIR class got DNSSEC elements and DNR did not. * I wonder if postal address as a list of strings might have negative consequences, some people who parse WEIRDS may want to find "cities where administrators of these domains reside", this might be painful when some foreign weirds server will mix stuff up and show city first, street address last in that list. Appreciate your work and hope my comments could be useful. Alex Sergeyev Sr. Engineer of Dyn Labs --0016e6dbdf49e5e9d504ce752cf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd like to add my opinion on the=C2=A0 draft-ietf-weirds-json-response= -00

We plan to change our (Dyn Inc) implementation to follow this do= cument soon, it's a solid document. Few notes:

* I agree with pr= eviously stated point on telephone numbers, at least better examples (not 9= 99-999-999-99) and some recommendations could be made in WEIRDS.

* "variants" element has no example and it might be something= that needs=20 an URI sub-elements too (some variants could have information that is=20 not represented by another variant, some might be "reserved" vs &= quot;active"=20 and so on).

* I think it's confusing to have "status" property to= be used as "array or string", section 5 example has "string= " and page before - "array". I would suggest to make it cons= istent.

* I also would suggest some synonym for field "names" (in ent= ity object). Some long_key would also work better. Right now it is not real= ly easy to make mistake but replacing it could add some error-resiliency.
* My other personal wish as a consumer of that document is to have IPv= 6=20 examples whenever IP addresses are mentioned.

* I'm wondering wh= y RIR class got DNSSEC elements and DNR did not.

* I wonder if posta= l address as a list of strings might have negative=20 consequences, some people who parse WEIRDS may want to find "cities=20 where administrators of these domains reside", this might be painful= =20 when some foreign weirds server will mix stuff up and show city first,=20 street address last in that list.


Appreciate your work and hope = my comments could be useful.


Alex Sergeyev
Sr. Engineer of Dy= n Labs
--0016e6dbdf49e5e9d504ce752cf8-- From andy@arin.net Wed Nov 14 06:33:42 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB921F8583 for ; Wed, 14 Nov 2012 06:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8HVcVWZnHKb for ; Wed, 14 Nov 2012 06:33:41 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63D21F8581 for ; Wed, 14 Nov 2012 06:33:41 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 69A97213663; Wed, 14 Nov 2012 09:33:40 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id D1F132135EF; Wed, 14 Nov 2012 09:33:39 -0500 (EST) 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.283.3; Wed, 14 Nov 2012 09:33:27 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 14 Nov 2012 09:32:32 -0500 From: Andy Newton To: Alex Sergeyev , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27o7qF9wnShljEQOOC4HSUHYSddQG+MQsA//+wu4A= Date: Wed, 14 Nov 2012 14:32:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 14:33:42 -0000 > >* I agree with previously stated point on telephone numbers, at least >better examples (not 999-999-999-99) and some recommendations could be >made in WEIRDS. Sounds good. We could recommend servers use E.123 format if possible, but that clients should accept any format. >* "variants" element has no example and it might be something that needs >an URI sub-elements too (some variants could have information that is not >represented by another variant, some might be "reserved" vs "active" and >so on). I touched on this at the IETF, and basically pointed out the same issue. There were no objections, so I'll be changing the format to accommodate this information. >* I think it's confusing to have "status" property to be used as "array >or string", section 5 example has "string" and page before - "array". I >would suggest to make it consistent. Yup. The example is a mistake. Though the intent is to have status as an array of strings. Objects can have multiple statuses. >* I also would suggest some synonym for field "names" (in entity object). >Some long_key would also work better. Right now it is not really easy to >make mistake but replacing it could add some error-resiliency. I don't think I understand. Can you provide an example? >* My other personal wish as a consumer of that document is to have IPv6 >examples whenever IP addresses are mentioned. Will do. >* I'm wondering why RIR class got DNSSEC elements and DNR did not. Both classes have it as the DNR class inherits everything from the RIR class. If everybody finds this inheritance things confusing, we can collapse all the classes into one. That was done to show how the RIR and DNR models were being "unified". >* I wonder if postal address as a list of strings might have negative >consequences, some people who parse WEIRDS may want to find "cities where >administrators of these domains reside", this might be painful when some >foreign weirds server will mix stuff up > and show city first, street address last in that list. Just like phone numbers, the data registries have is the data registries have. If addresses are not in a structured format in the registry, it would be difficult for them to use a format that does enforce structure. -andy From jaap@NLnetLabs.nl Wed Nov 14 10:24:30 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5821F86A9 for ; Wed, 14 Nov 2012 10:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1NWe8IT+LZJ for ; Wed, 14 Nov 2012 10:24:30 -0800 (PST) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6721F85FD for ; Wed, 14 Nov 2012 10:24:27 -0800 (PST) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id qAEIOGq3075950 for ; Wed, 14 Nov 2012 19:24:16 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201211141824.qAEIOGq3075950@bela.nlnetlabs.nl> To: "weirds@ietf.org" In-reply-to: References: Comments: In-reply-to Andy Newton message dated "Wed, 14 Nov 2012 14:32:27 +0000." Date: Wed, 14 Nov 2012 19:24:16 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bela.nlnetlabs.nl [127.0.0.1]); Wed, 14 Nov 2012 19:24:18 +0100 (CET) Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 18:24:30 -0000 > >* I agree with previously stated point on telephone numbers, at least >better examples (not 999-999-999-99) and some recommendations could be >made in WEIRDS. Sounds good. We could recommend servers use E.123 format if possible, but that clients should accept any format. The E.123 format is really a presentation for mat and "apply specifically to the printing of national and international telephone numbers, electronic mail addresses and Web addresses on letterheads, business cards, bills, etc." and is less suited for weird. It actually has multiple formats. It might be more prudent to stick with E.164, something that EPP does as well. jaap From Ed.Lewis@neustar.biz Wed Nov 14 11:22:35 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC19621F87CE for ; Wed, 14 Nov 2012 11:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.047 X-Spam-Level: X-Spam-Status: No, score=-103.047 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs+8xv3gU4Xs for ; Wed, 14 Nov 2012 11:22:34 -0800 (PST) Received: from smtp181.dfw.emailsrvr.com (smtp181.dfw.emailsrvr.com [67.192.241.181]) by ietfa.amsl.com (Postfix) with ESMTP id 873E021F87CC for ; Wed, 14 Nov 2012 11:22:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E17CF26809A; Wed, 14 Nov 2012 14:22:33 -0500 (EST) X-Virus-Scanned: OK Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 786042680CE; Wed, 14 Nov 2012 14:22:33 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Nov 2012 14:12:34 -0500 To: "weirds@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ed.lewis@neustar.biz Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 19:22:35 -0000 At 14:32 +0000 11/14/12, Andy Newton wrote: >Just like phone numbers, the data registries have is the data registries >have. If addresses are not in a structured format in the registry, it >would be difficult for them to use a format that does enforce structure. For some reason I don't fully accept that reason. The registries willing to expose that information will have that information and can write code to add some structure to the data. Contact addresses are not free-form prose. By their nature they have a pretty fixed grammar. I'd recommend spec'ing out a more strict format until someone complains they can't support it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From aservin@lacnic.net Wed Nov 14 13:37:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56221F87E1 for ; Wed, 14 Nov 2012 13:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVhzMinfystH for ; Wed, 14 Nov 2012 13:37:10 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id C199621F87B7 for ; Wed, 14 Nov 2012 13:37:09 -0800 (PST) Received: from [IPv6:2800:af:ba30:fc38:21e:52ff:fe76:b63] (unknown [IPv6:2800:af:ba30:fc38:21e:52ff:fe76:b63]) by mail.lacnic.net.uy (Postfix) with ESMTP id 91FFC308457; Wed, 14 Nov 2012 19:37:08 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Wed, 14 Nov 2012 19:37:03 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Edward Lewis X-Mailer: Apple Mail (2.1085) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 21:37:10 -0000 On 14 Nov 2012, at 17:12, Edward Lewis wrote: > At 14:32 +0000 11/14/12, Andy Newton wrote: >=20 >> Just like phone numbers, the data registries have is the data = registries >> have. If addresses are not in a structured format in the registry, it >> would be difficult for them to use a format that does enforce = structure. >=20 > For some reason I don't fully accept that reason. The registries = willing to expose that information will have that information and can = write code to add some structure to the data. No, we cannot. At least not in 100% of cases. We can change our systems to try to enforce that new/updated = data will comply with the format. However there would be some legacy = data that will never comply. >=20 > Contact addresses are not free-form prose. =20 > By their nature they have a pretty fixed grammar. I'd recommend = spec'ing out a more strict format until someone complains they can't = support it. But sometimes it is difficult to know what is a city, a street. etc. The = current data in the whois have some structure, but you are asking too = much. And probably, I would complain. Regards. as > --=20 > = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis > NeuStar You can leave a voice message at = +1-571-434-5468 >=20 > 2012...time to reuse those 1984 calendars! > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From alexandrsergeyev@gmail.com Wed Nov 14 14:04:10 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738E621F881D for ; Wed, 14 Nov 2012 14:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0B2hr3a6lH6 for ; Wed, 14 Nov 2012 14:04:10 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B239E21F881B for ; Wed, 14 Nov 2012 14:04:09 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm14so480380wib.13 for ; Wed, 14 Nov 2012 14:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7s7ZFeh7zvTulfFvyz62y/AJ2prXimCaC6FkhoP0rbg=; b=t+3y5xSQphY0QeLh5oBkzG4Sq/aqFEhH1Jr8n4lLv3K2QByfv/PrP9DbO3Rf6z2wEi x8YwOTRdfWYJtxcvOGF58fUCJ4+gdEA2R4v4VnRFJsstvB/ZPh+PZ4KlSDq69NHVP0sh wWwNlso7u9XvFG1yHxX6+n5ENdvU6tOgDwCYFb9N4nx8SJc+kgY2eLKaBlioreEzjBJo l+CRVDKzqs5afbY6fOOiylw8kYSngq4tF1btD660HUdFcLgVGYVyKxNGCsO2qFUU64/p G6gc38u25GcbQvBupa0FuqrFEYNN0K2PUO9BtOX2w/2G2KFXWG4F7jaqHpdhDWZ+tDlH QEuw== MIME-Version: 1.0 Received: by 10.216.70.195 with SMTP id p45mr2024287wed.193.1352930648571; Wed, 14 Nov 2012 14:04:08 -0800 (PST) Sender: alexandrsergeyev@gmail.com Received: by 10.216.159.211 with HTTP; Wed, 14 Nov 2012 14:04:08 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 17:04:08 -0500 X-Google-Sender-Auth: KlT3ldNLJEQjQslJTb8xnYBsCxg Message-ID: From: Alex Sergeyev To: Andy Newton Content-Type: multipart/alternative; boundary=00504502d321b6bf7c04ce7bb623 Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Wed, 14 Nov 2012 22:04:10 -0000 --00504502d321b6bf7c04ce7bb623 Content-Type: text/plain; charset=UTF-8 Andy, Thank you for answers, >* I also would suggest some synonym for field "names" (in entity object). > >Some long_key would also work better. Right now it is not really easy to > >make mistake but replacing it could add some error-resiliency. > > I don't think I understand. Can you provide an example? > it's truly just a gut feeling "something might be wrong there in future" might be paranoia Right now there is: "name": "domain.com" and "names": ["John Doe"] I think that even simple typos made by client developers could be annoying. Also, when someone would go and extend WEIRDS, say with the object "reseller", that might be identified by some abstract "name" and by company name. It would be tempting for them to reuse "names" field and I think people might be making wrong decisions here. Sincerely, Alex. --00504502d321b6bf7c04ce7bb623 Content-Type: text/html; charset=UTF-8 Andy,

Thank you for answers,

>* I also would suggest some synonym for field "names" (in entity object).
>Some long_key would also work better. Right now it is not really easy to
>make mistake but replacing it could add some error-resiliency.

I don't think I understand. Can you provide an example?


it's truly just a gut feeling "something might be wrong there in future" might be paranoia

Right now there is:
"name": "domain.com"
and
"names": ["John Doe"]

I think that even simple typos made by client developers could be annoying. Also,
when someone would go and extend WEIRDS, say with the object "reseller", that
might be identified by some abstract "name" and by company name.

It would be tempting for them to reuse "names" field and I think people might be making wrong decisions here.



Sincerely,

Alex.

--00504502d321b6bf7c04ce7bb623-- From bje@apnic.net Wed Nov 14 16:02:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C47621F854E for ; Wed, 14 Nov 2012 16:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWG8C0Yh+5Nu for ; Wed, 14 Nov 2012 16:02:17 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id E556F21F853F for ; Wed, 14 Nov 2012 16:02:15 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:486f:d8d8:ded4:cae6] (unknown [IPv6:2001:dc0:a000:4:486f:d8d8:ded4:cae6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id ED650B69A1; Thu, 15 Nov 2012 10:02:12 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_DC6ADFAF-3029-486F-BCCA-85E79E07AE8A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Thu, 15 Nov 2012 10:02:12 +1000 Message-Id: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> References: To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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, 15 Nov 2012 00:02:17 -0000 --Apple-Mail=_DC6ADFAF-3029-486F-BCCA-85E79E07AE8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Edward, On 15/11/2012, at 5:12 AM, Edward Lewis wrote: > At 14:32 +0000 11/14/12, Andy Newton wrote: >=20 >> Just like phone numbers, the data registries have is the data = registries >> have. If addresses are not in a structured format in the registry, it >> would be difficult for them to use a format that does enforce = structure. >=20 > For some reason I don't fully accept that reason. The registries = willing to expose that information will have that information and can = write code to add some structure to the data. >=20 > Contact addresses are not free-form prose. By their nature they have = a pretty fixed grammar. I'd recommend spec'ing out a more strict format = until someone complains they can't support it. Let me give you some real examples from actual data. address: Phnom Penh address: Level 25, 41 George Street address: Mostofa Center Road#27, Plot#59, Banani, Dhaka-1213 address: PLDT Building , Pasig City address: Level 7 141 St Georges Terrace address: Perth address: WA 6000 address: Jl. Jimerto 25-27 Gedung Pemkot Surabaya address: Surabaya address: Greater Noida, UP. address: Schwarzenbergstrae=9F=9F 13/14a, Wien 1010 Addresses pretty much are free-form prose in the data I have in front of = me. I cannot support a more structured format. Byron --Apple-Mail=_DC6ADFAF-3029-486F-BCCA-85E79E07AE8A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTUwMDAyMTJaMCMGCSqGSIb3DQEJBDEWBBSG QAGN1JiCnWBwxg7Hhsb74r4SHjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBsgYj9/2dz/RTj KSB8NKss//Fr1j5rdmzVowxaI2p5YlCMCCuKQKcgPKrTBMZYV50+nbxIeULBBEtkjhQm6brywwCq MKOd2+AoTv7pYNwnPaeI9QU/kJmDV1/jcjvnI/TMayy3c6o9WE6HHEN1Os9uEuG5BV6wjwl2k9in 0VH9OxmwBdedFBsKEZWr6mEk/3SZmuh1pCAUO7ZdUi7ORBlB4nwaZ0GBfdLYFSX/uqBNKTIyOhge I5juAlCPwFnqPglRCzZ+ezMcC70HLmPP12hIffv+b6gMGF9oryBWIjf/GLiWrv7zrTOBlfGnCYWd /FM6imPPz4/00W2se6orjJEMAAAAAAAA --Apple-Mail=_DC6ADFAF-3029-486F-BCCA-85E79E07AE8A-- From kranjbar@ripe.net Thu Nov 15 01:25:41 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B3621F859D for ; Thu, 15 Nov 2012 01:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ItfAYGfIVVP for ; Thu, 15 Nov 2012 01:25:40 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 7580821F8428 for ; Thu, 15 Nov 2012 01:25:40 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TYvhZ-00050n-22; Thu, 15 Nov 2012 10:25:38 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-89.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TYvhY-0002Du-Q5; Thu, 15 Nov 2012 10:25:36 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_871E8910-3AA6-4DBF-ADCD-729E0CF83F31" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Kaveh Ranjbar In-Reply-To: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> Date: Thu, 15 Nov 2012 10:25:35 +0100 Message-Id: <0E430D07-B566-4FE2-AA1F-3DE2B1945441@ripe.net> References: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> To: Byron Ellacott X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121115 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5b058e158c7c26b32b6c195e9476bed3dd Cc: Edward Lewis , "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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, 15 Nov 2012 09:25:41 -0000 --Apple-Mail=_871E8910-3AA6-4DBF-ADCD-729E0CF83F31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Nov 15, 2012, at 1:02 AM, Byron Ellacott wrote: > Addresses pretty much are free-form prose in the data I have in front = of me. I cannot support a more structured format. +1, I can not agree more with Byron. Kaveh.= --Apple-Mail=_871E8910-3AA6-4DBF-ADCD-729E0CF83F31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bje@apnic.net> = wrote:

, "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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, 15 Nov 2012 16:32:01 -0000 At 10:02 +1000 11/15/12, Byron Ellacott wrote: >Let me give you some real examples from actual data. > >address: Phnom Penh > >address: Level 25, 41 George Street > >address: Mostofa Center Road#27, Plot#59, Banani, Dhaka-1213 > >address: PLDT Building , Pasig City > >address: Level 7 141 St Georges Terrace >address: Perth >address: WA 6000 > >address: Jl. Jimerto 25-27 Gedung Pemkot Surabaya >address: Surabaya > >address: Greater Noida, UP. > >address: Schwarzenbergstrae=9F=9F 13/14a, Wien 1010 =46irst I'm shocked that registries would be so sloppy in collecting data. Phnom Penh is obviously not enough detail to locate a registrant. So I tried to pick apart the "Level 25, 41 George=20 Street." It's pretty straightforward to tie this=20 to a (civilian) government agency probably in=20 Brisbane Australia - only a few searches are=20 needed. But - "only a few searches" to find one=20 full address does not scale. (And I have to=20 admit that I am not 100% certain the city=20 involved is Brisbane.) Neither the APNIC whois=20 (which has the address above) nor the AU registry=20 whois (looking up the mail domain listed at=20 APNIC) had the city - in fact the latter didn't=20 include any postal address information. (I'm surprised that a public agency would be so=20 well hidden - that's not in the protocol's scope.) The Perth address is pretty complete to me...yes=20 that "WA" is Western Australia and not (State of)=20 Washington in the US. I'll admit that I have=20 travelled a lot and can fill in the fields not=20 supplied in most cases even without resorting to=20 a few web searches. There are three perspectives here. One is the=20 registry operator, who isn't inclined to flesh=20 out the addresses. One is the registrant who=20 also isn't inclined to supply more than is asked=20 for and is more inclined to try to hide as much a=20 possible. The third perspective is the relying=20 party who is inclined to want details - because=20 they are probably looking up this address because=20 they have a problem with the object on the=20 network. The specification should encourage the server to=20 provide as much structured information as it can=20 while also letting a server give back what it can. PS - I hope no one wants to see the last address=20 "translated (in English)" to Black Mountain=20 Street in Vienna, Austria ... ;) -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From bje@apnic.net Thu Nov 15 17:50:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81821F8319 for ; Thu, 15 Nov 2012 17:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBhsO8qZJDX1 for ; Thu, 15 Nov 2012 17:50:35 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A57D821F8232 for ; Thu, 15 Nov 2012 17:50:29 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:35eb:5785:6fc6:4de6] (unknown [IPv6:2001:dc0:a000:4:35eb:5785:6fc6:4de6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D8FA0B684D; Fri, 16 Nov 2012 11:50:27 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_BC212E19-AADD-40C6-A537-7D59D9F53ED3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Fri, 16 Nov 2012 11:50:27 +1000 Message-Id: <4FF162C1-4C77-46E3-A32C-8A50565CBE3D@apnic.net> References: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 01:50:36 -0000 --Apple-Mail=_BC212E19-AADD-40C6-A537-7D59D9F53ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Edward, On 16/11/2012, at 2:30 AM, Edward Lewis wrote: > At 10:02 +1000 11/15/12, Byron Ellacott wrote: >=20 >> Let me give you some real examples from actual data. >=20 > [...] > But - "only a few searches" to find one=20 > full address does not scale. (And I have to=20 > admit that I am not 100% certain the city=20 > involved is Brisbane.) > [...] Right, it doesn't scale. A human can figure out most of these = addresses. This is probably good news for consumers of the data - = there's enough information provided that they can still send snail-mail, = though they might need to have some Google-fu to do so. It doesn't scale = to overhaul the data, and it doesn't scale to do it as the data arrives = - the cost of registration would increase to manage that workload. > (I'm surprised that a public agency would be so=20 > well hidden - that's not in the protocol's scope.) I'm concerned you think the quality or right of access to data is within = a protocol's scope at all. It's policy, and the IETF is simply unable = to make those decisions: choices made here won't be binding. The IETF = doesn't even trump ICANN policy, let alone the varying regional privacy = laws. Also, the address attribute quoted here is associated with a person, not = an organisation - this data set does not expose organisations' = addresses, and only so much of a person's (or role's) address as they're = *willing* to provide for public consumption. Other data sets will have = other policy or legal constraints on them. Other views of *this* data = set will have different policy or legal constraints on it. > The specification should encourage the server to=20 > provide as much structured information as it can=20 > while also letting a server give back what it can. This notion I can get behind. There's a happy ground between the = perfect representation of ideal information and the unstructured glom of = bytes that is port 43 output, and that's what weirds will give us. I'd be very interested to see a proposal from you for an address data = structure that can accommodate all the examples I gave you. (So long as = you also include pseudocode for how I might map from what I have to what = I would need! :-) > PS - I hope no one wants to see the last address=20 > "translated (in English)" to Black Mountain=20 > Street in Vienna, Austria ... ;) I think the working group has reached an agreement that any translation = or transliteration done will be done by the client, after the weirds = protocol's part in the story is done and dusted, or it will be done = because the registry in question has that as part of their own processes = and policies, before the weirds protocol's part in the story even = begins. A process servicing a weirds request will do neither. Byron --Apple-Mail=_BC212E19-AADD-40C6-A537-7D59D9F53ED3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTYwMTUwMjhaMCMGCSqGSIb3DQEJBDEWBBQG YYI/lRSi3m9gQuhs5Gfb+RR6gjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQDL9LQDx+XOg+Bf Hh9mcMrGbsMhJEVbbexhZVWXcAaA3hhwKsQrFziOA+xn4Z70hmBbJdom5YFFLqVCDTTFd6ENLjsF ClRAgKbhQXZRYnjIag8bensUjMctW+puBMuEBjQrYjDlVCCYRM9JfC/A+xVdEIEZ8T0LhfV1Fhj7 REEHhJMlle9EB41bEkisYlwIZeNAE1Zo52khDD0imRs5kev9KZGFCBcZVzMN/IWDnWfxDI8WNyhu frnR37S1nFh/8jNGwxWC1FFj1xsV7PNm5VHEGCAnRse7+UF0Ww+PbWc30s68ClAOJpBLEfgoISem sm3tOBU9HtggpQlUnpJrQxfnAAAAAAAA --Apple-Mail=_BC212E19-AADD-40C6-A537-7D59D9F53ED3-- From johnl@iecc.com Thu Nov 15 20:20:42 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4675221E802E for ; Thu, 15 Nov 2012 20:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.473 X-Spam-Level: X-Spam-Status: No, score=-106.473 tagged_above=-999 required=5 tests=[AWL=-3.874, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf4en5gO3o2n for ; Thu, 15 Nov 2012 20:20:40 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54D21F84D4 for ; Thu, 15 Nov 2012 20:20:35 -0800 (PST) Received: (qmail 81267 invoked from network); 16 Nov 2012 04:20:33 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Nov 2012 04:20:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50a5bf11.xn--3zv.k1211; i=johnl@user.iecc.com; bh=Bq0LK2HAZBvrOhbXq/EdV6kKEaTtsUv0YZr3pKSrJBI=; b=0LcwtI6/uhjLLQKg7dT9s1cVUnVq2zN92YvAD/oFmLdTrY27kZIhs9hdY2IweUaIZJkouDqfQi4jliZfkcZMOy9dtUkdaPOdzJkGeIEU+cpOJGXmP+3ykhkgSefpcfjxZPV0sLNavyOcLfk//kKk/n8TpkXjIrA3/a1LQ9G0cns= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50a5bf11.xn--3zv.k1211; olt=johnl@user.iecc.com; bh=Bq0LK2HAZBvrOhbXq/EdV6kKEaTtsUv0YZr3pKSrJBI=; b=iAxMuSrWKePWmhS+JAxsxr0A4AF8gehnFtvYqiAt0WMGFTJgd4O500pl15cP7uQPocS9VBRw8PZuJmp7puvuc7HzC8dX9jAYVocXOIFhYyqrcYNd8i0sOFFNh3SBTLsKB+GtfAEHDJYzsfGOUZEnFXC4JhBBsIgV5rJU684Tb8Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Nov 2012 04:20:11 -0000 Message-ID: <20121116042011.13492.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 04:20:42 -0000 >First I'm shocked that registries would be so sloppy in collecting data. You shouldn't be. There's some pretty funky registrations in .BIZ, too. >The specification should encourage the server to >provide as much structured information as it can >while also letting a server give back what it can. Sure, but this is an insoluble problem. Some countries like the US and UK have address standards and it's easy to check an address against the post office's master list. Some countries don't even have street addresses. In Costa Rica, for example, addresses are things like " Calle Foo, 50 meters past the corner of Calle Bar." Given that we're not doing a research project here, I'd say that servers SHOULD use return standardized addresses when possible, but clients have to be prepared for whatever crud the server has. R's, John From dblumenthal@pir.org Thu Nov 15 21:50:50 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC9521F85E3 for ; Thu, 15 Nov 2012 21:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-rO3W9T3fdU for ; Thu, 15 Nov 2012 21:50:49 -0800 (PST) Received: from mail.pir.org (mail.pir.org [207.87.85.226]) by ietfa.amsl.com (Postfix) with ESMTP id AED3421F8617 for ; Thu, 15 Nov 2012 21:50:49 -0800 (PST) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 16 Nov 2012 00:50:48 -0500 From: Don Blumenthal To: "weirds@ietf.org" Date: Fri, 16 Nov 2012 00:50:43 -0500 Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac3DvlQhJ9JQO5TvQ5+KMi+deQ4jeA== Message-ID: In-Reply-To: <20121116042011.13492.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Levine Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 05:50:50 -0000 On 11/15/12 11:20 PM, "John Levine" wrote: >>The specification should encourage the server to >>provide as much structured information as it can >>while also letting a server give back what it can. > >Sure, but this is an insoluble problem. Some countries like the US >and UK have address standards and it's easy to check an address against >the post office's master list. Some countries don't even have street >addresses. In Costa Rica, for example, addresses are things like " >Calle Foo, 50 meters past the corner of Calle Bar." Accuracy isn't so easy to determine even in the US. Postal address registries were based, at least in part and maybe entirely, on addresses as laid out in initial maps. Structures don't necessarily go up according to original plans, so the USPS system may show an address where none exists.=20 The situation has improved over the last five years. I just checked the neighborhood where I grew up, which I used to demonstrate the problem when I taught classes where the mismatch was relevant. A street number that I know is bad used to show up as valid. It now carries the message "The address you provided is not recognized by the US Postal Service as an address we serve. Mail sent to this address may be returned." I still wouldn't trust the system until I see assurances that all of it has been cleaned up. Don From andy@arin.net Fri Nov 16 04:34:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD57121F86AF for ; Fri, 16 Nov 2012 04:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljTQdrWMuIj3 for ; Fri, 16 Nov 2012 04:34:42 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 7062B21F86AC for ; Fri, 16 Nov 2012 04:34:42 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id CF0F61653B1; Fri, 16 Nov 2012 07:34:41 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 41CFD1653AA; Fri, 16 Nov 2012 07:34:41 -0500 (EST) 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.283.3; Fri, 16 Nov 2012 07:34:22 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Fri, 16 Nov 2012 07:33:32 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Comments on draft-ietf-weirds-json-response Thread-Index: Ac27o7qF9wnShljEQOOC4HSUHYSddQG+MQsA//+wu4CAAKIZAIAAUO0AgAEUPwCAAMYqgIAANgeA Date: Fri, 16 Nov 2012 12:33:32 +0000 Message-ID: In-Reply-To: <20121116042011.13492.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ed.Lewis@neustar.biz" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 12:34:43 -0000 On 11/15/12 11:20 PM, "John Levine" wrote: >>First I'm shocked that registries would be so sloppy in collecting data. > >You shouldn't be. There's some pretty funky registrations in .BIZ, too. :) >Given that we're not doing a research project here, I'd say that >servers SHOULD use return standardized addresses when possible, but >clients have to be prepared for whatever crud the server has. I agree with this. And to summarize Byron's suggestion for those desiring the structure, "send text." -andy From Ed.Lewis@neustar.biz Fri Nov 16 05:54:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1967121F851F for ; Fri, 16 Nov 2012 05:54:19 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq1TSXnHj1QB for ; Fri, 16 Nov 2012 05:54:18 -0800 (PST) Received: from smtp153.ord.emailsrvr.com (smtp153.ord.emailsrvr.com [173.203.6.153]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB021F850D for ; Fri, 16 Nov 2012 05:54:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 96D88160090; Fri, 16 Nov 2012 08:54:17 -0500 (EST) X-Virus-Scanned: OK Received: by smtp28.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 3A49E1600D4; Fri, 16 Nov 2012 08:54:17 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20121116042011.13492.qmail@joyce.lan> References: <20121116042011.13492.qmail@joyce.lan> Date: Fri, 16 Nov 2012 08:54:10 -0500 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ed.Lewis@neustar.biz Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 13:54:19 -0000 At 4:20 +0000 11/16/12, John Levine wrote: >servers SHOULD use return standardized addresses when possible, but >clients have to be prepared for whatever crud the server has. In summary to what I wrote - that's exactly the point I was trying to make. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Ed.Lewis@neustar.biz Fri Nov 16 06:23:37 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9004821F886A for ; Fri, 16 Nov 2012 06:23:37 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTSXtPTKWzQn for ; Fri, 16 Nov 2012 06:23:36 -0800 (PST) Received: from smtp145.ord.emailsrvr.com (smtp145.ord.emailsrvr.com [173.203.6.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1321F8485 for ; Fri, 16 Nov 2012 06:23:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp27.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 003CE2A80BD; Fri, 16 Nov 2012 09:23:35 -0500 (EST) X-Virus-Scanned: OK Received: by smtp27.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id A27DF2A80A7; Fri, 16 Nov 2012 09:23:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4FF162C1-4C77-46E3-A32C-8A50565CBE3D@apnic.net> References: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> <4FF162C1-4C77-46E3-A32C-8A50565CBE3D@apnic.net> Date: Fri, 16 Nov 2012 09:23:30 -0500 To: "weirds@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis Subject: [weirds] Cycling through threads X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:23:37 -0000 At 11:50 +1000 11/16/12, Byron Ellacott wrote: >I'm concerned you think the quality or right of access to data is within a >protocol's scope at all. It's policy, and the IETF is simply unable to make >those decisions: choices made here won't be binding. The IETF doesn't even >trump ICANN policy, let alone the varying regional privacy laws. http://www.ietf.org/mail-archive/web/weirds/current/msg01802.html It would be good to have a requirements document so we don't have to keep referring to the mail list archives and/or so we don't keep recycling threads. >I'd be very interested to see a proposal from you for an address data >structure that can accommodate all the examples I gave you. (So long as you >also include pseudocode for how I might map from what I have to what I would >need! :-) UPU.int is one source. (Previously covered on this list.) Previously written, most of the examples have too little detail and missing elements to fill this out. That shouldn't be an excuse for the protocol to be flat and weak, whether or not the protocol's existence influences policy. I know that "the IETF does not trump ICANN." But I also know that operators will tend to be guided by the standards under which they work. E.g., there is a standard in DNS that says, for a certain field, 'pick a low number under 150' and there is an operator using 150. Why? Guessing (as I haven't talked to that operator) that 150 was the number 'in print.' I've worked with places whose attitude is 'we will work up to the requirements' meaning that if the requirement asked for one more thing, they'd do it, if the requirement doesn't ask for the thing, they don't. And this leads up to - the protocol we are developing isn't just for the registries and registrants, its for the relying parties that want more than the current status quo of WhoIs. >I think the working group has reached an agreement that any translation or >transliteration done will be done by the client, after the weirds protocol's >part in the story is done and dusted, or it will be done because the registry >in question has that as part of their own processes and policies, before the >weirds protocol's part in the story even begins. A process servicing a >weirds request will do neither. Such an agreement ought to be in the requirements/goals document. ;) The reason I mentioned the example was to underscore that (undocumented?) agreement. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From jaap@NLnetLabs.nl Fri Nov 16 09:02:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0621F842A for ; Fri, 16 Nov 2012 09:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EIM8C+2WuBR for ; Fri, 16 Nov 2012 09:02:03 -0800 (PST) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id D403E21F8231 for ; Fri, 16 Nov 2012 09:02:02 -0800 (PST) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id qAGH1kCA072310; Fri, 16 Nov 2012 18:01:51 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201211161701.qAGH1kCA072310@bela.nlnetlabs.nl> To: Don Blumenthal In-reply-to: References: Comments: In-reply-to Don Blumenthal message dated "Fri, 16 Nov 2012 00:50:43 -0500." Date: Fri, 16 Nov 2012 18:01:46 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bela.nlnetlabs.nl [127.0.0.1]); Fri, 16 Nov 2012 18:01:55 +0100 (CET) Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Comments on draft-ietf-weirds-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: Fri, 16 Nov 2012 17:02:04 -0000 Accuracy isn't so easy to determine even in the US. Postal address registries were based, at least in part and maybe entirely, on addresses as laid out in initial maps. Structures don't necessarily go up according to original plans, so the USPS system may show an address where none exists. I got a similar experience while working for the .nl registry. We did a sanity check against the official postal code database , We ended up finding quite some inaccuracies in the database and therefore contemplated that reason to stop that practice. (I Don't remember we actually did give up or what the curret situation is). jaap PS. The URL mentioned has pointers of similar sites in various countries: From bje@apnic.net Sun Nov 18 16:46:57 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DD21F85C1 for ; Sun, 18 Nov 2012 16:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWx8y4Dg6z-Z for ; Sun, 18 Nov 2012 16:46:56 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 86C1F21F85BC for ; Sun, 18 Nov 2012 16:46:55 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:d899:ce2c:90a2:7caa] (unknown [IPv6:2001:dc0:a000:4:d899:ce2c:90a2:7caa]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CC4F1B6906; Mon, 19 Nov 2012 10:46:53 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_FE2A8EE1-F5F0-4DE0-AD3A-D112AFFE312F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Mon, 19 Nov 2012 10:46:53 +1000 Message-Id: <9E9E8022-9329-4DE6-A6E7-1795430297D5@apnic.net> References: <4389D4FC-B27A-482D-A1D0-6093DA46E0C3@apnic.net> <4FF162C1-4C77-46E3-A32C-8A50565CBE3D@apnic.net> To: Edward Lewis X-Mailer: Apple Mail (2.1499) Cc: "weirds@ietf.org" Subject: Re: [weirds] Cycling through threads X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 00:46:57 -0000 --Apple-Mail=_FE2A8EE1-F5F0-4DE0-AD3A-D112AFFE312F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17/11/2012, at 12:23 AM, Edward Lewis wrote: > At 11:50 +1000 11/16/12, Byron Ellacott wrote: >=20 >> I'm concerned you think the quality or right of access to data is = within a >> protocol's scope at all. It's policy, and the IETF is simply unable = to make >> those decisions: choices made here won't be binding. The IETF = doesn't even >> trump ICANN policy, let alone the varying regional privacy laws. >=20 > http://www.ietf.org/mail-archive/web/weirds/current/msg01802.html >=20 > It would be good to have a requirements document so we don't have to = keep referring to the mail list archives and/or so we don't keep = recycling threads. I may be misunderstanding you, since what you linked to appears to have = very little bearing to your expressed concern over the amount of = information visible in a particular address field. Are we in oblique = agreement that the protocol covers representation of data, and policy = covers contents of data? >> I'd be very interested to see a proposal from you for an address data >> structure that can accommodate all the examples I gave you. (So long = as you >> also include pseudocode for how I might map from what I have to what = I would >> need! :-) >=20 > UPU.int is one source. (Previously covered on this list.) Previously = written, most of the examples have too little detail and missing = elements to fill this out. That shouldn't be an excuse for the protocol = to be flat and weak, whether or not the protocol's existence influences = policy. UPU.int was passingly referred to, not covered; UPU.int do not seem to = offer a single data structure to best represent a postal address, but if = they do, feel free to link to it, or describe a JSON data structure that = would best encapsulate it, and let's talk about whether it's possible to = use that structure in the face of the several decades' worth of existing = data many operators have. I agree with you completely that having a structure would be preferable. = vCard has one [1], which is a specification I can point to, as opposed = to what UPU.int offers publicly. We could even adopt vCard's format, = slightly changed to suit JSON, but given the existing data and the = impracticality of converting free-form text into a structured address, = all the data I have would wind up looking like this: "address": { "value": ";;;;;;", "label": "Level 25, 41 George = Street" } I don't believe it is practical or reasonable to mandate a structured = format. If a structured format is specified, an unstructured = alternative must also be specified to allow existing data to be = presented, or relying parties will see something more like this: "address": ";;;;;;" So the question to me is whether address looks better as: "address": [ "Jl. Jimerto 25-27 Gedung Pemkot Surabaya", "Surabaya", ] or: "address: { "value": ";;;;;;", "label": "Jl. Jimerto 25-27 = Gedung Pemkot Surabaya\nSurabaya" } Of those, I favour the former, which is what is in the existing draft. Byron [1] http://tools.ietf.org/html/rfc6350#section-6.3.1 --Apple-Mail=_FE2A8EE1-F5F0-4DE0-AD3A-D112AFFE312F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTkwMDQ2NTRaMCMGCSqGSIb3DQEJBDEWBBSr n8GpJBapwQWWDl2FRlTSHpiseDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAf/3vuewczFMSr xUfDcYzYzfct4vK3SoX8uxDwoq5Z9VrZSfqPvfflMUo1PZapiH29bjTA+mI6WsNcC380gkM3Zgdk nxCPBnMX0SXhOnKVVqmUi4G0vyl++tfzMHI5K1bW9oJqmpsEtkEiMKbo8i5136SgdDGZYpG70erF qJPJubVYrb3EGf9Lb9umq6O0WaUUemtk0ZNLj9Lzbw01P/o7p/BfwImbx26m0c1GAYG2oF5M47/A dre7uQ/Q7LysMUHsG1V2917MKdZbq6miMlr4oGDD0boZEa6OEpJXrbHKbSGKNLrPnCMZXBfQqAIT cSyriyVyrDEpVwtnXmYnC7edAAAAAAAA --Apple-Mail=_FE2A8EE1-F5F0-4DE0-AD3A-D112AFFE312F-- From internet-drafts@ietf.org Mon Nov 26 09:21:22 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0221F8540; Mon, 26 Nov 2012 09:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR5RKKsTmOi7; Mon, 26 Nov 2012 09:21:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382821F8514; Mon, 26 Nov 2012 09:21:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126172121.32102.60981.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 09:21:21 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:21:22 -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 : Unified Registration Data Access Protocol Query Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-01.txt Pages : 11 Date : 2012-11-26 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Mon Nov 26 09:25:21 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED7221F86B1 for ; Mon, 26 Nov 2012 09:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+PYSwKaBC2Q for ; Mon, 26 Nov 2012 09:25:21 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 00CC321F867F for ; Mon, 26 Nov 2012 09:25:17 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKULOl/TEiv0UxJl5oxSXoixZ/llFglEtT@postini.com; Mon, 26 Nov 2012 09:25:21 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAQHPEiN005171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Nov 2012 12:25:16 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 26 Nov 2012 12:25:14 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNy/qBWfTFSGY+J06pXjL2TyCmWZf8XS2Q Date: Mon, 26 Nov 2012 17:25:13 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B3D95@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121126172121.32102.60981.idtracker@ietfa.amsl.com> In-Reply-To: <20121126172121.32102.60981.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-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:25:22 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, November 26, 2012 12:21 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.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 : Unified Registration Data Access Protocol Query > Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-01.txt > Pages : 11 > Date : 2012-11-26 This version of the document is mostly complete (or so Andy and I think) wi= th the exception of the Security Considerations section. I'll address that = deficiency after we make decisions about the text in the new security consi= derations draft. I'll post rdap-sec-01 shortly. Scott From internet-drafts@ietf.org Mon Nov 26 09:29:24 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6281421F8794; Mon, 26 Nov 2012 09:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-qDuBWz6HEJ; Mon, 26 Nov 2012 09:29:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E397621F8755; Mon, 26 Nov 2012 09:29:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 09:29:23 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:29:24 -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-01.txt Pages : 9 Date : 2012-11-26 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services, specific requirements for RDAP, and approaches to provide RDAP security services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-sec-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shollenbeck@verisign.com Mon Nov 26 09:33:08 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AEF21F8594 for ; Mon, 26 Nov 2012 09:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29pC+hVBY7hO for ; Mon, 26 Nov 2012 09:33:07 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F121F8750 for ; Mon, 26 Nov 2012 09:33:07 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKULOn0kD0G3gtHx1h3CGDjLsrw59onI1X@postini.com; Mon, 26 Nov 2012 09:33:07 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAQHX2uM005429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Nov 2012 12:33:06 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Mon, 26 Nov 2012 12:33:02 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt Thread-Index: AQHNy/ueyDPWKBr6b0W0ZQ9xW2Q9JZf8X2zw Date: Mon, 26 Nov 2012 17:33:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B3DE2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> In-Reply-To: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:33:08 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, November 26, 2012 12:29 PM > To: i-d-announce@ietf.org > Cc: weirds@ietf.org > Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Extensible Internet Registration > Data Service Working Group of the IETF. >=20 > Title : Security Services for the Registration Data > Access Protocol > Author(s) : Scott Hollenbeck > Ning Kong > Filename : draft-ietf-weirds-rdap-sec-01.txt > Pages : 9 > Date : 2012-11-26 This version of the document has been edited extensively to include require= ments and approaches to meet those requirements based on mailing list and i= n-room IETF-85 discussion. Please take a look and let me know if Ning and I= missed something. Scott From ed.lewis@neustar.biz Tue Nov 27 09:08:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E771221F85CE for ; Tue, 27 Nov 2012 09:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.788 X-Spam-Level: X-Spam-Status: No, score=-98.788 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKzTrPwt95vZ for ; Tue, 27 Nov 2012 09:08:04 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id E4C2821F851F for ; Tue, 27 Nov 2012 09:08:03 -0800 (PST) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121127170803.MHOX5450.eastrmfepo201.cox.net@eastrmimpo109> for ; Tue, 27 Nov 2012 12:08:03 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo109 with cox id Uh811k00M3cuADQ01h818y; Tue, 27 Nov 2012 12:08:03 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020201.50B4F373.0090,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=EM+EIilC c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=zj0LwYoATe4A:10 a=hGBaWAWWAAAA:8 a=oH__LpYN30IA:10 a=48vgC7mUAAAA:8 a=zbUtx5hpxRaUeMFUKIgA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=Prl2fuwvDQJUg5Jf:21 a=70FHydSIAV5uNNPS:21 a=bKKK88wPiVGVaD7MRjgA:9 a=_W_S_7VecoQA:10 a=x34-mIcv-UEjCNRS:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3C4A983-5209-4BD5-A6E7-4548C7A60368" From: Edward Lewis In-Reply-To: <20121126172121.32102.60981.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 12:08:01 -0500 Message-Id: References: <20121126172121.32102.60981.idtracker@ietfa.amsl.com> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:08:05 -0000 --Apple-Mail=_E3C4A983-5209-4BD5-A6E7-4548C7A60368 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Apologies in advance - I'm using a new mail client and fear that my = formatting options are properly set. If there's a problem seeing this, = let me know.) Comments on this document: Overall I like this. It's simple and enforces the idea that there are = only five kinds (IP addresses, AS numbers, domain names, name servers = and entities) of things that this protocol is supposed to be covering. = I had a problem with the idea that name servers would be in the list = until I thought about the need to check a name server's address when it = was used in a different registry (like inspecting this from the tld. = registry "company.tld. NS ns1.dns.example." might drive me to need the = ns1.dns.example. address records from the example. registry.) My two items here are basically nits. The first is driven by wanting to = avoid talking about what a technical standards body does and does not = do. And the second is to "put units" on two numbers. On Nov 26, 2012, at 12:21, = wrote: > Title : Unified Registration Data Access Protocol = Query Format > Author(s) : Andrew Lee Newton > Scott Hollenbeck > Filename : draft-ietf-weirds-rdap-query-01.txt > Pages : 11 > Date : 2012-11-26 Item #1: This paragraph at the end of section 2 is well-intended but not quite = worded properly. While HTTP contains mechanisms for servers to authenticate clients and for clients to authenticate servers (from which authorization schemes may be built), both authentication of clients and servers and authorization for access to data are out-of-scope of this document. In general, these matters require "policy" and are not the domain of technical standards bodies. I'll suggest this: HTTP contains mechanisms for servers to authenticate clients and for = clients to authenticate servers (from which authorization schemes may be = built) so such mechanisms are not described in this document. Policy, = provisioning, and processing of authentication and authorization are = out-of-scope for this document as deployments will have to make choices = based on local criteria. So long as the solution chosen makes use of = the HTTP mechanisms, implementations ought to be interoperable. I'm avoiding this as it sounds a bit like lecturing on the structure of = the Internet "standards" bodies: In general, these matters require "policy" and are not the domain of = technical standards bodies. Item #2: 3.1. IP Network Path Segment Specification ... a CIDR block with a length of 32 for IPv4 and a length of 128 for s/length/bitmask length/g = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions and responses. --Apple-Mail=_E3C4A983-5209-4BD5-A6E7-4548C7A60368 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

My two items here are basically = nits.  The first is driven by wanting to avoid talking about what a = technical standards body does and does not do.  And the second is = to "put units" on two numbers.

On Nov 26, = 2012, at 12:21, <internet-drafts@ietf.org> = <internet-drafts@ietf.org> = wrote:

Title =           : Unified = Registration Data Access Protocol Query Format
Author(s) =   : Andrew Lee Newton
            =                 Scott = Hollenbeck
= Filename    : = draft-ietf-weirds-rdap-query-01.txt
Pages         = : 11
= Date =            : = 2012-11-26

Item = #1:

This paragraph at the end of section 2 is = well-intended but not quite worded properly.
   While HTTP =
contains mechanisms for servers to authenticate clients
   and for clients to authenticate servers (from which authorization
   schemes may be built), both authentication of clients and servers and
   authorization for access to data are out-of-scope of this document.
   In general, these matters require "policy" and are not the domain of
   technical standards bodies.

I'll suggest = this:

HTTP contains =
mechanisms for servers to authenticate clients and for clients to =
authenticate servers (from which authorization schemes may be built) so =
such mechanisms are not described in this document.  Policy, =
provisioning, and processing of authentication and authorization are =
out-of-scope for this document as deployments will have to make choices =
based on local criteria.  So long as the solution chosen makes use of =
the HTTP mechanisms, implementations ought to be =
interoperable.
In general, =
these matters require "policy" and are not the domain of technical =
standards bodies.
Item #2:
3.1.  IP Network =
Path Segment Specification

...
   a CIDR block with a length of =
32 for IPv4 and a length of 128 for

s/length/bitmask =
length/g
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNy/qBWfTFSGY+J06pXjL2TyCmWZf+P1+A//+tQjA= Date: Tue, 27 Nov 2012 17:12:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B5654@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121126172121.32102.60981.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F0D6B5654BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 17:12:36 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F0D6B5654BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, Ed. No disagreement from me on either point - and = thanks for sending text. Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Edward Lewis Sent: Tuesday, November 27, 2012 12:08 PM To: weirds@ietf.org Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt (Apologies in advance - I'm using a new mail client and fear that my format= ting options are properly set. If there's a problem seeing this, let me kn= ow.) Comments on this document: Overall I like this. It's simple and enforces the idea that there are only= five kinds (IP addresses, AS numbers, domain names, name servers and entit= ies) of things that this protocol is supposed to be covering. I had a prob= lem with the idea that name servers would be in the list until I thought ab= out the need to check a name server's address when it was used in a differe= nt registry (like inspecting this from the tld. registry "company.tld. NS n= s1.dns.example." might drive me to need the ns1.dns.example. address recor= ds from the example. registry.) My two items here are basically nits. The first is driven by wanting to av= oid talking about what a technical standards body does and does not do. An= d the second is to "put units" on two numbers. On Nov 26, 2012, at 12:21, > > wro= te: Title : Unified Registration Data Access Protocol Query= Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-01.txt Pages : 11 Date : 2012-11-26 Item #1: This paragraph at the end of section 2 is well-intended but not quite worde= d properly. While HTTP contains mechanisms for servers to authenticate clients and for clients to authenticate servers (from which authorization schemes may be built), both authentication of clients and servers and authorization for access to data are out-of-scope of this document. In general, these matters require "policy" and are not the domain of technical standards bodies. I'll suggest this: HTTP contains mechanisms for servers to authenticate clients and for client= s to authenticate servers (from which authorization schemes may be built) s= o such mechanisms are not described in this document. Policy, provisioning= , and processing of authentication and authorization are out-of-scope for t= his document as deployments will have to make choices based on local criter= ia. So long as the solution chosen makes use of the HTTP mechanisms, imple= mentations ought to be interoperable. I'm avoiding this as it sounds a bit like lecturing on the structure of the= Internet "standards" bodies: In general, these matters require "policy" and are not the domain of techni= cal standards bodies. Item #2: 3.1. IP Network Path Segment Specification ... a CIDR block with a length of 32 for IPv4 and a length of 128 for s/length/bitmask length/g -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions and responses. --_000_831693C2CDA2E849A7D7A712B24E257F0D6B5654BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, = Ed. No disagreement from me on either point – and thanks for sending = text.

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Edward Lewis
Sent: Tuesday, November 27, 2012 12:08 PM
To: weirds@ietf.org
Cc: Edward Lewis
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.tx= t

 

(Apologies in advance - I'm using a new mail client = and fear that my formatting options are properly set.  If there's a pr= oblem seeing this, let me know.)

 

Comments on this document:

 

Overall I like this.  It's simple and enforces = the idea that there are only five kinds (IP addresses, AS numbers, domain n= ames, name servers and entities) of things that this protocol is supposed t= o be covering.  I had a problem with the idea that name servers would be in the list until I thought about the need= to check a name server's address when it was used in a different registry = (like inspecting this from the tld. registry "company.tld. NS ns1.dns.= example."  might drive me to need the ns1.dns.example. address records from the example. registry.)

 

My two items here are basically nits.  The firs= t is driven by wanting to avoid talking about what a technical standards bo= dy does and does not do.  And the second is to "put units" o= n two numbers.

 

On Nov 26, 2012, at 12:21, <internet-drafts@ietf.org> <internet-drafts@ietf.org> wrote:

 

   &nb= sp;      Title     &nbs= p;     : Unified Registration Data Access Protocol= Query Format
       &n= bsp;  Author(s)   : Andrew Lee Newton
                     = ;       Scott Hollenbeck
       &n= bsp;  Filename    : draft-ietf-weirds-rdap-query-01.t= xt
       &n= bsp;  Pages         : 11
       &n= bsp;  Date         &nbs= p;  : 2012-11-26

 

Item #1:

 

This paragraph at the end of section 2 is well-inten= ded but not quite worded properly.

   While HTTP contains mechanisms for servers to authenticate c=
lients
   and for clie=
nts to authenticate servers (from which authorization

   schemes may =
be built), both authentication of clients and servers and=



   authorizatio=
n for access to data are out-of-scope of this document.

   In general, =
these matters require "policy" and are not the domain of


   technical st=
andards bodies.

 

I'll suggest this:

 

HTTP contains mechanisms for servers to authenticate clients and for clie=
nts to authenticate servers (from which authorization schemes may be built)=
 so such mechanisms are not described in this document.  Policy, provi=
sioning, and processing of authentication and authorization are out-of-scop=
e for this document as deployments will have to make choices based on local=
 criteria.  So long as the solution chosen makes use of the HTTP mecha=
nisms, implementations ought to be interoperable.
I'm avoiding this as it sounds a =
bit like lecturing on the structure of the Internet "standards" b=
odies:
In general, these matters require "policy" and are not the doma=
in of technical standards bodies.

Item #2:

3.1.  IP Network Path Segment Specification
 <=
/pre>

...


   a CIDR block with a length of 32 for IPv4 and a length of 12=
8 for


 


s/length/bitmask le=
ngth/g


-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-










Edward Lewis      &nbs=
p;      

NeuStar           &n=
bsp;        You can leave a voice messag=
e at +1-571-434-5468



There are no answers - just tradeoffs, decisions and responses.<=
/p>









 
--_000_831693C2CDA2E849A7D7A712B24E257F0D6B5654BRN1WNEXMBX01vc_-- From ed.lewis@neustar.biz Tue Nov 27 11:31:52 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C3721F86D1 for ; Tue, 27 Nov 2012 11:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.25 X-Spam-Level: X-Spam-Status: No, score=-99.25 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BANkFu7oS4uW for ; Tue, 27 Nov 2012 11:31:52 -0800 (PST) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id BBAD521F86B5 for ; Tue, 27 Nov 2012 11:31:51 -0800 (PST) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121127193151.BLYO6475.eastrmfepo202.cox.net@eastrmimpo109> for ; Tue, 27 Nov 2012 14:31:51 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo109 with cox id UjXp1k00P3cuADQ01jXpkr; Tue, 27 Nov 2012 14:31:50 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.50B51526.01D1,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=EM+EIilC c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=fwVOWxnvPYUA:10 a=hGBaWAWWAAAA:8 a=ctp8zMK05xsA:10 a=48vgC7mUAAAA:8 a=lu39Royhef68-UXDp6UA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=o_8WHkTpeM3BQcu2sBUA:9 a=_W_S_7VecoQA:10 a=PaapYx7nyTGWSHfb:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_52767D4F-ED24-45DC-856A-D3E846D311AD" From: Edward Lewis In-Reply-To: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 14:31:49 -0500 Message-Id: References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 19:31:52 -0000 --Apple-Mail=_52767D4F-ED24-45DC-856A-D3E846D311AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Comments on: On Nov 26, 2012, at 12:29, = wrote: > Title : Security Services for the Registration Data = Access Protocol > Author(s) : Scott Hollenbeck > Ning Kong > Filename : draft-ietf-weirds-rdap-sec-01.txt Item #1 This section 3.1 requirement isn't testable: REQUIREMENT: The RDAP authentication framework MUST be capable of supporting future authentication methods defined for use with HTTP. In the sense that we can't know the future... I wonder if there is another way to write this. I'm taking a pot shot = here in case I'm misinterpreting something... The RDAP authentication framework MUST conform with the authentication = methods and approach in use by HTTP in order to anticipate future = improvements to HTTP authentication methods. Item #2 Section 3.1.1, federated authentication, seems to be an ill-fit in a = requirements document. The possible approaches are fine descriptions as = far as they go, but, they aren't requirements. It's not bad to place = hold them here until there's a document detailing a solution or a = solution approach, but - well, they aren't requirements. But it's the requirement that is there that seems flakey. I understand = the utility of a federated authentication model but don't see how it is = germane to the definition of this protocol. I mean - authentication is = merely the task of proving I am who I claim to be. If this is done via = a trusted third party that is trusted by many servers (in the sense that = there are clients, servers and third parties), that is fine. It's a good discussion to have, but I don't see it as a requirement. I = can see 3.1.1. being labeled as a note on how to build the = authentication system. Item #3 In 3.2: REQUIREMENT: RDAP MUST include an authorization framework that is capable of providing granular (per registration data object) access controls according to the policies of the operator. The granularity probably ought to be extended to the other side of the = table - the actors. I.e., per actor, not just per class of actor. This = is a suggestion, perhaps there's only a need for "anonymous" and = "privileged" but I can see the latter quickly being subdivided into "law = enforcement in the jurisdiction" and "sponsoring registrar" and "this = registrant" classes...just to thrown down examples. Item #4 In 3.4, another "future" requirement: REQUIREMENT: RDAP MUST be capable of supporting future data confidentiality methods defined for use with HTTP. Perhaps what is needed is "sticking with the plan" so to speak of HTTP. Item #5 Maybe it's just me...but when I think of security concerns there are = lower-in-the-stack problems like message insertion and forgery. Those = things not a concern in here because we assume a transport better than = unreliable datagram. Perhaps it would be good to state the "floor" = assumption that there's a stream based transport (TCP) and more = involved. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_52767D4F-ED24-45DC-856A-D3E846D311AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii internet-drafts@ietf.org> = <internet-drafts@ietf.org> = wrote:
Title =           : Security = Services for the Registration Data Access Protocol
Author(s) =   : Scott Hollenbeck
            =                 Ning = Kong
= Filename   : = draft-ietf-weirds-rdap-sec-01.txt

Ite= m #1

This section 3.1 requirement isn't = testable:

   REQUIREMENT: The RDAP authentication framework MUST be =
capable of
   supporting future authentication methods defined for use with HTTP.
In the sense that we can't know the = future...

I wonder if there is another way to = write this.  I'm taking a pot shot here in case I'm misinterpreting = something...

The RDAP authentication framework = MUST conform with the authentication methods and approach in use by HTTP = in order to anticipate future improvements to HTTP authentication = methods.

Item = #2

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

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

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

Item #3

In = 3.2:

   REQUIREMENT: RDAP MUST include an authorization framework =
that is
   capable of providing granular (per registration data object) access
   controls according to the policies of the operator.

The granularity probably ought to be = extended to the other side of the table - the actors.  I.e., per = actor, not just per class of actor.  This is a suggestion, perhaps = there's only a need for "anonymous" and "privileged" but I can see the = latter quickly being subdivided into "law enforcement in the = jurisdiction" and "sponsoring registrar" and "this registrant" = classes...just to thrown down examples.

Item = #4

In 3.4, another "future" = requirement:

   REQUIREMENT: RDAP MUST be capable of supporting future =
data
   confidentiality methods defined for use with HTTP.
Perhaps what is needed is "sticking with the plan" so = to speak of HTTP.

Item = #5

Maybe it's just me...but when I think of = security concerns there are lower-in-the-stack problems like message = insertion and forgery.  Those things not a concern in here because = we assume a transport better than unreliable datagram.  Perhaps it = would be good to state the "floor" assumption that there's a stream = based transport (TCP) and more involved.

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

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

= --Apple-Mail=_52767D4F-ED24-45DC-856A-D3E846D311AD-- From johnl@iecc.com Tue Nov 27 19:32:20 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F7421F87A3 for ; Tue, 27 Nov 2012 19:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.24 X-Spam-Level: X-Spam-Status: No, score=-100.24 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pccbB1l35x1N for ; Tue, 27 Nov 2012 19:32:15 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EB27121E8044 for ; Tue, 27 Nov 2012 19:32:14 -0800 (PST) Received: (qmail 69103 invoked from network); 28 Nov 2012 03:32:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Nov 2012 03:32: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:vbr-info; s=50b585bd.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=l7QtEZeF8weH3ln1HF0Dr74Hf34NpVpKScBWyAyU9f0=; b=d1/5ENJfXa0UTYw8YDnqYul9A2pF4Wwb5hw/XRyDpJv/+5BPvWBgJazmoOOch1hucBwGgL9SbJPBkECd+w/73uohHvBS8VRGCBtu45I4xouieipAXB0r929Joy99OjVD9cETQGAcJgERZzTf7+bKLmE7jLtr+62HOBiYH8I5XwI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b585bd.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=l7QtEZeF8weH3ln1HF0Dr74Hf34NpVpKScBWyAyU9f0=; b=EwY0cYr5xwDhCYdBiKDWHSLLBrNJ1YslEvlulXHtYSitAanuzhsaVMhkAoLipzLPh4r0jBit6GTeHF/Vr+HNYx69jn1Avn/3PYIXsOFicKh47wmdc7i6JRzV/iYJB/u+xXNfF+1PONKFP/Hg26UQucg7Y4s6WbQ3omP6Q3NZ9rc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Nov 2012 03:31:51 -0000 Message-ID: <20121128033151.26459.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B3D95@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:32:21 -0000 I agree this is mostly done, at least for RIRs, except for the crufty bits around the edges. Section 3: it looks to me like each URL can contain only one resource type path segment. Are these wrong? If not, what do they mean? http://foo.example/weirds/ip/1.2.3.4/ip/2002::123 http://foo.example/weirds/domain/bar.example/ip/2002::123 End of section 4: "Servers SHOULD ignore unrecognized path segments." What should a server do with these? http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2.3.0/24 http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/fooble/parp Since a path segment can contain a variable number of slashes, how can a server do anything but fail the entire request, since it can't tell where to start looking for the next segment? Nit: top of page five, rather than "lowest IP network" say "smallest IP network". A sufficiently perverse reader might interpret lowest IP network to be the network with the lowest base address which is exactly wrong. R's, John From johnl@iecc.com Tue Nov 27 19:42:25 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490F521F87B9 for ; Tue, 27 Nov 2012 19:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.42 X-Spam-Level: X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1vQan2InILN for ; Tue, 27 Nov 2012 19:42:23 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACD021F8748 for ; Tue, 27 Nov 2012 19:42:23 -0800 (PST) Received: (qmail 71478 invoked from network); 28 Nov 2012 03:42:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Nov 2012 03:42:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b5881d.xn--yuvv84g.k1211; i=johnl@user.iecc.com; bh=d4ikRZqedf+m+6EciiILNoPAvonjUXvXGuetBJxop4o=; b=Ho+qY3zZa0qM3EwVp/G7WI8VeR0LTqNi/OnBLUcV92Ql+sdgfTVREoZuXy69EHiYrYyVfMXZzCXs+1vVeTNjD4X4r3qr7+jDCtNShPLIj2Jl7LXvOSH0JVBo3gFdFrooUfJlFM4IBWPgoZAhTNbZhXZtY6G0bjLjb/KP6qz0pyY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b5881d.xn--yuvv84g.k1211; olt=johnl@user.iecc.com; bh=d4ikRZqedf+m+6EciiILNoPAvonjUXvXGuetBJxop4o=; b=vCwU7tov7/y/0DBkY22V9Mo9fvYhi6eApW6mxjHrSOPUoGSF5Ss5W6PiihzqeSiJtKNZlwiJWjjZRLRehIyBhfXnyMvBAVbB81r0zxhpjz96JucCr7KT20CY3Is6Lj0q5GW/+Jxlsi23cxIOMNrlKbhpcyLYso/sUr9zHSbQEGM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Nov 2012 03:41:58 -0000 Message-ID: <20121128034158.26842.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:42:25 -0000 >Section 3.1.1, federated authentication, seems to be an ill-fit in a requirements document. >The possible approaches are fine descriptions as far as they go, but, they aren't >requirements. It's not bad to place hold them here until there's a document detailing a >solution or a solution approach, but - well, they aren't requirements. I have to agree. I'd just say something like the design MUST NOT do anything to preclude federated authentication, e.g., credentials required to be tied to the specific server. > REQUIREMENT: RDAP MUST include an authorization framework that is > capable of providing granular (per registration data object) access > controls according to the policies of the operator. It seems to be an open question whether there will be a strict hierarchy of credentials, so a level N+1 password provides everything from level N plus other stuff, or whether there will be multiple baskets and each password will provide access to some group of baskets, or something else. I don't see any need to try to answer it here, because we can be sure that server operators will do whatever works for them. From andy@arin.net Wed Nov 28 05:18:05 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2918321F84BA for ; Wed, 28 Nov 2012 05:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFyNgX-iljOQ for ; Wed, 28 Nov 2012 05:18:04 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB821F8521 for ; Wed, 28 Nov 2012 05:18:04 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 1C52E213671; Wed, 28 Nov 2012 08:18:04 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 8D663213649; Wed, 28 Nov 2012 08:18:03 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 28 Nov 2012 08:17:24 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 08:17:59 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNy/p8YBQJ6lIvEEeQpZvwTNfYhZf8sdmAgAI70oCAAE/wgA== Date: Wed, 28 Nov 2012 13:17:58 +0000 Message-ID: In-Reply-To: <20121128033151.26459.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 13:18:05 -0000 On 11/27/12 10:31 PM, "John Levine" wrote: >Section 3: it looks to me like each URL can contain only one resource >type path segment. Are these wrong? If not, what do they mean? > >http://foo.example/weirds/ip/1.2.3.4/ip/2002::123 >http://foo.example/weirds/domain/bar.example/ip/2002::123 They are wrong. > >End of section 4: "Servers SHOULD ignore unrecognized path segments." > >What should a server do with these? > >http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2.3.0/24 If it understands custom_crud and the rest of that path looks correct, then answer the query. Otherwise send back a 400. >http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/fooble/parp This is just wrong. Send a 400. >Nit: top of page five, rather than "lowest IP network" say "smallest >IP network". A sufficiently perverse reader might interpret lowest IP >network to be the network with the lowest base address which is >exactly wrong. Agreed. -andy From ed.lewis@neustar.biz Wed Nov 28 06:04:55 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF321F8882 for ; Wed, 28 Nov 2012 06:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.019 X-Spam-Level: X-Spam-Status: No, score=-99.019 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz1BSxII1LSC for ; Wed, 28 Nov 2012 06:04:55 -0800 (PST) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0A621F8856 for ; Wed, 28 Nov 2012 06:04:48 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121128140447.PUFE8874.eastrmfepo103.cox.net@eastrmimpo209> for ; Wed, 28 Nov 2012 09:04:47 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id V24n1k00A3cuADQ0124nVK; Wed, 28 Nov 2012 09:04:47 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.50B619FF.0164,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=zj0LwYoATe4A:10 a=hGBaWAWWAAAA:8 a=oH__LpYN30IA:10 a=mieqlyhvMVUyMPL9P5YA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=1VjP1sAcLc09VgzMr_QA:9 a=_W_S_7VecoQA:10 a=SreGAitM1rTOlkdD:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6F8669AE-1AA4-4DE2-8454-1E1760FFB48C" From: Edward Lewis In-Reply-To: <20121128033151.26459.qmail@joyce.lan> Date: Wed, 28 Nov 2012 09:04:46 -0500 Message-Id: References: <20121128033151.26459.qmail@joyce.lan> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 14:04:55 -0000 --Apple-Mail=_6F8669AE-1AA4-4DE2-8454-1E1760FFB48C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 27, 2012, at 22:31, John Levine wrote: > Section 3: it looks to me like each URL can contain only one resource > type path segment.=20 I believe that is the intention. I say "believe" because I can't find = any requirement statement on this, but I do recall reading that the = intent was for a one-object query and response protocol. I'm not = claiming consensus on that belief, I mean to comment to ask if that is = the consensus. Technically, I doubt that we could accommodate multiple questions in a = query. If we did pipelining or otherwise piggybacking questions in a = query, we'd complicate the response language. (I.e., having an answer = for one object and a referral to another.) [Once again a lesson from = DNS: this is a design problem in DNS, the query can handle multiple = questions but the response can contain only one response code.] = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_6F8669AE-1AA4-4DE2-8454-1E1760FFB48C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Section= 3: it looks to me like each URL can contain only one resource
type = path segment. 

I believe that is = the intention.  I say "believe" because I can't find any = requirement statement on this, but I do recall reading that the intent = was for a one-object query and response protocol.  I'm not claiming = consensus on that belief, I mean to comment to ask if that is the = consensus.

Technically, I doubt that we could = accommodate multiple questions in a query.  If we did pipelining or = otherwise piggybacking questions in a query, we'd complicate the = response language.  (I.e., having an answer for one object and a = referral to another.)  [Once again a lesson from DNS: this is = a design problem in DNS, the query can handle multiple questions but the = response can contain only one response = code.]

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

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

= --Apple-Mail=_6F8669AE-1AA4-4DE2-8454-1E1760FFB48C-- From johnl@taugh.com Wed Nov 28 07:12:26 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFA721F8866 for ; Wed, 28 Nov 2012 07:12:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r611cwfifWF for ; Wed, 28 Nov 2012 07:12:19 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE421F885C for ; Wed, 28 Nov 2012 07:12:19 -0800 (PST) Received: (qmail 23647 invoked from network); 28 Nov 2012 15:12:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=5c5e.50b629d0.k1211; bh=m9k2vH2o6j9BuXn5pOIL+/sLQzj5QB6S/g/VlPf7qCU=; b=nF0ysVhXDa3zR27r+jIcgs+6Ad472T0KO3YulcJTsRV+Z5jRd0I9at0JCi9ZL1bolkPI0OHDoNqQYPsEhIENOI18SeTaQ0gruY1NsvU7S44jAme4tts1WnNE/vmS6S+ZO6dcHWSqYmWAhyYL6PVDtKiFcnaplTZDK3qVGOVaccw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=5c5e.50b629d0.k1211; bh=m9k2vH2o6j9BuXn5pOIL+/sLQzj5QB6S/g/VlPf7qCU=; b=MFSJC6S1qm/E2V41uIqqlse45cOKimYWbHl5iz+RaJlXYiC9DvbdE9P/u1IoDgAInBClOvuJQ/Yp6nr6Uqs/si0p79DoikXdHWmi2a6ghuBEOX3avz0MtWhtFrSGXd+D2pRkpcZNOBQkIiyxBTo9ISMVqsCJk93W2NzwjHZPyzI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 28 Nov 2012 15:11:54 -0000 Date: 28 Nov 2012 10:12:16 -0500 Message-ID: From: "John R Levine" To: "Andy Newton" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:12:26 -0000 Looks like we agree. Proposed text changes: Section 3 old: The base URL will be appended with resource type specific path segments. new: The base URL is followed by a resource type specific path segment. Section 4 old: Servers SHOULD ignore unrecognized path segments. new Servers MUST return an appropriate failure status code for a request with an unrecognized path segmenst. I say MUST because it's important for for interop that clients are able to tell reliably that a request hasn't worked. R's, John From shollenbeck@verisign.com Wed Nov 28 07:18:29 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6192F21F8470 for ; Wed, 28 Nov 2012 07:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI6poCyu9xWk for ; Wed, 28 Nov 2012 07:18:23 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id CE5A821F8625 for ; Wed, 28 Nov 2012 07:18:20 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKULYrPBrNlrZOV4UQ42Iq5yGiyhOoW+QY@postini.com; Wed, 28 Nov 2012 07:18:23 PST 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 qASFIH4S007614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 10:18:17 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 10:18:16 -0500 From: "Hollenbeck, Scott" To: John R Levine , Andy Newton Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNzRjnWfTFSGY+J06pXjL2TyCmWZf/jzEAgAAf7wD//63EcA== Date: Wed, 28 Nov 2012 15:18:16 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B5EB7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:18:29 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of John R Levine > Sent: Wednesday, November 28, 2012 10:12 AM > To: Andy Newton > Cc: weirds@ietf.org > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt >=20 > Looks like we agree. Proposed text changes: >=20 > Section 3 old: >=20 > The base URL will be appended with resource type specific path > segments. >=20 > new: >=20 > The base URL is followed by a resource type specific path segment. >=20 > Section 4 old: >=20 > Servers SHOULD ignore unrecognized path segments. >=20 > new >=20 > Servers MUST return an appropriate failure status code for > a request with an unrecognized path segmenst. >=20 > I say MUST because it's important for for interop that clients are able > to tell reliably that a request hasn't worked. I'm OK with these changes. Scott From andy@arin.net Wed Nov 28 07:53:33 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E33621F8908 for ; Wed, 28 Nov 2012 07:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF1QiVVo+mOO for ; Wed, 28 Nov 2012 07:53:32 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id A061421F8906 for ; Wed, 28 Nov 2012 07:53:32 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 2DDC81652FB; Wed, 28 Nov 2012 10:53:32 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 73E0F1652F8; Wed, 28 Nov 2012 10:53:31 -0500 (EST) 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.283.3; Wed, 28 Nov 2012 10:53:17 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 10:53:30 -0500 From: Andy Newton To: "Hollenbeck, Scott" , John R Levine Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNy/p8YBQJ6lIvEEeQpZvwTNfYhZf/jzEAgAAf7wD//63EcIAADCoA Date: Wed, 28 Nov 2012 15:53:29 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B5EB7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.35.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:53:33 -0000 On 11/28/12 10:18 AM, "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of John R Levine >> Sent: Wednesday, November 28, 2012 10:12 AM >> To: Andy Newton >> Cc: weirds@ietf.org >> Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt >>=20 >> Looks like we agree. Proposed text changes: >>=20 >> Section 3 old: >>=20 >> The base URL will be appended with resource type specific path >> segments. >>=20 >> new: >>=20 >> The base URL is followed by a resource type specific path segment. >>=20 >> Section 4 old: >>=20 >> Servers SHOULD ignore unrecognized path segments. >>=20 >> new >>=20 >> Servers MUST return an appropriate failure status code for >> a request with an unrecognized path segmenst. >>=20 >> I say MUST because it's important for for interop that clients are able >> to tell reliably that a request hasn't worked. > >I'm OK with these changes. +1 -andy From johnl@iecc.com Wed Nov 28 08:13:07 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572021F884A for ; Wed, 28 Nov 2012 08:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rR3JYWeRdhh for ; Wed, 28 Nov 2012 08:13:07 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D621F8849 for ; Wed, 28 Nov 2012 08:13:01 -0800 (PST) Received: (qmail 40986 invoked from network); 28 Nov 2012 16:13:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Nov 2012 16:13: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:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b6380c.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=5tWcqAz7Rhh1QPa17b5c/CkmqDgqnyCjP2uMyMPgo54=; b=OwIh6I2U7FStxcCdjuSzZCtoqkqiOP6CPGhFY3gwmQYw2FAVEzYIBAJbjKXnew8KDGEkHGV66klGGLIEUz6WYup0d8MdEBIOVbkKNS+5gGo7s7CQhnvMwzALZ9NCQnLTJgWJ1i+9BMjGbyXUNdJ8BZUSrRHufSie1PfO2DaQIDI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b6380c.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=5tWcqAz7Rhh1QPa17b5c/CkmqDgqnyCjP2uMyMPgo54=; b=tjHNv0wcSAM3dgKqlqZgKbxo8/3cU+yOo8/b5pa2DOYOWOqN1PDwUer2QfMOjFlJ1tTskRjk/9Mb7nb4y0JktqYADX9kewL8v5DO1su1YZVw7w5kgV3WUqpbHpkUtkcWXXd5naICdFz2OsNJzvvtzBinrSl7TqKzG9fLHxrs6RI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Nov 2012 16:12:38 -0000 Message-ID: <20121128161238.54846.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 16:13:07 -0000 >Technically, I doubt that we could accommodate multiple questions in a query. Pipelining already exists in http/1.1, send a series of requests, get a series of responses. I can't see any benefit in reinventing it inside WEIRDS. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ed.lewis@neustar.biz Wed Nov 28 08:31:04 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C8121F84B9 for ; Wed, 28 Nov 2012 08:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.149 X-Spam-Level: X-Spam-Status: No, score=-100.149 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkpkdpkgfyD7 for ; Wed, 28 Nov 2012 08:31:03 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEA21F849A for ; Wed, 28 Nov 2012 08:30:59 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121128163058.FFU5450.eastrmfepo201.cox.net@eastrmimpo210> for ; Wed, 28 Nov 2012 11:30:58 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id V4Wy1k00H3cuADQ014Wy7E; Wed, 28 Nov 2012 11:30:58 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.50B63C42.01C4,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=zj0LwYoATe4A:10 a=hGBaWAWWAAAA:8 a=oH__LpYN30IA:10 a=3DW5ysfuAAAA:8 a=HHdnZQ_pAAAA:8 a=48vgC7mUAAAA:8 a=40QKIquWZsGgVh9j1EUA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=2SAumGWBsQEA:10 a=lZB815dzVvQA:10 a=IimkFrUKJYIGFPUBzEMA:9 a=_W_S_7VecoQA:10 a=jT_7WPFansy3uz-p:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_71C86F9B-6FE0-4C6B-8279-1A8B0457303D" From: Edward Lewis In-Reply-To: <20121128161238.54846.qmail@joyce.lan> Date: Wed, 28 Nov 2012 11:30:58 -0500 Message-Id: <28561C4F-0C33-42ED-8DC5-CD35E8BCC530@neustar.biz> References: <20121128161238.54846.qmail@joyce.lan> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 16:31:04 -0000 --Apple-Mail=_71C86F9B-6FE0-4C6B-8279-1A8B0457303D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was referring to pipelining in the protocol under design. As in (from = the examples earlier in the thread): http://foo.example/weirds/ip/1.2.3.4/ip/2002::123 Would implicate pipelining a request for 1234, then 2002::123...yes, not = desired. If there's sublayer shenanigans going on, the documents can ignore them = - unless said shenanigans are a problem. On Nov 28, 2012, at 11:12, John Levine wrote: >> Technically, I doubt that we could accommodate multiple questions in = a query. >=20 > Pipelining already exists in http/1.1, send a series of requests, get > a series of responses. I can't see any benefit in reinventing it = inside > WEIRDS. >=20 > --=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = http://jl.ly > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_71C86F9B-6FE0-4C6B-8279-1A8B0457303D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://foo.exam= ple/weirds/ip/1.2.3.4/ip/2002::123

Wou= ld implicate pipelining a request for 1234, then 2002::123...yes, not = desired.

If there's sublayer shenanigans going = on, the documents can ignore them - unless said shenanigans are a = problem.

On Nov 28, 2012, at 11:12, John Levine = wrote:

Technically, I doubt that = we could accommodate multiple questions in a = query.

Pipelining already exists in http/1.1, send a = series of requests, get
a series of responses.  I can't see any = benefit in reinventing it inside
WEIRDS.

-- =
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator = of "The Internet for Dummies",
Please consider the environment before = reading this e-mail. http://jl.ly
________________________________= _______________
weirds mailing list
weirds@ietf.org
https://www.ietf.or= g/mailman/listinfo/weirds

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

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

= --Apple-Mail=_71C86F9B-6FE0-4C6B-8279-1A8B0457303D-- From johnl@iecc.com Wed Nov 28 11:07:02 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902AB21F883F for ; Wed, 28 Nov 2012 11:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=4.890, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB8G0SZ6mGrL for ; Wed, 28 Nov 2012 11:07:01 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 45FE621F86CC for ; Wed, 28 Nov 2012 11:07:00 -0800 (PST) Received: (qmail 96308 invoked from network); 28 Nov 2012 19:06:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Nov 2012 19:06:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b660d3.xn--30v786c.k1211; i=johnl@user.iecc.com; bh=q0dL59ySafmbMDHgUiJnq+W2zTfNMo6EUAeDn9+L3Zc=; b=siHfeeIGL3EH5bubBLf1TfRiFRNTJmD1y+S4k+7F1j2mqpaMgRHNCnAHghwKelhnCXb8smyaUW6kRL47jsVESI2Ukq0dgZUen7MPH08J+i76gbIr6cLWie4For27pHJbNxciQ586YEQSHatWotcxvw9rVrRrFwrsPq9tRCeS4NA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b660d3.xn--30v786c.k1211; olt=johnl@user.iecc.com; bh=q0dL59ySafmbMDHgUiJnq+W2zTfNMo6EUAeDn9+L3Zc=; b=VywB5eFjKA6tyfPctdd4yXSr24c3jbjDMj//H1h9KPKiEIDfDId/frOrow6wIiGheJGZVZ/WTBoPugJmtG6YzLLJpL7oTTBnZnIKxMSe/dFAB/t2GxurLOxtFpJaWZbFHJ6Gjw5SeQ5+ybWAADzl9CHsqfDqLxTXfPG6AvYdWwA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Nov 2012 19:06:37 -0000 Message-ID: <20121128190637.60726.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <28561C4F-0C33-42ED-8DC5-CD35E8BCC530@neustar.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:07:02 -0000 >I was referring to pipelining in the protocol under design. As in (from the examples earlier in the thread): > >http://foo.example/weirds/ip/1.2.3.4/ip/2002::123 > >Would implicate pipelining a request for 1234, then 2002::123...yes, not desired. I think we're agreeing. If a client wants to pipeline those two requests, it can use existing http/1.1 pipelining to send http://foo.example/weirds/ip/1.2.3.4 http://foo.example/weirds/ip/2002::123 and the server will pipeline the responses back as two separate HTTP responses. This already exists, libraries support it, nothing we need to do about it either way. From andy@arin.net Thu Nov 29 03:37:01 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957BC21F89B7 for ; Thu, 29 Nov 2012 03:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvI2GRK7Y1EC for ; Thu, 29 Nov 2012 03:37:00 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 3267921F89A2 for ; Thu, 29 Nov 2012 03:36:56 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 8E5FF165432; Thu, 29 Nov 2012 06:36:55 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 211D716542B for ; Thu, 29 Nov 2012 06:36:55 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 29 Nov 2012 06:36:06 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 06:36:44 -0500 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: a small proposal toward simplification Thread-Index: AQHNziXOLrSKvqMQYkaRQFNRevaW6A== Date: Thu, 29 Nov 2012 11:36:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 11:37:01 -0000 All, I have a small proposal to make our drafts a little more readable. Though we have a draft about JSON responses (draft-ietf-weirds-json-response) some might not be aware that there are JSON structures also in draft-ietf-weirds-using-http. This was done to accommodate a bifurcated response model where both JSON and XML are used. Since we are no longer talking about XML, I'd like to move the JSON naming rules and other JSON structures over to draft-ietf-weirds-json-response so readers will see it all in one place. The rules for compatibility with XML tag names will remain in case we want to bring XML back in the future. In my opinion, this makes our documents a bit easier to read and understand. What does everyone think of this? Comments? -andy From shollenbeck@verisign.com Thu Nov 29 04:09:03 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11821F89F7 for ; Thu, 29 Nov 2012 04:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG8NxMx+wR+a for ; Thu, 29 Nov 2012 04:09:03 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id D16F521F89E9 for ; Thu, 29 Nov 2012 04:09:01 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKULdQXbHKLMSP9Uq7ub72OuabDTWJMpT3@postini.com; Thu, 29 Nov 2012 04:09:02 PST 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 qATC8vjK002846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 07:08:58 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 07:08:57 -0500 From: "Hollenbeck, Scott" To: Andy Newton , "weirds@ietf.org" Thread-Topic: a small proposal toward simplification Thread-Index: AQHNziXOLrSKvqMQYkaRQFNRevaW6JgAt+rQ Date: Thu, 29 Nov 2012 12:08:56 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B6428@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 12:09:03 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Andy Newton > Sent: Thursday, November 29, 2012 6:37 AM > To: weirds@ietf.org > Subject: [weirds] a small proposal toward simplification >=20 > All, >=20 > I have a small proposal to make our drafts a little more readable. >=20 > Though we have a draft about JSON responses > (draft-ietf-weirds-json-response) some might not be aware that there > are JSON structures also in draft-ietf-weirds-using-http. This was done > to accommodate a bifurcated response model where both JSON and XML are > used. >=20 > Since we are no longer talking about XML, I'd like to move the JSON > naming rules and other JSON structures over to draft-ietf-weirds-json- > response so readers will see it all in one place. The rules for > compatibility with XML tag names will remain in case we want to bring > XML back in the future. >=20 > In my opinion, this makes our documents a bit easier to read and > understand. What does everyone think of this? Comments? I support this idea. It makes a lot of sense to have as much of the JSON-sp= ecific text in the response document and all of the HTTP-specific text (red= irects aside (at least for now)) in the HTTP document. Scott From aservin@lacnic.net Thu Nov 29 04:17:53 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3821F89D7 for ; Thu, 29 Nov 2012 04:17:53 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4wqGU5t-5bt for ; Thu, 29 Nov 2012 04:17:52 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4521F89E9 for ; Thu, 29 Nov 2012 04:17:52 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:6d72:153c:2023:90cb]) by mail.lacnic.net.uy (Postfix) with ESMTP id F4009308424; Thu, 29 Nov 2012 10:17:36 -0200 (UYST) Message-ID: <50B7525C.3080504@lacnic.net> Date: Thu, 29 Nov 2012 10:17:32 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F0D6B6428@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B6428@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "weirds@ietf.org" Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 12:17:53 -0000 I like the idea. It could simplify the documents. Regards, as On 29/11/2012 10:08, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On >> Behalf Of Andy Newton >> Sent: Thursday, November 29, 2012 6:37 AM >> To: weirds@ietf.org >> Subject: [weirds] a small proposal toward simplification >> >> All, >> >> I have a small proposal to make our drafts a little more readable. >> >> Though we have a draft about JSON responses >> (draft-ietf-weirds-json-response) some might not be aware that there >> are JSON structures also in draft-ietf-weirds-using-http. This was done >> to accommodate a bifurcated response model where both JSON and XML are >> used. >> >> Since we are no longer talking about XML, I'd like to move the JSON >> naming rules and other JSON structures over to draft-ietf-weirds-json- >> response so readers will see it all in one place. The rules for >> compatibility with XML tag names will remain in case we want to bring >> XML back in the future. >> >> In my opinion, this makes our documents a bit easier to read and >> understand. What does everyone think of this? Comments? > > I support this idea. It makes a lot of sense to have as much of the JSON-specific text in the response document and all of the HTTP-specific text (redirects aside (at least for now)) in the HTTP document. > > Scott > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From carlosm3011@gmail.com Thu Nov 29 06:01:56 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663CC21F89BA for ; Thu, 29 Nov 2012 06:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd0-LqV2AH3s for ; Thu, 29 Nov 2012 06:01:55 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E69B21F89B8 for ; Thu, 29 Nov 2012 06:01:51 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so1267646ggn.31 for ; Thu, 29 Nov 2012 06:01:51 -0800 (PST) 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=OHsRMWfU9O+5AkLVdp17iBUQFZ1Ws3vA9PWpjEj0PB0=; b=yyLYI7gWHli2HBPPeqcxQDAkUaumGvPXPluTo57KnCcZqus/ldubeY+QuUdini1X0w pybKXafRu0xkwOMv3h6PHf2EvPdc2N+TWhcsSI2SY06HLh7gKj1Vt43S8Xf9abEo1HvU IoLwlm2Kvh6cLXh5P/P5alZj5TiyNxprCboByqDggy1LDGEkhsWc3UETeB/A46leJVjQ 2dt5au9gqfWXyNFOL6xS5sMeV4TW3odXBhht+4TBMPzC1JL50eHIqXbfp43i1N3iUE9M y/emepXkzPfzeqP1pt5swkQc0qbC/2CFTzNpBO3Yl8AQEpKegjaA1DZ1jABVvmeJAq1j 9A7Q== Received: by 10.236.93.16 with SMTP id k16mr24077474yhf.51.1354197710937; Thu, 29 Nov 2012 06:01:50 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:5128:1923:eb24:fecd:331f? ([2001:13c7:7001:5128:1923:eb24:fecd:331f]) by mx.google.com with ESMTPS id u11sm1513987ane.11.2012.11.29.06.01.47 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 06:01:49 -0800 (PST) Message-ID: <50B76AC6.5080903@gmail.com> Date: Thu, 29 Nov 2012 12:01:42 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 14:01:56 -0000 I agree with Andy. On 11/29/2012 09:36 AM, Andy Newton wrote: > All, > > I have a small proposal to make our drafts a little more readable. > > Though we have a draft about JSON responses > (draft-ietf-weirds-json-response) some might not be aware that there are > JSON structures also in draft-ietf-weirds-using-http. This was done to > accommodate a bifurcated response model where both JSON and XML are used. > > Since we are no longer talking about XML, I'd like to move the JSON naming > rules and other JSON structures over to draft-ietf-weirds-json-response so > readers will see it all in one place. The rules for compatibility with XML > tag names will remain in case we want to bring XML back in the future. > > In my opinion, this makes our documents a bit easier to read and > understand. What does everyone think of this? Comments? > > -andy > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From ed.lewis@neustar.biz Thu Nov 29 07:19:43 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B0B21F8B36 for ; Thu, 29 Nov 2012 07:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.103 X-Spam-Level: X-Spam-Status: No, score=-99.103 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3n19Kfa3-xG for ; Thu, 29 Nov 2012 07:19:43 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id A17D521F8AAE for ; Thu, 29 Nov 2012 07:19:42 -0800 (PST) Received: from eastrmimpo110 ([68.230.241.223]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121129151942.LXSN5450.eastrmfepo201.cox.net@eastrmimpo110> for ; Thu, 29 Nov 2012 10:19:42 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo110 with cox id VTKg1k00h3cuADQ01TKhrh; Thu, 29 Nov 2012 10:19:41 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020206.50B77D0D.015F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=N5Wr5hBB c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=iUUaEdRVlz0A:10 a=hGBaWAWWAAAA:8 a=FCxuZFkPDZMA:10 a=48vgC7mUAAAA:8 a=vJS9GCTgpn8pZWbEXpQA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=rJKpLXxIrkekSeuCtJ4A:9 a=_W_S_7VecoQA:10 a=qLLmqc1S9zcvdZ8j:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C65449C-745C-4CFA-8250-C5B7BA124432" From: Edward Lewis In-Reply-To: Date: Thu, 29 Nov 2012 10:19:40 -0500 Message-Id: References: To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:19:44 -0000 --Apple-Mail=_1C65449C-745C-4CFA-8250-C5B7BA124432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It makes sense to put all of the response information into one place. I'd ask that the JSON document include text about why JSON is defined = (at this point) and not XML. The reason is that it'll be a natural = question. In as much as EPP and the protocol under development here are = unrelated, operators may see this a little differently at first. = Running an XML based protocol now, there might be some explanation = needed to say why the new one is not XML. (Yes, it's a decade later, = yadda, yadda, yadda, but the change ought to be rationalized in words.) On Nov 29, 2012, at 6:36, Andy Newton wrote: > All, >=20 > I have a small proposal to make our drafts a little more readable. >=20 > Though we have a draft about JSON responses > (draft-ietf-weirds-json-response) some might not be aware that there = are > JSON structures also in draft-ietf-weirds-using-http. This was done to > accommodate a bifurcated response model where both JSON and XML are = used. >=20 > Since we are no longer talking about XML, I'd like to move the JSON = naming > rules and other JSON structures over to = draft-ietf-weirds-json-response so > readers will see it all in one place. The rules for compatibility with = XML > tag names will remain in case we want to bring XML back in the future. >=20 > In my opinion, this makes our documents a bit easier to read and > understand. What does everyone think of this? Comments? >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_1C65449C-745C-4CFA-8250-C5B7BA124432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

I have a small proposal to make our = drafts a little more readable.

Though we have a draft about JSON = responses
(draft-ietf-weirds-json-response) some might not be aware = that there are
JSON structures also in draft-ietf-weirds-using-http. = This was done to
accommodate a bifurcated response model where both = JSON and XML are used.

Since we are no longer talking about XML, = I'd like to move the JSON naming
rules and other JSON structures over = to draft-ietf-weirds-json-response so
readers will see it all in one = place. The rules for compatibility with XML
tag names will remain in = case we want to bring XML back in the future.

In my opinion, this = makes our documents a bit easier to read and
understand. What does = everyone think of this? = Comments?

-andy

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

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

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

= --Apple-Mail=_1C65449C-745C-4CFA-8250-C5B7BA124432-- From andy@arin.net Thu Nov 29 07:30:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F321F887B for ; Thu, 29 Nov 2012 07:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iSBQHqHAFUx for ; Thu, 29 Nov 2012 07:30:19 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id DFD5D21F86E7 for ; Thu, 29 Nov 2012 07:30:18 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 73D98213694; Thu, 29 Nov 2012 10:30:18 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 5CA2B21367F; Thu, 29 Nov 2012 10:30:17 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 29 Nov 2012 10:29:25 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 10:30:04 -0500 From: Andy Newton To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] a small proposal toward simplification Thread-Index: AQHNziXOLrSKvqMQYkaRQFNRevaW6JgBQWwA//+vDwA= Date: Thu, 29 Nov 2012 15:30:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: multipart/alternative; boundary="_000_CCDCE99DF180andyarinnet_" MIME-Version: 1.0 Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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 Nov 2012 15:30:19 -0000 --_000_CCDCE99DF180andyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Edward Lewis > Date: Thursday, November 29, 2012 10:19 AM To: "weirds@ietf.org" > Cc: Edward Lewis > Subject: Re: [weirds] a small proposal toward simplification I'd ask that the JSON document include text about why JSON is defined (at t= his point) and not XML. The reason is that it'll be a natural question. I= n as much as EPP and the protocol under development here are unrelated, ope= rators may see this a little differently at first. Running an XML based pr= otocol now, there might be some explanation needed to say why the new one i= s not XML. (Yes, it's a decade later, yadda, yadda, yadda, but the change = ought to be rationalized in words.) We can do that. -andy --_000_CCDCE99DF180andyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: Edward Lewis <ed.lewis@neustar.biz>
Date: Thursday, November 29, 2012 1= 0:19 AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Cc: Edward Lewis <ed.lewis@neustar.biz>
Subject: Re: [weirds] a small propo= sal toward simplification

I'd ask that the JSON document include text about why JSON is defined (at this= point) and not XML.  The reason is that it'll be a natural question. =  In as much as EPP and the protocol under development here are unrelat= ed, operators may see this a little differently at first.  Running an XML based protocol now, there might be some exp= lanation needed to say why the new one is not XML.  (Yes, it's a decad= e later, yadda, yadda, yadda, but the change ought to be rationalized in wo= rds.)


We can do that.

-andy
--_000_CCDCE99DF180andyarinnet_-- From shollenbeck@verisign.com Thu Nov 29 12:43:19 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09621F8C42 for ; Thu, 29 Nov 2012 12:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S0Gf85fDAE8 for ; Thu, 29 Nov 2012 12:43:16 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32821F8C0A for ; Thu, 29 Nov 2012 12:43:15 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKULfI402fdIsGW6ShZ6Z3rsozucJEszwp@postini.com; Thu, 29 Nov 2012 12:43:16 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qATKhA4V013097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 15:43:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 15:43:10 -0500 From: "Hollenbeck, Scott" To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt Thread-Index: AQHNy/ueyDPWKBr6b0W0ZQ9xW2Q9JZf+Z4qAgALiKpA= Date: Thu, 29 Nov 2012 20:43:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6B693A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F0D6B693ABRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 20:43:19 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F0D6B693ABRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm going to ask Ning to talk to your comments on the federated authenticat= ion stuff in Item #2. I did some editing, but the spirit of the text is his= . We'll work together to rework it. Item #1, #4: Agreed, they can be reworded. Item #3: So you're suggesting that we should include some sort of capabilit= y in the protocol to identify roles? Enumerating roles always leads to some= that we miss, or that appear in the future, so I feel much better about le= aving the responsibility of defining access controls to the server operator= . Item #5: Comments like this are always a little vexing. We've already estab= lished that we're using HTTP, so do we _really_ need to also state that we'= ve got TCP and stream-based transport? Scott From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of= Edward Lewis Sent: Tuesday, November 27, 2012 2:32 PM To: weirds@ietf.org Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt Comments on: On Nov 26, 2012, at 12:29, > > wro= te: Title : Security Services for the Registration Data Acc= ess Protocol Author(s) : Scott Hollenbeck Ning Kong Filename : draft-ietf-weirds-rdap-sec-01.txt Item #1 This section 3.1 requirement isn't testable: REQUIREMENT: The RDAP authentication framework MUST be capable of supporting future authentication methods defined for use with HTTP. In the sense that we can't know the future... I wonder if there is another way to write this. I'm taking a pot shot here= in case I'm misinterpreting something... The RDAP authentication framework MUST conform with the authentication meth= ods and approach in use by HTTP in order to anticipate future improvements = to HTTP authentication methods. Item #2 Section 3.1.1, federated authentication, seems to be an ill-fit in a requir= ements document. The possible approaches are fine descriptions as far as t= hey go, but, they aren't requirements. It's not bad to place hold them her= e until there's a document detailing a solution or a solution approach, but= - well, they aren't requirements. But it's the requirement that is there that seems flakey. I understand the= utility of a federated authentication model but don't see how it is german= e to the definition of this protocol. I mean - authentication is merely th= e task of proving I am who I claim to be. If this is done via a trusted th= ird party that is trusted by many servers (in the sense that there are clie= nts, servers and third parties), that is fine. It's a good discussion to have, but I don't see it as a requirement. I can= see 3.1.1. being labeled as a note on how to build the authentication syst= em. Item #3 In 3.2: REQUIREMENT: RDAP MUST include an authorization framework that is capable of providing granular (per registration data object) access controls according to the policies of the operator. The granularity probably ought to be extended to the other side of the tabl= e - the actors. I.e., per actor, not just per class of actor. This is a s= uggestion, perhaps there's only a need for "anonymous" and "privileged" but= I can see the latter quickly being subdivided into "law enforcement in the= jurisdiction" and "sponsoring registrar" and "this registrant" classes...j= ust to thrown down examples. Item #4 In 3.4, another "future" requirement: REQUIREMENT: RDAP MUST be capable of supporting future data confidentiality methods defined for use with HTTP. Perhaps what is needed is "sticking with the plan" so to speak of HTTP. Item #5 Maybe it's just me...but when I think of security concerns there are lower-= in-the-stack problems like message insertion and forgery. Those things not= a concern in here because we assume a transport better than unreliable dat= agram. Perhaps it would be good to state the "floor" assumption that there= 's a stream based transport (TCP) and more involved. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --_000_831693C2CDA2E849A7D7A712B24E257F0D6B693ABRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m going to ask Ni= ng to talk to your comments on the federated authentication stuff in Item #= 2. I did some editing, but the spirit of the text is his. We’ll work together to rework it.

 <= /p>

Item #1, #4: Agreed, they= can be reworded.

 <= /p>

Item #3: So you’re = suggesting that we should include some sort of capability in the protocol t= o identify roles? Enumerating roles always leads to some that we miss, or that appear in the future, so I feel much better about leaving= the responsibility of defining access controls to the server operator.

 <= /p>

Item #5: Comments like th= is are always a little vexing. We’ve already established that we̵= 7;re using HTTP, so do we _really_ need to also state that we’= ve got TCP and stream-based transport?

 <= /p>

Scott

 <= /p>

From: weirds-b= ounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Edward Lewis
Sent: Tuesday, November 27, 2012 2:32 PM
To: weirds@ietf.org
Cc: Edward Lewis
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt<= o:p>

 

Comments on:

 

On Nov 26, 2012, at 12:29, <internet-drafts@ietf.org> <internet-drafts@ietf.org> wrote:

   &nb= sp;      Title     &nbs= p;     : Security Services for the Registration Da= ta Access Protocol
       &n= bsp;  Author(s)   : Scott Hollenbeck
                     = ;       Ning Kong
       &n= bsp;  Filename   : draft-ietf-weirds-rdap-sec-01.txt<= /o:p>

 

Item #1

 

This section 3.1 requirement isn't testable:

 

   RE=
QUIREMENT: The RDAP authentication framework MUST be capable of<=
/span>
   supporting future authenticat=
ion methods defined for use with HTTP.

In the sense that we can't know the future...

 

I wonder if there is another way to write this. &nbs= p;I'm taking a pot shot here in case I'm misinterpreting something...<= /o:p>

 

The RDAP authentication framework MUST conform with = the authentication methods and approach in use by HTTP in order to anticipa= te future improvements to HTTP authentication methods.

 

Item #2

 

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

 

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

 

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

 

Item #3

 

In 3.2:

 

   RE=
QUIREMENT: RDAP MUST include an authorization framework that is<=
/span>
   capable of providing granular=
 (per registration data object) access
   controls according to the pol=
icies of the operator.

 

The granularity probably ought to be extended to the= other side of the table - the actors.  I.e., per actor, not just per = class of actor.  This is a suggestion, perhaps there's only a need for= "anonymous" and "privileged" but I can see the latter quickly being subdivided into "law enforcement in the juri= sdiction" and "sponsoring registrar" and "this registra= nt" classes...just to thrown down examples.

 

Item #4

 

In 3.4, another "future" requirement:=

 

   RE=
QUIREMENT: RDAP MUST be capable of supporting future data=

   confidentiality methods defin=
ed for use with HTTP.

Perhaps what is needed is "sticking with the pl= an" so to speak of HTTP.

 

Item #5

 

Maybe it's just me...but when I think of security co= ncerns there are lower-in-the-stack problems like message insertion and for= gery.  Those things not a concern in here because we assume a transpor= t better than unreliable datagram.  Perhaps it would be good to state the "floor" assumption that there's a = stream based transport (TCP) and more involved.

 

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-

Edward Lewis      &nbs= p;      
NeuStar           &n= bsp;        You can leave a voice messag= e at +1-571-434-5468

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

 

--_000_831693C2CDA2E849A7D7A712B24E257F0D6B693ABRN1WNEXMBX01vc_-- From ed.lewis@neustar.biz Thu Nov 29 13:27:36 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7921F8C22 for ; Thu, 29 Nov 2012 13:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.258 X-Spam-Level: X-Spam-Status: No, score=-100.258 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQElm8qWxV5x for ; Thu, 29 Nov 2012 13:27:34 -0800 (PST) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7A21F8BF0 for ; Thu, 29 Nov 2012 13:27:34 -0800 (PST) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121129212731.WQSS6475.eastrmfepo202.cox.net@eastrmimpo109> for ; Thu, 29 Nov 2012 16:27:31 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo109 with cox id VZTW1k00S3cuADQ01ZTWuD; Thu, 29 Nov 2012 16:27:31 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020A.50B7D343.00C8,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=EM+EIilC c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=WQbcPEAUyV4A:10 a=hGBaWAWWAAAA:8 a=itrjNh4ZBAIA:10 a=48vgC7mUAAAA:8 a=yffwy6eimctfEIcgticA:9 a=pILNOxqGKmIA:10 a=9k6G2--EmesA:10 a=lZB815dzVvQA:10 a=h43zgKdQg3N_UQbY:21 a=STbsxYiim5YDN292:21 a=x5m0CNlrNLsfqFROEzYA:9 a=_W_S_7VecoQA:10 a=l80WKgs1dX0r9Z3s:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_65515755-A6C6-4E12-8C10-798DAE8E051F" From: Edward Lewis In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D6B693A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 29 Nov 2012 16:27:30 -0500 Message-Id: <604489EB-3A86-4E95-9506-9846C5E86750@neustar.biz> References: <20121126172923.31777.44765.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F0D6B693A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:27:36 -0000 --Apple-Mail=_65515755-A6C6-4E12-8C10-798DAE8E051F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Regarding #3 - no, no need to try to identify the roles (via = enumeration), just state that I should be able to say per object what = can be seen per role. E.g., ARIN might allow DMRs to see who is the registered DMR of another = organization, whereas this would be not applicable to the = non-member-having .com registry. The requirement should give the = capability to ARIN to designate per object what members could see, what = a law enforcement agent (*) could see, etc (* - who/what is a law = enforcement agent aside, I'm just using that as the example most often = tossed around) Regarding #5 - from the charter: The framework shall be for data to be delivered via a RESTful data service using HTTP (optionally using TLS), and may use standard features of HTTP to support differential service levels to different classes of user. That's in the charter, I guess where I am missing the boat is that I = don't see where the security draft says that the protocol will use HTTP. = I know that sounds stupid, but I see statements like "available to = existing HTTP clients and servers" and "Web services commonly use HTTP = Over TLS" in the draft, but never an explicit "this protocol will run = over HTTP." I kept taking the statements as a comparison, not as an = indication this protocol will be over HTTP too. I guess I just never = found the "smoking gun" statement that this protocol will only ever = exist over HTTP. (Maybe it's in the two drafts in section 1.) Maybe in Section 3: RDAP itself does not include native security services. Instead, RDAP relies on features that are available in other protocol layers to provide needed security services including authentication, authorization, availability, and data confidentiality. =20 This is where it should be mentioned that RDAP will assume all of the = security 'features' of HTTP(S), which rules out the stuff I'm generally = afraid of (thanks to work with UDP-based protocols). On Nov 29, 2012, at 15:43, Hollenbeck, Scott wrote: > I=92m going to ask Ning to talk to your comments on the federated = authentication stuff in Item #2. I did some editing, but the spirit of = the text is his. We=92ll work together to rework it. > =20 > Item #1, #4: Agreed, they can be reworded. > =20 > Item #3: So you=92re suggesting that we should include some sort of = capability in the protocol to identify roles? Enumerating roles always = leads to some that we miss, or that appear in the future, so I feel much = better about leaving the responsibility of defining access controls to = the server operator. > =20 > Item #5: Comments like this are always a little vexing. We=92ve = already established that we=92re using HTTP, so do we _really_ need to = also state that we=92ve got TCP and stream-based transport? > =20 > Scott > =20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On = Behalf Of Edward Lewis > Sent: Tuesday, November 27, 2012 2:32 PM > To: weirds@ietf.org > Cc: Edward Lewis > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt > =20 > Comments on: > =20 > On Nov 26, 2012, at 12:29, = wrote: > Title : Security Services for the Registration = Data Access Protocol > Author(s) : Scott Hollenbeck > Ning Kong > Filename : draft-ietf-weirds-rdap-sec-01.txt > =20 > Item #1 > =20 > This section 3.1 requirement isn't testable: > =20 > REQUIREMENT: The RDAP authentication framework MUST be capable of > supporting future authentication methods defined for use with HTTP. > In the sense that we can't know the future... > =20 > I wonder if there is another way to write this. I'm taking a pot shot = here in case I'm misinterpreting something... > =20 > The RDAP authentication framework MUST conform with the authentication = methods and approach in use by HTTP in order to anticipate future = improvements to HTTP authentication methods. > =20 > Item #2 > =20 > Section 3.1.1, federated authentication, seems to be an ill-fit in a = requirements document. The possible approaches are fine descriptions as = far as they go, but, they aren't requirements. It's not bad to place = hold them here until there's a document detailing a solution or a = solution approach, but - well, they aren't requirements. > =20 > But it's the requirement that is there that seems flakey. I = understand the utility of a federated authentication model but don't see = how it is germane to the definition of this protocol. I mean - = authentication is merely the task of proving I am who I claim to be. If = this is done via a trusted third party that is trusted by many servers = (in the sense that there are clients, servers and third parties), that = is fine. > =20 > It's a good discussion to have, but I don't see it as a requirement. = I can see 3.1.1. being labeled as a note on how to build the = authentication system. > =20 > Item #3 > =20 > In 3.2: > =20 > REQUIREMENT: RDAP MUST include an authorization framework that is > capable of providing granular (per registration data object) access > controls according to the policies of the operator. > =20 > The granularity probably ought to be extended to the other side of the = table - the actors. I.e., per actor, not just per class of actor. This = is a suggestion, perhaps there's only a need for "anonymous" and = "privileged" but I can see the latter quickly being subdivided into "law = enforcement in the jurisdiction" and "sponsoring registrar" and "this = registrant" classes...just to thrown down examples. > =20 > Item #4 > =20 > In 3.4, another "future" requirement: > =20 > REQUIREMENT: RDAP MUST be capable of supporting future data > confidentiality methods defined for use with HTTP. > Perhaps what is needed is "sticking with the plan" so to speak of = HTTP. > =20 > Item #5 > =20 > Maybe it's just me...but when I think of security concerns there are = lower-in-the-stack problems like message insertion and forgery. Those = things not a concern in here because we assume a transport better than = unreliable datagram. Perhaps it would be good to state the "floor" = assumption that there's a stream based transport (TCP) and more = involved. > =20 > = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis =20 > NeuStar You can leave a voice message at = +1-571-434-5468 >=20 > There are no answers - just tradeoffs, decisions, and responses. > =20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_65515755-A6C6-4E12-8C10-798DAE8E051F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The framework shall be for data to be = delivered via a RESTful data service using HTTP (optionally using TLS), and may use standard features of HTTP to support differential service levels to different classes of user.

That's in the = charter, I guess where I am missing the boat is that I don't see where = the security draft says that the protocol will use HTTP.   I know = that sounds stupid, but I see statements like "available to existing HTTP clients and servers" = and "Web services commonly use HTTP Over TLS" in the draft, but never an explicit = "this protocol will run over HTTP."  I kept taking the statements = as a comparison, not as an indication this protocol will be over HTTP = too.  I guess I just never found the "smoking gun" statement that = this protocol will only ever exist over HTTP.  (Maybe it's in the = two drafts in section 1.)

Maybe in Section = 3:
RDAP itself does not =
include native security services.  Instead, RDAP
   relies on features that are available in other protocol layers to
   provide needed security services including authentication,
   authorization, availability, and data confidentiality.  =
This is where it should be mentioned that RDAP will assume = all of the security 'features' of HTTP(S), which rules out the stuff I'm = generally afraid of (thanks to work with UDP-based = protocols).

On Nov 29, 2012, at 15:43, = Hollenbeck, Scott wrote:

I=92m = going to ask Ning to talk to your comments on the federated = authentication stuff in Item #2. I did some editing, but the spirit of = the text is his. We=92ll work together to rework = it.
Item = #1, #4: Agreed, they can be reworded.
Item = #3: So you=92re suggesting that we should include some sort of = capability in the protocol to identify roles? Enumerating roles always = leads to some that we miss, or that appear in the future, so I feel much = better about leaving the responsibility of defining access controls to = the server operator.
 
Item #5: Comments like this are = always a little vexing. We=92ve already established that we=92re using = HTTP, so do we _really_ need to also state that we=92ve got TCP = and stream-based transport?
 weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.o= rg] On Behalf = Of Edward = Lewis
Sent: Tuesday, November 27, 2012 = 2:32 PM
To: weirds@ietf.org
Cc: Edward = Lewis
Subject: Re: [weirds] I-D Action: = draft-ietf-weirds-rdap-sec-01.txt
 
Comments = on:
On Nov 26, 2012, at = 12:29, <internet-drafts@ietf.org> = <internet-drafts@ietf.org> = wrote:
        &= nbsp; Title =           : Security = Services for the Registration Data Access Protocol
        &= nbsp; Author(s) =   : Scott Hollenbeck
            =                 Ning = Kong
        &= nbsp; Filename =   : = draft-ietf-weirds-rdap-sec-01.txt
 
Item #1
 
This section 3.1 requirement isn't = testable:
   REQUIREMENT: The RDAP = authentication framework MUST be capable of
   supporting future =
authentication methods defined for use with =
HTTP.
In the sense that we = can't know the future...
 
I wonder if there is another way to write this. =  I'm taking a pot shot here in case I'm misinterpreting = something...
The RDAP authentication = framework MUST conform with the authentication methods and approach in = use by HTTP in order to anticipate future improvements to HTTP = authentication methods.
 
Item #2
 
Section 3.1.1, federated authentication, seems to be an = ill-fit in a requirements document.  The possible approaches are = fine descriptions as far as they go, but, they aren't requirements. =  It's not bad to place hold them here until there's a document = detailing a solution or a solution approach, but - well, they aren't = requirements.
But it's the requirement = that is there that seems flakey.  I understand the utility of a = federated authentication model but don't see how it is germane to the = definition of this protocol.  I mean - authentication is merely the = task of proving I am who I claim to be.  If this is done via a = trusted third party that is trusted by many servers (in the sense that = there are clients, servers and third parties), that is = fine.
It's a good discussion to = have, but I don't see it as a requirement.  I can see 3.1.1. being = labeled as a note on how to build the authentication = system.
Item = #3
In = 3.2:
   REQUIREMENT: RDAP MUST = include an authorization framework that is
   capable of providing =
granular (per registration data object) =
access
The granularity probably =
ought to be extended to the other side of the table - the actors. =
 I.e., per actor, not just per class of actor.  This is a =
suggestion, perhaps there's only a need for "anonymous" and "privileged" =
but I can see the latter quickly being subdivided into "law enforcement =
in the jurisdiction" and "sponsoring registrar" and "this registrant" =
classes...just to thrown down examples.
 
Item #4
 
In 3.4, another "future" = requirement:
   REQUIREMENT: RDAP MUST be = capable of supporting future data
   confidentiality methods =
defined for use with HTTP.
Perhaps what is needed is "sticking with the plan" so = to speak of HTTP.
Item = #5
Maybe it's just me...but = when I think of security concerns there are lower-in-the-stack problems = like message insertion and forgery.  Those things not a concern in = here because we assume a transport better than unreliable datagram. =  Perhaps it would be good to state the "floor" assumption that = there's a stream based transport (TCP) and more = involved.
Edward = Lewis           &nb= sp; 
NeuStar         =            You can = leave a voice message at +1-571-434-5468

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

= --Apple-Mail=_65515755-A6C6-4E12-8C10-798DAE8E051F-- From andy@arin.net Thu Nov 29 14:04:16 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E420221F8C54 for ; Thu, 29 Nov 2012 14:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KypF7suvQdyU for ; Thu, 29 Nov 2012 14:04:11 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BB9FD21F8C0C for ; Thu, 29 Nov 2012 14:04:11 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 0E62C1655A8; Thu, 29 Nov 2012 17:04:07 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 72D9B1655A6; Thu, 29 Nov 2012 17:04:06 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 29 Nov 2012 17:03:24 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.124]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 17:04:04 -0500 From: Andy Newton To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt Thread-Index: AQHNy/ue0ySkZYbtl0G2HbUkNxHryZf+Z4qAgAM4mQCAAAxjAP//tmCA Date: Thu, 29 Nov 2012 22:04:04 +0000 Message-ID: In-Reply-To: <604489EB-3A86-4E95-9506-9846C5E86750@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.34.130] Content-Type: multipart/alternative; boundary="_000_CCDD45E7F222andyarinnet_" MIME-Version: 1.0 Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:04:17 -0000 --_000_CCDD45E7F222andyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Edward Lewis > Date: Thursday, November 29, 2012 4:27 PM To: "weirds@ietf.org" > Cc: Edward Lewis > Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt E.g., ARIN might allow DMRs to see who is the registered DMR of another org= anization Just for everyone's clarity, this is not a real use case. :) -andy --_000_CCDD45E7F222andyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
From: Edward Lewis <ed.lewis@neustar.biz>
Date: Thursday, November 29, 2012 4= :27 PM
To: "weirds@ietf.org" <= weirds@ietf.org>
Cc: Edward Lewis <ed.lewis@neustar.biz>
Subject: Re: [weirds] I-D Action: d= raft-ietf-weirds-rdap-sec-01.txt

E.g., ARIN might allow DMRs to see who is the registered DMR of another organiza= tion

Just for everyone's clarity, this is not a real use case. :)

-andy
--_000_CCDD45E7F222andyarinnet_-- From superuser@gmail.com Thu Nov 29 16:12:38 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A321F8AA1 for ; Thu, 29 Nov 2012 16:12:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjxyW-yb46+U for ; Thu, 29 Nov 2012 16:12:38 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6421F8AA0 for ; Thu, 29 Nov 2012 16:12:37 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so38177lbk.31 for ; Thu, 29 Nov 2012 16:12:37 -0800 (PST) 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=DP6rpXVvuZOZyirgwfvav+nol0b1hlnB3PgpW9OOVCo=; b=lsgZfVceo5c7l6FBTjbVesNWbdMfSvEHJoWeUZWiA1mnU7+CopkNXgkfZUI/6G2BXd bIVxek+H0uBMoKAvX6svI8pxbr1SK9haCo8GHSJk/p4gCVHYLn/3EDf6PpEoCD6fZNBV yQmI6vfFcDrgeyCJaw39q3BhVPcwG0dFx7OqFpiAav1bfDazIOPvO3SIVf1AxNXrT+3q Hd5r1fKWm8ZLeGVgs4awAFxdik41ueydsZoSDYO5itkSy92+b/5gwd8wD/+TT3JiBnee Ws8FT4ozAOe6/sSbzI02Cla6R25nuqEsnuYEy758MrmoiTds2921yhJryQucwLQcQfw3 KxfQ== MIME-Version: 1.0 Received: by 10.152.105.33 with SMTP id gj1mr23423504lab.49.1354234356890; Thu, 29 Nov 2012 16:12:36 -0800 (PST) Received: by 10.112.61.67 with HTTP; Thu, 29 Nov 2012 16:12:36 -0800 (PST) In-Reply-To: <20121128033151.26459.qmail@joyce.lan> References: <831693C2CDA2E849A7D7A712B24E257F0D6B3D95@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20121128033151.26459.qmail@joyce.lan> Date: Thu, 29 Nov 2012 16:12:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d040716e3c8fddd04cfab4104 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 00:12:38 -0000 --f46d040716e3c8fddd04cfab4104 Content-Type: text/plain; charset=ISO-8859-1 What's missing for the names case? On Tue, Nov 27, 2012 at 7:31 PM, John Levine wrote: > I agree this is mostly done, at least for RIRs, except for the > crufty bits around the edges. > > Section 3: it looks to me like each URL can contain only one resource > type path segment. Are these wrong? If not, what do they mean? > > http://foo.example/weirds/ip/1.2.3.4/ip/2002::123 > http://foo.example/weirds/domain/bar.example/ip/2002::123 > > End of section 4: "Servers SHOULD ignore unrecognized path segments." > > What should a server do with these? > > http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2.3.0/24 > http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/fooble/parp > > Since a path segment can contain a variable number of slashes, how can > a server do anything but fail the entire request, since it can't tell > where to start looking for the next segment? > > Nit: top of page five, rather than "lowest IP network" say "smallest > IP network". A sufficiently perverse reader might interpret lowest IP > network to be the network with the lowest base address which is > exactly wrong. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --f46d040716e3c8fddd04cfab4104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What's missing for the names case?

On Tue, Nov 27, 2012 at 7:31 PM, John Levine <= span dir=3D"ltr"><j= ohnl@taugh.com> wrote:
I agree this is mostly done, at least for RI= Rs, except for the
crufty bits around the edges.

Section 3: it looks to me like each URL can contain only one resource
type path segment. Are these wrong? =A0If not, what do they mean?

http://foo.example/weirds/ip/1.2.3.4/ip/2002::123
http://foo.example/weirds/domain/bar.example/ip/2002::123<= br>
End of section 4: "Servers SHOULD ignore unrecognized path segments.&q= uot;

What should a server do with these?

http://foo.example/weirds/custom_crud/fooble/parp/ip/1.2= .3.0/24
http://foo.example/weirds/ip/1.2.3.0/24/custom_crud/foob= le/parp

Since a path segment can contain a variable number of slashes, how can
a server do anything but fail the entire request, since it can't tell where to start looking for the next segment?

Nit: top of page five, rather than "lowest IP network" say "= smallest
IP network". =A0A sufficiently perverse reader might interpret lowest = IP
network to be the network with the lowest base address which is
exactly wrong.

R's,
John
___________________________________= ____________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--f46d040716e3c8fddd04cfab4104-- From johnl@taugh.com Thu Nov 29 17:27:58 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E050B21F8A13 for ; Thu, 29 Nov 2012 17:27:58 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzknsZmAu0JB for ; Thu, 29 Nov 2012 17:27:58 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DB0F021F8A04 for ; Thu, 29 Nov 2012 17:27:57 -0800 (PST) Received: (qmail 29419 invoked from network); 30 Nov 2012 01:27:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=72e8.50b80b9a.k1211; bh=M/hEribEjhsoBBoEMqIB+uQfFkT/+B1la3QpW+uh5dA=; b=zyV5WWZZZIRScKnRxKdbtce/1z4VAABdaQjZskEfNt6oT9oEQOj9uoU3hgGfZpgqpDR5MFogNxlnQmxDQT6JRcCnkezxVdS3mxD5oj9FEdAVj69vvhG4iULrB8zSMMk5sMwWA5NYe62IjYNQDxpUJSc4DBcwZH/FY3cXQEElUxI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=72e8.50b80b9a.k1211; bh=M/hEribEjhsoBBoEMqIB+uQfFkT/+B1la3QpW+uh5dA=; b=hRi3ONyjexW6ZnuqVNnwrHzoUZHrAxx1JpifnZm/KyUx2ilhxos+oKoXn3VuVxGujvt92A7T/m5/8EgyKvCSlwAxxn5w1fFveuOT/Dd6MMrYKIa0JhEERyd0G2WiOZMfjzb/CabsXivrobLiDYcCywlN6x/3eIHHXkDvS4XP3TY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 30 Nov 2012 01:27:32 -0000 Date: 29 Nov 2012 20:27:54 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <831693C2CDA2E849A7D7A712B24E257F0D6B3D95@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20121128033151.26459.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] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 01:27:59 -0000 > What's missing for the names case? The short answer is that nobody knows, since different TLDs accept varying sets of queries, and ICANN has a process going on where they're trying to figure out what else people want for WHOIS in the new TLDs. Some whois servers accept wildcards for some or all queries, some don't, most provide for search by registrar and full vs. summary reports. Here's the specs for WHOIS for the ICANN contracted TLDs. Often the language is almost but not quite the same from one TLD to the next. http://www.icann.org/en/about/agreements/registries/aero/aero-appendix-5-11jun09-en.htm http://www.icann.org/en/about/agreements/registries/asia/appendix-s-06dec06-en.htm#6 http://www.icann.org/en/about/agreements/registries/biz/appendix-05-08dec06-en.htm http://www.icann.org/en/about/agreements/registries/cat/cat-appendixs-22mar06-en.htm (part vi) http://www.icann.org/en/about/agreements/registries/verisign/appendix-05-01mar06-en.htm http://www.icann.org/en/about/agreements/registries/coop/appendix-s-01jul07-en.htm#part5 http://www.icann.org/en/about/agreements/registries/info/appendix-05-08dec06-en.htm http://www.icann.org/en/about/agreements/registries/jobs/appendix-s-06aug10-en.htm#Part6 http://www.icann.org/en/about/agreements/registries/mobi/mobi-appendixs-23nov05-en.htm (part 6) http://www.icann.org/en/about/agreements/registries/museum/appendix-05-03nov07-en.htm http://www.icann.org/en/about/agreements/registries/name/appendix-05-15aug07-en.htm http://www.icann.org/en/about/agreements/registries/net/appendix-5-01jul11-en.htm http://www.icann.org/en/about/agreements/registries/org/appendix-05-08dec06-en.htm http://www.icann.org/en/about/agreements/registries/post/post-appendix-s-11dec09-en.htm (part VI) http://www.icann.org/en/about/agreements/registries/pro/pro-appendix-5-22apr10-en.htm http://www.icann.org/en/about/agreements/registries/tel/appendix-s-02feb11-en.htm#Part6 http://www.icann.org/en/about/agreements/registries/travel/travel-appendix-s-12apr06-en.htm#part6 http://www.icann.org/en/about/agreements/registries/xxx/appendix-s-31mar11-en.htm (part 6) The ccTLDs have their own requirements, as does IANA for the TLDs it manages (arpa and int). This is one of the reasons why I pushed back so hard against coupling the numbers and names WEIRDS designs. The people who want names need to figure this out and come up with at least an approximate set of query types and terms, but I haven't seen much progress in that regard. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From bje@apnic.net Thu Nov 29 22:52:11 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52821F88E9 for ; Thu, 29 Nov 2012 22:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0BDoOkzkemH for ; Thu, 29 Nov 2012 22:52:11 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id A98C921F88C5 for ; Thu, 29 Nov 2012 22:52:09 -0800 (PST) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 30 Nov 2012 16:52:05 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Fri, 30 Nov 2012 16:52:05 +1000 From: Byron Ellacott To: Andy Newton , "weirds@ietf.org" Thread-Topic: [weirds] a small proposal toward simplification Thread-Index: AQHNziXOLrSKvqMQYkaRQFNRevaW6JgB8heA Date: Fri, 30 Nov 2012 06:52:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.188] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] a small proposal toward simplification X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 Nov 2012 06:52:11 -0000 On 29/11/12 9:36 PM, "Andy Newton" wrote: >Since we are no longer talking about XML, I'd like to move the JSON naming >rules and other JSON structures over to draft-ietf-weirds-json-response so >readers will see it all in one place. The rules for compatibility with XML >tag names will remain in case we want to bring XML back in the future. I support this. There's no reason any more to have the response contents in the http draft. Byron From bje@apnic.net Thu Nov 29 23:26:15 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0C21F843A for ; Thu, 29 Nov 2012 23:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDasem8xUvgT for ; Thu, 29 Nov 2012 23:26:14 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 1312121F8438 for ; Thu, 29 Nov 2012 23:26:13 -0800 (PST) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 30 Nov 2012 17:24:51 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Fri, 30 Nov 2012 17:25:58 +1000 From: Byron Ellacott To: John R Levine Thread-Topic: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt Thread-Index: AQHNy/p7HgDYvBFM50mo0Eqr55Nrxpf7tmSAgAI70oCAAuz+AIAAFQoAgAELpIA= Date: Fri, 30 Nov 2012 07:25:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.188] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-query-01.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 07:26:15 -0000 Hi John, On 30/11/12 11:27 AM, "John R Levine" wrote: >> What's missing for the names case? > >The short answer is that nobody knows, since different TLDs accept >varying=20 >sets of queries, and ICANN has a process going on where they're trying to >figure out what else people want for WHOIS in the new TLDs. Some whois >servers accept wildcards for some or all queries, some don't, most >provide=20 >for search by registrar and full vs. summary reports. The current drafts only provide for lookups, not searches; this isn't part of the charter, but I do seem to recall that it was discussed at some point with an agreement at the time that searches should come later. It's a useful simplification, since even in the numbers world the possible search terms and query modes widen up quite dramatically when you move away from simple lookup. >This is one of the reasons why I pushed back so hard against coupling the >numbers and names WEIRDS designs. The people who want names need to >figure this out and come up with at least an approximate set of query >types and terms, but I haven't seen much progress in that regard. http://tools.ietf.org/html/draft-zhou-weirds-dnrd-ap-object-inventory is a decent effort at the lookup side of this, by identifying the result terms and by implication the object types. Byron From ed.lewis@neustar.biz Fri Nov 30 06:11:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807D21F85C0 for ; Fri, 30 Nov 2012 06:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.463 X-Spam-Level: X-Spam-Status: No, score=-99.463 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvg7PxV1XLAH for ; Fri, 30 Nov 2012 06:11:17 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id C585721F85BF for ; Fri, 30 Nov 2012 06:11:16 -0800 (PST) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121130141116.QQEA5450.eastrmfepo201.cox.net@eastrmimpo210> for ; Fri, 30 Nov 2012 09:11:16 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id VqBF1k00F3cuADQ01qBFlv; Fri, 30 Nov 2012 09:11:16 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020201.50B8BE84.002E,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=avoYeJJfTOgA:10 a=hGBaWAWWAAAA:8 a=ChpeqE8C4EUA:10 a=wCIwrrFakMaWAlCEnAQA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=_W_S_7VecoQA:10 a=lnaMlcTudh8sZAp0:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3F7D8C6-161D-4D4B-ACD2-0E7E9D4B3829" From: Edward Lewis In-Reply-To: Date: Fri, 30 Nov 2012 09:11:15 -0500 Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F0D6B3D95@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20121128033151.26459.qmail@joyce.lan> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:11:17 -0000 --Apple-Mail=_A3F7D8C6-161D-4D4B-ACD2-0E7E9D4B3829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 29, 2012, at 20:27, John R Levine wrote: >=20 > Here's the specs for WHOIS for the ICANN contracted TLDs. Often the = language is almost but not quite the same from one TLD to the next. > ... > The ccTLDs have their own requirements, as does IANA for the TLDs it = manages (arpa and int). This soapbox statement is driven by the concern that we sometimes seem = to think that our requirements is to cover all of ICANN's requirements = or to cover all current functionality across the board, or to just do = something that works well in HTTP. Each time specs and requirements of = existing deployments are raised we need to recall whether or not we want = to support what we see. It would be good to document, as in something = we can reference, the boundaries of what is to be solved and what is = left off. In as much as we say that the protocol under development in the WEIRDS = WG is a replacement for WhoIs, it is a protocol that has its own set of = requirements. In that vein it doesn't really matter what WhoIs does in = aggregate today. What matters is that "this time" we get a directory = lookup protocol that does the job right - more right that is, in the = technical sense. That's my opinion, not a WG statement. It is worth doing a survey of existing implementations for ideas and to = build up an idea of what should be included and what should be excluded = from this protocol. Research is good. But that doesn't mean we have to = (as in MUST) replicate all of features identified. Down the road the regulator overseeing a TLD (not necessarily the = operator) will consider the specification of this new protocol. They = may consult with the operator to make a decision on whether to deploy. = Perhaps the new protocol lacks a feature required by the regulator. In = that case they have three options. Stick with the WhoIs as is and not = deploy. Deploy this protocol and retain the WhoIs service. Extend the = definition of this protocol to add the feature, staying with in the = guidelines for extending this protocol. The "success" of WEIRDS, in my opinion, is measured by the number of = registries that ultimately deploy this new protocol, hopefully "right = out of the box" or following the third choice above. = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_A3F7D8C6-161D-4D4B-ACD2-0E7E9D4B3829 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Here's the = specs for WHOIS for the ICANN contracted TLDs.  Often the language = is almost but not quite the same from one TLD to the next.
...
The = ccTLDs have their own requirements, as does IANA for the TLDs it manages = (arpa and int).

This = soapbox statement is driven by the concern that we sometimes seem to = think that our requirements is to cover all of ICANN's requirements or = to cover all current functionality across the board, or to just do = something that works well in HTTP.  Each time specs and = requirements of existing deployments are raised we need to recall = whether or not we want to support what we see.   It would be good = to document, as in something we can reference, the boundaries of what is = to be solved and what is left = off.



In as much as we = say that the protocol under development in the WEIRDS WG is a = replacement for WhoIs, it is a protocol that has its own set of = requirements.  In that vein it doesn't really matter what WhoIs = does in aggregate today.  What matters is that "this time" we get a = directory lookup protocol that does the job right - more right that is, = in the technical sense.  That's my opinion, not a WG = statement.

It is worth doing a survey of existing = implementations for ideas and to build up an idea of what should be = included and what should be excluded from this protocol.  Research = is good.  But that doesn't mean we have to (as in MUST) replicate = all of features identified.

Down the road the = regulator overseeing a TLD (not necessarily the operator) will consider = the specification of this new protocol.  They may consult with the = operator to make a decision on whether to deploy.  Perhaps the new = protocol lacks a feature required by the regulator.  In that case = they have three options.  Stick with the WhoIs as is and not = deploy.  Deploy this protocol and retain the WhoIs service. =  Extend the definition of this protocol to add the feature, staying = with in the guidelines for extending this = protocol.

The "success" of WEIRDS, in my = opinion, is measured by the number of registries that ultimately deploy = this new protocol, hopefully "right out of the box" or following the = third choice above.

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

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

= --Apple-Mail=_A3F7D8C6-161D-4D4B-ACD2-0E7E9D4B3829-- From johnl@iecc.com Fri Nov 30 07:13:16 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E4521F8B17 for ; Fri, 30 Nov 2012 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.137 X-Spam-Level: X-Spam-Status: No, score=-105.137 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbm+A2OdpSuZ for ; Fri, 30 Nov 2012 07:13:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81721F8B04 for ; Fri, 30 Nov 2012 07:13:11 -0800 (PST) Received: (qmail 56445 invoked from network); 30 Nov 2012 15:13:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Nov 2012 15:13:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b8cd07.xn--9vv.k1211; i=johnl@user.iecc.com; bh=pQ138REM5ibg95fsQP2DgkuVFSIaKy9bE9J8+zQtgBY=; b=PdG9NY5cT1Ztz8aO6R+Q/HBY1zcdMKF6ywqLtlDtPGd/rfIim0gQ3xHTRCNauke1yM8cwCA4g1J9hpYtf2BTZK+IBX7Vy2h220hJR3+2FRNgq1Hs23k+vAKLk4z4TruHK7BQjzvLJdaoc5fENwGYYYjv9ZI2pAfhRVaBryNah8E= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b8cd07.xn--9vv.k1211; olt=johnl@user.iecc.com; bh=pQ138REM5ibg95fsQP2DgkuVFSIaKy9bE9J8+zQtgBY=; b=cHAruHEYLyr9RNHpUwzSRxGJE3TmqdHjMXbQ2MnDnDXKwAY64rPHRfrq+9KwJM3uCZkznj0zHdoaULaHooiIzncqbNqBeXPUAPrBE+rmDqAo2QpVGbTIxzDIfR4Z/98JsLgSE4KJ6/7nhbn8aYWHcLwQvAIuFkGaY8EdcJASr7M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Nov 2012 15:12:48 -0000 Message-ID: <20121130151248.55300.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ed.lewis@neustar.biz Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:13:16 -0000 > The "success" of WEIRDS, in my opinion, is measured by the number of > registries that ultimately deploy this new protocol, hopefully "right > out of the box" or following the third choice above. If it can't do all the stuff required by those ICANN contracts, how likely do you think that will be? R's, John From ed.lewis@neustar.biz Fri Nov 30 07:58:09 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135B621F86AC for ; Fri, 30 Nov 2012 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.078 X-Spam-Level: X-Spam-Status: No, score=-99.078 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLYzfJnICM8c for ; Fri, 30 Nov 2012 07:58:08 -0800 (PST) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2494C21F8B58 for ; Fri, 30 Nov 2012 07:58:08 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121130155807.ESVI26743.eastrmfepo102.cox.net@eastrmimpo209> for ; Fri, 30 Nov 2012 10:58:07 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id Vry61k00c3cuADQ01ry7Ja; Fri, 30 Nov 2012 10:58:07 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.50B8D78F.0098,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=RARgB1Ut8ocA:10 a=hGBaWAWWAAAA:8 a=7Ce6JUiEEagA:10 a=0s4qTkZ9N1YSAIFc2LQA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=KCnO99Ya7NdzD5iFJq0A:9 a=_W_S_7VecoQA:10 a=mRXgLdsfSKeiRCwN:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_44743305-77AB-4772-8C46-897895EB7843" From: Edward Lewis In-Reply-To: <20121130151248.55300.qmail@joyce.lan> Date: Fri, 30 Nov 2012 10:58:06 -0500 Message-Id: <0A46543C-7701-4212-9002-5F13E88BFD1A@neustar.biz> References: <20121130151248.55300.qmail@joyce.lan> To: weirds@ietf.org X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:58:09 -0000 --Apple-Mail=_44743305-77AB-4772-8C46-897895EB7843 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 30, 2012, at 10:12, John Levine wrote: > If it can't do all the stuff required by those ICANN contracts, how > likely do you think that will be? (realizing that this is a very obtuse thread of conversation) I assume you are asking "if the new protocol can't support each and = every feature in the current union of ICANN contracted WhoIs servers, = what chance does the new protocol have of displacing the existing WhoIs = services?" There are people on this list more aware of what ICANN wants than I. = They can answer this. I don't know if each and every feature required in a current contract = has to be in the new protocol, as far as ICANN is concerned. What is = apparent is that ICANN is dissatisfied with the current state of WhoIs = and has asked the IETF to make something better. ...and ICANN is not the only consumer for this new protocol... = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_44743305-77AB-4772-8C46-897895EB7843 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If it = can't do all the stuff required by those ICANN contracts, how
likely = do you think that will = be?

(realizing that this = is a very obtuse thread of conversation)

I = assume you are asking "if the new protocol can't support each and every = feature in the current union of ICANN contracted WhoIs servers, what = chance does the new protocol have of displacing the existing WhoIs = services?"

There are people on this list more = aware of what ICANN wants than I.  They can answer = this.

I don't know if each and every feature = required in a current contract has to be in the new protocol, as far as = ICANN is concerned.  What is apparent is that ICANN is dissatisfied = with the current state of WhoIs and has asked the IETF to make something = better.

...and ICANN is not the only consumer = for this new protocol...

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

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

= --Apple-Mail=_44743305-77AB-4772-8C46-897895EB7843-- From andy@arin.net Fri Nov 30 08:38:17 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352DD21F8B67 for ; Fri, 30 Nov 2012 08:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNRdlwqReXFl for ; Fri, 30 Nov 2012 08:38:12 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4221F8B4F for ; Fri, 30 Nov 2012 08:38:12 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 87ABA1656D4; Fri, 30 Nov 2012 11:38:09 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 0A0AF1656D0; Fri, 30 Nov 2012 11:38:09 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 30 Nov 2012 11:37:47 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.60]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Fri, 30 Nov 2012 11:38:07 -0500 From: Andy Newton To: Edward Lewis , "weirds@ietf.org" Thread-Topic: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... Thread-Index: AQHNzxkTI74TfYibTUy+wbYQMszs9w== Date: Fri, 30 Nov 2012 16:38:06 +0000 Message-ID: In-Reply-To: <0A46543C-7701-4212-9002-5F13E88BFD1A@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.1.1.56] Content-Type: multipart/alternative; boundary="_000_CCDE4A90F24Aandyarinnet_" MIME-Version: 1.0 Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 16:38:17 -0000 --_000_CCDE4A90F24Aandyarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Edward Lewis > Date: Friday, November 30, 2012 10:58 AM To: "weirds@ietf.org" > Cc: Edward Lewis > Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf= -... I don't know if each and every feature required in a current contract has t= o be in the new protocol, as far as ICANN is concerned. What is apparent i= s that ICANN is dissatisfied with the current state of WhoIs and has asked = the IETF to make something better. I agree with this 100%. And I don't feel we should just stop work until suc= h a time as ICANN is more clear about their desires. -andy --_000_CCDE4A90F24Aandyarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4434633DE2B74447BDFA636E130C31F1@corp.arin.net> Content-Transfer-Encoding: quoted-printable
From: Edward Lewis <ed.lewis@neustar.biz>
Date: Friday, November 30, 2012 10:= 58 AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Cc: Edward Lewis <ed.lewis@neustar.biz>
Subject: Re: [weirds] requirements/= success was - Re: I-D Action: draft-ietf-...

I don't know if each and every feature required in a current contract has to= be in the new protocol, as far as ICANN is concerned.  What is appare= nt is that ICANN is dissatisfied with the current state of WhoIs and has as= ked the IETF to make something better.


I agree with this 100%. And I don't feel we should just stop work unti= l such a time as ICANN is more clear about their desires.

-andy
--_000_CCDE4A90F24Aandyarinnet_-- From johnl@iecc.com Fri Nov 30 15:48:31 2012 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1F21F85E6 for ; Fri, 30 Nov 2012 15:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.431 X-Spam-Level: X-Spam-Status: No, score=-105.431 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keqWC01guJRC for ; Fri, 30 Nov 2012 15:48:30 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD621F85E3 for ; Fri, 30 Nov 2012 15:48:29 -0800 (PST) Received: (qmail 33830 invoked from network); 30 Nov 2012 23:48:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Nov 2012 23:48:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b945ca.xn--9vv.k1211; i=johnl@user.iecc.com; bh=RDtptgS1bf8QgeUELXpBDo4ZqmUYtF7+9CPdJgKSJmo=; b=LXNZMsxbRet6nJeFwPukrbiYGi460D6ClGeraXfueJXQoEHne1WTEAZ0K6eAJpjISy+tydVzmIOHpmDjFeClTRVC+7qqxq1ZAFG6i41IeiFCPtJM0OwjMuIUUv9XfqV4yIpVTKp6AtYWpx3DGTO/c4rNyfExe1TtTlyK9Bvo8t0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50b945ca.xn--9vv.k1211; olt=johnl@user.iecc.com; bh=RDtptgS1bf8QgeUELXpBDo4ZqmUYtF7+9CPdJgKSJmo=; b=V+qvgJjjTF5rsPJAwV5+0kJ3wc/TpDweHNYUAAcHx4q/DZXNwDLJtZ0egXoDqcDbCPkXKVeNwtXOw6uPPrGUaVeM7tYsYyoDD/f23eQ72G8u+5kjExNHI3Ulq8Pc4NijsWua+Fp1v/dKSJT2RD7DN7l9Yvp9tOlxaL0xVVJUCZU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Nov 2012 23:48:03 -0000 Message-ID: <20121130234803.72618.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-... X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 23:48:31 -0000 >I don't know if each and every feature required in a current contract has to be in the new protocol, as >far as ICANN is concerned. What is apparent is that ICANN is dissatisfied with the current state of WhoIs >and has asked the IETF to make something better. FYI, the new .COM agreement published today says that ICANN can tell Verisign to switch from thin to think WHOIS, or to provide whatever WEIRDS comes up with so long as it's published as a draft standard and is "commercially reasonable in the context of the overall operation of the registry". So it's still up to ICANN to decide what they want. >I agree with this 100%. And I don't feel we should just stop work until such a time as ICANN is more clear >about their desires. Agreed. Given the limited interest shown by the names community here (just Ed and Scott as far as I can tell), it makes sense to go ahead with the numbers stuff.