Subject: [VCARDDAV] Minor issues

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2008 22:19:04 -0500

Hi,
Some minor issues in the current draft:

1) Several examples use 'foobar.com', 'abc.com' etc as domain names. 
Usually IETF policy requires use of 'example.com'.

2) Section 4.1 - line folding: in Calsify we tweaked the line folding 
description to use 'octets' rather than 'characters' and to describe the 
issue with multi-octet UTF-8 sequences. I think we should try and follow 
the same wording/approach in vCard.

3) Section 4.2:

x-name       = "x-" 1*(ALPHA / DIGIT / "-")

But the comment says 'X-' can also be used. So I think the ABNF should be:

x-name       = ("x-" / "X-") 1*(ALPHA / DIGIT / "-")

I don't think I have ever seen lowercase 'x-' used - certainly iCalendar 
only defines uppercase 'X-' if that counts for anything. Also Section 5.9 
only mentions 'X-'. Also Section 6 only defines 'X-'.

4) Section 4.2 - the ABNF is duplicated. Plus the same things appears in 
Section 6.

5) Section 6 - repeats several definitions from 5234 (e.g. WSP, HTAB).

6) Did we decide on whether UID should be mandatory in a vCard? If so, we 
need to include that in the vcard definition comment in Section 6.

7) In Section 6 where it lists the definition of each property it uses 
comments like:

    ;For name='ADR'

I actually find it a little hard to quickly scan that to find the 
definition of a partocular property. Can we change the comment to something 
that would stand out, like:

    ; **** ADR ****

-- 
Cyrus Daboo

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 28 Feb 2008 01:46:58 -0200

Cyrus Daboo wrote,

> only mentions 'X-'. Also Section 6 only defines 'X-'.

Per Section 4.2 (page 7) [[
  Property names and parameter names are case insensitive
]]

and from Section 2.3 of RFC 5234 [[
 ABNF strings are case insensitive
]]

I think the current definition is fine (and I see no advantage on declaring 
"X-" as case sensitive).

> that would stand out, like:

Good idea..

Another approach would be moving each ABNF rule to the section where the 
related property is defined, leaving Section 6 for "core" rules.

Disadvantages: ABNF will be scattered though the document.

Advantages: ABNF rules will be placed near enough natural language 
description (i.e. "special notes") and examples for each case. Besides, 
subsections appear in TOC, which contains links when the document is 
formatted as HTML. I have found it is easier to scroll through 5.* 
subsections than scrolling through  Section 6 is.

Best Regards,

Javier

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2008 23:13:29 -0500

Hi Javier,

--On February 28, 2008 1:46:58 AM -0200 Javier Godoy 
<[email-masked]> wrote:

> I think the current definition is fine (and I see no advantage on
> declaring "X-" as case sensitive).

Yes, OK. May I suggest then that one or two examples use all lowercase 
property names etc just to emphasize this.

The iCalendar spec ought to do the same too.

> subsections than scrolling through  Section 6 is.

iCalendar has the definitions "inline" rather than in a formal grammar 
section. It is easier to use the TOC or section title to quickly find what 
you want.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Feb 2008 16:09:04 -0500

On Wednesday 27 February 2008 22:19:04 Cyrus Daboo wrote:
> Section 4.1 - line folding: in Calsify we tweaked the line folding

I violently object. :)

We fold lines because it is easier on the eyes of a human. Computers couldn't 
care less. Therefore lines should be folded on 75 humanly-visible characters, 
not octets. If a "very simple implementation" (VSI) only speaks bytes, then 
it shouldn't try to fold, period.

I understand that unfolding on an octet basis is intended to accomodate VSIs. 
But note that this affects badly "not-so-simple implementations" (NSSI) that 
work in UTF-8 but do not expect multi-byte characters to be split.

Take for example this beautiful unfolding Perl regexp:

  $vcard =~ s/\r?\n\s//sg

Since Perl is all UTF-8, this should do the job, right? Wrong. You need to 
remove the UTF-8 flag from $vcard, apply the regexp, and reset the UTF-8 
flag. That is, perform some voodoo. By allowing VSIs to do whatever they 
want, we made life harder for NSSIs.

So here's what I would like to see in the text:
- Fold on 75 characters (not octets).
- SHOULD unfold on octets.

This way, the VSI will be doing something wrong (which it really is) when 
splitting in the middle of UTF-8 characters. And the NSSI will at least have 
the fuzzy feeling of knowing it's more compliant than VSI when it can't 
unfold the output of VSI. And of course a majestically complex implementation  
will be able to unfold the output of both VSI and NSSI and produce output 
that is unfoldable also by both VSI and NSSI.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Fri, 29 Feb 2008 08:38:53 -0500

> Usually IETF policy requires use of 'example.com'.

Fixed, thanks.

> only mentions 'X-'. Also Section 6 only defines 'X-'.

Will not fix as detailed in other comments.

> 4) Section 4.2 - the ABNF is duplicated. Plus the same things appears in

Fixed duplication. It was caused by a bug in xml2rfc which was worked around.
As for section 6, I think the duplication is intended because that's the way 
it was in the original RFC.

> 5) Section 6 - repeats several definitions from 5234 (e.g. WSP, HTAB).

They have been removed.

> need to include that in the vcard definition comment in Section 6.

The status quo from RFC 2426 is that UID isn't mandatory. I would argue 
against it being made so.

> that would stand out, like:

Eventually this section 6 will be merged in the rest of the document, as 
suggested.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Feb 2008 16:00:01 -0500

Hi Simon,

--On February 28, 2008 4:09:04 PM -0500 Simon Perreault 
<[email-masked]> wrote:

> We fold lines because it is easier on the eyes of a human. Computers
> couldn't  care less.

Um, no. The whole reason we have line folding is to ensure that the object 
can be transported over a transport that wraps lines - yes the legacy of 
old email systems hits us here. Its not a user presentation thing at all. 
In fact I would argue that humans should never see "raw" vcards so trying 
to make them look "pretty" is wasted effort.

The bottom line is the limit is 75 octets NOT 75 characters for transport. 
That is certainly the way it is in iCalendar and I believe the same is true 
for vCard. And yes that does raise the issue of splitting in the middle of 
a multi-octet character. Ideally that should not be allowed as otherwise it 
gives rise to invalid utf-8 data in the folded line state.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 29 Feb 2008 16:23:52 -0500

> to make them look "pretty" is wasted effort.

Wow. Thanks for the reality check. I'm going to add the rationale to the 
document to spare other people from the humiliation. ;)

Ok, I'll add something along these lines in the text. Instead of:

> After generating a content line, lines longer than 75 characters SHOULD be
> folded.

we'll have:

> Content lines SHOULD be folded to a maximum width of 75 octets. Multi-byte
> characters SHOULD remain contiguous.

And I will add the unfolding note verbatim from 2445bis.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav