RE: [provision] - Comments on draft-pstc-spml-core-07.doc

hi 
Darren, comments/answers inline

  
-----Original Message-----
From: Darran Rolls 
  [mailto:]
Sent: Tuesday, April 15, 2003 8:30 
  PM
To: Paul Madsen; 
  
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           
  

  
512) 657 
  8360                     
  

  
=========================================================

  
 

  
-----Original 
  Message-----
From: 
  Paul Madsen 
  [mailto:] 
Sent: Monday, April 14, 2003 2:26 
  PM
To: ; 
  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:  
  613-270-2632

  

  
Entrust

  

  
Securing Digital 
  Identities 
& Information

  

  
http://www.entrust.com