Subject: Re: [VCARDDAV] Questions, Concerns, and Errata concerning vcardrev-13

From: Simon Perreault <[email-masked]>
Date: Mon, 01 Nov 2010 15:57:53 -0400

On 2010-10-12 10:43, Cyrus Daboo wrote:
> Perhaps we should tie the vCard value to the iCalendar registry for
> CALSCALE values so we stay in sync.

I'm unable to find such a registry on IANA's website. We need one, if
I'm reading RFC 5545 correctly.

In any case, RFC 5545 only defines the GREGORIAN value.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Andy Mabbett <[email-masked]>
Date: Mon, 1 Nov 2010 20:11:31 +0000

On 12 October 2010 15:43, Cyrus Daboo <[email-masked]> wrote:

> [CALSCALE]

> Now, is this a real problem? I really can't say whether users are clamoring
> for a fix.

As I've pointed out previously, the inability to correctly generate
vCards with Julian dates has already been a problem on Wikipedia.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 14:11:24 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * The group concept arrives early on (page 9). Only much later would the
> revision history clue me in that it’s been a controversial idea that’s
> made it in and out of the drafts.
> 
> In any case, the “group.” prefix came out of nowhere as I was reading
> the syntax, without reference to its roots in the HOME/WORK distinction.
> Whenever I introduce a new degree of freedom, I prefer to ground it with
> specific, evocative examples as soon as possible. At this point, even
> after reviewing the whole doc, I’m unclear on why it exists — are there
> other cultures that have lots of evidence of a taxonomy with higher
> valence than Home/Work? Are implementations incorrectly assuming the
> group prefix correlates to a user-facing label (fields should never
> determine display, imo)?

The reason for the group construct's existence is simple: it was in
vCard 3. There is absolutely no change to the group construct from vCard
3 to vCard 4.

We did attempt to change its semantics for replacing the TYPE parameter,
but finally gave up in the name of backward compatibility.

We know that Mac OS X's address book uses it heavily to group things in
some way.

I acknowledge that it is under-specified and uninteroperable. But any
change to this sad state of things implies breaking backward
compatibility substantially.

> Editorial recommendation: a better explanation inline, or at least a
> specific forward reference. Instead, the early arrival of such a weak
> claim (SHOULD/MAY) reduced my confidence that this would be an
> interoperable spec.

Pick your poison: uninteroperability or backward incompatibility.

At this late stage in the process, and in the absence of an explicit
proposal, I'll refrain from making the choice myself.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 14:23:40 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * … specifically because it makes comma and semicolon handling
> worryingly complex (§3.3). My spidey-senses start tingling when I have
> to scan over special handling for escaping. I always hope for something
> so mandatory that I can pre-process my input with a regex, but I usually
> don’t get that moment of satori :) Short of that, I became concerned
> that if I’m going to be ABNF-driven, that’s fine, but having input
> processing rules that aren’t context-sensitive seemed surprising (every
> comma, everywhere).

I'm not sure I understand this proposal correctly. Are you arguing for
or against context-aware parsing?

Would the following be a faithful summary?

Proposal: relax comma escaping rules.
  - MUST escape commas in values of properties that may have multiple
instances.
  - SHOULD escape commas in other values.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 14:36:37 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> Also, I don’t understand why so much case conversion is permitted here?
> Are there lots of examples of interoperability failures, or can we just
> remind authors the ABNF is the controlling legal language (all CAPS per
> page 10 - not at all “case insensitive”!). They may accept “TrUE” at
> their own risk, but never to generate that.

Actually, the ABNF accurately reflects what's in the text.

We have:

     boolean = "TRUE" / "FALSE"

and RFC 5234 states:

      ABNF strings are case insensitive and the character set for these
      strings is US-ASCII.

> Editorial recommendation: mandate all-caps case.

Proposal understood. We'll discuss this during next week's meeting.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 15:25:59 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 5.0 (top of page 17) Implementers MUST ignore undocumented or private
> use parameters, but MAY ignore group prefixes (3.2). Given the risk of
> merge loops, especially when a PID is specified, dropping fields seems
> worse than round-tripping intact. I wonder why that was ruled out?
> Evidence of propagation failures in the wild might help decide this issue.

I don't understand. Ignoring doesn't mean dropping. An app could ignore
a property and still round-trip it correctly.

