Subject: [weirds] URIs in draft-newton-et-al-weirds-rir-json-response-01

From: Alex Sergeyev <[email-masked]>
Date: Wed, 23 May 2012 13:59:01 -0400

Hi,

I have a small question/proposal about weirds JSON responce format.
Mostly about "uris" section in examples from
http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-json-response-01

   {
     "handle" : "XXXX-RIR",
     "startAddress" : "10.0.0.0",
     "endAddress" : "10.0.0.255",
     "ipVersion" : 4,
     "name": "NET-RTR-1",
     "description" : [ "A network used for routing" ],
     "type" : "DIRECT ALLOCATION",
     "country" : "AU",
     "parentHandle" : "YYYY-RIR",
     "remarks" : [
       "she sells seas shells",
       "down by the seashore"
     ],
     "uris" : [
       {
         "type" : "source",
         "uri" : "http://whois-rws.net/network/xxxx"
       },
       {
         "type" : "parent",
         "uri" : "http://whois-rws.net/network/yyyy"
       },
       {
         "type" : "held",
         "uri" : "http://example.net/location/xxxx"
       }
     ],
     "registrationDate" : "20110509",
     "lastChangedDate" : "20110509",
     "lastChangedBy" : "[email-masked]"
   }

In my opinion, "type" inside of each URI section is really not saying much.
Would anyone agree that automated tools would be easier to design if
say it'll be "ref" element instead. and it would refer to actual keys
inside of JSON:

   "uris" : [
       {
         "ref" : "source",
         "type": "network",
         "uri" : "http://whois-rws.net/network/xxxx"
       },
       {
         "ref" : "parentHandle",
         "type": "network",
         "uri" : "http://whois-rws.net/network/yyyy"
       },
       {
         "type" : "held",
         "ref" : null,
         "uri" : "http://example.net/location/xxxx"
       }
     ],

Something in this sense, that will allow automatic tools to make
better judgement of URIs. Also in case of contacts for domain
registrations it would be nice to do structured "refs", like ' "ref":
"contact/tech" '

I do have another note about generic "status" field for all future
JSON info responses. I'm adding it here because it makes sense if
things above are interesting.

Right now, similar to EPP in domain registration world WEIRDS will likely show:

status: ["clientTransferProhibited", "clientDeleteProhibited",
"clientUpdateProhibited"]

which in my opinion is not having value to consumer of WEIRDS info.

When I find info about domains for EPP purposes, I need to
differentiate between "clientTransferProhibited" and
"serverTransferProhibited". And I will. But, when i'm in WHOIS/WEIRDS
context, I think it's unnecessary information. My goal is to find few
basic bits of data:

"status" : {
   "transferProhibited" : true,
   "updateProhibited"  : true,
   "deleteProhibited"   : true,
   "Hold" : false
}

same thing, it'll help to add additional info URIs to those elements:

{
"ref" : "status/Hold",
"uri": ....
}

meaning that ideally you can EXTEND that status block with meaningful keys

It might be impractical for all interested parties for sure but I just
thought to start this conversation while working on toy implementation
for our own needs.

Sincerely,

Alex Sergeyev,
Dyn Labs

---

From: Andy Newton <[email-masked]>
Date: Wed, 23 May 2012 20:24:08 +0000

>         "uri" : "http://example.net/location/xxxx"

That sounds reasonable to me. Though, what would the type be for pointing to that network in a legacy system, such as ARIN's current Whois-RWS system? Would it be "arin_network"?

> registrations it would be nice to do structured "refs", like ' "ref":

That sounds reasonable to me.

>   "deleteProhibited"   : true,

That sounds like a good idea.

> same thing, it'll help to add additional info URIs to those elements:

but I don't follow this. Can you provide another example or explain it further?

> meaning that ideally you can EXTEND that status block with meaningful keys

-andy

---

From: Francisco Arias <[email-masked]>
Date: Wed, 23 May 2012 13:50:49 -0700

Hi Alex,

See below.

>   "deleteProhibited"   : true,

I disagree, or should I say, it depends on who you are whether you care if
it's server or client hold, etc. Perhaps for unsophisticated users it
might be enough what you propose, but not for others.

For example, in ICANN we process complains from registrants when things go
wrong with their registration. We have no other source of information but
the public information in the DNRD service provided by the
registry/registrar. Having the possibility of differentiating whether an
issue is at the registrar or the registry is valuable, to say the less.

I can see similar needs for other parties looking at the data.

>meaning that ideally you can EXTEND that status block with meaningful keys

Not sure what you mean here.

>thought to start this conversation while working on toy implementation

