[uf-discuss] Some hcard feedback from a vCard implementor

[Sam Roberts]

On Tue, Apr 04, 2006 at 04:02:45PM -0500, brian suda wrote:
> Sam Roberts wrote:
> > On Tue, Apr 04, 2006 at 11:38:36AM -0700, Ryan King wrote:
> > You have a description on the wiki of deriving N from FN, which assumes
> > things about the format of FN that are culturally specific (first names
> > before last, for example), when the very absence of N is a violation of
> > the vCard spec.
> >
> > It sure looked to me like the spec is describing how to do that which
> > shouldn't be done. Maybe saying "we know its a bad idea" would be a good
> > idea. I don't see why you have any rules at all.  Have you actually
> > found non-conformant vCards in the wild that lack a N?
> >   
> The spec itself says that N is required, then in the examples at the end
> of the RFC, where the Authors mark-up their own identities in vCard,
> omit the  N property.

A well-known error in a part of RFC2426 that isn't even in the text of
the specification isn't normative, and isn't what I'd consider "in the
wild", though I'm sure the authors feel suitably foolish. Frank Dawson
got it right his next try, in RFC2445.

What I'm trying (unsucesfully) to ask is if anybody has actually found
vCard generating software that violates the spec, and that they really
want hcard to be able to interoperate with?

If not, the avowed guideline of simplicity would suggest that there not
be special case rule set to handle hypothetically non-conformant cards.

If you all think that assigning semantic meaning to FN is actually a
good idea, I'd understand, if not agree, but since it seems to be agreed
that its a bad idea... why do it?

I just don't get it...

> >> I believe newer versions of AddressBook have fixed  this bug.
> >>     
> >
> > What bug? I didn't describe any bugs. Mangling utf-8 isn't a bug, how
> > was AddressBook supposed to know utf-8 is my favorite character set?
> >   
> In the APPLE Address Book, under preferences -> vCard you specify which
> is your favourite encoding type. Even when UTF-8 was selected it mangled
> the input. (I believe) this has been corrected in the newest version. I
> am running 4.0.3 and it works for me - previous versions did not.

Huh, it would never occur to me that specifying the ENCODING charset was
intended to have the side effect of changing the charset assumed during
DECODING, but sounds like I'll be happy when I upgrade. Encoding as
UTF-16 was annoying, I like utf-8, and I've a lot of non-ASCII contacts.

Cheers,
Sam