[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] - Comments on draft-pstc-spml-core-07.doc
I'll add the DSML namespace as suggested and text around the filter/attributes question as described by Jeff. Thanks. ========================================================= Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com 512) 657 8360 ========================================================= -----Original Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: Thursday, April 17, 2003 8:44 AM To: Paul Madsen; Darran Rolls; provision@lists.oasis-open.org Subject: RE: [provision] - Comments on draft-pstc-spml-core-07.doc Some additional comments: 1) If memory serves me right, the reason the the term "Requesting Authority" was used was because typically the web service client was not the person that the provisioning request is being made for, but rather an "Authority" that is making the request on that person's behalf. Having said all that, "Requestor" is more intuitive and not burdened with implied meaning. 3) I agree with Paul that it is better to preserve the DSML namespace in the XML samples. 5) A better way to describe this is: "A search request allows specifying the search criteria (filter) and the attributes to be returned." Note you can not specify what values can be returned. If no attriubtes are specified on the search request, all attributes should be returned. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Paul Madsen [mailto:p.madsen@entrust.com] Sent: Thu 4/17/2003 8:07 AM To: 'Darran Rolls'; provision@lists.oasis-open.org Cc: Subject: RE: [provision] - Comments on draft-pstc-spml-core-07.doc hi Darren, comments/answers inline -----Original Message----- From: Darran Rolls [mailto:Darran.Rolls@waveset.com] Sent: Tuesday, April 15, 2003 8:30 PM To: Paul Madsen; provision@lists.oasis-open.org Subject: RE: [provision] - Comments on draft-pstc-spml-core-07.doc Paul Thanks. Good catches. I have some return questions in line (below). Editorial changes will be included in this weeks draft. ========================================================= Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com 512) 657 8360 ========================================================= -----Original Message----- From: Paul Madsen [mailto:p.madsen@entrust.com] Sent: Monday, April 14, 2003 2:26 PM To: provision@lists.oasis-open.org; Darran Rolls Subject: [provision] - Comments on draft-pstc-spml-core-07.doc Hi Darran, some comments against draft-pstc-spml-core-07.doc 0) editorial - bunch of 'SMPL' references Editorial error. Fixed 1) Section 5.1.1.17 - I question use of 'authority' in the name 'Requesting Authority'. Over what is this entity authoritative? While I see that in some cases the request will carry user attributes for which the client is (in some sense) asserting to be 'true', I suggest that the term authority has connotations that don't intuitively combine with 'requestor' Interesting point: I have interpreted the authority to be referring to the requestor being somehow (out of scope) authorized to make the request... [Paul Madsen] but presumably all requests from a particular RA will not be authorized, consequently it would be only a 'partial' authority. I have not come across this interpretation in the context of any request/response protocol. 1) Line 229 - the statement 'when System Two implemented its service at Resource E, it DID NOT use an SPML protocol message' gives the impression that SPML cannot be applied here, rather than merely that System 2 is not forced to use SPML for communicating with Resource E once it used SPML to communicate with System One. Softened this statement. 2) Line 348 - use of 'service requestor' should be replaced with RA for consistency Editorial error. Fixed 3) Line 431 - suggest adding DSML namespace prefix to appropriate elements To reduce complexity should we omitted this in the code samples. Is this what you mean? [Paul Madsen] I'd suggest that the cost of extra complexity is exceeded by the clarity of distinguishing the different namespaces, especially so for spml and dsml as doing so makes it clear what we have done on top of DSML. 5) Section 7.3.4 - SPML Search Operations - After explicitly calling out the symmetry of the filtering (e. g that filters can be applied to both the search criteria and to the returned attributes), the schema treats these differently. Why? Is it the filtering model in question (i.e. the use of filter and attributes) or the example? [Paul Madsen] Not the model, merely its markup representation, ie. we call both operations 'filters, but only explcitly reflect this as an XML tag for the search critera, it is implicit for the search results. Additionally, do we need to provide a processing rule to indicate what the SPML server should do if no filtering attributes are listed in the request. I believe the behavior is that is the client asks for no "attribute" filtering in the returned data set they get every attribute. 6) Line 486 - the searchResponse example lists the returned attributes in the opposite order as to which they were specified in the request, e.g . 'cn' & 'email' We should clarify what, if anything, is meant by the order of listing. Good catch, editor error. I have made an explicit statement in the spec that ordering must be maintained. 7) line 541 - the example extendedRequest incorrectly shows an operationIDType on the spml:identifier element rather than the spml:operationIdentifier Editorial error. Fixed Additionally, the example of extended request demonstrates a mail server purge. Perhaps we should mention that this operation could (I believe) have been performed by a delete request with appropriate operationalAttributes? iis this a general phenomena? Alternatively (and preferably in my opinion), could we not come up with an example that couldn't be similarly broken down (although I can't come up with one) Duly noted for now. I'll see if we can come up with a better example. 8) Line 623 - the schema snippet conflicts with that of Line 741. Editorial error. Fixed paul ----------------------------------------------------------------- Paul Madsen e: p.madsen@entrust.com <mailto:p.madsen@entrust.com> p: 613-270-2632 Entrust Securing Digital Identities & Information http://www.entrust.com <http://www.entrust.com/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]