Subject: Re: [VCARDDAV] RFC 6350 on vCard Format Specification

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 17:55:44 +0300

Hello,

I've found three minor errors in the recently published RFC 6350, so I'd 
like to notify the WG about them so that we could decide whether some of 
these mistakes are worth submitting errata reports. (Sorry for not 
reporting this during Last Call.)

First,

>     vcard = "BEGIN:VCARD" CRLF
>             "VERSION:4.0" CRLF
>             1*contentline
>             "END:VCARD" CRLF
>       ; A vCard object MUST include the VERSION and FN properties.
>       ; VERSION MUST come immediately after BEGIN:VCARD.

Here ABNF and prose comment are conflicting.  I propose:

>     vcard = "BEGIN:VCARD" CRLF
>             "VERSION:4.0" CRLF
>             *contentline
>             fn-property
>             *contentline
>             "END:VCARD" CRLF
>       ; A vCard object MUST include the VERSION and FN properties.
>       ; VERSION MUST come immediately after BEGIN:VCARD.
>    fn-property = [group "."] "FN" *(";" FN-param) ":" FN-value CRLF
>       ;<FN-param>  and<FN-value>  are defined in Section 6.2.1

2:

>     param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

As this may be interpreted doubly, the following clarification should be 
done:

>     param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

Third issue:

>       year   = 4DIGIT  ; 0000-9999
>       month  = 2DIGIT  ; 01-12
>       day    = 2DIGIT  ; 01-28/29/30/31 depending on month and leap year
>       hour   = 2DIGIT  ; 00-23
>       minute = 2DIGIT  ; 00-59
>       second = 2DIGIT  ; 00-58/59/60 depending on leap second

Here ABNF permits values which are a priori outside allowed range (eg. 
37 for month etc.).  So the correction is:

>       year   = 4DIGIT  ; 0000-9999
>       month  = ( "0" DIGIT-NZ ) / ( "1" %x30-32 )  ; 01-12
>       day    = ( %x30-32 DIGIT ) / ( "3" %x30-31)
>           ; 01-28/29/30/31 depending on month and leap year
>       hour   = ( %x30-31 DIGIT ) / ( "2" %x30-33 )  ; 00-23
>       minute = ( %x30-34 DIGIT ) / ( "5" DIGIT-NZ ) ; 00-59
>       second = ( %x30-35 DIGIT ) / "60"
>           ; 00-58/59/60 depending on leap second
>       DIGIT-NZ = %x31-39 ; RFC 5234<DIGIT>  excluding "0"

Thanks,
Mykyta Yevstifeyev

01.09.2011 2:59, [email-masked] wrote:
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 6350
>
>          Title:      vCard Format Specification
>          Author:     S. Perreault
>          Status:     Standards Track
>          Stream:     IETF
>          Date:       August 2011
>          Mailbox:    [email-masked]
>          Pages:      74
>          Characters: 139895
>          Obsoletes:  RFC2425, RFC2426, RFC4770
>          Updates:    RFC2739
>
>          I-D Tag:    draft-ietf-vcarddav-vcardrev-22.txt
>
>          URL:        http://www.rfc-editor.org/rfc/rfc6350.txt

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Sep 2011 11:09:20 -0400

Hi Mykyta,

>>       ;<FN-param>  and<FN-value>  are defined in Section 6.2.1

I think the current ABNF is fine - there is no need to make this change. 
There is no conflict with the ABNF as that requires at least one property 
(content-line) to be present in addition to VERSION, and that covers the 
requirement that FN must also be present.

>>     param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

Yes, this seems like a reasonable change.

> Here ABNF permits values which are a priori outside allowed range (eg. 37
> for month etc.).  So the correction is:
>

I do not agree with this change. It adds needless complexity and doesn't 
even go far enough (e.g. to do it properly there should be proper 
restrictions on day/month/year combinations to account for different days 
in the month and leap years). The ABNF in vCard 4 is the same as that in 
iCalendar (RFC5545) which arguably places a lot more important on date 
values. This change should not be made.

-- 
Cyrus Daboo

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 18:29:02 +0300

08.09.2011 18:09, Cyrus Daboo wrote:
> I think the current ABNF is fine - there is no need to make this 
> change. There is no conflict with the ABNF as that requires at least 
> one property (content-line) to be present in addition to VERSION, and 
> that covers the requirement that FN must also be present.

The current requirement is that at least one <content-line> should be 
present additionally to Version property; and this makes such text as, eg.:

> BEGIN:VCARD
> VERSION:4.0
> URL:http://example.org
> END:VCARD

a valid vCard, as URL property matched <content-line> and this 
<content-line> is present.  If we want to keep actual 2119 requirements 
and ABNF in sync, the change is necessary.

> Yes, this seems like a reasonable change.

So I'll submit an erratum report on this issue.

> I do not agree with this change. It adds needless complexity and 
> doesn't even go far enough (e.g. to do it properly there should be 
> proper restrictions on day/month/year combinations to account for 
> different days in the month and leap years). The ABNF in vCard 4 is 
> the same as that in iCalendar (RFC5545) which arguably places a lot 
> more important on date values. This change should not be made.

Indeed, it is impossible to provide ABNF for all the possible 
combinations of DD/MM/YYYY from year 0000 to year 9999.  However, 
providing the "allowed range" ABNF is better than the current one, IMO.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Sep 2011 11:36:10 -0400

I agree with Cyrus's reply, with the following precision:

Cyrus Daboo wrote, on 09/08/2011 11:09 AM:
>> Here ABNF and prose comment are conflicting.
> 
> I think the current ABNF is fine - there is no need to make this change. There
> is no conflict with the ABNF as that requires at least one property

