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

From: Ernie Dainow <[email-masked]>
Date: Fri, 04 Jan 2013 14:38:29 -0500

Various postal formats being suggested are unnecessarily complicated, 
and don't conform to the ultimate standard here, which is the Post 
Office. I have never addressed a letter by writing

Street: 1234 Maple St
Unit: Suite 901
City: Vancouver
Province: BC
Postal Code: V6J 3R8
Country: Canada

And I don't think too many post offices in other countries expect a 
"structured" address. In fact, the structured address expected is:
Line 1:
Line 2:
Line 3:
...
Where the interpretation of each Line depends on the locality or the 
context. This is exactly what is currently defined for "postalAddress".

-Ernie

On Thu, Dec 27, 2012 at 9:28 AM, Marc Blanchet 
<[email-masked] <mailto:[email-masked]>> wrote:

    Le 2012-12-26 à 20:58, Linlin Zhou a écrit :

     > Dear Marc,
     >> In other words, the protocol format should be the "best
    possible" (not the
     >> perfect one) and then each organization maps its current dataset
    into that
     > format.
     >> And overtime, things will improve as new registries come, as old
     > registries are
     >> redoing their apps/database, as ...
     >>
     >> Given that vcard is not only used a lot into the field for all
    kind of
     > apps, and that
     >> vcard is an IETF format, I would suggest to closely look at it
    to reuse as
     > much as
     >> possible, instead of reinventing the wheel.  Moreover, vcard
    includes the
     > i18n
     >> requirements.
     >>
     > As seeing you mentioned the i18n requirements included in the
    vcard, I'd
     > like to know more details about it. Could you please give any
    reference?

    sure. first, I'm not claiming that vcard i18n "features" are in
    match with weirds requirements (maybe, maybe not).
    But:
    - previous vcard version (RFC2425,…) was not "clean" for i18n.
    multiple charsets, etc…
    - current version of vcard (RFC6350): the group went to make sure
    any i18n requirement was met. so, more precisely:
      + mandating UTF-8 (section 3.1, RFC6350)
      + escaping (section 3.4)
      + dates/time in iso format (section 4.3)
      + language (section 5.1)
      + geo
      + tz
      + tel: based on x.520

    Please see RFC6350.

    Marc.

     > Thanks.
     > Linlin

    _______________________________________________
    weirds mailing list
    [email-masked] <mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/weirds

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Jan 2013 16:09:34 -0500

On Fri, Jan 04, 2013 at 02:38:29PM -0500, Ernie Dainow wrote:
> Various postal formats being suggested are unnecessarily
> complicated

That sounds like an assertion that you know what the requirement is
for the postal address.  What _is_ it we want to do with the postal
address?

> , and don't conform to the ultimate standard here, which
> is the Post Office.

Well, maybe not.  If the thing people want from this is postal address
data that can be consumed by a machine, that turns out to be something
that the post office people _have_ tried to do, and given up
repeatedly in frustration because humans tend not to follow the
standards very well.  So this boils down to the question of whether we
want subsections of the address to be identifiable all on their own.
Those who say "yes" will simply disagree that the more complicated
formats are "unnecessarily" complicated.  Those who say "no" will of
course think the subfields are overkill.

I have no real opinion, but I don't think we can resolve this
fundamental question just by dismissing one of the options out of
hand.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Jan 2013 19:47:03 +0100

> context. This is exactly what is currently defined for "postalAddress".

In vCard there is the ADR property, which is structured and based on 
X.520, and there is the LABEL property which is unstructured. We have 
both because various situations have various needs. Use what you need.

I would expect WEIRDS servers to provide either ADR or LABEL according 
to what they have in their databases, and I would expect clients to be 
able to handle both.

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

---

From: Gavin Brown <[email-masked]>
Date: Mon, 07 Jan 2013 20:47:27 +0000

> to what they have in their databases, and I would expect clients to be

+1. When I raised this topic, it was always my expectation that the
specification would allow servers to choose which format they wanted,
not to impose one format on everyone. If you have flat, unstructured
addresses, then that's fine by me, but I would like to preserve the
structure that already exists in my database.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Peter Koch <[email-masked]>
Date: Tue, 8 Jan 2013 08:00:16 +0100

> not to impose one format on everyone. If you have flat, unstructured

assuming the IETF is still in the business of protocol development rather
than describing web services, could people please be more specific about what
they mean with "servers"? Are we talking about "mandatory/optional to implement"
or "mandatory/optional to operate"?

-Peter