Subject: [VCARDDAV] some issues with draft 13

From: Kevin Marks <[email-masked]>
Date: Fri, 8 Oct 2010 00:18:29 -0700

*4.7.  BINARY*

While this format needs preserving for backwards compatibility, I'd suggest
deprecating it in favour of using a data URL per RFC 2397.

This is already common practice for inline embedding of images in PHOTO or
LOGO.

Adding a data URL example to section 4.2, would clarify this, and making
this a recommended practice going forwards will simplify the spec overall,
as currently which fields that can be specified as BINARY need to be
explicitly called out.

*7.2 Matching*

The examples here repeatedly state that FN has a cardinality of 1, whereas
FN now has a cardinality of n, so the examples need revising to reflect this
- apply the cardinality n merge model to FN, and add a cardinality 1
property to the example to illustrate that behaviour.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Oct 2010 08:52:24 -0400

On 2010-10-08 03:18, Kevin Marks wrote:
> *4.7.  BINARY*
> 
> While this format needs preserving for backwards compatibility, I'd
> suggest deprecating it in favour of using a data URL per RFC 2397. 
> 
> This is already common practice for inline embedding of images in PHOTO
> or LOGO. 
> 
> this a recommended practice going forwards will simplify the spec
> overall, as currently which fields that can be specified as BINARY need
> to be explicitly called out.

I really like this. Unless people disagree, I'll do exactly that for the
next version.

> *7.2 Matching*
> 
> The examples here repeatedly state that FN has a cardinality of 1,
> whereas FN now has a cardinality of n, so the examples need revising to
> reflect this - apply the cardinality n merge model to FN, and add a
> cardinality 1 property to the example to illustrate that behaviour.

Wow, good catch! I'll revise the examples.

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