Subject: [weirds] vcard example in http://tools.ietf.org/html/draft-ietf-weirds-json-response-03

From: Maarten Wullink <[email-masked]>
Date: Wed, 1 May 2013 15:43:49 +0200

Hi,

When implementing
http://tools.ietf.org/html/draft-ietf-weirds-json-response-03 i
noticed that in the example used in section 6.1 the
"label" property is used  together with a vcard version identifier
value "4.0".

The "label" property is no longer supported in version 4.0 of the
vcard spec http://tools.ietf.org/html/rfc6350 It should be replaced by
the "adr" property.

 "vCard" :
         [
            [ "version", {}, "text", "4.0" ],
            [ "fn", {}, "text", "Joe Bob, Inc." ],
            [ "fn", {}, "text", "Bobby Joe Shopping" ],
            [ "label", {}, "text", "123 Maple Ave\n",
                                   "Suite 90001\n",
                                   "Vancouver\n",
                                   "BC\n",
                                   "1239\n" ],
            [ "email", {}, "text", "joe at bob.com" ],
            [ "email", {}, "text", "bob at joe.com" ],
            [ "tel", { "type": "work" }, "uri", "tel:+1-958-555-4321" ],
            [ "tel", { "type": "work" }, "uri", "tel:+1-958-555-4322" ],
            [ "tel", { "type": "fax" }, "uri", "tel:+1-958-555-4323" ],
            [ "tel", { "type": "cell" }, "uri", "tel:+1-958-555-4324" ],
         ],

The jcard draft
http://tools.ietf.org/html/draft-kewisch-vcard-in-json-01#appendix-B.1.2
shows an example with the "adr" property.

  ["adr",
          { "type": "work" },
          "text",
          ";Suite D2-630;2875 Laurier;Quebec;QC;G1V 2M2;Canada"
   ]

Cheers,

Maarten

- -- 
Maarten Wullink MSc|Technical advisor / R&D engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl

---

From: Simon Perreault <[email-masked]>
Date: Wed, 01 May 2013 16:02:37 +0200

> vcard spec http://tools.ietf.org/html/rfc6350 It should be replaced by

You're absolutely right. Sorry about that. Removing the LABEL property 
happened lated in the vCard 4 drafting process and I had totally forgot 
about it. The LABEL property was replaced by the LABEL parameter, which 
applies to the ADR property. The LABEL parameter has exactly the same 
functionality.

What's important to WEIRDS is:

- Structured addresses can be expressed using the ADR property.

- Unstructured addresses can be expressed using the LABEL parameter on 
an ADR property. The ADR property value can be empty if there is no 
structured equivalent.

- Addresses that have both structured and unstructured representations 
are expressed with an ADR property having a LABEL parameter.

This will be important when the examples get updated to use structured 
and/or unstructured addresses.

Simon

---

From: Pete Resnick <[email-masked]>
Date: Wed, 1 May 2013 11:04:40 -0500

JACARDCAL folks:

Let's please make sure that the ADR example in the jcard document shows 
the use of the LABEL parameter, given that this is a requirement for the 
WEIRDS folks.

WEIRDS folks:

The jcard document is very close to done:

https://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcard

You folks giving it a sniff would be exceedingly useful. If there are 
open issues (other than the above, making sure that there is an example 
of the use of an unstructured address), please let us know.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Wed, 1 May 2013 17:23:55 -0500

On 5/1/13 5:15 PM, Philipp Kewisch wrote:

> If this is a requirement I'm happy to comply, but since those examples 
> are not about the ADR property but rather about the structured value 
> it uses, I think the "label" parameter is just additional clutter. Or 
> is label becoming mandatory?

Oh, no, if I gave that impression, I apologize. The *ability* to have an 
unstructured (i.e., label) form of the address is a requirement for 
WEIRDS, and since we are writing a document at this break-neck speed for 
their benefit, I think it would be a good thing to show them an example 
of how one does that in the document. But this is not some sort of 
protocol requirement.

pr

---

From: Simon Perreault <[email-masked]>
Date: Thu, 02 May 2013 10:25:32 +0200

(Re-sending to include WEIRDS.)

Le 2013-05-02 02:38, Michael Angstadt a écrit :
> @Philipp: The first two components of the ADR property are for storing
> a post office box and an "extended" address (such as a suite or
> apartment number).  In the second example, it might be good to
> populate these fields with values that will make this more obvious.

Sorry, no. RFC 6350 section 6.3.1 says:

       Experience with vCard 3 has shown that the first two components
       (post office box and extended address) are plagued with many
       interoperability issues.  To ensure maximal interoperability,
       their values SHOULD be empty.

Why not just translate the example from vCard into jCard?

      ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
       Mail Drop: TNE QB\n123 Main Street\nAny Town, CA  91921-1234\n
       U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.

["adr",
   {
     "geo": "geo:12.3457,78.910",
     "label": "Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main 
Street\nAny Town, CA  91921-1234\nU.S.A."
   },
   "text",
   [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ]
}

> @Pete: The syntax of the jCards in your examples aren't *quite*
> correct.  The first element of the jCard array is the string "vcard".
> The second element is an array which contains all of the property
> arrays.  The "vcard" string is redundant in this context, since the
> object field already uses this name, but I am just thinking that
> parsers might have trouble parsing the jCard without it.  The examples
> should look like this:
>
> {
>    "handle" : "XXXX",
>    "vCard" :
>    [
>      "vcard",
>      [
>        ...

Right. Mea culpa again.

Simon
_______________________________________________
jcardcal mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jcardcal

---

From: Philipp Kewisch <[email-masked]>
Date: Thu, 02 May 2013 00:15:03 +0200

Ok, I see you already noticed the issue with LABEL property vs 
parameter. I've changed the example for structured values to:

["adr",
  { "label": "123 Main Street\n Any Town\n CA\n 91921-1234\n U.S.A" },
  "text",
  [
   "", "", "123 Main Street",
   "Any Town", "CA", "91921-1234", "U.S.A."
  ]
]

and:

["adr",
  { "label": "My Street, Left Side, Second 
Shack\nHometown\nPA\n18252\nU.S.A" },
  "text",
  [
   "", "",
   ["My Street", "Left Side", "Second Shack"],
   "Hometown", "PA", "18252", "U.S.A."
  ]
]

If this is a requirement I'm happy to comply, but since those examples 
are not about the ADR property but rather about the structured value it 
uses, I think the "label" parameter is just additional clutter. Or is 
label becoming mandatory?

Philipp

On 5/1/13 6:04 PM, Pete Resnick wrote:
> JACARDCAL folks:
>
> Let's please make sure that the ADR example in the jcard document 
> shows the use of the LABEL parameter, given that this is a requirement 
> for the WEIRDS folks.
>
> WEIRDS folks:
>
> open issues (other than the above, making sure that there is an 
> example of the use of an unstructured address), please let us know.
>
> pr
>

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 1 May 2013 20:38:20 -0400

@Philipp: The first two components of the ADR property are for storing
a post office box and an "extended" address (such as a suite or
apartment number).  In the second example, it might be good to
populate these fields with values that will make this more obvious.
Also, in the label, maybe remove the newlines between the town/state
and state/zip-code so that it more closely resembles a mailing label.
For example:

["adr",
 { "label": "P.O. Box 123\nSuite 456\nSecond Shack\nHometown, PA
18252\nU.S.A" },
 "text",
 [
  "P.O. Box 123", "Suite 456", "Second Shack", "Hometown", "PA",
"18252", "U.S.A."
 ]
]

{
  "handle" : "XXXX",
  "vCard" :
  [
    "vcard",
    [

Thanks,
Mike

On Wed, May 1, 2013 at 6:23 PM, Pete Resnick <[email-masked]> wrote:
>> If this is a requirement I'm happy to comply, but since those examples are
>> not about the ADR property but rather about the structured value it uses, I
>> think the "label" parameter is just additional clutter. Or is label becoming
>> mandatory?
>
>
> unstructured (i.e., label) form of the address is a requirement for WEIRDS,
> and since we are writing a document at this break-neck speed for their
> benefit, I think it would be a good thing to show them an example of how one
> does that in the document. But this is not some sort of protocol
> requirement.
>
>
> pr
>
> --

---

From: Michael Angstadt <[email-masked]>
Date: Thu, 2 May 2013 08:22:20 -0400

>       their values SHOULD be empty.

Ahem, I do believe that the wording here is "SHOULD" not "MUST".
Also, if I may refer you to the paragraph above (asterisks added for
emphasis):

Quoting RFC 6350, section 6.3.1, page 33:

   Special notes:  The structured type value consists of a sequence of
      address components.  The component values MUST be specified in
      their corresponding position.  The structured type value
      corresponds, in sequence, to
         ** the post office box; **
         ** the extended address (e.g., apartment or suite number); **
         the street address;
         the locality (e.g., city);
         the region (e.g., state or province);
         the postal code;
         the country name (full name in the language specified in
         Section 5.1).

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 03 May 2013 15:21:31 -0400

>> does that in the document. But this is not some sort of protocol

Following from this, it looks like a structured example based on what is 
in json-response-03 would be:
     ["adr",
         {},
         "text", [ "P.O. Box 12", "Suite 901", "123 Maple Ave", 
"Vancouver", "BC", "A1B 2C9, "Canada" ]
     ]

For both structured and unstructured:
     ["adr",
         { "label": "123 Maple Ave\nSuite 901\nP.O. Box 12\nVancouver 
BC\nA1B 2C9\nCanada" },
         "text", [ "P.O. Box 12", "Suite 901", "123 Maple Ave", 
"Vancouver", "BC", "A1B 2C9, "Canada" ]
     ]

For only unstructured, neither the jCard or vCard spec have examples. 
I'm guessing the following is correct, since "a single structured text 
value" seems to be required: 
http://tools.ietf.org/html/rfc6350#section-6.3.1
     ["adr",
         { "label": "123 Maple Ave\nSuite 901\nP.O. Box 12\nVancouver 
BC\nA1B 2C9\nCanada" },
         "text", []
     ]

-Ernie

---

From: Michael Angstadt <[email-masked]>
Date: Thu, 2 May 2013 19:43:33 -0400

Sorry, I'm just joking.  I think it makes sense to leave the
"post-office-box" and "extended" components empty too.

Thanks,
Mike

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 6 May 2013 00:58:21 +0000

Hi all,

>"Vancouver", "BC", "A1B 2C9, "Canada" ]

The -01 draft I'm looking at shows a "text" value as a single string, not
an array of strings:

["adr",
  { "type": "work" },
  "text",

Is the array syntax a valid alternative to the semi-colon separated string
that is yet to appear in the draft, or in the draft in a corner I can't
find?

  Byron

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 5 May 2013 21:59:52 -0400

> that is yet to appear in the draft, or in the draft in a corner I can't

The array syntax is *required*.  There is no alternative.  The
semi-colon syntax is only used in traditional, text-based vCards.
jCard does not support this.  The label parameter is *optional*.

-Mike

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 08 May 2013 15:12:47 -0400

>        [ "fn", {}, "text", "Joe Bob, Inc." ],

For RDAP, this is confusing and prone to reversal and case errors. We 
should use a different name, as in

{
   "handle" : "XXXX",
   "vcardArray" :
   [
     "vcard",
     [

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 May 2013 14:18:38 +0000

>should use a different name, as in

I agree.

-andy

---

From: Michael Angstadt <[email-masked]>
Date: Thu, 9 May 2013 12:31:21 -0400

On Tue, May 7, 2013 at 3:52 PM, Philipp Kewisch <[email-masked]> wrote:
> Even this should work out, although its probably the solution least
> compatible to the spec.
>
> [ "adr", { "label": "foo bar baz" }, "text" ]

I think that example is pushing it, but I agree that an empty ADR
value should be valid.

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 07 May 2013 21:52:58 +0200

> jCard does not support this.  The label parameter is *optional*.

So for your unstructured-value-only property is a text property without 
a value. This is allowed per vCard spec with the following abnf:

value = text / text-list / date-list / ....
text = *TEXT-CHAR
TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII / %x21-2B / %x2D-5B / 
%x5D-7E

This gives you the following property:
ADR;LABEL="foo bar baz":

Foremost, this is a text property. Parsers are instructed to always 
check the type since it may turn out to be a structured value. 
Therefore, using:

[ "adr", { "label": "foo bar baz" }, "text", "" ]

shouldn't cause parsers to break. As ADR is a structured property, this 
would be fine too:

[ "adr", { "label": "foo bar baz" }, "text", [] ]

I guess this isn't 100% clear, although given the first two options 
should both work per spec, I don't know if I should add clarification.