Subject: [VCARDDAV] Some issues of draft 04 and 05

From: Markus Lorenz <[email-masked]>
Date: Tue, 04 Nov 2008 00:10:53 +0100

First of all, it was real fun to see the changes made in draft 04. I
loved the group-construct and worried I would have to live without it.

I found some issues and wanted to report them. There are still some
remaining which I reported in my e-mail from the 14th of October. For
example the "word" grammar-type is still being used in the formal
grammar part but not defined. Do I have to report the issues somewhere
else than this mailing-list?

The related-type "agent" as mentioned in "B.1. Changes in -04" is
introduced in "12.2.5. Values Registries" but is missing in "9. Formal
Grammar" at the definition of "related-type".

The newly introduced "pref"-parameter is not consistent with the other
parameters, because it has no value. What about a boolean-value? You
could write "pref" = "true". Of course you could also leave it out
instead of using "pref" = "false".

One thought which might be considered: I newly participated in a survey
on the usage of wikipedia and there have been three options for gender:
"Male", "Female" and "Other". For me it seemed kind of weird, but there
is much stuff like this out there:
http://www.telegraph.co.uk/news/worldnews/asia/thailand/2156544/Thai-school-builds-transgender-toilet.html
So maybe someone wants to add a third gender value to the definition.

The pid-value only accepts singular-digit numbers. Can you tell me why?
I read that is has to be a SMALL integer. But I also know some guys
having more than ten e-mail-addresses. It may be senseless to collect
all these in one vcard, but why do you restrict the pid that hard?

What about a reference from a person which is member of a group to this
group? By now the "KIND:group"-vcard can refer to its members. But I did
not see a chance to refer from the person to the group. Maybe it would
be reasonable to introduce a "RELATED;TYPE=membership" relationship.

Why does the non-standard-type "X-" only accept text-values? Maybe I
would like to write a program which adds non-standard binary information
to a vcard. I do not see the need to restrict the value to only textual
information, because this type's right to exist (7.10.) is exactly to
include non-standard information which most likely will not be
understood by any other program. Why not allowing any kind of parameters
and values, so that programs can also handle complex non-standard data
by using the correct syntax?

Best regards

Markus

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

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 3 Nov 2008 20:48:33 -0500

Comments on two of the items,
dgc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Markus Lorenz
> Sent: Monday, November 03, 2008 6:11 PM
> To: [email-masked]
> Subject: [VCARDDAV] Some issues of draft 04 and 05
> 

Allow me to just repeat a previous email, since I made the same mistake...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Simon Perreault
Sent: Thursday, June 26, 2008 4:49 PM
To: [email-masked]
Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-02.txt

On Thursday 26 June 2008 16:43:27 Darryl Champagne wrote:
> >    pid-param    = ("PID" "=" 1*DIGIT)
>
> Umm, seeing Javier's email with just this section made me realize...
>
> Being a little sarcastic, are we?
>
> That requires slightly more than one character digit.

1*DIGIT means "at least one digit".

I almost wish I had forgot the *, that would have been very funny.

;-)

> by using the correct syntax?

This seems very problematic - how could a parser for vCard skip over it?
You either need a length for the data, or some kind of start or end tag
(like MIME), or you will need to do some form of escaping for the
CR/LF/;/etc characters in the binary.

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 4 Nov 2008 06:16:14 -0200

On Monday, November 03, 2008 Markus Lorenz wrote,

> So maybe someone wants to add a third gender value to the definition.

I think this issue is more complex than "Male, Female and Other". A value of
"other" may be enough for statistical purposes, but it does not convey useful
information when identifying individuals. For instance, does the value
represent the phyisical gender or the adopted one? In consequence, which
pronouns should be used when addressing this individual?

Furthermore, the N property may represent the legal name, or the adopted name;
and both names might be present as different N properties, with no means for
distingishing one from the other.

This issue could be addressed in a separate extension if GENDER is made
extensible, but simpler applications might treat GENDER as a binary valued
property.

> be reasonable to introduce a "RELATED;TYPE=membership" relationship.

