Subject: [VCARDDAV] vcardrev nits

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Sep 2009 15:30:57 -0600

Herewith some nits regarding draft-ietf-vcarddav-vcardrev-08. I might
have more substantive comments regarding synchronization.

0. Abstract

The reference to "individuals" might be taken to imply that vCards are
only for humans, which I think they are not. Indeed, there is an old
tradition in the Jabber community of assigning vCards to servers for
geolocation purposes.

1. Introduction

This text is worrisome...

   Note: This draft contains much of the same text as 2425 and 2426
   which may not be correct.

Is this a specification that is explicitly inaccurate?

Typo: presense => presence

3. MIME Type Registration

Would it simplify things for IANA if this were in the IANA
Considerations section?

4.1. Line Delimiting and Folding

   At least one character must be present on the
   folded line.

I suggest:

   The folded line MUST contain at least one character.

4.2. ABNF Format Definition

The comment on the contentline field contains normative text:

       ; When parsing a content line, folded lines MUST first
       ; be unfolded according to the unfolding procedure
       ; described above.

This strikes me as an odd place to put normative text.

5.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP

   based on a the definitions

should be

   based on the definitions

6. Property Parameters

   Applications MUST ignore x-param and iana-param value they don't
   recognize.

should be

   Applications MUST ignore x-param and iana-param values they don't
   recognize.

7.1.5. KIND

   Special notes:  The value may be one of: "individual" for a single
      person, "group" for a group of people, "org" for an organization,
      "location" for a named geographical place, an x-name or an iana-
      token.  If this property is absent, "individual" MUST be assumed
      as default.

What about devices, servers, and other entities?

(Compare to 7.2.3 NICKNAME, which at least mentions the possibility that
the entity could be a "thing".)

7.2.4. PHOTO

   The full
   media type name, including the "image/" prefix, should be used.

Change "should" to "SHOULD"?

(Same for LOGO and SOUND.)

7.2.10. SEX

aplicable => applicable

7.3.2. LABEL

   corresponding to delivery address

should be

   corresponding to a delivery address

7.4.1. TEL

prefered-use => preferred-use

cellular telephone number => cellular or mobile telephone number

      parameter values can be specified as a parameter list (i.e.,
      "TYPE=text;TYPE=voice") or as a value list (i.e.,
      "TYPE=text,voice")

I would change "i.e." to "e.g." because these are merely examples.

7.4.3. IMPP

Would a reference to RFC 4770 be appropriate?

7.5.1.  TZ

I still think it would be nice to have a field for offset from UTC.

7.6.3. LOGO

   Encoding:  The encoding MUST be reset to "b" using the ENCODING
      parameter in order to specify inline, encoded binary data.  If the
      value is referenced by a URI value, then the default encoding of
      8bit is used and no explicit ENCODING parameter is needed.

   Value type:  A single value.  The default is binary value.  It can
      also be reset to uri value.  The uri value can be used to specify
      a value outside of this MIME entity.

This strikes me as contradictory -- the "default is binary value" yet
"the encoding MUST be reset to "b" using the ENCODING parameter in order
to specify inline, encoded binary data"?? Why is it necessary to reset
the ENCODING parameter to "b" if the default is binary? (The same
comment applies to 7.7.6 SOUND and 7.8.2 KEY.)

7.6.5. MEMBER

tpe => type

7.6.6. RELATED

represents has => has

   "child" means the opposite of "parent"

Hot is the opposite of cold, high is the opposite of low, but child is
the opposite of parent? I recommend:

   "child" means that the related individual is the child of the
   individual this vCard represents.

We might also mention that a child does not need to be a natural,
biological child (adopted child, stepchild, etc.).

7.7.1. CATEGORIES

Is a category essentially the same as a "tag"?

7.7.3. PRODID

assure => ensure

7.7.5. SORT-STRING

   locale- or national-language- specific sorting

This is hard to parse. I suggest:

   The sort string is used to provide family name or
   given name text that is to be used in sorting of
   the formatted name and structured name types in the
   context of a particular locale or national language.

7.9.1. FBURL

   last six weeks

Is the definition of FBURL really that specific?

it's => its

7.9.3 CALURI

it's => its

8. Synchronization

As noted, I might have more substantive comments on this section.

8.1.1.  Matching vCard Instances

   vCard instances for which the UID properties (Section 7.7.7) are
   equivalent MUST be matched.

Is it not an option to punt on matching?

10. Security Considerations

The mention of Internet mail is jarring. Perhaps first mention that
vCards are often used to transport vCards?

   In cases where threats of "spoofed" vCard information is a concern

should be

   In cases where the threat of "spoofed" vCard information is a concern

11.1 MIME Type Registration

[see comment above]

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 16 Sep 2009 01:24:24 -0300

Peter Saint-Andre wrote,

> tradition in the Jabber community of assigning vCards to servers for

It is legacy text from RFC 2426 abstract.
Does it makes sense if we write "individuals or other entities"?

> the entity could be a "thing".)

The idea behind KIND was to provide guidance about the semantics of other 
properties (for instance, the semantics of ORG when KIND:org is different from 
its semantics when KIND:individual), therefore the kind for "device" and 
"server" should be the same. We could define a new standard value "thing" for 
other cases which are not addressed by the current defined values.

Alternatively, KIND:x-Jabber-server may work, but I would prefer not 
encouraging x-* tokens when it can be managed with standards values (however, 
if distinguishing servers from other devices is important, this information 
should be conveyed in a different property).

> Would a reference to RFC 4770 be appropriate?

I don't think so, RFC 4770 will be obsoleted by vcardrev.

> I still think it would be nice to have a field for offset from UTC.

Me too.

Note that the cardinality of TZ is defined as (0,n). If several TZ properties 
are specified, are they supposed to be equivalent?, for instance:

TZ:-0500
TZ:EST
TZ:Raleigh/North America

If it were the case, we could require that text values of the form -hh, 
+hh, -hhmm, +hhmm and the literal value "Z" should be understood as 
differences from UTC, as defined in ISO 8601.2004

> comment applies to 7.7.6 SOUND and 7.8.2 KEY.)

The default is binary value (i.e. VALUE=binary) and 8bit encoding (as for the 
every other property).
If a URI is specified, the value must be reset to "uri", but the default 
encoding is right.
If inline data is specified, the encoding must be reset to binary ("b"), but 
the default value is right.

>   individual this vCard represents.

It also may be
 "child" is the opposite relation of "parent".

> Is a category essentially the same as a "tag"?

I think so...

>   context of a particular locale or national language.

I don't agree with the "context of a particular locale or national language" 
part, as it seems to suggest that the collation is well-known and defined 
somewhere else.
I would modify it by "an implied particular locale or national language."

Besides, the current special note "The sort string is used to provide family 
name or given name text..." is ambiguous. How could the sort-string be of use 
if one cannot tell whether it applies to the given name or the family name.

Example 1
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten

Example 2
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Rene

In example 2 were specified (which is valid according to the definition), I 
would collate "van der Harten" under R.

Note also that the N property was redefined as a four-component text value. 
Hence the example (copied from section 7.7.5 of vcardrev-08) should read
N:van der Harten;Rene,J.;Sir;R.D.O.N.

> 8.1.1.  Matching vCard Instances> >   vCard instances for which the UID 
> properties (Section 7.7.7) are>   equivalent MUST be matched.> > Is it not 
> an option to punt on matching?
The option should be not to synchronize.
 "If synchronization is performed vCard instances for which the UID properties 
..."

Best regards

Javier

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 09:37:06 +0200

Javier Godoy wrote:
> ...
> ...

If it's mentioned as obsoleted then it should also have an informative 
reference.

BR, Julian

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 16 Sep 2009 05:55:07 -0300

> If it's mentioned as obsoleted then it should also have an informative 

I think the question was whether RFC 4770 should be explicitly referenced in 
section 7.4.3. IMPP of vcardrev (which is based on RFC 4770).

BTW, the references to RFC 2425, RFC 2426 and RFC 4770 (all of them will be 
obsoleted by vcardrev) are normative in draft version 08.

Best Regards

Javier

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 16 Sep 2009 10:50:06 +0100