Great!!!

__

Francisco.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 May 2012 22:24:35 -0400

[Full disclosure: Alex is my colleague, but we haven't discussed this
email in advance]

> That sounds reasonable to me. Though, what would the type be for pointing to that network in a legacy system, such as ARIN's current Whois-RWS system? Would it be "arin_network"?

It seems to me, amazed as I am to be saying this, that we could either
invent an IANA registry or else find one that matches our needs (I'm
wondering about URI schemes here).  If there is one that matches our
needs, we might needs to add some entries, but that surely won't be
the end of the world.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alex Sergeyev <[email-masked]>
Date: Thu, 24 May 2012 14:05:16 -0400

Andy, Francisco, everyone,

let me comment what I meant

> might be enough what you propose, but not for others.

I wish you would comment on reasons why ICANN cannot use EPP but I can
imagine it might be "complicated" :)
Anyhow, I''m not pushing for this change. It just was logical to have
object structure vs array of literals. Not critical though.

>>meaning that ideally you can EXTEND that status block with meaningful keys

What I meant here is that sometimes we need to have info-service for
new kinds of statuses, and URIs section could become neat explanation
for details about that status.

{
   status: {
          something : true
   },
   ...
   uris: [
       {  ref: status/something,  uri: more-info-here }
   ]
}

So far as I don't see any "oh it could be useful for us", I think I'm
over-complicating it :) Will only continue with my idea about "ref"
element for "uris" array then.

--
Alex

---

From: Arturo Servin <[email-masked]>
Date: Thu, 24 May 2012 15:14:29 -0300

Hi,

	I am a bit confused.

	We are discussing draft-newton-et-al-weirds-rir-json-response-01, which is for numbers, no names.

	So basically, unless I am mistaken no RIR have these status in the allocations/assignments they made.

"status" : {

	In any case, a resource is either: allocated, assigned, reserved or available.

	Or are we talking about other kind of status?

	For names, I guess we could recycle the same structure (status) but with different content (as suggested by Alex).

Regards,
as

On 24 May 2012, at 15:05, Alex Sergeyev wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Francisco Arias <[email-masked]>
Date: Thu, 24 May 2012 18:06:46 -0700

See below.

>object structure vs array of literals. Not critical though.

That was just an example, but I think in general you would want to have
the full information available.

>element for "uris" array then.

About having and URI that provides information about the meaning of the
status, I like that. Actually, I remember there is a new policy that is
already approved or in the works to have precisely that requirement in the
gTLD world.

__

Francisco.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 25 May 2012 16:29:33 +0200

On Fri 25/May/2012 03:06:46 +0200 Francisco Arias wrote:
> About having an URI that provides information about the meaning of the
> status, I like that.

While I like that too, I wonder why do we need to have cross
references within the same record, rather than, say:

{
   "transferProhibited" :  { "status": true},
   "updateProhibited"  :  { "status": true},
   "deleteProhibited"   :  { "status": true},
   "Hold" :  { "status": false,
               "uri": non-empty-uri-here}
}

The same question holds for entities, where Section 5 has:

{
   "handle" : "XXXX-RIR",
   "names": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ],
   "emails" : [ "[email-masked]", "[email-masked]" ],
   // ...
}

If there were a relationship between names and emails, like the
exemplified data tend to suggest, it might be simpler to make it
explicit, for example like so:

{
   "handle" : "XXXX-RIR",
   "people": [
      { "name": "Joe Bob, Inc.",
        "email": "[email-masked]"},
      { "name": "Bobby Joe Shopping",
        "email": "[email-masked]"}],
   // ...
}

The former representation is more compact, the latter less ambiguous.

Note: I'm not proposing a change, just querying the design choices and
the rationale behind them.

---

From: Andy Newton <[email-masked]>
Date: Fri, 25 May 2012 14:56:31 +0000

> The former representation is more compact, the latter less ambiguous.

You are assuming a one-to-one relationship, and that is not necessarily true. Also the mapping is that the entity has a set of names and a set of emails, not that the entity has a set of name/email pairs.

-andy

---

From: Alex Sergeyev <[email-masked]>
Date: Sat, 26 May 2012 08:30:57 -0400

>               "uri": non-empty-uri-here}
My original thought about JSON format (before I saw draft proposals)
was to have something like that, putting URIs close to things they
describe... BUT, when I read the document, it made way more sense for
automated parser and generator to have things in one place, rather
than checking every field to be "just value" or "value and uri".

I'm not saying that your format makes things any worse. I'm just
thinking that URIS block can be a flexible tool to put any link you
would need to show.

Alex.