[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] New Version for draft-cal-resource-schema-03

To: Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Subject: Re: [ldapext] New Version for draft-cal-resource-schema-03
From: Ciny Joy <ciny.joy@oracle.com>
Date: Wed, 1 Dec 2010 14:56:04 -0800
Cc: ldapext@ietf.org, directory@ietf.org, CardDAV <VCARDDAV@ietf.org>
Delivered-to: ldapext@core3.amsl.com
In-reply-to: <AANLkTimSF4jn4g669vRAFnp9ksJz4WtLK1neG9dBHGZB@mail.gmail.com>
References: <20101129173512.825FF28C18A@core3.amsl.com> <4305745B-B6D5-4DBA-B5AC-B48E05A586C3@oracle.com> <AANLkTimSF4jn4g669vRAFnp9ksJz4WtLK1neG9dBHGZB@mail.gmail.com>

Hi Andrew,
   Thanks a lot for your corrections and comments. I agree that all the ones you mention need to be corrected. I will discuss them with my co-authors and submit a new draft with the corrections.

Thanks again,
Ciny

On Nov 30, 2010, at 3:45 PM, Andrew Sciberras wrote:

> 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 <ciny.joy@oracle.com> wrote:
>> 
>> 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 <idsubmission@ietf.org>
>> Date: November 29, 2010 9:35:12 AM PST
>> To: ciny.joy@oracle.com
>> Cc: cyrus@daboo.name, douglm@rpi.edu
>> 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.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www.ietf.org/mailman/listinfo/ldapext
>> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

Index(es):
- Chronological
- Thread