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

[Florian Zeitz <[e-mail]>]

On 2010-04-06 15:12 Simon Perreault wrote:
> First, thank you very much for this review! You caught many important bugs!
> 
Well, thank you for taking the time to read it and act upon it ;)
Especially since it was rather lengthy.

> On 2010-03-31 20:44, Florian Zeitz wrote:
>> »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?
> 
Yes this is a lot clearer. To clarify my concern, IMHO the old text
stated that you escape a NEWLINE with a BACKSLASH followed by a NEWLINE
character.

>> 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.
> 
Why would *TEXT-LIST-CHAR not represent a single text value any more?
Anyway, I'm fine with this even though I don't really see the use-case.

>> 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"...
> 
I think my basic concern about this is that if you're not using
CLIENTPIDMAP the synchronization described in Section 7 doesn't work
(AFAICT).
I suspect that regardless of whether Section 7 is to be split in a
separate RFC, some text will be needed to make everything work together.

> Thanks,
> Simon

--
Florian Zeitz