I recall this was already discussed and some rationale was argued that time,
but I didn't find any reference. I think it is a good idea.

Note: MEMBER could be also represented as a particular case of RELATED.

> by using the correct syntax?

X- parameters are allowed (per text-param definition) and I understand the
"encoding" parameter should be allowed too, then you would be able to
represent binary information encoded as base64.

Best regards

Javier

---

From: Markus Lorenz <[email-masked]>
Date: Tue, 04 Nov 2008 22:26:28 +0100

> > I almost wish I had forgot the *, that would have been very funny.

Ok, I think I missed this one. Then it is of course all right with the
pid. :-)

> > extensible, but simpler applications might treat GENDER as a binary
valued

You are right. If I wanted to use the gender-type for automation, for
example to decide between using "Mr." or "Ms.", it would be useless if
there was a third value.

> > Note: MEMBER could be also represented as a particular case of RELATED.

If this is possible, it is what I liked to have. But I did not find this
in draft 05. There are only the related-types "parent", "child",
"sibling", "manager", "assistant" and "agent".

> > represent binary information encoded as base64.

This is what I wanted to say.

For Darryl Champagne: My mail was mistakable, because I did not
mention the base64 encoding of the binary data I wanted to include. Pure
binary data would violate the hole textual-format of the vcard.

Thanks

Markus

---

From: Dan Brickley <[email-masked]>
Date: Tue, 04 Nov 2008 22:42:37 +0100

+cc: foaf-dev

> example to decide between using "Mr." or "Ms.", it would be useless if

Maybe not useless. It just might not divide the world into two tidy 
collections. But there are many thousands of people for whom the world 
is not so divided.

In the FOAF spec, we went with a hybrid design:

http://xmlns.com/foaf/0.1/#term_gender

'gender - The gender of this Agent (typically but not necessarily 'male' 
or 'female').'
[[
The foaf:gender property relates a foaf:Agent (typically a foaf:Person) 
to a string representing its gender. In most cases the value will be the 
string 'female' or 'male' (in lowercase without surrounding quotes or 
spaces). Like all FOAF properties, there is in general no requirement to 
use foaf:gender in any particular document or description. Values other 
than 'male' and 'female' may be used, but are not enumerated here. The 
foaf:gender mechanism is not intended to capture the full variety of 
biological, social and sexual concepts associated with the word 'gender'.
[...]
]]

The concept of gender is too complex and politicised if you dig into it 
for any formal set of categories to please everyone. Yet it is clear 
that a simple binary field doesn't do justice to the richness of this 
area of human life. So for FOAF we defined two privileged values 'male', 
'female' and left the possibility for other values. This certainly does 
make things harder at the UI and automation level, but I found the 
alternative less acceptable: we shouldn't impose a simplistic cartoon 
universe on human users simply because it's easier to compute with.

imho etc.,

cheers

Dan

--
http://danbri.org/

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 4 Nov 2008 23:44:56 +0000

In message <[email-masked]>, Dan Brickley
<[email-masked]> writes

>area of human life. So for FOAF we defined two privileged values
>'male', 'female' and left the possibility for other values. This
>certainly does make things harder at the UI and automation level, but I
>found the alternative less acceptable: we shouldn't impose a simplistic
>cartoon universe on human users simply because it's easier to compute
>with.

Perhaps, but many authorities (including legislation in most countries)
only recognise the two majority values.

Then there's the issue of numbers; I bet >99.999% of people identify
themselves as either male or female (FOAF's audience may be more, shall
we say, esoteric, than the population at large).

Perhaps "male", "female" and other" would suffice?

-- 
Andy Mabbett
            Says  "NO! to compulsory UK ID Cards":  <http://www.no2id.net/>
            and:  "Free Our Data":  <http://www.freeourdata.org.uk>
                   (both also on Facebook)
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Markus Lorenz <[email-masked]>
Date: Wed, 05 Nov 2008 10:19:10 +0100

> Perhaps "male", "female" and other" would suffice?

