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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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


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

p:  613-270-2632

Entrust

Securing Digital Identities
& Information

 

 



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