If this is an issue with the way it's phrased in the text, please
propose new text that fixes it.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:12:38 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * Case-insensitivity arises throughout the doc, again in 5.2 (‘b’ and
> ‘B’). As an implementer, I wish I didn’t have to read the text to
> discover gotchas — either the ABNF should be mixed-case, or declare
> outright that uppercase is preferred and MUST NOT be propagated.

If you are aware of any bugs in the ABNF, please tell me, because I've
been looking and I can't find any.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:15:05 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 5.3 The motivational scenario for non-vCard-aware consumers of vCard
> data seems quite made-up. For that matter, the hypothetical search
> engine just got some witness killed because it indexed the location as
> TEXT but didn’t obey CLASS ;)

Agreed. That paragraph is a relic of the past. I'll remove it in the
next revision.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:19:12 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> And what’s with the sudden preference for lower-case symbols? I was half
> expecting to be told elsewhere in the doc that TYPEs would be
> case-insensitive too.

This is what we're talking about:

     value-type = "text"
                / "uri"
                / "date"
                / "time"
                / "date-time"
                / "timestamp"
                / "boolean"
                / "integer"
                / "float"
                / "binary"
                / "language-tag"
                / iana-token  ; registered as described in section 12
                / x-name

First, ABNF double-quoted strings are case insensitive, as explained in
a previous email.

Second, the ABNF reflects common usage. Parameter values (in this case
we're discussing the VALUE parameter) are typically lower-case. Such as
in this example:

PHOTO;VALUE=uri:http://...

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:28:22 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * PREF reminds me of content-negotiation in HTTP. It was a beautiful
> idea that was convoluted too far to really ever work. The similarities
> begin with the arbitrary 0-100 scale (oops! 1-100 see? and 1 > 100,
> don’t forget — this kind of scaling jiggery-pokery is unlikely to
> interoperate, much less compose (concatenating records from multiple
> sources). Where is the actual reference to a running system with that
> much subtlety of expression?

At this late stage in the process, we need concrete and explicit
proposals. I can't find one in this (still interesting and valuable)
comment.

Here's the history behind PREF, for your information:

The PREF parameter has been in vCard since at least 2.1 (maybe earlier)
and is widely implemented. What was added in vCard 4 is the integer
value. The ability to quantify and express relative preference was one
of the first feature requests for vCard 4. The 1-100 range was picked
with guidance from OMA and made working group consensus. In earlier
versions of the draft (-06 and earlier), there was no range (just
"positive integer"). Also, the use of zero was ruled out because
indicating top priority with PREF=0 would surely cause a lot of confusion.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:34:48 -0400

On 2010-11-03 16:28, Simon Perreault wrote:
>> * PREF reminds me of content-negotiation in HTTP. It was a
>> beautiful idea that was convoluted too far to really ever work. The
>> similarities begin with the arbitrary 0-100 scale (oops! 1-100 see?
>> and 1 > 100, don’t forget — this kind of scaling jiggery-pokery is
>> unlikely to interoperate, much less compose (concatenating records
>> from multiple sources). Where is the actual reference to a running
>> system with that much subtlety of expression?
> 

I'm sorry, I found your proposal in the following:

> Editorial Recommendation: By contrast, I can bet you that users care
> immensely about the *exact order* that fields were typed in. Why not
> make this ORDER, if we don’t want the original sequential occurrence
> of lines in the file to be controlling law? If anything, I’d wish we
> ruled out the use of PREF precisely because the same four characters
> exist in RFC 2426 with a completely different meaning (and it’s a
> presence/absence token to boot, not a parameter)

The order of properties is irrelevant since at least vCard 2.1.
Introducing this would mean a major break of backward compatibility.
This idea (which I proposed myself IIRC) was ruled out by the working
group in favour of an integer-valued PREF parameter.

Using the order of properties would also create other problems:

- Non-preference is going to be the most common case, but there is no
way to represent that when preference follows order.

- CardDAV would need to be heavily modified to keep properties in order.
  - There is also no way in CardDAV to make queries related to the order
of properties, whereas it is easy to construct queries including the
value of the PREF parameter.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:36:31 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * Aside: one new function that’s become integral to my user of an
> ‘address book’ in the decades since RFC 2426 is the ‘call log’. I can
> imagine that it might be a useful illustrative example for how to use
> private extensions and propose new IANA registries to show how a
> cellphone developer could extend vCard to round-trip their address book
> more completely…

I'm sure you could be convinced that this would be better suited for a
separate extension? ;)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 16:38:48 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 5.5. Is ALTID a number or an entity tag or what? I mean, if every
> single example uses a digit, I was inclined to believe it was close to a
> ordinal position referent system, until I was rudely awakened at the
> very last line of the section that it was text (and hence a
> string-equivalence index referent system).

There is a paragraph that answers this question:

   This parameter's value is treated as an opaque string.  Its sole
   purpose is to be compared for equality against other ALTID parameter
   values.

Simon

---

From: Rohit Khare <[email-masked]>
Date: Wed, 3 Nov 2010 13:01:32 -0700

[Three specific quotes from earlier in the thread pasted below] 

At the very least, I appreciate the explanation, so CALSCALE may have a place in the spec text.

The explicit pointer to the calendar specs might remind the reader that dates are discussed normatively over in that community. It would still bother me that RFC 5545 hasn’t defined more, either, but that places the blame more accurately :)

That said, I am personally skeptical that such a degree of calendar fidelity is essential for the task of managing address books. I would be swayed by a credible example in the spec text. Wikipedia, if better cited, would still bother me as not-quite-an-address-book; I have assumed the general problem of describing human beings is entirely out-of-scope for VCARDDAV.

— Rohit

On Oct 12, 2010, at 7:43 AM, Cyrus Daboo wrote:

> Now, is this a real problem? I really can't say whether users are clamoring for a fix. However, I believe we should take the time to fix it. The fact that we have not formally defined CALSCALEs beyond GREGORIAN is a side issue. Already, there has started to be more interest from various parties to work on extending iCalendar with non-GREGORIAN CALSCALE, so that work will filter down to vCard too. Perhaps we should tie the vCard value to the iCalendar registry for CALSCALE values so we stay in sync.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Nov 2010 17:29:26 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.1.4 Q: where the hell does KIND come from? A: the impulse to model
> things no address book has ever modeled before.

:)

