Re: [weirds] Response container structure

[Andy Newton <[e-mail]>]

On 9/17/12 12:04 PM, "Francisco Obispo" <[e-mail]> wrote:

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


I'd be happy to clarify the section and add clarifying text if you can
tell us what you suggest isn't clear.

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


Please provide your gap analysis if you have it.

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


Again, if you can provide your actual analysis that would be helpful. Real
examples beat theoretical discussions.

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


Did you read the reference above? It's not about policy. It's about object
representation.

-andy