headers
Francisco Obispo | 11 May 2011 22:07

Re: Splitting the launch phase block in 2 parts

Sorry for jumping in late, I tried to re-subscribe shortly after the list was reactivated but couldn't do it..

I'm looking at the archives, and it seems like you guys have made some progress, which is of course good.

Here are some of my comments on the last email:

> 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.
> 

My view from the beginning has been to keep the registry business away from the IP business as much as
_possible_, we do not want to model a IP database into our Registry repository. However if the IP
repository manager wants to use EPP to manage their objects it's good for the protocol itself, and they're
welcome to do so.

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Mevzek | 18 May 2011 00:09

Re: EPP LaunchPhase Extension: draft requirements and scope

Wil Tan <wil <at> cloudregistry.net> 2011-04-12 18:24
> The draft is now posted to the IETF repository:
> 
>   http://www.ietf.org/internet-drafts/draft-tan-epp-launchphase-00.txt

In case you have not seen it already, there is a similar extension at
http://cocca.org.nz/index.php/cocca-tools/extensions.html

It may be another example of what is already done on the field.

HTH.

--

-- 
Patrick Mevzek
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |
headers
Wil Tan | 21 May 2011 13:12
Favicon
Gravatar

Re: EPP LaunchPhase Extension: draft requirements and scope

Hi Patrick,

On Wed, May 18, 2011 at 8:09 AM, Patrick Mevzek <provreg <at> contact.dotandco.com> wrote:
Wil Tan <wil <at> cloudregistry.net> 2011-04-12 18:24
> The draft is now posted to the IETF repository:
>
>   http://www.ietf.org/internet-drafts/draft-tan-epp-launchphase-00.txt

In case you have not seen it already, there is a similar extension at
http://cocca.org.nz/index.php/cocca-tools/extensions.html

It may be another example of what is already done on the field.


Thanks for the pointer.

It's not clear how one would manage multiple applications for the same domain name with this extension. Do you know if that's a supported use case?
It does have an interesting feature which we hadn't envisioned though, which is the ability to submit multiple trademark claims in the same create command. In our limited experience, and as far as I can tell in the generic TLD sunrise phases, there hasn't been a need for that. Do folks think that it is a useful thing to have?

.wil
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Gavin Brown | 22 May 2011 19:13
Gravatar

Re: EPP LaunchPhase Extension: draft requirements and scope

On 21/05/2011 12:12, Wil Tan wrote:
> Hi Patrick,
>
> On Wed, May 18, 2011 at 8:09 AM, Patrick Mevzek
> <provreg <at> contact.dotandco.com <mailto:provreg <at> contact.dotandco.com>> wrote:
>
>     Wil Tan <wil <at> cloudregistry.net <mailto:wil <at> cloudregistry.net>>
>     2011-04-12 18:24
>      > The draft is now posted to the IETF repository:
>      >
>      > http://www.ietf.org/internet-drafts/draft-tan-epp-launchphase-00.txt
>
>     In case you have not seen it already, there is a similar extension at
>     http://cocca.org.nz/index.php/cocca-tools/extensions.html
>
>     It may be another example of what is already done on the field.
>
>
> Thanks for the pointer.
>
> It's not clear how one would manage multiple applications for the same
> domain name with this extension. Do you know if that's a supported use case?
> It does have an interesting feature which we hadn't envisioned though,
> which is the ability to submit multiple trademark claims in the same
> create command. In our limited experience, and as far as I can tell in
> the generic TLD sunrise phases, there hasn't been a need for that. Do
> folks think that it is a useful thing to have?

The traditional approach in computer science is to allow 0, 1 or ∞ 
instances of something :-)

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |
headers
Gavin Brown | 22 May 2011 20:39
Gravatar

Re: EPP LaunchPhase Extension: draft requirements and scope

With my serious hat on, I don't see what benefit there would be in allowing multiple claims for an
application. If an applicant has multiple claims over a domain name, then surely they should just use the
"strongest" one?

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

On 22 May 2011, at 18:13, Gavin Brown <gavin.brown <at> centralnic.com> wrote:

> On 21/05/2011 12:12, Wil Tan wrote:
>> Hi Patrick,
>> 
>> On Wed, May 18, 2011 at 8:09 AM, Patrick Mevzek
>> <provreg <at> contact.dotandco.com <mailto:provreg <at> contact.dotandco.com>> wrote:
>> 
>>    Wil Tan <wil <at> cloudregistry.net <mailto:wil <at> cloudregistry.net>>
>>    2011-04-12 18:24
>>     > The draft is now posted to the IETF repository:
>>     >
>>     > http://www.ietf.org/internet-drafts/draft-tan-epp-launchphase-00.txt
>> 
>>    In case you have not seen it already, there is a similar extension at
>>    http://cocca.org.nz/index.php/cocca-tools/extensions.html
>> 
>>    It may be another example of what is already done on the field.
>> 
>> 
>> Thanks for the pointer.
>> 
>> It's not clear how one would manage multiple applications for the same
>> domain name with this extension. Do you know if that's a supported use case?
>> It does have an interesting feature which we hadn't envisioned though,
>> which is the ability to submit multiple trademark claims in the same
>> create command. In our limited experience, and as far as I can tell in
>> the generic TLD sunrise phases, there hasn't been a need for that. Do
>> folks think that it is a useful thing to have?
> 
> The traditional approach in computer science is to allow 0, 1 or ∞ instances of something :-)
> 
> 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 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Jothan Frakes | 23 May 2011 02:16
Picon
Gravatar

Re: EPP LaunchPhase Extension: draft requirements and scope

