Re: [weirds] Response container structure

[Francisco Obispo <[e-mail]>]

Hi Andy,

Thanks for taking the time to go over my concerns again,

here are more comments:


On Sep 17, 2012, at 7:30 AM, Andy Newton <[e-mail]> wrote:

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

I have not use such parsers in JSON, I don't doubt they exist, but the ones
that I've used and are common to both Perl, Python and C++ are not event-based.

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

yes I've seen that, and perhaps it's the fact that the elements are intermixed with the object attributes what generates me the additional noise.



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

In sync with my previous comment, so please do!.




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

I wouldn't call it complexity, it's a feature, users don't have to know about it unless a registry supports it, you can provide some reasonable default for your setup, but let others decide on their experience.


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

Yes and no,

EPP is not _always_ about exchanging money, secondly, EPP is considered a
standard for Registry-Registrar interaction, so having a protocol to represent
registry data should at least make sure that it is capable of covering the
object types and extensions used by registries with EPP.

I'm not saying that the same information will be made available, that's registry
policy, but at the minimum they should be bundled.

Imaging building a car that can go 100 mph, but only using tires that cannot 
go over 40 mph..

We will start hitting serious limitations as more registries try to adopt it,
and will fall back to P43 whois where they can publish exactly what they need
in free form format.

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

Registry policy should be outside of this specification, the policy cannot
be whether they want to support an object or not, the policy is whether they
make the information public or not, and if they do, then the way of making
it public is by representing them in objects just like everyone else.

Francisco Obispo 
Director of Applications and Services - ISC
email: [e-mail]
Phone: [phone] || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE