Re: [VCARDDAV] Calendar resource schema draft

Hi Simon,
   It does map existing VCARD to new or existing LDAP equivalents in many cases. Actually in as many as possible. To take a quick example:

5.1.  Common Name

   Description:
      Full name of the resource.  This attribute MUST be defined for a
      resource object.

   ValueType:
      String value.

   Example value:
      Room One

5.1.1.  LDAP Attribute Definition

   cn attribute as defined in Section 2.3 of [RFC4519].  This attribute
   MUST be present in a CalendarResource object.

5.1.2.  VCard Property Definition

   FN property as defined in Section 6.2.1 of [RFC6350].

Will this cause a conflict with the proposed LDAP->vCard mapping work?

Thanks,
Ciny

On Oct 12, 2011, at 1:13 PM, Simon Perreault wrote:

> On 2011-09-28 11:00, Cyrus Daboo wrote:
>> We would like to move ahead with publishing of
>> <http://tools.ietf.org/html/draft-cal-resource-schema-05>, but I wanted
>> to know whether the new charter item for this WG of producing an
>> LDAP->vCard mapping might pre-empt that. Do we have to delay the
>> cal-resource-schema draft in the WG work item?
> 
> Note that this item is not new. It has always been in the charter.
> 
> As far as I can see, your draft defines a vCard<->LDAP mapping but only
> for new stuff, right? Does it say, for example, that some piece of
> information is represented in vCard as syntactic element X, where X is
> something that already exists? If all Xs are new stuff (i.e. IANA will
> need to create new records in the vCard registry for them) then I don't
> see a conflict.
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV@ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav