Re: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Possible Errata/Questions

[Simon Perreault <[e-mail]>]

First, thank you very much for this review! You caught many important bugs!

On 2010-03-31 20:44, Florian Zeitz wrote:
> Section 3.3. Property Value Escaping:
> »A property instance may contain one or more values delimited by a
>     COMMA character (ASCII decimal 44).«
> This is IMHO somewhat misleading because (if I'm not mistaken) not all
> properties can contain more than one value. This could be rephrased as
> "Instances of some properties may contain [...]"

Agreed. Will be changed in -11.

> »Finally, newline (ASCII decimal 10) and backslash (ASCII decimal 92)
>     characters in values MUST be escaped by prefixing them with a
>     backslash character.«
> Is this intended? While it is not unheard of to prefix newline
> characters with a backslash character to escaping it I would have
> expected that "\n" is used here for consistency.

I'm not sure I understand your point perfectly, but I agree that this is 
confusing. Here's the proposed new text:

>     <t>Finally, BACKSLASH characters in values MUST be escaped with a BACKSLASH
>       character. NEWLINE (ASCII decimal 10) characters in values MUST be encoded
>       by two characters: a BACKSLASH followed by an 'n' (ASCII decimal 110).</t>

Is this clearer? If not, how else could it be made clearer?

> Section 4. Property Value Data Types:
> »text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)«
> I suspect this was supposed to say
> "text-list = 1*TEXT-LIST-CHAR *("," 1*TEXT-LIST-CHAR)"
> so that empty list entries are not allowed.

No. Empty lists are allowed. It is perfectly fine to have e.g.

NICKNAME:

which means: "I have one nickname, and it is the empty string."

> If it was on purpose it could also be rewritten as
> "text-list = *(*"," *TEXT-LIST-CHAR)"
> admittedly this is not beautiful, but would make it clearer that empty
> list entries are allowed and might avoid misinterpretation.

I disagree. I think it would be much more confusing because then the 
production *TEXT-LIST-CHAR would no longer represent a single text value.

> Section 4.7. BINARY:
> »The "binary" value type specifies that the type value is
>     inline, encoded binary data.«
> Honestly I'm not even sure what this is supposed to mean. Would
> 'The "binary" value type specifies that the properties value
>     inline, encoded binary data.'
> be an equivalent statement?

Yes. This is a relic of vCard 3.0, when "properties" were "types".

Fixed in -11.

> Section 5. Property Parameters
> »Property parameter values that are not in quoted strings are case
>     insensitive.«
> Earlier it is mentioned in Section 3.2 that whether a parameter is case
> sensitive depends on it's definition, which IMHO slightly contradicts
> this. I also wonder if assuming that quoted strings are case sensitive
> is correct (this should probably be explicitly mentioned in any case).
>
> Only for the VALUE (5.3) and PREF (5.4) parameter it is explicitly
> specified that they are optional. My understanding is that all
> parameters are optional unless otherwise specified for a certain
> property. If this is correct this statement is IMHO misleading and/or
> unnecessary.

True. This sentence is false and will be removed in -11. Thanks.

> I'm a bit unclear on the usage of the LANGUAGE param. Is it
> possible/intended to have the same property in different languages?
> E.g.:
> BIRTH;LANGUAGE=de-DE:Köln
> BIRTH;LANGUAGE=en-US:Cologne
> If it is this won't integrate nicely with properties with Cardinality
> (0,1) or (1,1) and PIDs.
> If this usage is however not expected I think it would be useful to
> explicitly state this.

Ouch! This is a big problem!

I'll start a new thread to gather input from the working group on this 
issue.

> Section 6.6.4 ORG:
> »Value type: A single structured text value consisting of components
>        separated the SEMI-COLON character (ASCII decimal 59).«
> Should probably say "separated by"

Yes, thanks.

> PID/CLIENTPIDMAP:
> The specification is IMHO a bit confusing in regard to PIDs and
> CLIENTPIDMAP. It is said that a PID can be either of the form "n" or
> "n.m" where n and m are small numbers. CLIENTPIDMAPs however seem to
> assume a PID always has 2 fields the second being a "PID source
> identifier". Does that mean a PID of the form "n" can not be mapped to a
> UUID?

Yes, that's exactly it. The second field of a PID has only one purpose: 
to match it against a UUID. If you're not using CLIENTPIDMAP, you should 
use the "n" form.

> Is there any reason to allow this form at all? None of the
> examples seem to use it.

Some people argued a lot for having just a "single small integer"...

> Section 7.2.5. Global Context Simplification:
> I wonder what is up with this section... It introduces a completely new
> concept to which there is no normative reference whatsoever within an
> example.
> When I read it, it sounded like a good idea at first. Reduces size,
> makes vCard better readable (at least for humans), etc. But on second
> thought this seams *very* error prone especially since it is unspecified.
> It will IMHO fail if you sync more than 2 devices (not necessarily at
> the same time), not all of the devices perform the simplification and
> probably in many other cases.
> If this section is kept I think there should be some normative text
> explaining how this process should be implemented.

Well, one could argue that the whole of section 7 is experimental since 
it has never been implemented. This was argued in Anaheim.

I'll start a separate thread for this issue.

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