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
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.
-----------------------------------------------------------------
Securing Digital
Identities
& Information