Re: [weirds] Response container structure

[Francisco Obispo <[e-mail]>]

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

> On 9/17/12 10:08 PM, "Byron Ellacott" <[e-mail]> wrote:
> 
>> 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.
> 
> That's an interesting take. I'll posit that even if such a flag were
> needed for some policy reason, another policy will pop up needing another
> flag, etcŠ But like you said, if somebody can demonstrate the need...

I think Byron was very clear with his use case, which is exactly the same
that I have.

If you provide an answer that does not have all the components, the client might
generate additional requests asking for the missing pieces.

But I also don't want to make that behavior mandatory, in some other occasions, 
I want exactly the opposite, to prevent hitting the backend with unnecessary
requests if the client does not want them.


> 
>>> 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#s
>> ection-4)
> 
> 
> DOH!
> 
>> 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.
> 
> 
> Exactly!
> 


Can't speak for number registries, but it is very common for name registries
to have unique identifiers for the internet objects they manage: contacts (contact_id),
hosts (host_name), and domains (domain_names).

The ID doesn't need to be universal, it just needs to be unique to that repository.

In my opinion the handle should be used to retrieve the specific object via another
restful request, why not do it? or am I missing something




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

We can start with the general set that EPP has, and the rest will need 
to be done using an extension mechanism, which is nothing more than
placing the additional information in 'extension' field that has a namespace
identifier associated to it.

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