Subject: [VCARDDAV] New Version for draft-cal-resource-schema-03

From: Ciny Joy <[email-masked]>
Date: Mon, 29 Nov 2010 10:42:29 -0800

Hi,
   A new version has been submitted for the calendar resource schema draft - http://tools.ietf.org/html/draft-cal-resource-schema-03. Changes have been to include an IANA section for OID registration, clarifying definition of booking window, and fixing some typos. We believe this document is ready for last call. Your review comments would be greatly appreciated.

Thanks,
Ciny

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: November 29, 2010 9:35:12 AM PST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-cal-resource-schema-03 
> 
> 
> A new version of I-D, draft-cal-resource-schema-03.txt has been successfully submitted by Ciny Joy and posted to the IETF repository.
> 
> Filename:	 draft-cal-resource-schema
> Revision:	 03
> Title:		 Schema for representing resources for calendaring and scheduling services
> Creation_date:	 2010-11-29
> WG ID:		 Independent Submission
> Number_of_pages: 37
> 
> Abstract:
> This specification describes a schema for representing resources for
> calendaring and scheduling.  A resource in the scheduling context is
> any shared entity that can be scheduled by a calendar user, but does
> not control its own attendance status.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 29 Nov 2010 15:29:29 -0500

this document "knows" a lot about the internal structure of a vcard. I 
think it would be more appropriate to wait until vcardrev goes to a 
stable mode (such as RFC-editor queue) before this goes out. I'm not 
sure a Normative Reference would be sufficient to make sure the two 
documents are fully in sync at the time of publication.

Marc.

Le 10-11-29 13:42, Ciny Joy a écrit :
> Hi,
> A new version has been submitted for the calendar resource schema draft
> - http://tools.ietf.org/html/draft-cal-resource-schema-03. Changes have
> been to include an IANA section for OID registration, clarifying
> definition of booking window, and fixing some typos. We believe this
> document is ready for last call. Your review comments would be greatly
> appreciated.
>
> Thanks,
> Ciny
>
> Begin forwarded message:
>
>> *From: *IETF I-D Submission Tool <[email-masked]
>> <mailto:[email-masked]>>
>> *Date: *November 29, 2010 9:35:12 AM PST
>> *To: [email-masked] <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>, [email-masked]
>> <mailto:[email-masked]>
>> *Subject: **New Version Notification for draft-cal-resource-schema-03 *
>>
>>
>> A new version of I-D, draft-cal-resource-schema-03.txt has been
>> successfully submitted by Ciny Joy and posted to the IETF repository.
>>
>> Filename:draft-cal-resource-schema
>> Revision:03
>> Title:Schema for representing resources for calendaring and scheduling
>> services
>> Creation_date:2010-11-29
>> WG ID:Independent Submission
>> Number_of_pages: 37
>>
>> Abstract:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

-- 
=========
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

---

From: Ciny Joy <[email-masked]>
Date: Mon, 29 Nov 2010 15:31:50 -0800

Ok.

Ciny

On Nov 29, 2010, at 12:29 PM, Marc Blanchet wrote:

> this document "knows" a lot about the internal structure of a vcard. I think it would be more appropriate to wait until vcardrev goes to a stable mode (such as RFC-editor queue) before this goes out. I'm not sure a Normative Reference would be sufficient to make sure the two documents are fully in sync at the time of publication.
> 
> Marc.
>

---

From: Andrew Sciberras <[email-masked]>
Date: Wed, 1 Dec 2010 10:45:21 +1100

Hi Ciny

I have some observations... The only technical error in the ID is a
syntax/matching rule described immediately below. The rest of my
observations are simply my opinion, which I believe will facilitate
interoperability and remove ambiguity.

5.14.1 and 5.23.4.1
Each of these LDAP attribute definitions use a DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax and a caseIgnoreIA5Match
Equality matching rule. This is not a legal combination of syntax and
matching rule. A distinguishedNameMatch matching rule would be more
appropriate for the DistinguishedName syntax.

5.7 Categories
I think it may be ambiguous as to whether the category values are all
stored as a single attribute value (e.g. "Rooms,
EngineeringResources") or as separate values of the attribute (e.g.
"Rooms" and "EngineeringResources").

The name of the attribute (categories) implies that a given value
contains "categories" (i.e. more than one).
The example however (in section 6.1.1), illustrates that each category
is stored as a separate value of the multivalued categories attribute.

In RFC4519 you'll find test such as "Each address is one value of this
multi-valued attribute" to remove the ambiguity of how the values
should be stored.

5.12.2.1 InventoryList - As per 5.7.
In this case however the example in 6.2.1 shows the entire inventory
list being stored as a single commas separated value.
Since this is a multivalued attribute, is there a semantic difference
between values that are stored together within one attribute value
(comma separated) and those that are stored in another?
E.g.:
  inventorylist:phone, projector
  inventorylist:webcam, keyboard

Is the above permitted? If not, then the attribute should be single valued.
If so, then is there a semantic difference in the separation of the
items? i.e. would a value of "phone, projector, webcam, keyboard" be
equivalent?

5.9.2.1, 5.19.1, 5.20.1, 5.21.1, 5.22.1, 5.23.2.1, 5.24.2.2
In these LDAP attribute definitions it would be best if they were
defined to be SINGLE-VALUE.
E.g. 5.9.2.1 is a boolean attribuet called 'restricted'. As a
multivalued attribute, it would be possible for both the value TRUE
and FALSE to exist. It is likely that such an instance will cause
problems, which can be solved by making the attribute single valued.

Regards,
Andrew Sciberras.

On Tue, Nov 30, 2010 at 5:42 AM, Ciny Joy <[email-masked]> wrote:
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext
>