[VCARDDAV] New vCard 4.0 fields

[<[e-mail]>]

Hello,

The OMA-CAB group defines vCard 2.1 extensions which are :
 
attributes      
      X-CAB-PCC-TYPE : To specify the kind of object the vCard represents.
      X-CAB-CONTACT-STATUS : To specify the CAB status of the object the vCard represents (updated, temporary, subscription active, ...)
      X-CAB-SEX : looks like SEX/GENDER
      X-CAB-LANG : To specify the language(s) that may be used for contacting the individual associated with the vCard.
      X-CAB-SERVICE : To specify the aliases used on different sites by the object that the vCard refers to.
      X-CAB-EXPERTISE : To specify the expertise(s) of the object that the vCard refers to.
      X-CAB-HOBBY : To specify the hobbies of the object that the vCard refers to.
      X-CAB-INTEREST : To specify the interest(s) of the object that the vCard refers to.
      X-CAB-PUBLICNOTE : To specify additional information associated with the object the vCard refers to.
      X-CAB-ORG-DIRECTORY : To specify the organization-directory of the object the vCard represents.

Parameters used in the new attributes definitions
      X-CAB-CONTACT-ID-REF 
      X-CAB-INDEX
      X-CAB-LANGUAGE-PROFICIENCY-TYPE 
      X-CAB-LANGUAGE-FLUENCY-TYPE 
      X-CAB-LEVEL

The OMA-CAB group defines these extensions with an "IETF like" description.

My question is : can we introduce these extensions as standard fields in the vCard 4.0 in order to be compliant with "OMA-CAB vCard extensions" ?

Regards

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
Envoyé : lundi 15 novembre 2010 19:46
À : [e-mail]
Objet : VCARDDAV Digest, Vol 39, Issue 93

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/vcarddav

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.



Send VCARDDAV mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/vcarddav
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of VCARDDAV digest..."


Today's Topics:

   1.  IETF79 vcarddav wg meeting notes (Marc Blanchet)


----------------------------------------------------------------------

Message: 1
Date: Mon, 15 Nov 2010 13:46:50 -0500
From: Marc Blanchet <[e-mail]>
Subject: [VCARDDAV] IETF79 vcarddav wg meeting notes
To: CardDAV <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,
  please find the minutes of our meeting. Please send any modifications to me directly.

Marc, co-chair.

--------------------

IETF Vcarddav working group
IETF 79 meeting, Beijing, China
November 10th 2010, 15h10-16h10

1. Administrativia

2. vcard4 and vcardxml wglc comments (Perreault, Resnick)
  draft-ietf-vcarddav-vcardrev
  draft-ietf-vcarddav-vcardxml

- i18n email
   - Problem: How to allow Unicode characters in EMAIL. Choose eai? 
utf-8? ...
   - Resolution: None. Chairs will discuss with area directors about.

- Restoring N format
   - Problem: Current format for N is not backward compatible.
   - Resolution: Go back to vCard 3's format and allow multiple items in each component.

- DDAY, BIRTH, DEAH
   - Problem: New properties which are not widely implemented.
   - Resolution: Remove them from base vCard 4. (Could be defined as an
extension.)

- Remove fields from ADR
   - Problem: PO box and extended address fields are misunderstood and not interoperable.
   - Resolution: Keep fields, but indicate that they SHOULD be empty.

- Link LABEL to ADR
   - Problem: No way to know which LABEL is associated with which ADR.
   - Resolution: Remove LABEL property and make it a parameter of ADR.

- Remove BINARY
   - Problem: BINARY value type is redundant with data: URI scheme.
   - Resolution: Remove BINARY property, remove FMTTYPE and ENCODING parameters.

- SEX
   - Problem: Biological vs psychological semantics are unclear. Allowed values are un-intuitive and restrictive.
   - Resolution: Rename SEX to GENDER. Change values to (male, female, <free-form text>). IANA registry for additional values that could be reserved.

- TEL property
   - Problem: Previous parsers of TEL property values cannot parse tel: 
URIs.
   - Resolution: Default to free-form text, but SHOULD reset to a URI.

- CALSCALE parameter
   - Problem: Having only a single pre-defined value makes this parameter useless.
   - Resolution: Refer to iCalendar and create an IANA registry for calendar types.

- Calendar properties
   - Problem: FBURL, CALADRURI, and CALURI are new for vCard 4. Maybe better suited for an extension.
   - Resolution: Keep them.

- Date ranges
   - Problem: Proposal to add a new parameter for identifying validity ranges for properties.
   - Resolution: Do not add.

- KIND property
   - Problem:
     - KIND property is new for vCard 4.
     - Maybe BEGIN:VGROUP would be better.
     - Semantics for KIND:thing are vague.
   - Resolution:
     - Reduce the list to the ones we think we understand well right now.
     - If you want new ones registered, you have to write a draft that profiles the fields that make sense for that kind.

- RELATED property
   - Problem: Property is new for vCard 4. Allowed values do not make consensus. Multiple types are impossible.
   - Resolution:
     - Use the XFN 1.1 taxonomy.
     - Allow a list of types.

- Synchronization
   - Problem: Synchronization is new for vCard 4.
   - Resolution: Keep it.

- CATEGORIES property
   - Problem: Would be nice to use URIs as tags.
   - Resolution: Do not do this. (Could be specified in an extension.)

- VERSION parameter
   - Problem: VERSION parameter is useless, violates DRY.
   - Resolution: None. ("Take it to the list.")
     - Proposal: Drop it. Specify 1.0 in text.

- CLASS parameter
   - Problem: Not used in practice. Interoperability is bad.
   - Resolution: Drop it.

- Case sensitivity
   - Problem: Case causes interoperability issues in practice.
   - Resolution: Output SHOULD be upper-case. Accept both.

- New ACCOUNT property
   - Problem: Proposal for a new ACCOUNT property.
   - Resolution: Reject proposal. (Could be added in an extension.)

- REV property
   - Problem: Proposal for allowing date resolution.
   - Resolution: Reject proposal.

- Cardinality notation
   - Problem: Notation is new, people are unfamiliar with it.
   - Resolution: Adopt ABNF notation.

3. Charter discussion
  Concensus was that there are possible additional work items. Next IETF should have a vcarddav meeting to discuss these.


-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca



------------------------------

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


End of VCARDDAV Digest, Vol 39, Issue 93
****************************************