Re: [weirds] Response container structure

[Byron Ellacott <[e-mail]>]

Hi Andy,

On 18/09/2012, at 12:30 AM, Andy Newton wrote:

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

If someone is willing to demonstrate that their weirds server would require such a flag to meet actual or reasonably likely policy conditions, I'd be OK with including it.  Otherwise, it's just one more thing client software will need to consider, and the protocol will need to include.

I have no such need of a flag, as a server I'd rather have fewer code paths and fewer clients coming back for additional data and just shove everything I know out the door in one go, and as a client I'd rather have fewer code paths and fewer round trips and just get everything I can learn in one go.

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

(http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#section-4)

I was thinking that you could just take the data you'd put inline in that section and move it down to an additional, but you're right in that where there's no handle or other identifier you'd be making up a UUID or something just to link the two items together, and it might be quite misleading to clients to have a handle that cannot be queried for separately.

Regarding duplicated data objects, the unified response draft only has one entity object per entity handle.  There's no difference, that I can see.  It might be fractionally harder to find the particular type of entity you want, but one of the things we quickly see with the domain survey data is that the types of entities recorded is one of the most widely variant facets of registration data - I don't know that it's feasible to specify an enumeration of entity roles, and it might be hard to even specify a minimum set.

  Byron