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

I'll add the DSML namespace as suggested and text around the
filter/attributes question as described by Jeff.


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 
	Subject: RE: [provision] - Comments on
	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



		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


		Hi Darran, some comments against


		0)       editorial - bunch of 'SMPL' references

		Editorial error. Fixed


		1) Section - 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

		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 Madsen

		e:  p.madsen@entrust.com <mailto:p.madsen@entrust.com> 

		p:  613-270-2632


		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]