From bernie@ietf.hoeneisen.ch Fri Apr 1 13:41:56 2011 Return-Path: X-Original-To: provreg@core3.amsl.com Delivered-To: provreg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95FE328C0E5 for ; Fri, 1 Apr 2011 13:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X1KGdgG5Vd4 for ; Fri, 1 Apr 2011 13:41:55 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 4506628C0D8 for ; Fri, 1 Apr 2011 13:41:54 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1Q5lBt-0000Mh-Hl; Fri, 01 Apr 2011 22:43:33 +0200 Date: Fri, 1 Apr 2011 22:43:33 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF0703A39D7B@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: References: <201103311220.p2VCKLwx004730@bartok.nlnetlabs.nl> <046F43A8D79C794FA4733814869CDF0703A39D7B@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: provreg@ietf.org Subject: Re: [provreg] Test for Provreg list X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:41:56 -0000 Scott, Actually, the (old) archives also have been migrated to the new location (IETF server) and can be accessed at: http://www.ietf.org/mail-archive/web/provreg/ cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization On Thu, 31 Mar 2011, Hollenbeck, Scott wrote: > Thanks, Jaap (and Liman). Thankfully the old list archives are still > available: > > http://www.cafax.se/ietf-provreg/maillist/ > > Scott > >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On >> Behalf Of Jaap Akkerhuis >> Sent: Thursday, March 31, 2011 8:20 AM >> To: provreg@ietf.org >> Subject: [provreg] Test for Provreg list >> >> All, >> >> Now that you get this message, it means that the old provreg list >> is alive again. The machine hosting this list dies a horrible dead >> and we took the opportunity to move the list to the ietf mail list >> servers. >> >> I would like to take this opportunity to thank Cafax AB >> (http://www.cafax.se/) and Lars-Johan Liman for hosting the list >> all those years. >> >> jaap >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From gavin.brown@centralnic.com Wed Apr 6 04:20:20 2011 Return-Path: X-Original-To: provreg@core3.amsl.com Delivered-To: provreg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0E63A6910 for ; Wed, 6 Apr 2011 04:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3HXzO1IM2P5 for ; Wed, 6 Apr 2011 04:20:18 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by core3.amsl.com (Postfix) with ESMTP id 949B43A6907 for ; Wed, 6 Apr 2011 04:20:18 -0700 (PDT) Received: from [10.63.74.90] (staffgw.zmg.lon.uk.centralnic.net [82.68.174.118]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id C6FD1712C3A; Wed, 6 Apr 2011 11:22:00 +0000 (UTC) From: Gavin Brown To: provreg@ietf.org Content-Type: multipart/mixed; boundary="=-jv28W2TrvTc4CFADJDI0" Organization: CentralNic Ltd Date: Wed, 06 Apr 2011 12:22:00 +0100 Message-ID: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Subject: [provreg] EPP LaunchPhase Extension: draft requirements and scope X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:20:20 -0000 --=-jv28W2TrvTc4CFADJDI0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Dear colleagues, Thanks to the list administrators for getting this mailing list back up and running. For those subscribers not on the regops list (http://nlnetlabs.nl/mailman/listinfo/regops) there is a draft co-authored by myself and Wil Tan of CloudRegistry for an EPP extension to deal with so-called "sunrise" and "landrush" phases during the initial startup of a TLD. The draft can be found at this URL: https://github.com/wil/EPP-Launch-Phase-Extension-Specification Having spoken to several registrars and registries, I get the feeling that such a specification would be very valuable, especially since we expect to see hundreds of new TLDs going through sunrise and landrush phases in the next couple of years. Many registrars would appreciate being able to do a single development that can be reused for all new TLDs. Following discussions on regops and a brief meeting during the ICANN meeting in San Francisco last month, we've prepared a "first pass" of a requirements document to frame the scope and objectives for this extension. We are very keen to get feedback, especially from registrars and those who might offer "trademark clearinghouses" - these people are unlikely to be subscribers to this list, so if you know them, please reach out and ask them to participate. The initial requirements document is attached. Gavin. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --=-jv28W2TrvTc4CFADJDI0 Content-Disposition: attachment; filename="LaunchPhase-Requirements.txt" Content-Type: text/plain; name="LaunchPhase-Requirements.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Requirements -------------------- In Scope ---------- Module 5 of ICANN's gTLD Applicant Guidebook states: "The registry operator must implement, at a minimum, either a Sunrise period or a Trademark Claims service during the start-up phases for registration in the TLD. These mechanisms will be supported by the established Trademark Clearinghouse as indicated by ICANN." This extension is designed to meet the requirements of registry operators and registrars participating in the Sunrise period of a new gTLD during the start-up phase of the gTLD registry, and during the additional "Landrush" period which has frequently followed the Sunrise period during previous registry launches. During Sunrise and Landrush periods, the registry operates under a different model to the standard "first-come, first-served", "steady state" or "General Availability" model. Specifically: * domain names are *not* registered on a "first-come, first-served" basis Multiple applications for the same domain name may be received. After an application is received, a for the associated domain name will still return an available result, as other registrars may still submit application requests. The domain name is only provisioned at the end of the specific phase of the launch. * All applications made during the Sunrise period must meet minimum Sunrise Eligibility Requirements (SERs), which are validated by the Trademark Clearinghouse During the Sunrise period, all applications submitted to the registry must include proof of eligibility. This may include details of an associated trademark, or a token from the Trademark Clearinghouse indicating that the applicant's eligibility has already been validated. * Contentious applications for the same domain name are resolved via an out-of-band process At the end of the Sunrise and/or Landrush period, all applications are processed by the registry operator. Where there is only a single application for a given domain name, then this domain name is immediately provisioned and associated with the applicant, and the applicant's registrar. Where there are multiple applications for the same domain name, an out-of-band process such as a mediation or auction process is used to determine the final registrant of the domain. Out of scope -------------------- This extension does not attempt to solve any other use cases. In particular, it is not meant for "steady-state" operations, so any use case that may require an extension beyond a phase with a defined window of time will not be addressed. For example, if a registry is to be run with ongoing eligibility (or "nexus") requirements, then a separate extension should be used for these requirements. 1. This extension does not specify any mechanism for performing validation of submitted data. It is assumed to be out of band. 2. Management of the application object on the server side (updating status, cancelling an application) [see notes] Requirements for Registrars --------------------------- * the extension should not change the semantics of existing commands, objects or object elements, or define new object types * the extension should allow for applications to be submitted, queried (both during and after the launch phase) and cancelled Requirements for Registries --------------------------- * the extension should not change the semantics of existing commands, objects or object elements, or define new object types * The data elements for Sunrise Eligibility Requirements must allow for all possible data required by the Trademark Clearinghouse * the extension should allow for multiple clearinghouses, and provide a way for registrars to indicate which clearinghouse has been used to validate an application * the extension should provide a means to communicate the final outcome of an application after the completion of the Sunrise/Landrush period Requirements for Trademark Clearinghouses ----------------------------------------- * Any data passed to the registry by the registrar as part of Sunrise Eligibility Requirements should be complete NOTES * the above requirements are a first pass and we are very keen on getting feedback from all three stakeholder groups * this extension will be agnostic on contact (doesn't matter if registry is thin/thick) and host mappings (doesn't matter which style is used: hostObj / hostAttr) * can work with instant validation => in which case, registry may choose to reject requests that fail online validation, or place object into "validated" status immediately if it passes online validation. * no extension on poll messages - or is that the best way to communicate results of end-of-phase processing? * semantics of * should we allow updating of lp data e.g. trademark_name? * [question in the draft] should we allow multiple status values? For example, it may make sense to have both the "validated" and "allocated" status values. * proposal: adding a ID "type" field * do we need to specify management of the object on the backend, i.e. updating status, deleting an application, etc.? --=-jv28W2TrvTc4CFADJDI0-- From wil@cloudregistry.net Tue Apr 12 09:24:11 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C6D5CE0837 for ; Tue, 12 Apr 2011 09:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltbMqYprBphn for ; Tue, 12 Apr 2011 09:24:10 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id D6789E0833 for ; Tue, 12 Apr 2011 09:24:07 -0700 (PDT) Received: by qyk7 with SMTP id 7so4422977qyk.10 for ; Tue, 12 Apr 2011 09:24:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.37.65 with SMTP id w1mr186835qcd.110.1302625447374; Tue, 12 Apr 2011 09:24:07 -0700 (PDT) Received: by 10.229.12.193 with HTTP; Tue, 12 Apr 2011 09:24:07 -0700 (PDT) In-Reply-To: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> Date: Wed, 13 Apr 2011 02:24:07 +1000 Message-ID: From: Wil Tan To: Gavin Brown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: provreg@ietf.org Subject: Re: [provreg] EPP LaunchPhase Extension: draft requirements and scope X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:24:12 -0000 On Wed, Apr 6, 2011 at 9:22 PM, Gavin Brown wr= ote: > > For those subscribers not on the regops list > (http://nlnetlabs.nl/mailman/listinfo/regops) there is a draft > co-authored by myself and Wil Tan of =C2=A0CloudRegistry for an EPP exten= sion > to deal with so-called "sunrise" and "landrush" phases during the > initial startup of a TLD. The draft can be found at this URL: > https://github.com/wil/EPP-Launch-Phase-Extension-Specification > The draft is now posted to the IETF repository: http://www.ietf.org/internet-drafts/draft-tan-epp-launchphase-00.txt .wil From volker.janzen@internetx.de Wed Apr 13 00:52:38 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B08E7E06A0 for ; Wed, 13 Apr 2011 00:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gr7UQ+tISah for ; Wed, 13 Apr 2011 00:52:37 -0700 (PDT) Received: from web4.internetx.de (gate2.mailgate.de [62.116.129.39]) by ietfc.amsl.com (Postfix) with ESMTP id AC9FEE067E for ; Wed, 13 Apr 2011 00:52:36 -0700 (PDT) Received: from [192.168.100.46] (pizza.internetx.de [62.116.129.3]) (authenticated bits=0) by web4.internetx.de (8.13.8/8.13.8) with ESMTP id p3D7qWsE011574 for ; Wed, 13 Apr 2011 09:52:35 +0200 Message-ID: <4DA55645.3060501@internetx.de> Date: Wed, 13 Apr 2011 09:52:37 +0200 From: InterNetX - Volker Janzen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: provreg@ietf.org References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA6FCB7BFB0B450EF6ECF40A5" Subject: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:52:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA6FCB7BFB0B450EF6ECF40A5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I had a look at the draft and thought about some experiences we had with launch phases. A question regarding the lp:trademark_name field appeared.= Some registries do not allow Unicode characters to appear in data fields, they require US-ASCII. If you have a German trademark, for instance "B=C3=BCro" (the German word= for "office"), the common question on launch phases is how to pass this. With the EPP contact object, you have an attribute "type" defined for the contact:postalInfo with the values int or loc to handle this issue (perhaps only one is supported, but then it's clear if I need to pass US-ASCII or Unicode). I know that there might be a policy for validating and rewriting trademark names (e.g. "?" may be omitted). But I think it would be nice to have something like this "type" attribute for the trademark name in the draft. If there is no attribute for this, I'd suggest to include a hint to care about Unicode characters in trademark names. In my opinion this would increase chances to prevent problems with Unicode trademark names. Kind regards, Volker Janzen Team Entwicklung --=20 InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel: +49 941 59559-0 Fax: +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Gesch=C3=A4ftsf=C3=BChrer/CEO: Thomas M=C3=B6rz Amtsgericht Regensburg, HRB 7142 GPG-Key: 0x186C5F77 GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77 --------------enigA6FCB7BFB0B450EF6ECF40A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lVkkACgkQU2G8zBhsX3eoOACfUpINDoNqSjmQOcAapzVeEMrK NDYAoICe1s+8CVs06ade6xe9HFeUiJLk =lJK6 -----END PGP SIGNATURE----- --------------enigA6FCB7BFB0B450EF6ECF40A5-- From gavin.brown@centralnic.com Thu Apr 14 03:58:18 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C45D3E06CE for ; Thu, 14 Apr 2011 03:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGERPLf4fcG5 for ; Thu, 14 Apr 2011 03:58:18 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfc.amsl.com (Postfix) with ESMTP id C38FEE066A for ; Thu, 14 Apr 2011 03:58:17 -0700 (PDT) Received: from Gavins-MacBook-Pro.local (lon-gw-5.centralnic.net [213.146.157.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id 2701E712BA6; Thu, 14 Apr 2011 10:58:15 +0000 (UTC) Message-ID: <4DA6D344.8030701@centralnic.com> Date: Thu, 14 Apr 2011 11:58:12 +0100 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: InterNetX - Volker Janzen References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> <4DA55645.3060501@internetx.de> In-Reply-To: <4DA55645.3060501@internetx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 10:58:18 -0000 Hi Volker, thanks for your feedback. > I had a look at the draft and thought about some experiences we had with > launch phases. A question regarding the lp:trademark_name field appeared. My understanding of this field is that it does not contain data that is used to validate the applicant's eligibility. When a trademark clearinghouse is validating an application (for example.foo, say), they will take the trademark number (provided in the element) and use this to obtain the full trademark information from the trademark authority that has jurisdiction over the locality specified in the element. This information will include the trademark name. The clearinghouse will then apply whatever the TLD's policy is for confirming that the trademark matches the domain name being applied for. The field is therefore only a hint used to confirm the mark to which the application refers, but doesn't uniquely and solely identify it. It may not even be needed. Does anyone agree/disagree? G. -- CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From jim@rfc1035.com Thu Apr 14 05:02:39 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F7CDE08A2 for ; Thu, 14 Apr 2011 05:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aG89WLdUNoi for ; Thu, 14 Apr 2011 05:02:37 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfc.amsl.com (Postfix) with ESMTP id 2803DE088A for ; Thu, 14 Apr 2011 05:02:37 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 393D115420A1; Thu, 14 Apr 2011 13:02:35 +0100 (BST) Message-Id: From: Jim Reid To: Gavin Brown In-Reply-To: <4DA6D344.8030701@centralnic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 14 Apr 2011 13:02:34 +0100 References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> <4DA55645.3060501@internetx.de> <4DA6D344.8030701@centralnic.com> X-Mailer: Apple Mail (2.936) Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:02:39 -0000 On 14 Apr 2011, at 11:58, Gavin Brown wrote: > My understanding of this field is that it does not contain data that > is used to validate the applicant's eligibility. It might or might not provide validation. It depends on the trademark, where it's registered and who's doing the validation. In most cases I expect the filing number and other registration details would be enough. Though there may be examples where the string or logo -- assuming it can be rendered in Unicode -- will be helpful: Kanji or Arabic trademarks for instance. I'm not sure if this field needs to be added. It would be better to ask the people who do trademark validations and find out what they have to say about this. I suppose they'd say it was better to have this extra info and not need it than the other way round. FWIW I was on the periphery of the sunrise for .tel. Applicants had to submit a canonicalised version of their trademark (ie comparable to RFC1123 hostname rules) and the validation agent would ask them for more info if/when they felt it was needed. That largely happened for incomplete or garbled applications IIRC rather than for trademarks which used non-Latin scripts. > When a trademark clearinghouse is validating an application (for > example.foo, say), they will take the trademark number (provided in > the element) and use this to obtain the full > trademark information from the trademark authority that has > jurisdiction over the locality specified in the > element. This information will include the > trademark name. The clearinghouse will then apply whatever the TLD's > policy is for confirming that the trademark matches the domain name > being applied for. IMO it would be wise not to use terms like "clearinghouse" or couple this EPP stuff too closely to ICANN's gTLD plans/processes. Although that may well be the main focus, it isn't the only game in town: eg ccTLD relaunches. It doesn't follow that the TLD's trademark or sunrise policy can be definitive. This may well have to be subservient to the relevant trademark authority's rules: eg "if there's a discrepancy between the Latin-ised version of a mark and its expression in our local langauge, the local text wins". > The field is therefore only a hint used to > confirm the mark to which the application refers, but doesn't > uniquely and solely identify it. It may not even be needed. That's probably true most of the time. At least for those who are validating Latin character names against on-line trademark databases. However it may be useful supplementary information when there is uncertainty or ambiguity about the trademark. The validation agent may well have to ask the applicant for more info in those cases anyway. But that would probably be by out-of-band means -- IPR lawyers sending faxes or PDFs -- rather than EPP transactions. From jwagner@hexonet.net Thu Apr 14 05:08:49 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BEB4E088B for ; Thu, 14 Apr 2011 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNG9s+t8pkaE for ; Thu, 14 Apr 2011 05:08:48 -0700 (PDT) Received: from xmrelay2-out.mrelay.net (xmrelay2-out.mrelay.net [93.190.233.23]) by ietfc.amsl.com (Postfix) with ESMTP id 6705BE06FA for ; Thu, 14 Apr 2011 05:08:48 -0700 (PDT) Message-ID: <4DA6E3CC.8040102@hexonet.net> Date: Thu, 14 Apr 2011 14:08:44 +0200 From: Jens Wagner Organization: HEXONET GmbH User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Gavin Brown References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> <4DA55645.3060501@internetx.de> <4DA6D344.8030701@centralnic.com> In-Reply-To: <4DA6D344.8030701@centralnic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 188.97.91.25 X-SA-Exim-Mail-From: jwagner@hexonet.net Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:08:49 -0000 Hi Gavin, Volker, I think that a trademark_name field might be required, as long as there's no way to query the trademark_name from (trademark_number, trademark_locality) in realtime, for all permitted localities. Reason is that a registry should immediately refuse a domain application, if the respective trademark_name does not cover the domain name that's applied for. A registry making use of the launchphase extension should publish the set of allowed charactes for trademark_name, and should define a function which validates if a trademark_name covers a domain name (e.g. a german umlaut Ö could cover Ö only, or Ö, O and OE). I would not a flag like "type='loc/int'" for this purpose, as it only says 'unicode' vs. 7-bit ASCII. Some registries might e.g. want to limit e.g. to cyrillic chars only. Best, -jens Gavin Brown schrieb: > Hi Volker, thanks for your feedback. > >> I had a look at the draft and thought about some experiences we had with >> launch phases. A question regarding the lp:trademark_name field >> appeared. > > My understanding of this field is that it does not contain data that > is used to validate the applicant's eligibility. > > When a trademark clearinghouse is validating an application (for > example.foo, say), they will take the trademark number (provided in > the element) and use this to obtain the full > trademark information from the trademark authority that has > jurisdiction over the locality specified in the > element. This information will include the > trademark name. The clearinghouse will then apply whatever the TLD's > policy is for confirming that the trademark matches the domain name > being applied for. > > The field is therefore only a hint used to confirm > the mark to which the application refers, but doesn't uniquely and > solely identify it. It may not even be needed. > > Does anyone agree/disagree? > > G. > -- Jens Wagner Chief Executive Officer HEXONET GmbH Be Your Own Internet Services Provider T: +49 6841 69 84 0 F: +49 6841 69 84 199 E: jwagner@hexonet.net W: http://www.hexonet.net HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany. CEO & General Manager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbrücken, VAT-ID: DE-138316882 HEXONET Services Inc., 1100 - 1200 West 73rd Avenue, Vancouver, B.C., V6P 6G5, Canada. CSO & General Manager: Robert Birkner This email and any files transmitted are confidential and intended only or the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. From JGould@verisign.com Thu Apr 14 07:59:06 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D7CFE065F for ; Thu, 14 Apr 2011 07:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=-2.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJH3+a5KOO02 for ; Thu, 14 Apr 2011 07:59:03 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfc.amsl.com (Postfix) with ESMTP id E5B06E0699 for ; Thu, 14 Apr 2011 07:58:58 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTacLsOa+YlxcJCYcysVTqWtGiwnYEkVH@postini.com; Thu, 14 Apr 2011 07:59:02 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p3EEwt54015231; Thu, 14 Apr 2011 10:58:55 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 10:58:55 -0400 Received: from 10.131.30.174 ([10.131.30.174]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Apr 2011 14:58:54 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 14 Apr 2011 10:58:50 -0400 From: James Gould To: Gavin Brown , InterNetX - Volker Janzen Message-ID: Thread-Topic: [provreg] lp:trademark_name field Thread-Index: Acv6lIelB7yZ/dZnRw2Z/nW+9xrVEgAH+7nL In-Reply-To: <4DA6D344.8030701@centralnic.com> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3385623530_7856084" X-OriginalArrivalTime: 14 Apr 2011 14:58:55.0644 (UTC) FILETIME=[79E725C0:01CBFAB4] Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:59:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3385623530_7856084 Content-type: multipart/alternative; boundary="B_3385623530_7831111" --B_3385623530_7831111 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Gavin, I want to raise the question for the list whether there is any standard trademark authority interface / protocol since I believe that the EPP extension would be highly dependent on the underlying interface requirement= s with the trademark authorities? It would be great if representatives of th= e trademark authorities could participate and help collaborate on the EPP extension as well as helping define a standard interface for the registrars and registries to use. I=B9m afraid without understanding the underlying interface requirements of the trademark authorities that we=B9ll be guessing on what is needed in the EPP extension that could result in additional custom extensions having to be created or having to build additional flexibility into the extension to mitigate the unknown. --=20 JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com From: Gavin Brown Date: Thu, 14 Apr 2011 06:58:12 -0400 To: InterNetX - Volker Janzen Cc: Subject: Re: [provreg] lp:trademark_name field Hi Volker, thanks for your feedback. > I had a look at the draft and thought about some experiences we had with > launch phases. A question regarding the lp:trademark_name field appeared. My understanding of this field is that it does not contain data that is used to validate the applicant's eligibility. When a trademark clearinghouse is validating an application (for example.foo, say), they will take the trademark number (provided in the element) and use this to obtain the full trademark information from the trademark authority that has jurisdiction over the locality specified in the element. This information will include the trademark name. The clearinghouse will then apply whatever the TLD's policy is for confirming that the trademark matches the domain name being applied for. The field is therefore only a hint used to confirm the mark to which the application refers, but doesn't uniquely and solely identify it. It may not even be needed. Does anyone agree/disagree? G. -- CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --B_3385623530_7831111 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [provreg] lp:trademark_name field Gavin,

I want to raise the question for the list whether there is any standard tra= demark authority interface / protocol since I believe that the EPP extension= would be highly dependent on the underlying interface requirements with the= trademark authorities?  It would be great if representatives of the tr= ademark authorities could participate and help collaborate on the EPP extens= ion as well as helping define a standard interface for the registrars and re= gistries to use.  I’m afraid without understanding the underlying= interface requirements of the trademark authorities that we’ll be gue= ssing on what is needed in the EPP extension that could result in additional= custom extensions having to be created or having to build additional flexib= ility into the extension to mitigate the unknown.  

--

JG



James Gould
Principal Soft= ware Engineer
jgould@Verisign.com

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
VerisignInc.com


From: Gavin Brown <gavin.brown@centralnic.com>
Date: Thu, 14 Apr 2011 06:58:12 -0400
To: InterNetX - Volker Janzen <volker.janzen@internetx.de>
Cc: <provreg@ietf.org>
Subject: Re: [provreg] lp:trademark_name field

Hi Volker, thanks for your feedback.

> I had a look at the draft and thought about some experiences we had wi= th
> launch phases. A question regarding the lp:trademark_name field appear= ed.

My understanding of this field is that it does not contain data that is
used to validate the applicant's eligibility.

When a trademark clearinghouse is validating an application (for
example.foo, say), they will take the trademark number (provided in the
<lp:trademark_number> element) and use this to obtain the full tradem= ark
information from the trademark authority that has jurisdiction over the
locality specified in the <lp:trademark_locality> element. This
information will include the trademark name. The clearinghouse will then apply whatever the TLD's policy is for confirming that the trademark
matches the domain name being applied for.

