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

 

 

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]