Right, there is no conflict. I think what Mykyta is pointing at is the fact that
the ABNF is under-constrainted.

There are many other instances of ABNF under-contrainage throughout the RFC.
Mistakes excluded, they are intentional and should not be changed. The one in
the excerpt above is not a mistake.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Sep 2011 11:41:53 -0400

Mykyta Yevstifeyev wrote, on 09/08/2011 11:29 AM:
> The current requirement is that at least one <content-line> should be present
> additionally to Version property; and this makes such text as, eg.:
> 
>> BEGIN:VCARD
>> VERSION:4.0
>> URL:http://example.org
>> END:VCARD
> 
> a valid vCard

No, this is still invalid. Not every string that matches the ABNF is valid. The
ABNF is intentionally under-constrained. You still need to apply the rules
contained in the text.

Same goes for the xCard schema, by the way.

>> I do not agree with this change. It adds needless complexity and doesn't even
>> go far enough (e.g. to do it properly there should be proper restrictions on
>> day/month/year combinations to account for different days in the month and
>> leap years). The ABNF in vCard 4 is the same as that in iCalendar (RFC5545)
>> which arguably places a lot more important on date values. This change should
>> not be made.
> 
> Indeed, it is impossible to provide ABNF for all the possible combinations of
> DD/MM/YYYY from year 0000 to year 9999.  However, providing the "allowed range"
> ABNF is better than the current one, IMO.

I disagree that it is better, but I will concede that this is a matter of taste.
Making an ABNF grammear more constrained is generally good. However, in this
instance it comes with a loss of readability. I prefer readability in this case,
but I can understand why one could prefer the alternative.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Sep 2011 11:44:12 -0400

Hi Mykyta,

> and ABNF in sync, the change is necessary.

The validity of a vcard cannot be determined by an ABNF parser. The 
definition for FN clearly indicates it has a cardinality of 1 and that 
overrides the ABNF since the ABNF is deliberately left "loose" as it cannot 
precisely describe vcards because of a lack of an "unordered list" 
construct. The same is true for iCalendar. Nothing needs to be changed here.

> providing the "allowed range" ABNF is better than the current one, IMO.

Again, there is no need to add complexity here, for zero gain. ABNF is not 
going to be used as a strict schema checker. Yes it can be used as a 
"syntax" checker (i.e. testing that dates have digits rather than alpha) 
but it is not useful as a "semantic" checker because it is incapable of 
fully expressing the required semantics. No one will use ABNF that way in 
vcard so there is no need to make it more complex than it has to be.

-- 
Cyrus Daboo

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 18:49:07 +0300

08.09.2011 18:41, Simon Perreault wrote:
>> The current requirement is that at least one<content-line>  should be present

The matter is whether ABNF in RFC 6350 is normative or not.  ABNF was 
supposed to be used when defining "formal syntax", and form normative 
definition of this syntax either readable by a human and parsable by an 
application.  RFC 6350 makes normative reference to RFC 5234, so I 
assumed it is normative.

Otherwise, you need "caveat emptor" text notifying that ABNF may be far 
constrained by the specification.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 18:54:15 +0300

08.09.2011 18:44, Cyrus Daboo wrote:
> overrides the ABNF since the ABNF is deliberately left "loose" as it 
> cannot precisely describe vcards because of a lack of an "unordered 
> list" construct. The same is true for iCalendar. Nothing needs to be 
> changed here.

See my previous message for normative/non-normative ABNF thoughts.

Anyway, ABNF may be modified simply to keep 1* cardinality of FN and 
syntax definition in sync, unlike the date matter below.  Such change 
won't affect readability and simplicity much, but will clarify the issue.

> Again, there is no need to add complexity here, for zero gain. ABNF is 
> not going to be used as a strict schema checker. Yes it can be used as 
> a "syntax" checker (i.e. testing that dates have digits rather than 
> alpha) but it is not useful as a "semantic" checker because it is 
> incapable of fully expressing the required semantics. No one will use 
> ABNF that way in vcard so there is no need to make it more complex 
> than it has to be.

So I don't insist on this any more; leaving as-is, although not ideal, 
is not bad entirely.

Mykyta

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 08 Sep 2011 11:59:00 -0400

Hi Mykyta,

> constrained by the specification.

OK, it is reasonable to add a clarifying statement that the ABNF is not 
100% normative. iCalendar has a statement like this:

   The memo also includes a formal grammar for the content type based on
   the Internet ABNF defined in [RFC5234].  This ABNF is required for
   the implementation of parsers and to serve as the definitive
   reference when ambiguities or questions arise in interpreting the
   descriptive prose definition of the memo.  Additional restrictions
   that could not easily be expressed with the ABNF syntax are specified
   as comments in the ABNF.  Comments with normative statements should
   be treated as such.

Perhaps something similar can be added when the next revision occurs.

-- 
Cyrus Daboo

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 19:15:04 +0300

08.09.2011 18:59, Cyrus Daboo wrote:
> OK, it is reasonable to add a clarifying statement that the ABNF is 
> not 100% normative. iCalendar has a statement like this:
>

As current document has no separate paragraph that notifies about use of 
ABNF, I'll submit the erratum report (just for the record) proposing 
adding the following paragraph to Section 2:

> This document makes use of Augmented Backus-Naur Form (ABNF) [RFC5234] 
> for specifying formal syntax.  Whenever some ABNF productions are 
> imported from other documents, this is clearly noted.  Several 
> constraints, which may not be presented via ABNF, are defined in 
> comments to ABNF definitions and in the text of this specification, 
> via either using RFC 2119 language or defining properties' 
> cardinality.  Such constraints MUST be treated to be normative.

Please provide your comments to this text so that we could surely mark 
erratum with such text as "Held for document update".

Mykyta