The <lp:trademark_name> field is therefore only a hint used to confir= m
the mark to which the application refers, but doesn't uniquely and
solely identify it. It may not even be needed.

Does anyone agree/disagree?

G.

--
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg

 --B_3385623530_7831111-- --B_3385623530_7856084 Content-Type: image/gif; name="image.gif" Content-ID: <3385623530_7862234> Content-Transfer-Encoding: base64 R0lGODlhoQBmANUAACN9tqnI4jWGu7XR5tLk8ODt9Rx4s5K72mWhy3Clzpu83KHF30GNv8Da 6muizPD2+pvB3Yqy1kySwlGZxbHN5IC11Yu62IWw1X+t0/n7/Y+12HGrz8re7YO21pCSlbW2 uNrb3Nvc3W9wdHR2evb298jJyuTk5X5/gz2KvUePwVeXxluax4eIjHWn0GGdyVGUxO3t7qOk pqytr5mbnnqq0RFzr7+/wS2CuNHS0w5xrglvrYi31+bv92ttcQBqqv///yH5BAAAAAAALAAA AAChAGYAAAb/wJ9wSCwaj8iksFFpOp/QaKWhrHIGWAolwF14IeCD2GLZdTqFqnrNbrurj5pv Tq/b74D3kNdKOBAuKyovEikMKAICNwAABgY1OToAD3qVlpdtFXebnD4VlRB9f4GDhYeJi42P kQOYrq+wPwCdtHM1lG4ENKKAgoSGiIqMjpASscfIbQ21tQhvGrt+vaXAqMOrBMna20cMzLTZ bA0Y0aO+psGpxA7c7e0F350MbBka5Lykv6fCqpPu/9o2xOO0YM2AC/ek5UNnTZUFgBCPxRmI B1eSAhEQlpumL90wARFDwjpA8c4nJQEyJjRHbZ86DiJjYhJQsk6NNEgIaFC5cWE1/34rZAqt tKwmnQlIMizYqRHfuZ+peAyd6maCUTpUjHA4wHQlR4bCOlAduwbeVR8gizxQwJWn05bpBFgk S/eIprMFiQxg27XnU5cU6go+8mDW1Vt7FPB1q/BvMKSDIxNZcNbTEAqK2zZtDDcRTMmgf3g7 m6bAgsx933YUsCF06KJXGWQIcHrxZparpboGjaByACwDtHQBw/ZAmQsaN2xIEGB36AJyruZx Tl3P3asHqmtvY9go4u3gkwyo3Dq8eSOjr4Y7z55A5Xns4/c+2yr++YnS7bMnefak/vDd1XTT f+HBZpQzBIKXnlFZJVidWbE5uN11RuUloXP4GeXPhc5R1v8fh9TRRBqIuxlYE2QkhmbVWQ2m GBl0h+HkomQUUuTfjJEVVtOGOErmIUUW9ijZgszAJyRoJtbS4pGRzccMgkyClmEn30UJWo2b 3GilZAHiseVu43VS35ehEUmHkWSC5t4mMqYJmkB2lOdmaFNWOSdo/M2R3Z27GTYdn64VtSSg kk2AIqHPtYnooow26uijkEYq6aSUVmrppZhmqp0JIIBgwnYleCCqByUYIcOoHpgQKqqsiirD EKe26sEMH5RAQhGrivopETDIcEIPwPbggQ23FoFqqUXAEMMIwfYwQgy7EhHrrMUKYQKq0f5j QrMeGMEssCP88EGz5AbbrRAelEv/7gjICjFusCAQ8a66I3xQRLP2ElGCusG+SkS6weYrBAjN xhsRC81W+wPBwcYgLr/cDgEwxMC2O28PBv+wL8XCVouvvhz34LDEzY4AwxAMA5sxQDY0i4O0 Lj/M8bk/TDzCqAiXPMTFGX8L7AkxeOBzxUN8PPC6MXwwMbD+1kzuDCgXHBIMzY4sRM49nOBu s2pMTPMPJMwgtcwqH90wETYwO8LLRQdMcsPVmvAtCxkvXfbCYx8cbLhCUN3v1sF2bW4RKfeQ L89C4BAzESbMoPAPRm87eBEmnGCDseVqjTe8IrUc7K4bA7vrxYID+/XmwB4+tuLBnlBCtkcY 7TmwbJdO/+7lkHM+tdFi/7xzyP9OPkTvtAN+t9+Z0wp77qkLEQPXbEz8K7i35q03sCwI0WzT F/MbPLioTk+98RgPzzEL2Rq9NBHeoxuw+K9aD9HsPZDAuui/c/w9xxbnHTbHI/CY25wGLvap 620iC10PkFc+kTCwBDJonbzw9YEKWlBgBITYCWpHtgYOwQSngljT1Ac97R3Qfab7AdaepzuR EG8G4sMd+Wx3Mw+Iz4PkW1myQGCDpdHMaBeLFqpK6DXUkUuHEAnd0E6WP2DZ7lyFy94EW/gD GCzvB+L74QDvJzIjSM6JKBSW89SFRICQQF1SbGIPnojAHsiwgxkb19qKQAKfQfTNhM0D29Da BTasrTGM56pjucoIEOIF640dlJWokFXEvpWsWoiDwQ1ZYINO2eCG7TJaB4VVAhB84IZ/zCDN 6He3mCgQWExUI8Ty1cgx/i2HfQxZ1gyYx1jKEoFf8yMOQ3LGiBWhe/xipfD02CwmIg5shlTX CdI3QGvpsmSBAyQRCrfLkBiSj+RbpTSnmEI4EgEHz3TWBx6nSSGQIILkOgEIJobLIrCwlIQi gScr2ElLyJOeV9SUPvfJz376858ADahAB0rQghr0oJISQQh+oFCGLrShEH2oRB1K0YhWdKIW zShGN3rRjmrUoxz9qEhDSlKQXjQIADs= --B_3385623530_7856084-- From brunner@nic-naa.net Thu Apr 14 08:11:56 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E44FE06D7 for ; Thu, 14 Apr 2011 08:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ezkAVdSeeia for ; Thu, 14 Apr 2011 08:11:54 -0700 (PDT) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by ietfc.amsl.com (Postfix) with ESMTP id CF947E065F for ; Thu, 14 Apr 2011 08:11:54 -0700 (PDT) Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id p3EDDfb8053546 for ; Thu, 14 Apr 2011 09:13:42 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <4DA70EB4.8040905@nic-naa.net> Date: Thu, 14 Apr 2011 11:11:48 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:11:56 -0000 On 4/14/11 10:58 AM, James Gould wrote: > Gavin, > > I want to raise the question for the list whether there is any > standard trademark authority interface / protocol I don't think so, however there several candidates with less than=20 universal (in theory) coverage that may be (in practice) nearly so,=20 for some registries, so perhaps a (IANA ID, TBD, entry) key-value pair=20 would, if non-empty, convey useful data, for a practical number of=20 registrations for one or more registries. At the risk of pointing out the obvious, if a hack works for com, then=20 it is likely to be adopted by some others, so that's a starting point=20 to determine hack utility value for some future .foo's TM registration=20 processing data stream. > since I believe that > the EPP extension would be highly dependent on the underlying > interface requirements with the trademark authorities? It would be > great if representatives of the trademark authorities could > participate and help collaborate on the EPP extension as well as > helping define a standard interface for the registrars and registries > to use. I=92m afraid without understanding the underlying interface > requirements of the trademark authorities that we=92ll be guessing on > what is needed in the EPP extension that could result in additional > custom extensions having to be created or having to build additional > flexibility into the extension to mitigate the unknown. Yup. > -- > > JG > > > > *James Gould > *Principal Software Engineer > jgould@Verisign.com > > 703-948-3271 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > VerisignInc.com > > > ---------------------------------------------------------------------- > *From: *Gavin Brown > *Date: *Thu, 14 Apr 2011 06:58:12 -0400 > *To: *InterNetX - Volker Janzen > *Cc: * > *Subject: *Re: [provreg] lp:trademark_name field > > Hi Volker, thanks for your feedback. > >> I had a look at the draft and thought about some experiences we had w= ith >> launch phases. A question regarding the lp:trademark_name field > appeared. > > My understanding of this field is that it does not contain data that is= > used to validate the applicant's eligibility. > > When a trademark clearinghouse is validating an application (for > example.foo, say), they will take the trademark number (provided in the= > element) and use this to obtain the full trademar= k > information from the trademark authority that has jurisdiction over the= > locality specified in the element. This > information will include the trademark name. The clearinghouse will the= n > apply whatever the TLD's policy is for confirming that the trademark > matches the domain name being applied for. > > The field is therefore only a hint used to confirm > the mark to which the application refers, but doesn't uniquely and > solely identify it. It may not even be needed. > > Does anyone agree/disagree? > > G. > > -- > CentralNic Ltd > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Ltd is a company registered in England and Wales with compan= y > number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From gavin.brown@centralnic.com Thu Apr 14 08:24:25 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A280E075F for ; Thu, 14 Apr 2011 08:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1uSNxy0yQD1 for ; Thu, 14 Apr 2011 08:24:24 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfc.amsl.com (Postfix) with ESMTP id B10BFE0663 for ; Thu, 14 Apr 2011 08:24:23 -0700 (PDT) Received: from Gavins-MacBook-Pro.local (lon-gw-5.centralnic.net [213.146.157.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTP id DC5BE712B8D; Thu, 14 Apr 2011 15:24:21 +0000 (UTC) Message-ID: <4DA711A4.5030601@centralnic.com> Date: Thu, 14 Apr 2011 16:24:20 +0100 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: James Gould References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:24:25 -0000 Hi James, I am actively trying to get input from various trademark experts and authorities - including the UK's IPO and WIPO - about whether any such standards exist. I completely agree that we need to get the trademark data model right or we're not going to get any adoption. G. On 14/04/2011 15:58, James Gould wrote: > Gavin, > > I want to raise the question for the list whether there is any standard > trademark authority interface / protocol since I believe that the EPP > extension would be highly dependent on the underlying interface > requirements with the trademark authorities? It would be great if > representatives of the trademark authorities could participate and help > collaborate on the EPP extension as well as helping define a standard > interface for the registrars and registries to use. I’m afraid without > understanding the underlying interface requirements of the trademark > authorities that we’ll be guessing on what is needed in the EPP > extension that could result in additional custom extensions having to be > created or having to build additional flexibility into the extension to > mitigate the unknown. > > -- > > JG > > > > *James Gould > *Principal Software Engineer > jgould@Verisign.com > > 703-948-3271 > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > VerisignInc.com > > > ------------------------------------------------------------------------ > *From: *Gavin Brown > *Date: *Thu, 14 Apr 2011 06:58:12 -0400 > *To: *InterNetX - Volker Janzen > *Cc: * > *Subject: *Re: [provreg] lp:trademark_name field > > Hi Volker, thanks for your feedback. > >> I had a look at the draft and thought about some experiences we had with >> launch phases. A question regarding the lp:trademark_name field appeared. > > My understanding of this field is that it does not contain data that is > used to validate the applicant's eligibility. > > When a trademark clearinghouse is validating an application (for > example.foo, say), they will take the trademark number (provided in the > element) and use this to obtain the full trademark > information from the trademark authority that has jurisdiction over the > locality specified in the element. This > information will include the trademark name. The clearinghouse will then > apply whatever the TLD's policy is for confirming that the trademark > matches the domain name being applied for. > > The field is therefore only a hint used to confirm > the mark to which the application refers, but doesn't uniquely and > solely identify it. It may not even be needed. > > Does anyone agree/disagree? > > G. > > -- > CentralNic Ltd > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Ltd is a company registered in England and Wales with company > number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > -- CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From bernie@ietf.hoeneisen.ch Thu Apr 14 08:32:05 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CE03E0779 for ; Thu, 14 Apr 2011 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5PAGSSh0M+C for ; Thu, 14 Apr 2011 08:32:04 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfc.amsl.com (Postfix) with ESMTP id B1BA3E075F for ; Thu, 14 Apr 2011 08:31:57 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1QAOWX-0001L7-Tn for provreg@ietf.org; Thu, 14 Apr 2011 17:32:01 +0200 Date: Thu, 14 Apr 2011 17:32:01 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF Provreg Mailing List Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [provreg] Similarities with RFC 4725 / RFC 5076 & RFC 5105 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:32:05 -0000 Just for your information: Certain considerations that apply to the recent discussion on trademark validation are similar to the ENUM validation problem space, where a Domain Name could only be assigned, after the holder has proved his rights on the Domain Name / corresponding E.164 number. You might want to have look into the ENUM Validation RFCs: - http://tools.ietf.org/html/rfc4725 (Validation Architecture) - http://tools.ietf.org/html/rfc5076 (EPP Mapping) - http://tools.ietf.org/html/rfc5105 (Validation Token) cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization From jothan@gmail.com Thu Apr 14 09:05:32 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 115E7E0895 for ; Thu, 14 Apr 2011 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yprukibNvmq for ; Thu, 14 Apr 2011 09:05:30 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id C8A05E087E for ; Thu, 14 Apr 2011 09:05:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so3308798qyk.10 for ; Thu, 14 Apr 2011 09:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=afLfC7FIzqj7TgMeQlvFT3dF79gqEx2ntJpO4Qv7bPc=; b=YOnSlbmc+UDs1kI6Oopm2xvSuq2DdQZm27prAjc2bdbE0MaHr34qKkAw2OxDD8/KOM 19gs4/VsloL8K3LL9JdO5p4AvJmpeowwN2rFlelUlA0CiQIATh8FDfDhm6cInIQmnJOt uBskCfSZEx4rfTPyQxrZSM2KFi+W4/uXAL7AE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZkFH+KN8cwEhpr7wrQJREoPEEJ0jVhFfN1wBt0jh3vDMWgrm2jiO34Lhdntx5Iq5dg Q6TCMu/a5TWhtIfmD1cMmr2q/eQQIDiasILW3x962fuf7vHTX0z6OlmtgpRzqKr9IfVz rbP02EZBAM8O0SCFYzBNgQ0MmF/4+j2ELwb2c= Received: by 10.52.169.135 with SMTP id ae7mr1349902vdc.79.1302797130140; Thu, 14 Apr 2011 09:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.168.137 with HTTP; Thu, 14 Apr 2011 09:04:50 -0700 (PDT) In-Reply-To: <4DA711A4.5030601@centralnic.com> References: <4DA711A4.5030601@centralnic.com> From: Jothan Frakes Date: Thu, 14 Apr 2011 09:04:50 -0700 Message-ID: To: Gavin Brown Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:05:32 -0000 Hi- I've reached out to a few of the providers of CHIP-like validations to comment on this. Many of the IP systems that are the source for their end result data were written without the benefit of Unicode, but some of the clearinghouse providers spend some time in normalizing extended latin characters into A-Z (ie =E9->e, =FC->u) USPTO for example is mostly A-Z centric but in some cases do allow certain characters beyond those typically legal within a non-IDN domain name, such as extended latin, but candidly, there's no unified standard. The Laga system, IPRota, and some of the other clearinghouse services that will connect up to registries to work with this validation process on TM are pretty well evolved, but this is better fielded by them. -Jothan Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax On Thu, Apr 14, 2011 at 8:24 AM, Gavin Brown w= rote: > Hi James, > > I am actively trying to get input from various trademark experts and > authorities - including the UK's IPO and WIPO - about whether any such > standards exist. I completely agree that we need to get the trademark dat= a > model right or we're not going to get any adoption. > > G. > > On 14/04/2011 15:58, James Gould wrote: >> >> Gavin, >> >> I want to raise the question for the list whether there is any standard >> trademark authority interface / protocol since I believe that the EPP >> extension would be highly dependent on the underlying interface >> requirements with the trademark authorities? It would be great if >> representatives of the trademark authorities could participate and help >> collaborate on the EPP extension as well as helping define a standard >> interface for the registrars and registries to use. I=92m afraid without >> understanding the underlying interface requirements of the trademark >> authorities that we=92ll be guessing on what is needed in the EPP >> extension that could result in additional custom extensions having to be >> created or having to build additional flexibility into the extension to >> mitigate the unknown. >> >> -- >> >> JG >> >> >> >> *James Gould >> *Principal Software Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 21345 Ridgetop Circle >> LS2-2-1 >> Dulles, VA 20166 >> VerisignInc.com >> >> >> ------------------------------------------------------------------------ >> *From: *Gavin Brown >> *Date: *Thu, 14 Apr 2011 06:58:12 -0400 >> *To: *InterNetX - Volker Janzen >> *Cc: * >> *Subject: *Re: [provreg] lp:trademark_name field >> >> Hi Volker, thanks for your feedback. >> >>> =A0I had a look at the draft and thought about some experiences we had = with >>> =A0launch phases. A question regarding the lp:trademark_name field >>> appeared. >> >> My understanding of this field is that it does not contain data that is >> used to validate the applicant's eligibility. >> >> When a trademark clearinghouse is validating an application (for >> example.foo, say), they will take the trademark number (provided in the >> element) and use this to obtain the full trademark >> information from the trademark authority that has jurisdiction over the >> locality specified in the element. This >> information will include the trademark name. The clearinghouse will then >> apply whatever the TLD's policy is for confirming that the trademark >> matches the domain name being applied for. >> >> The field is therefore only a hint used to confirm >> the mark to which the application refers, but doesn't uniquely and >> solely identify it. It may not even be needed. >> >> Does anyone agree/disagree? >> >> G. >> >> -- >> CentralNic Ltd >> Innovative, Reliable and Flexible Registry Services >> for ccTLD, gTLD and private domain name registries >> https://www.centralnic.com/ >> >> CentralNic Ltd is a company registered in England and Wales with company >> number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >> > > -- > CentralNic Ltd > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Ltd is a company registered in England and Wales with company > number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > From wil@cloudregistry.net Thu Apr 14 10:07:51 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6907BE0663 for ; Thu, 14 Apr 2011 10:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr6M7gjnL1HZ for ; Thu, 14 Apr 2011 10:07:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 7681AE0835 for ; Thu, 14 Apr 2011 10:07:47 -0700 (PDT) Received: by qyk7 with SMTP id 7so1221144qyk.10 for ; Thu, 14 Apr 2011 10:07:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.37.65 with SMTP id w1mr756313qcd.110.1302800866650; Thu, 14 Apr 2011 10:07:46 -0700 (PDT) Received: by 10.229.12.193 with HTTP; Thu, 14 Apr 2011 10:07:46 -0700 (PDT) In-Reply-To: References: <1302088920.11239.56.camel@scimitar.gb.zmg.lon.uk.centralnic.net> <4DA55645.3060501@internetx.de> <4DA6D344.8030701@centralnic.com> Date: Fri, 15 Apr 2011 03:07:46 +1000 Message-ID: From: Wil Tan To: Jim Reid Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: provreg@ietf.org Subject: Re: [provreg] lp:trademark_name field X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:07:51 -0000 On Wed, Apr 13, 2011 at 5:52 PM, InterNetX - Volker Janzen wrote: > With the EPP contact object, you have an attribute "type" defined for > the contact:postalInfo with the values int or loc to handle this issue > (perhaps only one is supported, but then it's clear if I need to pass > US-ASCII or Unicode). > > I know that there might be a policy for validating and rewriting > trademark names (e.g. "?" may be omitted). But I think it would be nice > to have something like this "type" attribute for the trademark name in > the draft. If there is no attribute for this, I'd suggest to include a > hint to care about Unicode characters in trademark names. > I can see that adding a "type" attribute could help make the intention more explicit. However, I'm not sure how will this help in practice. Say you ha= ve a trademark with non-ASCII characters, so you send it as type=3D"loc", and th= e registry responds with an error because it only accepts ASCII. Without thi= s @type attribute, since the field is an XML "normalizedString" it can contai= n pretty much any Unicode characters, you'd just send it along and the registrywould respond with an error. I would prefer your latter suggestion to include wording about the trademark_name field being agnostic to the character repertoire, and that restrictions are left to the implementor. On Thu, Apr 14, 2011 at 10:08 PM, Jens Wagner wrote: > A registry making use of the launchphase extension should publish the set= of > allowed charactes for trademark_name, and should define a function which > validates if a trademark_name covers a domain name (e.g. a german umlaut = =C3=96 > could cover =C3=96 only, or =C3=96, O and OE). > > I would not a flag like "type=3D'loc/int'" for this purpose, as it only s= ays > 'unicode' vs. 7-bit ASCII. Some registries might e.g. want to limit e.g. = to > cyrillic chars only. > I agree. On Thu, Apr 14, 2011 at 10:02 PM, Jim Reid wrote: > On 14 Apr 2011, at 11:58, Gavin Brown wrote: > >> My understanding of this field is that it does not contain data that is >> used to validate the applicant's eligibility. > > It might or might not provide validation. It depends on the trademark, wh= ere > it's registered and who's doing the validation. In most cases I expect th= e > filing number and other registration details would be enough. Though ther= e > may be examples where the string or logo -- assuming it can be rendered i= n > Unicode -- will be helpful: Kanji or Arabic trademarks for instance. > Indeed, there are quite a few possible configurations of registry, validation agent, and policies. > I'm not sure if this field needs to be added. It would be better to ask t= he > people who do trademark validations and find out what they have to say ab= out > this. I suppose they'd say it was better to have this extra info and not > need it than the other way round. > The reason trademark_name and trademark_* fields were included was that our validation agent at that time asked for them. It has almost always appeared on past sunrises, most of them managed through a single validation agent notwithstanding, even if it was probably used as extra hint as you mentioned. > > IMO it would be wise not to use terms like "clearinghouse" or couple this > EPP stuff too closely to ICANN's gTLD plans/processes. Agree, and we've avoided using any such terms in the draft. .wil From wil@cloudregistry.net Fri Apr 15 05:11:52 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 296C4E06CB for ; Fri, 15 Apr 2011 05:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpwpqDz-MRNX for ; Fri, 15 Apr 2011 05:11:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 96563E06B1 for ; Fri, 15 Apr 2011 05:11:48 -0700 (PDT) Received: by qyk7 with SMTP id 7so1677456qyk.10 for ; Fri, 15 Apr 2011 05:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.4.203 with SMTP id 11mr1454128qcs.72.1302869508003; Fri, 15 Apr 2011 05:11:48 -0700 (PDT) Received: by 10.229.12.193 with HTTP; Fri, 15 Apr 2011 05:11:47 -0700 (PDT) Date: Fri, 15 Apr 2011 22:11:47 +1000 Message-ID: From: Wil Tan To: provreg@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [provreg] LP naming convention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 12:11:52 -0000 Dear all, James Gould had voiced out a valid point, i.e. the elements are named in a lowercase-with-underscores rather than camelCase. The latter is more consistent with the rest of EPP, so I propose updating it to the following on the next iteration of the draft: application_id => applicationID trademark_name => trademarkName trademark_number => trademarkNumber trademark_locality => trademarkLocality trademark_entitlement => trademarkEntitlement pvrc => PVRC (or stay all lowercase, I'm ambivalent) Any comments or objections? .wil From JGould@verisign.com Fri Apr 15 06:01:57 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CE38E0820 for ; Fri, 15 Apr 2011 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-1.831, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASkSIdUSM3+9 for ; Fri, 15 Apr 2011 06:01:56 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfc.amsl.com (Postfix) with ESMTP id CE398E06F8 for ; Fri, 15 Apr 2011 06:01:54 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTahBwRoudot2D9NdNqANzN6dnArF9iYJ@postini.com; Fri, 15 Apr 2011 06:01:55 PDT Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p3FD1rQM016544; Fri, 15 Apr 2011 09:01:53 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 09:01:53 -0400 Received: from 10.131.30.174 ([10.131.30.174]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Apr 2011 13:01:52 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 15 Apr 2011 09:01:46 -0400 From: James Gould To: Wil Tan , Message-ID: Thread-Topic: [provreg] LP naming convention Thread-Index: Acv7ZlRHM+6sAXEgTduILrhe8qyTHwABvIKt In-Reply-To: Mime-version: 1.0 Content-type: multipart/related; boundary="B_3385702907_9312361" X-OriginalArrivalTime: 15 Apr 2011 13:01:53.0284 (UTC) FILETIME=[4AA9CC40:01CBFB6D] Subject: Re: [provreg] LP naming convention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:01:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3385702907_9312361 Content-type: multipart/alternative; boundary="B_3385702907_9291258" --B_3385702907_9291258 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Will, Thanks for bringing this up. I prefer the lowercase pvrc that is in line with the other EPP specifications (e.g. roid). -- JG James Gould Principal Software Engineer jgould@Verisign.com 703-948-3271 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 VerisignInc.com From: Wil Tan Date: Fri, 15 Apr 2011 08:11:47 -0400 To: Subject: [provreg] LP naming convention Dear all, James Gould had voiced out a valid point, i.e. the elements are named in a lowercase-with-underscores rather than camelCase. The latter is more consistent with the rest of EPP, so I propose updating it to the following on the next iteration of the draft: application_id => applicationID trademark_name => trademarkName trademark_number => trademarkNumber trademark_locality => trademarkLocality trademark_entitlement => trademarkEntitlement pvrc => PVRC (or stay all lowercase, I'm ambivalent) Any comments or objections? .wil _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --B_3385702907_9291258 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [provreg] LP naming convention Will,

