Re: [VCARDDAV] two component GENDER

[Peter Saint-Andre <[e-mail]>]

On 12/16/10 1:11 AM, Tantek Çelik wrote:
> On Wed, Dec 15, 2010 at 21:48, Peter Saint-Andre <[e-mail]> wrote:
>> Hi Tantek, thanks for the feedback.
>>
>> On 12/15/10 8:31 PM, Tantek Çelik wrote:
>>
>>> One particularly important feature change that I wanted to comment on
>>> without delay however is the adoption of the new GENDER property.
>>>
>>> GENDER
>>>
>>> While I certainly applaud the increasing of flexibility from an enum
>>> to plain text field, I'd like to please ask the group to consider
>>> adopting the GENDER property as originally proposed with two
>>> components, a sex enum (M(ale),F(emale),N(one),O(ther),U(nknown)) and
>>> a plain text gender identity label. Both of these are necessary for
>>> supporting flexibility for human diversity and for representing
>>> existing publishing practices and gender specific search user
>>> interfaces.
>>>
>>> The two component GENDER property proposal was met with approval by
>>> Kevin Marks and Sarah Dopp:
>>>
>>> http://www.ietf.org/mail-archive/web/vcarddav/current/msg01784.html
>>>
>>> And as a result I had presumed there was at least weak consensus in
>>> the group on this specific proposal since there were no objections and
>>> no further messages on that thread. I must admit I was a little
>>> surprised to see a single component GENDER property instead (I am
>>> assuming this was simply a minor oversight rather than an explicit
>>> decision).
>>>
>>> I am more than happy to contribute specification text if necessary.
>>> I've iterated a bit more here:
>>>
>>> https://wiki.mozilla.org/VCard4-draft-13-review#GENDER
>>
>> The meeting notes said:
>>
>>  - Resolution: Rename SEX to GENDER. Change values to (male, female,
>>  <free-form text>). IANA registry for additional values that could be
>>  reserved.
> 
> Right, this is what I didn't understand, as just a single text value
> with 2 predefined values and <free-form text> was not proposed before
> this.
> 
>> If I recall correctly, the idea was that free-form text would be
>> allowed, such as:
>>
>>   GENDER:VALUE=text:Fellow
> 
> I think that's where the miscommunication was, probably due to my
> failure to provide specific syntax examples at the time.  The idea was
> that free-form text would be allowed IN ADDITION, such as:
> 
> GENDER:M;Fellow
> 
> 
>> Instead of:
>>
>>   GENDER:male
> 
> Instead of
> 
> GENDER:M
> 
> 
>> People could also register well-known values, such as:
>>
>>   GENDER:queer
>>
>> You seem to be proposing that the free-form text would supplement one of
>> the defined values (or no value at all). Correct? I just want to make
>> sure that I understand the proposal.
> 
> Close.
> 
> GENDER:;queer
> 
> (though in practice I'd expect many values, like 'queer', to be left
> unregistered, as different people have quite different definitions).

That seems to be endemic to the topic.

But, if someone registers "queer", the result would be what?

1. GENDER:;queer

or

2. GENDER:queer

My impression from the discussion in Beijing was #2, not #1 (if, again,
someone registered "queer" with IANA).

Peter

--
Peter Saint-Andre
https://stpeter.im/