OASIS Provisioning Services
Technical Committee (PSTC)
F2F #4 Meeting Minutes
Logistics
|
Meeting Date |
02/11-12/2003 |
|
Meeting Time |
9 – 5 p.m. |
|
Location |
Houston, Texas hosted by BMC |
|
Duration |
2 days |
|
Chair |
Darran Rolls |
|
Recording Secretary |
Gavenraj Sodhi |
|
Agenda |
As published as of February 12, 2003 |
Roll-call
Present
|
(JB) |
Jeff
Bohren, OpenNetwork Technologies |
|
(GS) |
Gavenraj
Sodhi, Business Layers |
|
(MP) |
Mike
Polan, IBM |
|
(RE) |
Rami Elron,
BMC |
|
(DC) |
Doron Cohen,
BMC |
|
(DR) |
Darran
Rolls, Waveset |
|
(ML) |
Matthias
Leibmann, Microsoft |
|
(YK) |
Yoav Kirsch,
Business Layers |
Minutes
We have reached quorum.
Requests
- Document to describe how XML is assembled.
- Separate documents doc as suggested by Doron
Minutes from January 20th meeting – Approved
Minutes from February 3rd meeting – Will be kept as working group minutes
Burton Group Catalyst discussion
- Mixed RA/PSP/PST elements with protocol flows that result in provisioned accounts that attendees then use to access fake services
o Discussion of level of effort required to make demonstration
o Get basic scenarios outline before end of F2F so each company can get commitment on attendance.
o Pre inter-op in mid-June
We need to have a motion on current draft of schema if it looks right or not…
- Now has SAML subject assertion in version 5 of core schema
- OID
- SPML attributes – can put operation type attributes
- Deleting a flag on a delete – Best example to come up with (Account, SLA, …)
- Attributes added to spmlADD
o ObjectClass
o EmailNotification
- Motion: Introduce a new container element to contain object attributes to be separate from request attributes (Enveloping a container for current object attributes, called “attributes” for object attributes. Also change the name of “requestAttr” to “operationalAttributes.” Also change “responseAttr” to “operationalAttributes.” Also add “attributes” container for response.
o So it may look as a bag of attributes within a browser
o Attributes of an object class where a bunch of object attributes and request attributes are separate from each other
o Nobody against – Accepted
RA
oc=partner
PST
oc=user
Motion: Add enveloping to a container for current object modifications, called “modification.” Also add “modifications” container for response.
o Nobody against – Accepted
- Core Operations should be complete except for Extended Request.
- Review of Extended Request proposal
- Schema to define what supported extended request are. If they are not implemented, we may run into interoperability issues.
- Extended request has a working example of “Run Report”
Motion: Accept schema for Extended Requests as it is and roll it into core operations
o
Proposal will be added to meeting minutes as
(draft_pstc_schema_extended_proposal_02.xsd)
o Nobody against – Accepted
- “Operationalattributes” will be known as “batch attributes”
Motion: To remove Response Return Type specification on a cancel request
o Nobody against – Accepted
o Add result status to batch response
- Doron: Should be able to say something more about attributes
o Can use attribute value pairs to describe attributes
- Yoav: Who is responsible for type checking?
o May want to query the system for schema but not forcing type checking.
1.0 – Query schema
- Need basic query
2.0 – Defined schemas
- UDDI / WS ( ) possible
Path 1
====
PSTC defined schema query
- attribute properties
- In schema definition, make it relevant to a specific provider
o Have a provide ID and operation ID
Motion: Unified provider identifier references across extended request and query schema and we modify both schemas to represent that.
o
Nobody against – Accepted
Need best practice to make URN or others would have to live with it. Should we namespace it?
Service A.name Service B.name
Name Name
Age Age
…. ….
Extended request and response maybe should support versioning on the object class.
- e.g., on the Server
Scenario Discussion
= A* Profile à Catalyst
================
- A * - Collect “One Sheet” ß outline of SPML, outlines Interop, tells them what to do
- A * - Goes to any available vendor station
- Talk about SPML
-
Company Name
Show me how it works…
-
- Need to understand both the North American and European Markets
- Common RA
- Fill in Basic details
- Create requests on every PSP
- Create request details
- One of which is the common PST
Day 2
*** Notes originally take earlier by Darran upto 10:30 a.m.
Example 1 – end – 2 – end
- schema
- schema for PSP service your mail
- 1. RA issues a Use Case 2 (UC2) addRequest to PSP
-
UC9
UC2
addRequest
-
Schema
email address
PSD-ID “DN”
Motion: Mandatory for PST to implement SPML search request operation.
6-2 vote against.
Notes taken by Darran
Rolls
·
Motion to accept query schema as
discussed in the F2F and reflected in JB’s 03 draft and roll into core
operations schema second JB passed.
·
Action item for JB to
specify status’s on responses
·
DR to open a
discussion on the nature of the flows between RA-PSP PSP-PST for an end-to-end
transaction. Example: RA asks PSP for a service, PSP subsequently
asks PST. Does the PSP directly return the response to the RA or wait on
the PST response then do so. Probably need to add text to specification to
outline what different models are possible and recommendations for their
use.
·
Need to consider a
possible v1.1 core operation that lists what operations a given actor
supports.
· Individual motions passed to vote accept the conformance matrix in the (soon to be published) 04 specification.
Summary of Motions
Motion:
Introduce a new container element to contain object attributes to be
separate from request attributes (Enveloping a container for current object
attributes, called “attributes” for object attributes. Also change the name of “requestAttr” to
“operationalAttributes.” Also
change “responseAttr” to “operationalAttributes.” Also add “attributes” container for
response. - ACCEPTED
Motion:
Add enveloping to a container for current object modifications, called
“modification.” Also add
“modifications” container for response. – ACCEPTED
Motion: Accept schema for Extended Requests as it is and roll it into core operations - ACCEPTED
o
Proposal will be added to meeting minutes as
(draft_pstc_schema_extended_proposal_02.xsd)
Motion: To remove Response Return Type specification on a cancel request - ACCEPTED
Motion: Unified provider identifier references across extended request and query schema and we modify both schemas to represent that. – ACCEPTED
Motion:
Mandatory for PST to implement SPML search request operation. – NOT ACCEPTED (6-2 Against)
Motion:
Motion to accept query
schema as discussed in the F2F and reflected in JB’s 03 draft and roll into core
operations schema - ACCEPTED
Motion:
Accept the conformance
matrix in the (soon to be published) 04 specification. - ACCEPTED