Thanks for bringing this up.  I prefer the lowercase pvrc that is in l= ine with the other EPP specifications (e.g. roid).  

--

JG



James Gould
Principal Soft= ware Engineer
jgould@Verisign.com

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
VerisignInc.com


From: Wil Tan <wil@cloudregistry.net>
Date: Fri, 15 Apr 2011 08:11:47 -0400
To: <provreg@ietf.org>
Subject: [provreg] LP naming convention

Dear all,

James Gould had voiced out a valid point, i.e. the elements are named
in a lowercase-with-underscores rather than camelCase. The latter is
more consistent with the rest of EPP, so I propose updating it to the
following on the next iteration of the draft:

application_id =3D> applicationID
trademark_name =3D> trademarkName
trademark_number =3D> trademarkNumber
trademark_locality =3D> trademarkLocality
trademark_entitlement =3D> trademarkEntitlement
pvrc =3D> PVRC (or stay all lowercase, I'm ambivalent)

Any comments or objections?

.wil
_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.or= g/mailman/listinfo/provreg

 --B_3385702907_9291258-- --B_3385702907_9312361 Content-Type: image/gif; name="image.gif" Content-ID: <3385702906_9266503> Content-Transfer-Encoding: base64 R0lGODlhoQBmANUAACN9tqnI4jWGu7XR5tLk8ODt9Rx4s5K72mWhy3Clzpu83KHF30GNv8Da 6muizPD2+pvB3Yqy1kySwlGZxbHN5IC11Yu62IWw1X+t0/n7/Y+12HGrz8re7YO21pCSlbW2 uNrb3Nvc3W9wdHR2evb298jJyuTk5X5/gz2KvUePwVeXxluax4eIjHWn0GGdyVGUxO3t7qOk pqytr5mbnnqq0RFzr7+/wS2CuNHS0w5xrglvrYi31+bv92ttcQBqqv///yH5BAAAAAAALAAA AAChAGYAAAb/wJ9wSCwaj8iksFFpOp/QaKWhrHIGWAolwF14IeCD2GLZdTqFqnrNbrurj5pv Tq/b74D3kNdKOBAuKyovEikMKAICNwAABgY1OToAD3qVlpdtFXebnD4VlRB9f4GDhYeJi42P kQOYrq+wPwCdtHM1lG4ENKKAgoSGiIqMjpASscfIbQ21tQhvGrt+vaXAqMOrBMna20cMzLTZ bA0Y0aO+psGpxA7c7e0F350MbBka5Lykv6fCqpPu/9o2xOO0YM2AC/ek5UNnTZUFgBCPxRmI B1eSAhEQlpumL90wARFDwjpA8c4nJQEyJjRHbZ86DiJjYhJQsk6NNEgIaFC5cWE1/34rZAqt tKwmnQlIMizYqRHfuZ+peAyd6maCUTpUjHA4wHQlR4bCOlAduwbeVR8gizxQwJWn05bpBFgk S/eIprMFiQxg27XnU5cU6go+8mDW1Vt7FPB1q/BvMKSDIxNZcNbTEAqK2zZtDDcRTMmgf3g7 m6bAgsx933YUsCF06KJXGWQIcHrxZparpboGjaByACwDtHQBw/ZAmQsaN2xIEGB36AJyruZx Tl3P3asHqmtvY9go4u3gkwyo3Dq8eSOjr4Y7z55A5Xns4/c+2yr++YnS7bMnefak/vDd1XTT f+HBZpQzBIKXnlFZJVidWbE5uN11RuUloXP4GeXPhc5R1v8fh9TRRBqIuxlYE2QkhmbVWQ2m GBl0h+HkomQUUuTfjJEVVtOGOErmIUUW9ijZgszAJyRoJtbS4pGRzccMgkyClmEn30UJWo2b 3GilZAHiseVu43VS35ehEUmHkWSC5t4mMqYJmkB2lOdmaFNWOSdo/M2R3Z27GTYdn64VtSSg kk2AIqHPtYnooow26uijkEYq6aSUVmrppZhmqp0JIIBgwnYleCCqByUYIcOoHpgQKqqsiirD EKe26sEMH5RAQhGrivopETDIcEIPwPbggQ23FoFqqUXAEMMIwfYwQgy7EhHrrMUKYQKq0f5j QrMeGMEssCP88EGz5AbbrRAelEv/7gjICjFusCAQ8a66I3xQRLP2ElGCusG+SkS6weYrBAjN xhsRC81W+wPBwcYgLr/cDgEwxMC2O28PBv+wL8XCVouvvhz34LDEzY4AwxAMA5sxQDY0i4O0 Lj/M8bk/TDzCqAiXPMTFGX8L7AkxeOBzxUN8PPC6MXwwMbD+1kzuDCgXHBIMzY4sRM49nOBu s2pMTPMPJMwgtcwqH90wETYwO8LLRQdMcsPVmvAtCxkvXfbCYx8cbLhCUN3v1sF2bW4RKfeQ L89C4BAzESbMoPAPRm87eBEmnGCDseVqjTe8IrUc7K4bA7vrxYID+/XmwB4+tuLBnlBCtkcY 7TmwbJdO/+7lkHM+tdFi/7xzyP9OPkTvtAN+t9+Z0wp77qkLEQPXbEz8K7i35q03sCwI0WzT F/MbPLioTk+98RgPzzEL2Rq9NBHeoxuw+K9aD9HsPZDAuui/c/w9xxbnHTbHI/CY25wGLvap 620iC10PkFc+kTCwBDJonbzw9YEKWlBgBITYCWpHtgYOwQSngljT1Ac97R3Qfab7AdaepzuR EG8G4sMd+Wx3Mw+Iz4PkW1myQGCDpdHMaBeLFqpK6DXUkUuHEAnd0E6WP2DZ7lyFy94EW/gD GCzvB+L74QDvJzIjSM6JKBSW89SFRICQQF1SbGIPnojAHsiwgxkb19qKQAKfQfTNhM0D29Da BTasrTGM56pjucoIEOIF640dlJWokFXEvpWsWoiDwQ1ZYINO2eCG7TJaB4VVAhB84IZ/zCDN 6He3mCgQWExUI8Ty1cgx/i2HfQxZ1gyYx1jKEoFf8yMOQ3LGiBWhe/xipfD02CwmIg5shlTX CdI3QGvpsmSBAyQRCrfLkBiSj+RbpTSnmEI4EgEHz3TWBx6nSSGQIILkOgEIJobLIrCwlIQi gScr2ElLyJOeV9SUPvfJz376858ADahAB0rQghr0oJISQQh+oFCGLrShEH2oRB1K0YhWdKIW zShGN3rRjmrUoxz9qEhDSlKQXjQIADs= --B_3385702907_9312361-- From wil@cloudregistry.net Fri Apr 15 13:26:44 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4926E0674 for ; Fri, 15 Apr 2011 13:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK1Xz1pWNPe1 for ; Fri, 15 Apr 2011 13:26:44 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2393EE066A for ; Fri, 15 Apr 2011 13:26:43 -0700 (PDT) Received: by qyk29 with SMTP id 29so4066074qyk.10 for ; Fri, 15 Apr 2011 13:26:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.73.95 with SMTP id p31mr1839363qcj.34.1302899203623; Fri, 15 Apr 2011 13:26:43 -0700 (PDT) Received: by 10.229.12.193 with HTTP; Fri, 15 Apr 2011 13:26:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Apr 2011 06:26:43 +1000 Message-ID: From: Wil Tan To: James Gould Content-Type: multipart/alternative; boundary=0016e6546d0035caaf04a0fadc7a Cc: provreg@ietf.org Subject: Re: [provreg] LP naming convention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:26:44 -0000 --0016e6546d0035caaf04a0fadc7a Content-Type: text/plain; charset=UTF-8 On Fri, Apr 15, 2011 at 11:01 PM, James Gould wrote: > Will, > > Thanks for bringing this up. I prefer the lowercase pvrc that is in line > with the other EPP specifications (e.g. roid). > > Thanks, James. I agree that lowercase is better. .wil --0016e6546d0035caaf04a0fadc7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 15, 2011 at 11:01 PM, James = Gould <jgould@v= erisign.com> wrote:
Will,

Thanks for bringing this up. =C2=A0I prefer the lowercase pvrc that is in l= ine with the other EPP specifications (e.g. roid). =C2=A0


Thanks, James. I a= gree that lowercase is better.

.wil=C2=A0
--0016e6546d0035caaf04a0fadc7a-- From provreg@contact.dotandco.com Mon Apr 18 15:46:22 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F239FE0864 for ; Mon, 18 Apr 2011 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPNR1BEohvCp for ; Mon, 18 Apr 2011 15:46:22 -0700 (PDT) Received: from mail.dotandco.com (mail.dotandco.com [IPv6:2001:470:1f13:4c2:74aa:293f:3e3d:c181]) by ietfc.amsl.com (Postfix) with ESMTP id 0C795E085E for ; Mon, 18 Apr 2011 15:46:18 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3IMkHEI010925; Tue, 19 Apr 2011 00:46:17 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p3IMkGd5010923; Tue, 19 Apr 2011 00:46:16 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Tue, 19 Apr 2011 00:46:14 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110418224614.GP28463@home.patoche.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Tue, 19 Apr 2011 00:46:17 +0200 (CEST) Subject: Re: [provreg] LP naming convention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:46:23 -0000 Wil Tan 2011-04-15 14:12 > James Gould had voiced out a valid point, i.e. the elements are named > in a lowercase-with-underscores rather than camelCase. The latter is > more consistent with the rest of EPP, so I propose updating it to the > following on the next iteration of the draft: > > application_id => applicationID > trademark_name => trademarkName > trademark_number => trademarkNumber > trademark_locality => trademarkLocality > trademark_entitlement => trademarkEntitlement > pvrc => PVRC (or stay all lowercase, I'm ambivalent) > > Any comments or objections? I agree very much with this change, even if it does not change anything technically I think it is better to stay in line with the other EPP drafts, and I wanted to suggest this but feared to be too much a nitpicker, so thanks James to have raised the point :-) On a related note, for me the 4 trademark nodes are atomic, as reprensenting a single "entity". So for me it would make even more sens to have a node with the name, number, locality and entitlement being children of it. I think it makes things clearer (as to see what is related to the trademark per se, and what is related to the trademark use in a given registry startup phase), and easier to expand if needed later on. I have no direct experiences with trademark claring houses, but I agree their input here would be very much valuable. Also seeing what was done for ENUM as Bernie suggested could be useful. As for the the draft, some quick comments: - §2 : Maybe add a not that an applicationID is like a domain ROID, the registry should make sure it is a unique number, which is needed later on (see §3.2 comment below) - §2.1 : I think the element is always useful, and it should not be derived from the time or the applicationID encoding. It can of course not be a MUST, but I would think having its presence as a SHOULD would be best. - §2.2 : for I would advise using a scheme similar to such as having the string as an attribute so that the node data is optional but could be a text in human form with more info. In order not to repeat problems with have with EPP, the draft should clearly specify if and how registry can use other statuses (than those defined in the draft) if they need. The schema should be in such a way that adding new statuses is easy, and can be done without breaking everything. Also, yes, I think we should allow multiple statuses at a time. - §2.3 I think a date is missing, either (trademark) application date or granted date, or both. - §3.2 when the registry does a lp:info, the applicationID should be enough, as soon as the registry makes it unique (same trademark used in 2 phases would have 2 applicationIDs) The lp:phase should of course be in the registry reply. In the registry reply I believe it to be strange that all nodes are optional, except the applicationID. If an applicationID exists it means something has been submitted so not all elements later can be optional, at least one or some must be defined. - §3.2.1 I fail to parse the first sentence : « The client MUST ensure that any successful command results in a response that an element is returned in the response. » Maybe it is completely clear for English speaker, in which case, can you make it just a little simpler to non native English speaker ? - §3.3 we take the case that 1 applicationID = 1 domain name Are there cases where we should or can consider 1 applicationID = more than one domain names ? (either because multiple domain names can be derived from the same trademark depending for example on canonicalisation rules, or because the trademark owner gives a list of domain names ordered from most prefered to least prefered, in case its first choice is alreay taken) Same remarks as before on all elements being optional: I think at least one or some may be needed. I'm uneasy with the registry reply, specifically the domain:creDate and domain:exDate and also the 1000 result code. Since there is further processing, I think we should have a 1001, not a 1000. Also, since the domain name is not really registered, the dates will be wrong. I know that at least one of them is mandatory, but I think in this way this create a problem. Registrars will need to adapt their system. There should be also some text about the domain:period asked by the registrar: in some launch phases, the registry may mandate the initial registration period, so some text should make clear what happens when the registrar asks for another period than the one allowed by the registry (is the operation accepted or refused ?) - §3.3.2 : same problem for first sentence as §3.2.1 above - §3.4 : same comment as above, the applicationID is enough in my view I also think that the update section should more concentrate on updating the info related to the application instead of the domain name. During the launch phases typically domain names are not published, so there is no sens changing their nameservers. Also for the contacts/registrants there may be registry policies forbidding change because, for example, the registrant may be the trademark owner or something like that. On the contrary one may need to change data about the application, such as adding the application granted date if it happens after the initial submission, or add a new preverification code. - §3.5 : as above, isn't the applicationID enough ? Hope that helps, -- Patrick Mevzek From jan@ipclearinghouse.org Tue Apr 19 01:42:20 2011 Return-Path: X-Original-To: provreg@ietfc.amsl.com Delivered-To: provreg@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DFE52E06A5 for ; Tue, 19 Apr 2011 01:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y58o6bKBqZ1I for ; Tue, 19 Apr 2011 01:42:20 -0700 (PDT) Received: from arthur.vbchosting.be (62-213-193-90.colo.housingcenter.be [62.213.193.90]) by ietfc.amsl.com (Postfix) with ESMTP id F3D8FE0665 for ; Tue, 19 Apr 2011 01:42:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id 852A4C8A9C for ; Mon, 18 Apr 2011 19:17:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at arthur.vbchosting.be Received: from arthur.vbchosting.be ([127.0.0.1]) by localhost (arthur.vbchosting.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VOCzd2YVG4w for ; Mon, 18 Apr 2011 21:17:23 +0200 (CEST) Received: from arthur.vbchosting.be (localhost.localdomain [127.0.0.1]) by arthur.vbchosting.be (Postfix) with ESMTP id 1BB8EC88A8 for ; Mon, 18 Apr 2011 21:17:23 +0200 (CEST) Received: (from apache@localhost) by arthur.vbchosting.be (8.13.8/8.13.8/Submit) id p3IJHLrG021859; Mon, 18 Apr 2011 21:17:21 +0200 X-Authentication-Warning: arthur.vbchosting.be: apache set sender to jan@ipclearinghouse.org using -f Received: from 94.225.68.235 (SquirrelMail authenticated user jan@nexperteam.be) by www.nexperteam.be with HTTP; Mon, 18 Apr 2011 21:17:21 +0200 (CEST) Message-ID: <55821.94.225.68.235.1303154241.squirrel@www.nexperteam.be> Date: Mon, 18 Apr 2011 21:17:21 +0200 (CEST) From: "Jan Jansen" To: provreg@ietf.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [provreg] Splitting the launch phase block in 2 parts X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jan@ipclearinghouse.org List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 08:42:21 -0000 Dear all, Thank you for this extensive and detailed effort to make the EPP scheme ready for 'sunrise'. Trying to extend the EPP scheme to provide means to incorporate validating services is a complicated matter. We will have to distinguish two different phases 1. Sending in info to show a certain right 2. Applying for an extension linked to the right Actually these phases can be interchanged and often a code is used to link the 2 different phases. As examples : .eu provided a code to a sunrise application that could be used to send in documentary evidence .co allowed to specify a code to register a name in sunrise that was verified against a clearing house If you want the EPP model to be extended to also include the data to show a certain 'right' than you will need a lot more than just a name, number and country. (Such as type of right, if the right has been given in concession, ...) Despite me being around IP lawyers for quite some time now, I always get the comment that I'm a technical guy and see this things way to simple. These are of course general remarks and I'm not certain how to get them into an EPP schema. But perhaps we should divide in an section (denoting the right) and an section (denoting the domain name application). The latter will be most easy to fill and could (should?) contain : domain name, phase, application id and/or pvrc. The first (lp:right) is more difficult. It will probably vary much from registry to registry. It depends on which rights you will allow to be applied for (eg: official TM, province/city/..., local business and many others). On a much lighter note I would like to change the wording in the transition state from 'cancelled' to 'rejected' since for me 'cancel' involves an active action on the registrar side and this seems to be a much more 'passive' state change from the registrar view point. Thank you all for putting your energy into this project. Jan Jansen From wil@cloudregistry.net Sat Apr 30 10:45:16 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51063E0685 for ; Sat, 30 Apr 2011 10:45:16 -0700 (PDT) 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 dUL3iUSTkjr7 for ; Sat, 30 Apr 2011 10:45:14 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A732E0674 for ; Sat, 30 Apr 2011 10:45:10 -0700 (PDT) Received: by qyk29 with SMTP id 29so769637qyk.10 for ; Sat, 30 Apr 2011 10:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.3 with SMTP id b3mr4775029qcb.194.1304185510356; Sat, 30 Apr 2011 10:45:10 -0700 (PDT) Received: by 10.229.228.80 with HTTP; Sat, 30 Apr 2011 10:45:10 -0700 (PDT) In-Reply-To: <55821.94.225.68.235.1303154241.squirrel@www.nexperteam.be> References: <55821.94.225.68.235.1303154241.squirrel@www.nexperteam.be> Date: Sun, 1 May 2011 03:45:10 +1000 Message-ID: From: Wil Tan To: jan@ipclearinghouse.org Content-Type: multipart/alternative; boundary=0015175d014c10e9b304a2265a4b Cc: provreg@ietf.org Subject: Re: [provreg] Splitting the launch phase block in 2 parts X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 17:45:16 -0000 --0015175d014c10e9b304a2265a4b Content-Type: text/plain; charset=UTF-8 Thanks for your comments, Jan. On Tue, Apr 19, 2011 at 5:17 AM, Jan Jansen wrote: > We will have to distinguish two different phases > 1. Sending in info to show a certain right > 2. Applying for an extension linked to the right > > Agreed, and the LP extension is indeed meant to cover a stripped down version of the latter i.e. simply "applying for a domain without the guarantee that it will be allocated." An implementation could then choose to either: 1. not accept any other field (as in the case of land rush type launch scenarios) 2. accept only a pre-verified code (pvrc) where it is used by the registry to validate against a third party (probably trademark clearing house) using an out-of-band mechanism. 3. accept either the pre-verified code or the set of fields that the applicant may use to claim the right to a mark. Actually these phases can be interchanged and often > a code is used to link the 2 different phases. As examples : > .eu provided a code to a sunrise application that > could be used to send in documentary evidence > This, as I understand, would mean that the "sending in documentary evidence" step is out-of-band. In that case, this extension can be used as in #1 above. > .co allowed to specify a code to register a name > in sunrise that was verified against a clearing house > > This is one of the primary use cases of the extension. > If you want the EPP model to be extended to also > include the data to show a certain 'right' than > you will need a lot more than just a name, number > and country. (Such as type of right, if the right > has been given in concession, ...) > Despite me being around IP lawyers for quite some > time now, I always get the comment that I'm a > technical guy and see this things way to simple. > > This is where we really need the help of the trademark community i.e. people like yourself and the IP lawyers you're referring to ;-) Ideally, we'd define a set of elements to cover the majority of the use cases and make them most/all optional, and let the implementation decide what is required by policy. > These are of course general remarks and I'm not > certain how to get them into an EPP schema. But > perhaps we should divide in an > section (denoting the right) and an > section (denoting the domain > name application). > > I think grouping the trademark-related fields into a parent element was also suggested by Patrick Mavzek. I agree it's more logical to group them together. I'm not sure if there's much to be gained from having the container though. The latter will be most easy to fill and could > (should?) contain : domain name, phase, > application id and/or pvrc. > The first (lp:right) is more difficult. It will > probably vary much from registry to registry. > It depends on which rights you will allow to > be applied for (eg: official TM, province/city/..., > local business and many others). > > Indeed. It is a tricky balancing act to have something generic enough for a wide spectrum of use cases and yet maintaining simplicity and providing semantically correct fields. > On a much lighter note I would like to change the > wording in the transition state from 'cancelled' > to 'rejected' since for me 'cancel' involves an > active action on the registrar side and this seems > to be a much more 'passive' state change from the > registrar view point. > > This makes sense. Unless anyone objects, I will change it in the next iteration of the draft. .wil --0015175d014c10e9b304a2265a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your comments, Jan.

On Tue, A= pr 19, 2011 at 5:17 AM, Jan Jansen <jan@ipclearinghouse.org><= /span> wrote:
We will have to distinguish =C2=A0two different phases
1. Sending in info to show a certain right
2. Applying for an extension linked to the right

<= br>
Agreed, and the LP extension is indeed meant to cover a strip= ped down version of the latter i.e. simply "applying for a domain with= out the guarantee that it will be allocated."

An implementation could then choose to either:
1. not accept any other field (as in the case of land rush type launch sc= enarios)
2. accept only a pre-verified code (pvrc) where it is us= ed by the registry to validate against a third party (probably trademark cl= earing house) using an out-of-band mechanism.
3. accept either the pre-verified code or the set of fields that the a= pplicant may use to claim the right to a mark.

Actually these phases can be interchanged and often
a code is used to li= nk the 2 different phases.
As examples :
.eu provided a code to a sunrise application that
could be used to send in documentary evidence

This, as I understand, would mean that the "sending in document= ary evidence" step is out-of-band. In that case, this extension can be= used as in #1 above.
=C2=A0
.co allowed to specify a code to register a name
in sunrise that was verified against a clearing house


This is one of the primary use cases o= f the extension.

=C2=A0
If you want the EPP model to be extended to also
include the data to show a certain 'right' than
you will need a lot more than just a name, number
and country. (Such as type of right, if the right
has been given in concession, ...)
Despite me being around IP lawyers for quite some
time now, I always get the comment that I'm a
technical guy and see this things way to simple.


This is where we really need the help = of the trademark community i.e. people like yourself and the IP lawyers you= 're referring to ;-)

Ideally, we'd define = a set of elements to cover the majority of the use cases and make them most= /all optional, and let the implementation decide what is required by policy= .

=C2=A0
These are of course general remarks and I'm not
certain how to get them into an EPP schema. But
perhaps we should divide in an
<lp:right> section (denoting the right) and an
<lp:application> section (denoting the domain
name application).


I think grouping the trademark-related= fields into a parent element was also suggested by Patrick Mavzek. I agree= it's more logical to group them together. I'm not sure if there= 9;s much to be gained from having the <lp:application> container thou= gh.


The latter will be most easy to fill and could
(should?) contain : domain name, phase,
application id and/or pvrc.
The first (lp:right) is more difficult. It will
probably vary much from registry to registry.
It depends on which rights you will allow to
be applied for (eg: official TM, province/city/...,
local business and many others).


Indeed. It is a tricky balancing act t= o have something generic enough for a wide spectrum of use cases and yet ma= intaining simplicity and providing semantically correct fields.
=C2=A0
On a much lighter note I would like to change the
wording in the transition state from 'cancelled'
to 'rejected' since for me 'cancel' involves an
active action on the registrar side and this seems
to be a much more 'passive' state change from the
registrar view point.


This makes sense. Unless anyone object= s, I will change it in the next iteration of the draft.

.wil
--0015175d014c10e9b304a2265a4b--