Updated spec issues.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Thanks to Ron Jacobsen and to Darran, we've closed several spec issues 
(below).
An updated list of open issues is attached (if inline, look after my 
signature).

|3.4.1.2.1. Do we need to give a reason why cancel must be synchronous?
|20050215 - Ron Jacobsen says 'no'.
|20050215 - Explained in the non-normative section
|           that introduces the Async Capability
|           why the cancel operation must be synchronous.
|
|3.4.2.2.1. Do we need to give a reason why status must be synchronous?
|20050215 - Ron Jacobsen says 'no'.
|20050215 - Explained in the non-normative section
|           that introduces the Async Capability
|           why the status operation must be synchronous.

|3.4.7.2.1. Do we need to give a reason why iterate must be synchronous?
|20050215 - Ron Jacobsen says 'no'.
|20050215 - Explained in the non-normative section
|           that introduces the Search Capability
|           why the iterate operation must be synchronous.

|3.4.8.1.2. May 'suspend' return an error when the object is already 
suspended? I think not.
|20050215 - Darran agrees that this should be treated as success.
|20050215 - Specified that neither suspend nor resume should return an 
error
|                 when the object is already in the desired state. 
|                 Explained (in the non-normative section that 
introduces the Suspend Capability)
|                 that the suspend and resume operations are idempotent.
|
|3.4.8.2.2. May 'resume' return an error when the object is already 
resumed? I think not.
|20050215 - Darran agrees that this should be treated as success.
|20050215 - Specified that neither suspend nor resume should return an 
error
|                 when the object is already in the desired state. 
|                 Explained (in the non-normative section that 
introduces the Suspend Capability)
|                 that the suspend and resume operations are idempotent.

|Appendix K: Do we need new OASIS notices?  From where?
|20050215 - Darran Rolls supplied these.  Gary Cole updated spec draft.
|

gpc


1.1. Rami will send more on "Purpose of SPML" itself.

1.3. Rami will provide a draft of “Changes from SPML 1.0”.

2.1. Darran will send UML diagram(s) to replace ERD.
20050215 - Darran Rolls has taken this action item (originally Gerry's).

2.1.3. Rami will draft content that further defines the term "capability". 
	   Same intent as extended operations in SPML1.0.

3.1.1. This implies that a multi-threaded provider must queue requests (by requestor). 
       Can we simply require requestID in RequestType?
20041208 - Jeff Larson said 'no'.  Imposes unnecessary burden on simple requestor. 

3.3. Use the correct terms for the long form and short-form of XPATH expressions.

3.3.1A. What is the 'namespaceURI' value for an XPath expression?

3.3.1B. What is the 'namespaceURI' value for a SPML1.0 (DSMLv2) attribute expression?

3.4.1.1.2. (See #51 in draft_13_xsd_issues.txt.)

3.4.1.2.2. (See #40 in draft_13_xsd_issues.txt.)

3.4.1.4.1. What does an instance of SelectionType <component> contain in the DSML Schema binding?
              For ‘modify’, <data> contains a DSML attributeModifier elements.

3.4.1.4.2. TO-DO: Discuss ErrorCode in Protocol general features.

3.4.1.4.3A. TO-DO: Since a modifyRequest can change the PSO-ID, 
              we should probably mention this, and show an example of 
              a modificationResponse returning the new PSO-ID.

3.4.1.4.3B. TO-DO: Show examples of adding and replacing a reference.
	  Should we show examples of modifying references where the cardinality assumptions differ?
	  Can one specify cardinality for a specific type of reference?
	 ** PENDING Reference Capability meta-data issues. **

3.4.1.5.2A. (See #55 in draft_13_xsd_issues.txt.)

3.4.1.5.2B. TO-DO: Discuss StatusCode in Protocol general features.

3.4.2.2.2. TO-DO: Link to discussion of RequestID.

3.4.3.1. TO-DO: Document as a general feature that we punt on logical unit of work--no UNDO.

3.4.4.1.3. A requestor can query for Person instances based on “owner” 
              only if the provider defines “owner” as an element or attribute of Person 
              in the schema for the target.  In such a case, what would the value of “owner” look like? 
              Would “owner=’joebob’ work?

3.4.4.1.3B. (Same as 3.4.1.4.3B above:  ** PENDING Reference Capability meta-data issues. **)

3.4.4.2.3. (Same as 3.4.3.1.3 above.)  

3.4.5.  Which password operations should be batchable?
20050215 - Darran says 'all'. validatePassword is the only questionable one
           but no real reason to stop it just there... 

3.4.5.4. (See #62 in draft_13_xsd_issues.txt.)

3.4.6. Reference Capability issues.  ** PENDING Reference Capability meta-data issues. **

3.4.7.1. Neither search nor iterate is batchable (for reasons of scale).
            (Combine with 3.4.5: Which operations of every capability are batchable?)

3.4.7.1.3. (Same as 3.4.4.1.3 above.)


3.4.7.2.2. A provider that changes the ID in an iterator each time can detect this.


5. Do we need to update "Security and privacy considerations"?
20050215 - Darran says that we should update this.  Wants a volunteer.

Appendix I (throughout): Document references need validation and update.

Appendix L: Glossary.  Definitions need review and update.

Appendix M: Requirements. TO-DO: Replace this section with SPML 2.0 requirements.