OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: IPC WD-07 feedback


In response to your comments:


1.)    I will fix typo.

2.)    I'm not sure what’s being requested here. Can I get some clarification or was this just a comment for discussion?

3.)    Since the DataType of this attribute is http://www.w3.org/2001/XMLSchema#date the ISO 8601 Date and Time Formats format allows granularity down to the second. I believe we’re ok here.

4.)    I will add your text suggestion to the description of the Encrypt Obligation.



If there are no other comments by the end of the week I will update the IPC with 1 & 4 above and upload by early next week.




Richard C. Hill

The Boeing Company
Information Security
(206) 856-6654


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Danny Thorpe
Sent: Monday, January 16, 2012 3:55 PM
To: xacml@lists.oasis-open.org
Subject: [xacml] IPC WD-07 feedback



1.       Typo on line 192: “fo” -> “of”


2.       In Sections 2.1.10 Effective-Date and 2.1.11 Expiration-Date it’s unclear whether the given date values are inclusive or exclusive to the agreement or resource lifetime. 

For example, is the Expiration-Date value the last date that the agreement/resource is valid (current-date <= expiration-date), or the first date that the agreement/resource is invalid (current-date < expiration-date)?  The last sentence of 2.1.11 (“This attribute may also convey the date on which other resource attribute elements are no longer valid; for example, when a copyright or patent expires”) suggests to me an exclusive endpoint (< test).

The non-normative copyright example in section 4 treats the effective and expiration dates as inclusive bounds (effective <= current <= expiration).


3.       As Date types, Effective-Date and Expiration-Date cannot represent agreements or resources that have a valid lifetime less than one full day, or that start or end at specific times of day.  Example: license to (re)broadcast protected content at a public event only during a specific 2 hour window of time.

I realize that traditional business contracts are phrased in terms of whole dates, not hour and minutes, but in the emerging world of on-demand content / media streaming, being able to specify a license’s effective period with a granularity of minutes or portion of a day may be increasingly useful.

(A hacky way around full-day granularity might be to leverage the optional time zone portion of the XMLSchema date type to approximate a time of day as the beginning of the day in a particular time zone, but this is really ugly)


4.       Section 2.3.1 Encrypt doesn’t state what the PEP is required to do when it receives an Encrypt obligation. 

Text suggestion, modeled after 2.3.2 Marking:  “The encrypt obligation can be used to command PEPs to encrypt the resource.”





Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]