Subject: [weirds] ICANN Whois Specifications

From: Ernie Dainow <[email-masked]>
Date: Mon, 3 Jun 2013 13:58:31 -0400

There are a number of fields defined in ICANN Registry Agreements that are
not reflected in draft-ietf-weirds-json-response-03. As contractual
requirements, some registries will need to report them. I think it would be
best to define standard RDAP elements for these.

A few examples I have come across are:

Domain Object:
  ENS_AuthID
  Maintainer URL (email)
  Sponsoring Registrar IANA ID

Nameserver Object:
  Currently Associated (true/false)
  IP addresses associated

Contact (Entity):
  Currently Associated (true/false)

Registrar (Entity):
  Referral URL:
  Registrar IANA ID

It might be worth a more complete and systematic search of existing ICANN
contracts to locate other missing fields. This could be a useful addition
to draft-ietf-weirds-object-inventory.
http://www.icann.org/en/about/agreements/registries

-Ernie

---

From: Francisco Arias <[email-masked]>
Date: Mon, 3 Jun 2013 11:11:36 -0700

Perhaps Steve's message http://www.ietf.org/mail-archive/web/weirds/current/msg01153.html could be a useful start point.

--
Francisco.

On 6/3/13 10:58 AM, "Ernie Dainow" <[email-masked]<mailto:[email-masked]>> wrote:

There are a number of fields defined in ICANN Registry Agreements that are not reflected in draft-ietf-weirds-json-response-03. As contractual requirements, some registries will need to report them. I think it would be best to define standard RDAP elements for these.

Domain Object:
  ENS_AuthID
  Maintainer URL (email)

Nameserver Object:

Contact (Entity):

Registrar (Entity):
  Referral URL:
  Registrar IANA ID

It might be worth a more complete and systematic search of existing ICANN contracts to locate other missing fields. This could be a useful addition to draft-ietf-weirds-object-inventory.
http://www.icann.org/en/about/agreements/registries

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 3 Jun 2013 18:40:48 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ernie Dainow
Sent: Monday, June 03, 2013 1:59 PM
To: [email-masked]
Subject: [weirds] ICANN Whois Specifications

These requirements refer to today's existing *WHOIS* services. Whether or not they are appropriate additions to RDAP is open to debate. I agree that we should look at them, but I do not think they should be blindly included just because they're part of the legacy system. To be included in RDAP they need to be useful to a large portion of the community.

This is one of the reasons I've been discouraging use of the term "RESTful WHOIS" to describe our work. Saddling ourselves with the WHOIS data model means we're stuck with perpetuating the inefficiencies that come along with it.

Scott

---

From: Andy Newton <[email-masked]>
Date: Tue, 4 Jun 2013 00:45:47 +0000

Ernie,

Thanks for putting this together. Some of these are already covered through other structures. For instance, email addresses are already accounted for in jCard and URLs in links.

I do think registrar ID should be added as it shows up in a lot of whois servers and there is an IANA registry for them.

Some of the others do not have an explanation. What is an ENS_AuthID? And what does "Currently Associated" mean? I don't think we should blindly put in items we don't understand.

-andy

From: Ernie Dainow <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 3, 2013 1:58 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [weirds] ICANN Whois Specifications

Domain Object:
  ENS_AuthID
  Maintainer URL (email)

Nameserver Object:

Contact (Entity):

Registrar (Entity):
  Referral URL:
  Registrar IANA ID

-Ernie

---

From: James Mitchell <[email-masked]>
Date: Tue, 4 Jun 2013 14:04:34 +1000

I have seen ICANN use the term GURID (Globally Unique R-something ID?) for the IANA ID (https://radar.icann.org).

.au does not require registrars to be ICANN accredited, instead a locally-unique identifier is used (the identifier used in EPP to indicate sponsoring registrar). I see no reason why a registrar cannot have both a locally-unique identifier and a globally-unique identifier. The locally unique identifier may or may not meet the ROID syntax requirements of RFC5730.

James

From: Andy Newton <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 4 June 2013 10:45 AM
To: Ernie Dainow <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] ICANN Whois Specifications

Ernie,

-andy

Domain Object:
  ENS_AuthID
  Maintainer URL (email)

Nameserver Object:

Contact (Entity):

Registrar (Entity):
  Referral URL:
  Registrar IANA ID

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Tue, 4 Jun 2013 11:19:55 +0000

From: James Mitchell <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 12:04 AM
To: Andrew Newton <[email-masked]<mailto:[email-masked]>>, Ernie Dainow <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] ICANN Whois Specifications

James,

Here is what I plan to put in the next draft. I think it meets your needs of having both types of identifiers:

      "publicIds" :
      [
        {
          "type": "IANA Registrar ID",
          "identifier" : "1"
        }
      ],

   o  publicIds - an array of objects, with each object containing the

      following memebers:

      *  type - a string denoting the type of public identifier

      *  identifier - a public identifier of the type denoted by 'type'

Let me know if you think we need to add something.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 04 Jun 2013 14:40:22 -0400

On 6/3/2013 8:45 PM, Andy Newton wrote:
> Ernie,
>
> Thanks for putting this together. Some of these are already covered 
> through other structures. For instance, email addresses are already 
> accounted for in jCard and URLs in links.

 From the ICANN Specifications:
     The Maintainer URL (email or website). The maintainer is a person 
that has been designated by the Registrar for the registration of the 
domain (for example a reseller, could also depend on the registrant).

If Maintainer is an email, using a jCard embedded in the Domain object 
would not have context to identify what it is. So it seems best to use a 
jCard in an Entity object and use another role, say "Maintainer", for 
this type of entity.

For a website link, we should recommend the relation type. Best fit by 
name seems to be "service", but this seems to have particular reference 
to Atom. http://www.iana.org/assignments/link-relations/link-relations.xml

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Tue, 4 Jun 2013 20:56:41 +0000

From: Ernie Dainow <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 2:40 PM
To: Andrew Newton <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] ICANN Whois Specifications

If Maintainer is an email, using a jCard embedded in the Domain object would not have context to identify what it is. So it seems best to use a jCard in an Entity object and use another role, say "Maintainer", for this type of entity.

Isn't "registrant" the same thing as "maintainer"? Otherwise I agree.

For a website link, we should recommend the relation type. Best fit by name seems to be "service", but this seems to have particular reference to Atom. http://www.iana.org/assignments/link-relations/link-relations.xml

Agreed.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 05 Jun 2013 12:39:59 -0400

On 6/4/2013 4:56 PM, Andy Newton wrote:
> From: Ernie Dainow <[email-masked] <mailto:[email-masked]>>
> To: Andrew Newton <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>         The Maintainer URL (email or website). The maintainer is a
>     person that has been designated by the Registrar for the
>     registration of the domain (for example a reseller, could also
>     depend on the registrant).
>
>     If Maintainer is an email, using a jCard embedded in the Domain
>     object would not have context to identify what it is. So it seems
>     best to use a jCard in an Entity object and use another role, say
>     "Maintainer", for this type of entity.
>
>
I think the maintainer is separate from the registrant, as in a reseller.
      registrant ----->  reseller -------> registrar

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Jun 2013 17:59:18 +0000

Date: Wednesday, June 5, 2013 12:39 PM

There are many more relationships that a registrant has with a registry than just these two. I don't think it is wise to define a new term for each type of relationship a registrant has with the registry.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 05 Jun 2013 14:23:35 -0400

On 6/3/2013 8:45 PM, Andy Newton wrote:
> ...
>
> Some of the others do not have an explanation. What is an ENS_AuthID? 
> And what does "Currently Associated" mean? I don't think we should 
> blindly put in items we don't understand.
>
>
 From ICANN Specifications:
     ENS_AuthId identifies the authorization of the registration,
     (this enables tracking of registrations performed using the same 
ENS_AuthId).

"Currently Associated" indicates whether the contact or nameserver is 
associated with a registered domain. A concise way to support this is by 
adding some status values, "associated"/"not associated" or more 
generically, "in use"/"not in use".

These have been ICANN requirements in several agreements since 2009.

-Ernie

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 10 Jun 2013 19:16:39 +0700

>       *  identifier - a public identifier of the type denoted by 'type'

Do we now need a registry for these types? Or guidance for naming them
so that there will not be clashes?  For instance, the type could include
the (domain) name of the registry.

No hats.

--Olaf

---

From: Andy Newton <[email-masked]>
Date: Mon, 10 Jun 2013 16:57:07 +0000

>the (domain) name of the registry.

I would think we only need a registry or other information if we believe
this will be machine interpreted. I doubt that is the case for these. But
I'm willing to be proven otherwise.

-andy