I was just looking through draft 05 for a likewise value definition,
where we have some constantly defined values and some which may be
chosen by the user. The CLASS-value definition matches these requirements:

   ; **** CLASS ****
   param        = ""
       ; No parameters allowed

   value        = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL"
                / iana-token / x-name
       ; Value are case insensitive

So maybe we can define

   ; **** GENDER ****
   param        = ""
       ; No parameters allowed

   value        = "M" / "F" / iana-token / x-name
       ; Value are case insensitive

I think that only allowing the usage of a gender called "other" would
not satisfy the need of the people who would have to use it because they
do not want to categorise themselves as simply "male" or "female".
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 17 Nov 2008 10:30:10 -0600

> loved the group-construct and worried I would have to live without it.

:)

> else than this mailing-list?

No, this is the perfect place to report all kinds of bugs.

Thanks for reporting this. I've filed an issue.

> Grammar" at the definition of "related-type".

Fixed.

> instead of using "pref" = "false".

What about changing the "param" production rule from this

    param        = param-name "=" param-value *("," param-value)

to this?

    param        = param-name ["=" param-value *("," param-value)]

> So maybe someone wants to add a third gender value to the definition.

No opinion on this...

> all these in one vcard, but why do you restrict the pid that hard?

See Darryl's reply.

> be reasonable to introduce a "RELATED;TYPE=membership" relationship.

The problem with this is the following. Imagine you create a group. It's
your own group. You have control over its membership.

Now suppose someone publishes a vCard claiming membership of your group
with RELATED.

That's why we initially restricted the RELATED property to one-way
membership.

> by using the correct syntax?

A non-standard property starting with "X-" has *VALUE-CHAR for
acceptable value. Is this what you're referring to? If so, what would
you change it to?

Keep in mind that it must fit with the vCard general syntax, i.e. line
folding and such. Also keep in mind that you can specify binary data 
using BASE64 encoding. See also Darryl's reply to this.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 17 Nov 2008 10:39:56 -0600

>        ; Value are case insensitive

This is the solution that I find most acceptable.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Markus Lorenz <[email-masked]>
Date: Mon, 17 Nov 2008 19:30:56 +0100

>    param        = param-name ["=" param-value *("," param-value)]

Well, this is a possible solution, of course. But why do you want to
change the formal definition of all parameters, to just introduce a new
parameter-name? In vCard 2.1 the "TYPE=" prefix was not required, but in
3.0 it is. I guess they made this to ensure a clean syntax. In my
opinion, allowing this "unclean" syntax again would be regressive.

> That's why we initially restricted the RELATED property to one-way

Ok, I didn't see this. I think I even didn't fully understand the
purpose of the group. I imagined groups which I create locally on my PC,
for example to group all friends together to easily send a mail to all
of them. But if the owner publishes this information, it's clear that no
one should be allowed to claim membership of the group.

> using BASE64 encoding. See also Darryl's reply to this.

As I wrote in my mail from the 4th of November, I intended a
non-standard type with all possible parameters and values, which the
format allows somewhere for some standard-types.
At this time, it is not possible to include binary (base64) information
into the non-standard-type value, like it can be used in SOUND or LOGO.
The "pid-param" is also not allowed. Needless to say that applications
which don't know the specific non-standard type can't handle it. But
maybe these which know it, would like to use pid. A "text-value-list" is
not allowed. Notice, that the "text-value-list" includes the more simple
"text-value".
I think this all should be allowed, because I can see no reason to deny
it. The aim of the non-standard type is that anyone may extend the vcard
for his or her own purpose by adding data of any kind, but to also
produce a valid vcard which matches the formal grammar. This enables
other programs to smoothly ignore the specific data.

The definition could look like this:

   ; **** X- **** non-standard type
   param        = x-bin-param / x-txt-param / pid-param

   value        = x-bin-value / x-txt-value
       ; Value and parameter MUST match

   x-bin-param = ("ENCODING" = "b") / text-param

   x-txt-param = text-param

   x-bin-value = binary-value

   x-txt-value = text-value-list

By the way: The draft-05 definition of the non-standard type is
redundant. It says 'param = text-param / (x-name "=" param-value)' but
'text-param' already includes '(x-name "=" param-value)'.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav