------- start of forwarded message ------- From: Seth Proctor <
seth.proctor@sun.com> To:
anne.anderson@sun.com Subject: 18c comments Date: Wed, 16 Oct 2002 11:10:16 -0400 Ok. Here is what I came up with (there's probably other smaller stuff too, but I was focusing more on the big picture). I suspect you've already caught a lot of these, but just in case... By Section: - 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is computed before arriving at the PDP. I know you're working on new language, so that may just not have been added yet. - In section 5, when the <Function> tag is explained in Apply, it should have a pointer to the higher-order bag section so people understand what it's there for - 10.3.6 (Identifiers) doesn't list the type of any these attributes, nor does it give the required uses for them that it says implementors must follow. I realize this is transparent to a lot of the code, and only one of these is required to support, but it would still be helpful to know what type they're supposed to be (if there is a certain expected type). Later in the spec they're explained in a little more detail, but not enough to make the strong language in this section about correct implemention make sense. - A.6 (Element <AttributeValue>) says that an AttributeValue's type is implied by the function using it, but that's changed now to state the type explicitly (same for next 2 sections)...actually, this change is missing in most of the section A examples. - A.11 (Matching elements) says that the AD/AS used in a Target match must return a bag, and then has some other language that borders on describing an API. This is the section we talked about. I think it should be made clear that if a function expects a single String (eg), then getting a bag is an error. Also, this section (and the section later describing bags) should clarify that _any_ type is allowed in a bag, not just those defined as base types in the spec. If you'd like, I can work on alternate language. - B.9 (Status codes) is still missing some of the codes that we discussed (like problems choosing the root policy). Maybe a few more could be added. Maybe I should writeup a few other codes, and include some proposal for the format of the values to accompany various Status codes? - D (Acknowledgments) ... this is a small issue, but since the list of voting memebers is basically also the contributer list, shouldn't this section name people who weren't on the TC but helped shape the standard? This is the way other specs look. General: - Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of just AD? Before it made sense, since all ADs were the same, but I would think that since there's now a special AD for Subjects, that's what you would want to extend. - There is still no discussion anywhere about treating the Request as a notional doc and going outside the PDP to get attribute values. The same text is still throughout the spec suggesting just the opposite, and the picture at the beginning looks the same. I know you're thinking about how to change this, but if this is really supposed to be supported, then the spec _must_ change dramatically to make this clear. One or two paragraphs added somewhere will not cut it. - Related to that, there needs to be some clear examples of how to use an AD/AS to make this happen. I don't think that AS's should be used for this functionality (just because it's too hard to support), but that's a separate issue. - There should probably be some language added to discuss how Policy[Set] Ids should be treated. At the very least, and example or some hints about typical use would make things better, since right now this is entirely up to the implementor, and as such is guarenteed to be a point where interoperability of policies fails. - There is still no text about how to do resolution in an Apply, and how this can be short-circuited, etc. Are you working on this change? The current spec doesn't make it clear that you should be able to do this, so I think this needs to be added in clear examples & specification, otherwise not all implementors will get this right. seth ------- end of forwarded message ------- -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692