[weirds] vCard | Was: Re: Entity postal address information in draft-ietf-weirds-json-response-01

[Alex Sergeyev <[e-mail]>]

> Please allow me to remind everyone that the IETF has a standard for such
> information: vCard. Let's use it and focus on WEIRDS, not on postal address
> formats.
Earlier this year many people mentioned that they just don't have
ability to present structured data.  vCard is even more structured
than EPP, it would be hard to get there.


Now back to having both "flat" and "structured" in postalAddress....

I like structured data but I think that having many ways to present
the info makes it harder for clients to parse and adds more ability
for server software engineers to get creative. Also:
* there is nothing good from additional nesting, adds complexity and
points for potential exception handling
* extensions will randomly use hashes and "structured/flat" approach
following the example (I truly assume that weirds might be universal
"object info" protocol, not just for replacing whois)

I would offer this:

* keep presentation as plain ordered string list
* make server able to provide postalAddressFields list that describes
positions that were used

e.g

"postalAddress" :  [ "123 Maple Ave", "Suite 90001", "Vancouver",
"BC",   "12393", "CA"  ],
"postalAddressFields": [ "street", "street", "city", "sp", "postal", "cc" ]

with list of appropriate strings in appendix (mine are from attempts
to recall EPP)


I also think such approach could be used elsewhere - phones, emails,
entityNames.... (wording for "*Fields" is tricky... essentially I wish
it would be "must if it has ability to reveal data structure")


Still feel it's not ideal but at least it gives schema that everyone
should follow when extending things.



--
Alex.




On Fri, Dec 21, 2012 at 9:13 AM, Simon Perreault
<[e-mail]> wrote:
>
> And there is a draft about a JSON representation for vCard:
> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
>
> It's really straightforward IMHO...
>
> Simon
>
>
> Le 2012-12-19 14:55, Gavin Brown a écrit :
>>
>> Postal address information for entities is returned in a flat array
>> format:
>>
>>           "postalAddress" :
>>           [
>>             "123 Maple Ave",
>>             "Suite 90001",
>>             "Vancouver",
>>             "BC",
>>             "12393"
>>           ],
>>
>> For any registry whose database design was developed to support EPP,
>> this is quite lossy, since the specific meaning of each field is lost.
>>
>> I suggest that in addition to the above format, the standard should also
>> permit a full object, like so:
>>
>>           "postalAddress" :
>>           {
>>             street: [ "123 Maple Ave", "Suite 90001", ],
>>             city: "Vancouver",
>>             sp: "BC",
>>             pc: "12393",
>>             cc: "CA"
>>           },
>>
>> It would be pretty easy for clients to work out which model was being
>> used, and handle it accordingly. Servers should use one model or the
>> other, but not both.
>>
>> G.
>>
>
>
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> weirds mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/weirds