Re: [weirds] Response container structure

[Andy Newton <[e-mail]>]

On 9/17/12 3:10 AM, "Byron Ellacott" <[e-mail]> wrote:

>Hi Francisco,
>
>On 17/09/2012, at 3:49 PM, Francisco Obispo wrote:
>
>> Most JSON parsers that I've used load the whole document in memory, so
>>you would have to have a lot of memory available to process a COM
>>response. :-S
>
>I would hope that looking  up the entire list of registrations underneath
>.COM. is NOT a necessary step in looking up the registration data for
>EXAMPLE.COM. :-)


Well, there are stream parsers available for JSON. The idea that you can
only do this with XML is bunk. And there is so much more wrong with that
pattern than the need for a stream/event parser.

>
>> There are several advantages of this:
>> 
>> 1) If someone stores the file, it can easily identify it;
>
>Still true;


Indeed. This argument keeps getting made as if Section 9 of Using-HTTP
didn't exist. 
(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9
).

>
>> 2) Objects have a "namespace" associated with it, which allows clients
>>to quickly identify the type of object thus be able to process it
>>accordingly (knowing exactly which fields to fetch and how to present
>>them).
>
>Still true; the current unified response draft doesn't include the type
>of the top level response object, which I think is a weakness we can
>correct, but the type of subsequent objects can be easily inferred by its
>position in the response document.  I note your example assumes that
>something contained in $response_json->{additional}->{contacts} is, in
>fact, a contact, too. :-)


Adding an "objectClass" member to the top level object is superfluous.
Certainly if the top level object has the members "startAddress" and
"endAddress", software confusing it for a name server object is poorly
written. But I'm willing to add this if we can finally quit arguing this
topic.

>
>> 3) If the "returnAll" flag is turned "on", (which should be definable
>>by registry policy), the response will also contain an "additional"
>>section with the additional "objects" identifying the query.
>
>Expand or do not expand the sub-objects; interesting potential discussion
>over a "returnAll" flag to have, I don't feel strongly either way, though
>it would be perhaps polite to make the reference a URI instead of an
>opaque string, if you're not going to include the actual data.

It is unnecessary complexity. We do this in the ARIN RESTful Whois service
and people get confused by it and generally hate it. Once they figure it
out, the set returnAll to true for everything.

>
>> 5) There is coherence with EPP with the ability to support registry
>>objects in general, so a group of people could work on the various
>>objects for their own types of registries: names, and numbers working
>>independently but agreeing on common object types: contacts, hosts
>
>Still true;


Agreed, and to expand further on this point: The EPP model is actually
different than the one being described here. In the EPP model, every
difference of a contact, name server, domain, etcŠ is a new object class
(that is if LunarNIC wants to add custom data to the contact class, they
override completely the standard contact class). In the EPP world, making
sure the client and server have a perfect understanding is essential
because money is changing hands, it is a read/write protocol, there is a
contractual relationship between the actors, and set of actors is limited
to a smaller community. None of that is true for WEIRDS. Requiring a
generic WEIRDS client to know a specialized object class for any registry
that simply wants to add one bit of custom data is to high a bar for the
purposes we need.


>I will freely admit that I prefer nested for no particular technical
>reason.  It "feels" like a flat model exposes an implementation specific
>abstraction of data, while a nested model "feels" like it talks about the
>registration information as a cohesive whole as seen from that
>perspective, but these are clearly not technical justifications, they are
>aesthetic.
>
>Are there technical justifications either way that I'm missing?


Actually, yes there is a very good technical reason. Not all registries
wish to model all data as first class objects. This is the cause of the
issue of name servers being attributes on domains vs being first class
objects. See section 4 of Unified Response
(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9
). I also see that we will have this issue with entities.

-andy