On Sep 16, 2009, at 8:37 AM, Julian Reschke wrote:

> If it's mentioned as obsoleted then it should also have an  
> informative reference.

I disagree.

If for some reason the I-D refers to information in the (to be)  
obsoleted information, then yes.  But this is no different than any  
other informational reference.   However, if the I-D simply has:

Obsoletes: RFC X

and text:
	This document obsoletes RFC X.

There is no need to have an informative reference and, in my opinion,  
having a informative reference for just such is distracting and ought  
to be avoided.

-- Kurt

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 11:52:32 +0200

Javier Godoy wrote:
> ...
> I think the question was whether RFC 4770 should be explicitly 
> referenced in section 7.4.3. IMPP of vcardrev (which is based on RFC 4770).
> 
> BTW, the references to RFC 2425, RFC 2426 and RFC 4770 (all of them will 
> be obsoleted by vcardrev) are normative in draft version 08.
> ...

Sorry. Should have done more checking.

However, shouldn't the references to to-be-obsoleted RFCs be *informative*?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 11:57:01 +0200

Kurt Zeilenga wrote:
> having a informative reference for just such is distracting and ought to 
> be avoided.
> ...

You are right if there's nothing else that needs to be said.

Frequently however, a revision of spec actually makes changes, in which 
case I would expect a "changes since rfc xxxx" section, which optimally 
should be precise in what changed (potentially including references to 
specific sections in the original spec).

BR, Julian

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 16 Sep 2009 11:19:33 +0100

On Sep 16, 2009, at 10:57 AM, Julian Reschke wrote:

>> There is no need to have an informative reference and, in my  
>> opinion, having a informative reference for just such is  
>> distracting and ought to be avoided.
>> ...
>
> Frequently however, a revision of spec actually makes changes, in  
> which case I would expect a "changes since rfc xxxx" section, which  
> optimally should be precise in what changed (potentially including  
> references to specific sections in the original spec).

I would avoid adding a reference even in this case.  But I don't care  
strongly about it.  I'm fine with leaving the decision to the  
document's editor.

-- Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Sep 2009 11:20:46 +0100

> references to specific sections in the original spec).

This section is pretty much a requirement and some IESG members put 
DISCUSSes if you don't have one.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Sep 2009 08:03:25 -0600

> You are right if there's nothing else that needs to be said.

My point was that the IMPP field is not new, however it was previously
defined in RFC 4770 rather than in RFC 2426. If someone comes to
vcardrev expecting to find all and only an update to RFC 2426, they
might be surprised by the inclusion of IMPP.

But it's not a major issue for me either way.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 16 Sep 2009 10:05:37 -0400

Hi Peter,

> I still think it would be nice to have a field for offset from UTC.

As we all known the UTC offset varies with time - not just because of the 
usual DST shifts that occur in may regions, but often entire regions will 
"re-base" their offset entirely. Whilst re-basing could be handled by 
updating the vCard, one clearly does not want to have to change vCards 
twice a year on DST shifts! Even re-basing can be nasty if you are a big 
provider and host millions of vCards for affected users/entities.

Given that, if we do include the offset in vCard I think we should add text 
pointing out that the value should not be treated as definitive - instead 
we should note that the actual offset may be +/- 1 hour (or perhaps a 
little more) than the one given.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Sep 2009 09:14:12 -0600

> Does it makes sense if we write "individuals or other entities"?

Works for me.

> The idea behind KIND was to provide guidance about the semantics of
> other properties (for instance, the semantics of ORG when KIND:org is
> different from its semantics when KIND:individual), therefore the kind
> for "device" and "server" should be the same. We could define a new
> standard value "thing" for other cases which are not addressed by the
> current defined values.

A value for "thing" sounds good.

> encouraging x-* tokens when it can be managed with standards values
> (however, if distinguishing servers from other devices is important,
> this information should be conveyed in a different property).

I agree that it's desirable to avoid x- tokens.

> The default is binary value (i.e. VALUE=binary) and 8bit encoding (as
> for the every other property).
> If inline data is specified, the encoding must be reset to binary ("b"),
> but the default value is right.

OK. I think this could be worded more clearly, but I'm yet sure exactly how.