The actual answer is the need for groups. Lots of address book apps let
you organize contacts in groups.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 09:11:38 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.2.4 PHOTO - bare subtypes? WHy not just describe it as *incorrect*
> (but found in the wild — you have to cull the herd at some point).

We had this:

                                                                The
      full media type name, including the "image/" prefix, SHOULD be
      used.  However, implementations SHOULD be able to handle bare
      subtypes.

I turned it into this:

                                                                The
      full media type name, including the "image/" prefix, MUST be
      used.  However, implementations SHOULD be able to handle bare
      subtypes.

Hopefully it addresses your concern, and I suppose everyone will be in
agreement.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 09:12:25 -0400

>       used.  However, implementations SHOULD be able to handle bare

Oh, and I did the same for other instances of this text (LOGO and SOUND).

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 11:51:20 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.2.10 is absence supposed to be inferred as 0 or 9? Because let me
> tell you, the politically freighted “not known” is not at all the same
> as “not included”. Properties ought to have default values, and the
> debate this one would provoke is worth watching.

No. Absence means neither 0 nor 9. Absence means absence of data.

0 means "I'm telling you I don't know." If the vCard is about myself,
that could be interesting. If the vCard is about someone else, I want to
indicate that I don't know the sex of the person, maybe as a reminder to
myself that I should find out.

9 means "I'm telling you it's not applicable." A use case I have in mind
is for a KIND:thing vCard.

Absence means "I'm not telling you anything." I could have neglected to
enter the sex. Or maybe I want to hide something. In any case, all
values (0,1,2,9) could be possible. You just have no data.

This all seems very obvious to me. If the text needs to be fixed, please
propose explicit text to be changed.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 12:52:39 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> So why not at least mandate a testable rule for interoperability by
> claiming that unrecognized integers should survive round-trips.

Makes sense.