Actually, documentary support in the form of multiple trademarks on a given string would prove deeply helpful to some of the providers, as the weight (ie # of trademarks) may be a tiebreaker in the presence of dueling applicants on a string.

We might see some providers operate in that manner.  May as well leave it if it hurts nothing.

Sent from my jphone

On May 22, 2011 12:10 PM, "Gavin Brown" <gavin.brown <at> centralnic.com> wrote:

With my serious hat on, I don't see what benefit there would be in allowing multiple claims for an application. If an applicant has multiple claims over a domain name, then surely they should just use the "strongest" one?


G.

--
Gavin Brown
Chief Technology Officer

CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs


CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered...

On 22 May 2011, at 18:13, Gavin Brown <gavin.brown <at> centralnic.com> wrote:

> On 21/05/2011 12:12, Wi...

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Jothan Frakes | 27 May 2011 19:56
Picon
Gravatar

Perhaps out of scope, but valuable: IDN Codepoint

Hi-

I am spending a bit of time with the Universal Acceptance aspect of
the new TLD launches, as well as spending a fair amount of time in my
volunteer role with the Mozilla Foundation on the IDN White-list and
the curation efforts for the Public Suffix List ( PublicSuffix.org is
the URL ).

I am noticing something that might be a worthwhile standardization in
and around having some means to identify to the registrars what are
and are not legal characters to receive registrations on for a given
TLD.  I wonder if a call that could pull down the Unicode code points
and/or any registry specific normalization, case folding, or homonym
replacement mapping  might be important to have.

Each registry seems to have strong opinions about how their solution
is the best, there are numerous cultural-linguistic elements and
sensitivities that a registry might make for having their own specific
mappings, or other things that make the character set code points
distinct to a TLD.

Mileage varies in current IDN implementations, though there are some
standardizations (ie the JET Guidelines).

The status quo in registry launches is that there is a
sunrise[1..x]->landrush->general availability cycle that happens in
the legal roman characters, followed by later launches for IDN.  What
I want to make sure of is that registries that wish to start day 1
with IDN inclusive have the ability to do so in a clean and sane
manner that is unified so that registrars can assimilate them.

Is this obtuse to our focus?

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 3 comments |
headers
Gavin Brown | 31 May 2011 12:53
Gravatar

Re: Perhaps out of scope, but valuable: IDN Codepoint

> [snip]
> Is this obtuse to our focus?

I don't think it has any relevance to the LaunchPhase extension.

EPP currently has no way to signal any metadata relating to IDNs. There
was a draft for an extension but it expired some time ago.

EPP is strictly a provisioning protocol, and therefore signalling of
policy (such as what code points are permitted) is out of scope. The
current best practice is for registries to submit their IDN tables to
IANA for publication. These can then be used by registrars to
pre-validate domains before attempting to register them.

Having said that, an EPP extension that extended the semantics of
<check> might be useful - something like this:

  <?xml version="1.0" encoding="utf-8" standalone="no"?>
  <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    <command>
      <check>
        <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
          <domain:name>xn--eqrt2g.xn--fiqs8s</domain:name>
        </domain:check>
      </check>
    </command>
    <extension>
      <validate:check xmlns="urn:centralnic:params:xml:ns:validate-1.0">
        <validate:language>zh</validate:language>
      </validate:check>
    </extension>
  </epp>

We implemented a function in our HTTP Toolkit [1] to do something very
similar.

G.

1: https://www.centralnic.com/registrars/toolkit/doc/validate_domain

--

-- 
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.

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 2 comments |
headers
Francisco Obispo | 31 May 2011 16:23

Re: Perhaps out of scope, but valuable: IDN Codepoint

And not even that,

Since you're using XML to exchange the request, if you specify the appropriate character encoding and pass
the document with entities such as:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
 <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   <command>
     <check>
       <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
         <domain:name>espa&#241;ol.com</domain:name>
       </domain:check>
     </check>
   </command>
 </epp>

On the registry side, you should be able to decode it properly and generate a UTF-8 string with: español.com

Which can be validated in the registry.

IDNs should be obscured to the client as much as possible. There's no need for them to know at this level that
this domain name translates into xn--espaol-zwa.com since that's something that the registry must
handle internally. 

Francisco

On May 31, 2011, at 3:53 AM, Gavin Brown wrote:

>> [snip]
>> Is this obtuse to our focus?
> 
> I don't think it has any relevance to the LaunchPhase extension.
> 
> EPP currently has no way to signal any metadata relating to IDNs. There
> was a draft for an extension but it expired some time ago.
> 
> EPP is strictly a provisioning protocol, and therefore signalling of
> policy (such as what code points are permitted) is out of scope. The
> current best practice is for registries to submit their IDN tables to
> IANA for publication. These can then be used by registrars to
> pre-validate domains before attempting to register them.
> 
> Having said that, an EPP extension that extended the semantics of
> <check> might be useful - something like this:
> 
>  <?xml version="1.0" encoding="utf-8" standalone="no"?>
>  <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
>    <command>
>      <check>
>        <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>          <domain:name>xn--eqrt2g.xn--fiqs8s</domain:name>
>        </domain:check>
>      </check>
>    </command>
>    <extension>
>      <validate:check xmlns="urn:centralnic:params:xml:ns:validate-1.0">
>        <validate:language>zh</validate:language>
>      </validate:check>
>    </extension>
>  </epp>
> 
> We implemented a function in our HTTP Toolkit [1] to do something very
> similar.
> 
> G.
> 
> 1: https://www.centralnic.com/registrars/toolkit/doc/validate_domain
> 
> -- 
> 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.
> 
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Hosted <at>  Programme Manager
email: fobispo <at> isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Francisco Obispo | 31 May 2011 17:20

Ways of querying for linked objects...

In RFC 5732 (Host Mapping for EPP), on the statuses section, there is:

-  linked

      The host object has at least one active association with another
      object, such as a domain object.  Servers SHOULD provide services
      to determine existing object associations.

There's no mention on how the server should provide theses services. In addition, I've seen several
registries implement queries such as this using very different methods (extensions, SOAP, REST, etc.)

I'm also thinking on a use case, where a registrar my want to get the list of objects it sponsors.. there's no
way in EPP to do this now.

Do yo guys think this is worth standardizing? I think this is the right kind of use for an extension.

Francisco Obispo 
ISC

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 9 comments |

Gmane