> "child" is the opposite relation of "parent".

Well all of these definitions are close to tautological ("parent" means
parent, etc.), so I don't know how much it really matters.

>> Is a category essentially the same as a "tag"?

It might be good to make that clear, since many people are familiar with
the concept of "tagging" these days.

> I don't agree with the "context of a particular locale or national
> language" part, as it seems to suggest that the collation is well-known
> and defined somewhere else.

That's better, yes.

> Besides, the current special note "The sort string is used to provide
> family name or given name text..." is ambiguous. How could the
> sort-string be of use if one cannot tell whether it applies to the given
> name or the family name.
> 
> Example 1
> FN:Rene van der Harten
> In example 2 were specified (which is valid according to the
> definition), I would collate "van der Harten" under R.

Correct. But that would be stupid. :) We can't save implementers from
their own stupidity, but I suppose we can help them understand that the
SORT-STRING is used for alphabetical sorting of family names containing
multiple words.

> Note also that the N property was redefined as a four-component text
> value. Hence the example (copied from section 7.7.5 of vcardrev-08)
> should read

OK.

>> 8.1.1.  Matching vCard Instances> >   vCard instances for which the
>> UID properties (Section 7.7.7) are>   equivalent MUST be matched.> >
> "If synchronization is performed vCard instances for which the UID
> properties ..."

Right, it's a hypothetical imperative, not a categorical imperative.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 16 Sep 2009 22:25:59 -0300

> SORT-STRING is used for alphabetical sorting of family names containing

I agree it would be stupid, but it is allowed by the definition!. I think 
there is an implicit agreement on using SORT-STRING for specifying a collation 
key for the family name, despite of the definition allowing either "family 
name or given name". In order to solve this ambiguity, the purpose of 
SORT-STRING should not mention the given name (which is not going to be 
specified there).

I propose (from the text  you suggested above):
[[
Purpose:  To specify the family name text to be used for 
national-language-specific sorting of the FN and N types.

Special notes:  The sort string is used to provide family name text that is to 
be used in sorting of the formatted name and structured name types in the 
context of an implied locale or national language. Without this information, 
sorting algorithms could incorrectly sort this vCard within a sequence of 
sorted vCards. When this property is present in a vCard, then this value, 
instead of the family name, is used for sorting the vCard.
]]

(Alternatively, it may be "family name text or family and given names text" 
instead of "family name tet")

Best Regards

Javier

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Sep 2009 19:38:55 -0600

On 9/16/09 7:25 PM, Javier Godoy wrote:
> I agree it would be stupid, but it is allowed by the definition!. I
> think there is an implicit agreement on using SORT-STRING for specifying
> a collation key for the family name, despite of the definition allowing
> either "family name or given name". In order to solve this ambiguity,
> the purpose of SORT-STRING should not mention the given name (which is
> not going to be specified there).
> 
> Special notes:  The sort string is used to provide family name text that
> is to be used in sorting of the formatted name and structured name types
> in the context of an implied locale or national language. Without this
> information, sorting algorithms could incorrectly sort this vCard within
> a sequence of sorted vCards. When this property is present in a vCard,
> then this value, instead of the family name, is used for sorting the vCard.
> ]]

Works for me.

By the way, what is a "national language"? It's not clear to me if that
term has any meaning, because it conflates political jurisdictions and
language communities (e.g., the German language is spoken in Germany,
Austria, Switzerland, parts of Belgium, etc. -- so what does it mean to
say that German is a "national language"?). I think that the phrase
"implied locale or language community" is more accurate, or even
"implied culture or language community" given that onomastics (the study
of proper names) combines aspects of both language and culture but is
not properly speaking a matter of locale.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 16 Sep 2009 23:48:35 -0300

On September 16, 2009 10:38 PM, Peter Saint-Andre wrote
> not properly speaking a matter of locale.

I like the idea of "locale" in that sentence, because it is related to 
Language-Tags. This interpretation, for instance, addresses the difference 
between nl-NL (Dutch of Netherlands) and
nl-BE (Dutch of Belgium), with different rules for collating surnames.

Replacing "national language" by "language community" (or "culture or language 
community") works for me.

Regards

Javier