Please provide text.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 13:00:27 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.3.1 positional notation isn’t that much better than CSV, is it
> really? Even if it is mandated by some other standard (and a citation at
> this point in the doc would be helpful, why not make the ABNF more
> developer-friendly by actually marking tokens, in order, for each of the
> levels. I don’t want to see devs counting ;s…

Makes sense. I wrote this for the next version:

  ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
              ADR-component-street ";" ADR-component-locality ";"
              ADR-component-region ";" ADR-component-code ";"
              ADR-component-country
  ADR-component-pobox    = list-component
  ADR-component-ext      = list-component
  ADR-component-street   = list-component
  ADR-component-locality = list-component
  ADR-component-region   = list-component
  ADR-component-code     = list-component
  ADR-component-country  = list-component

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 13:16:10 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.4.1 Editorial suggestion: make a table? it’s a wall of text and as a
> dev, I’d appreciate the Least You Have To Know (TM).

Consider it done.

      The property can include the parameter "TYPE" to specify intended
      use for the telephone number.  The predefined values for the TYPE
      parameter are:

   +-----------+-------------------------------------------------------+
   | Value     | Description                                           |
   +-----------+-------------------------------------------------------+
   | text      | Indicates that the telephone number supports text     |
   |           | messages (SMS).                                       |
   | voice     | Indicates a voice telephone number.                   |
   | fax       | Indicates a facsimile telephone number.               |
   | cell      | Indicates a cellular or mobile telephone number.      |
   | video     | Indicates a video conferencing telephone number.      |
   | pager     | Indicates a paging device telephone number.           |
   | textphone | Indicates a telecommunication device for the deaf.    |
   +-----------+-------------------------------------------------------+

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 13:19:46 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> Also, what happened to Telex?:)
> http://www.cio.com/article/598628/10_Technologies_That_Should_Be_Extinct_but_Aren_t_
> 
> http://www.economist.com/node/10609367 (telex: a faint ping - also at
> http://edwardlucas.blogspot.com/2008/02/telex-lives-on.html
> Telex is still used for ships at sea — this company was advertising on a
> Google search for the term today: http://plainsailing.org/telex.html
> and for the final entertainment from the time capsule: how hip ad firms
> use MCI Mail to send telexes! 1988 story on “THE EXECUTIVE COMPUTER;
> Sending a Telex From Your Desk”
> http://select.nytimes.com/gst/abstract.html?res=FB0710FE3F550C778DDDA10894D0484D81

The "tlx" type was defined in vCard 2.1, but was removed in 3.0. Current
usage would not justify adding it in core for 4.0.

(I did see the smiley, but I'm still not sure if you are joking...)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 13:40:10 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> This also makes a mockery of the template in 10.2.6. for “TOP SECRET” —
> how about actually useful examples, such as perhaps a “NOINDEX”
> classification to warn other services not to “crawl” that card for
> searching…?

Good example. I changed TOP-SECRET to NOINDEX for the next version.

Simon

---

From: Andy Mabbett <[email-masked]>
Date: Thu, 4 Nov 2010 17:43:30 +0000

>      use for the telephone number.  The predefined values for the TYPE

That format of table isn't very accessible. It certainly won't play
well in a text reader

If a tabular layout is needed perhaps:

       Value          Description
       =====        =========

       text             Indicates that the telephone number supports text
                         messages (SMS).

       voice           Indicates a voice telephone number.

would suffice; but it's still not ideal.

[...]

>   | textphone | Indicates a telecommunication device for the deaf.    |

better wording would be:

  Indicates a telecommunication device for people with hearing or
speech difficulties.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 13:47:40 -0400

On 2010-10-12 02:42, Rohit Khare wrote:
> * 6.8.2 are there examples of KEY in the wild?

I know of many email clients that let you associate PGP keys with
contacts and that export that as KEY properties in vCard.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Nov 2010 14:07:45 -0400

> That format of table isn't very accessible. It certainly won't play

You mean when viewed with non-monospace fonts?

In any case, xml2rfc doesn't support any other kind of table. I suggest
you redirect your comments to the person in charge of
http://xml.resource.org/.

>   Indicates a telecommunication device for people with hearing or

Thanks.

Simon

---

From: Andy Mabbett <[email-masked]>
Date: Thu, 4 Nov 2010 18:51:05 +0000

> You mean when viewed with non-monospace fonts?

No; I mean when read by an aural device or application like JAWS. The
user may hear:

"plus dash dash dash dash dash dash dash dash dash dash dash plus dash
dash dash dash..." and so on.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Nov 2010 23:26:31 +0100

On 04.11.2010 19:51, Andy Mabbett wrote:
> On 4 November 2010 18:07, Simon Perreault<[email-masked]>  wrote:

I'd recommend you read an HTML version of the spec instead (and I don't 
mean an htmlized-version of the text/plian version), but one generated 
from the XML source...

Best regards, Julian