Upload
bethany-johnston
View
212
Download
0
Embed Size (px)
Citation preview
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #1
draft-levin-xcon-cccp-01.txt
By Orit Levin
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #2
Agenda• Working assumptions
• Syntax questions– From “Data Manipulation” to pure “Semantics”– Can the requests be expressed using the same types
as the resulted state?………..........……………………………………....…• CCCP scope
– Instance/Occurrence, Reservation. Also, Template?– Resulting Naming Conventions– Querying the conferencing information
• Transaction Model Details
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #3
Working Assumptions
• Must run over reliable transport, but transport agnostic
• “Controlling a conference” (i.e. creating and managing it) means “changing the state of the conference object”
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #4
Choosing a preferred syntax
From “Data Manipulation” to “Semantics Oriented”
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #5
Options
• What would be the best way to express the desired changes or the resulted next stage of the conference object?– A-la draft-levin-xcon-cccp-00.txt– A-la TBD simple-partial-notifications– A-la draft-levin-xcon-cccp-01.txt– RPC-like with explicit parameters
• Let’s take a look at the example:– “Add user BOB and DIAL OUT to its PC4 with Main
Audio only”
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #6
A-la draft-levin-xcon-cccp-00.txt
• Operation is included in the object schema• Included XML document needs to be parsed in
order to parse the required operation• Supposedly not limited to data manipulations
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #7
A-la draft-levin-xcon-cccp-00.txt (cont.)
<request requestId="1“ from="sip:[email protected]“<request requestId="1“ from="sip:[email protected]“ to="[email protected]"> to="[email protected]"> <content entity="sips:[email protected]"><content entity="sips:[email protected]"><users><users>
<user entity="sip:[email protected]"><user entity="sip:[email protected]"><display-text>Bob Hoskins</display-text><endpoint entity="sip:[email protected]">
<display-text>Bob's Laptop</display-text><joining-method>dialed-out</joining-method>
<media id="1"><display-text>main audio</display-text><proto>audio</proto>
</media></endpoint><operator><code>add</code></operator><operator><code>add</code></operator>
</user></user></users></users></content></content></request></request>
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #8
A-la deprecated draft-simple-tbd-02.txt
• Operation is explicit and is (supposedly) limited to “data manipulation” type
• Key is expressed in XPATH and MUST point to an existing XML document
• CDATA is used as a part of XML (which is not a valid XML schema construction)
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #9
A-la deprecated draft-simple-tbd-02.txt (cont.)
<request requestId="1“ from="sip:[email protected]“<request requestId="1“ from="sip:[email protected]“ to="[email protected]">to="[email protected]"> <add parent=“conference-state[@<add parent=“conference-state[@entity=&sips:[email protected]]"entity=&sips:[email protected]]">> <![CDATA[<![CDATA[ <user entity="sip:[email protected]"> <display-text>Bob Hoskins</display-text> <endpoint entity="sip:[email protected]"> <display-text>Bob's Laptop</display-text> <joining-method>dialed-out</joining-method>
<media id="1"> <display-text>main audio</display-text> <proto>audio</proto> </media> </endpoint> </user> ]]>]]> </add></add> </request></request>
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #10
A-la draft-levin-xcon-cccp-01.txt
• Operation is explicit and not limited to “data manipulations”
• Keys are “strong typed”
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #11
A-la draft-levin-xcon-cccp-01.txt (cont.)CONFERENCE KEYS TYPECONFERENCE KEYS TYPE
<xs:complexType name="conference-keys-type"><xs:complexType name="conference-keys-type"> <xs:attribute name="confEntity" type="xs:anyURI"/><xs:attribute name="confEntity" type="xs:anyURI"/> <xs:anyAttribute namespace="##other"/><xs:anyAttribute namespace="##other"/> </xs:complexType></xs:complexType>USER KEYS TYPEUSER KEYS TYPE
<xs:complexType name="user-keys-type"><xs:complexType name="user-keys-type"> <xs:attribute name="confEntity" type="xs:anyURI"/><xs:attribute name="confEntity" type="xs:anyURI"/> <xs:attribute name="userEntity" type="xs:anyURI"/><xs:attribute name="userEntity" type="xs:anyURI"/> <xs:anyAttribute namespace="##other"/><xs:anyAttribute namespace="##other"/> </xs:complexType></xs:complexType>ENDPOINT KEYS TYPEENDPOINT KEYS TYPE
<xs:complexType name="endpoint-keys-type"><xs:complexType name="endpoint-keys-type"> <xs:attribute name="confEntity" type="xs:anyURI"/><xs:attribute name="confEntity" type="xs:anyURI"/> <xs:attribute name="userEntity" type="xs:anyURI"/><xs:attribute name="userEntity" type="xs:anyURI"/> <xs:attribute name="endpointEntity" type="xs:anyURI"/><xs:attribute name="endpointEntity" type="xs:anyURI"/> <xs:anyAttribute namespace="##other"/><xs:anyAttribute namespace="##other"/> </xs:complexType></xs:complexType>MEDIA KEYS TYPEMEDIA KEYS TYPE
<xs:complexType name="media-keys-type"><xs:complexType name="media-keys-type"> <xs:attribute name="confEntity" type="xs:anyURI"/><xs:attribute name="confEntity" type="xs:anyURI"/> <xs:attribute name="userEntity" type="xs:anyURI"/><xs:attribute name="userEntity" type="xs:anyURI"/> <xs:attribute name="endpointEntity" type="xs:anyURI"/><xs:attribute name="endpointEntity" type="xs:anyURI"/> <xs:attribute name="mediaId" type="xs:string"/><xs:attribute name="mediaId" type="xs:string"/> <xs:anyAttribute namespace="##other"/><xs:anyAttribute namespace="##other"/> </xs:complexType></xs:complexType>
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #12
A-la draft-levin-xcon-cccp-01.txt (cont.)
<request requestId="1“ from="sip:[email protected]“<request requestId="1“ from="sip:[email protected]“ to="[email protected]">to="[email protected]"> <addUser><addUser> <conferenceKeys confEntity="sip:[email protected]"/><conferenceKeys confEntity="sip:[email protected]"/> <user entity="sip:[email protected]"> <display-text>Bob Hoskins</display-text> <endpoint entity="sip:[email protected]"> <display-text>Bob's Laptop</display-text> <joining-method>dialed-out</joining-method>
<media id="1"> <display-text>main audio</display-text> <proto>audio</proto> </media> </endpoint> </user> </addUser></addUser> </request></request>
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #13
Advantages of syntax as inCCCP-01
• Not a Data Manipulation protocol. Any explicit requests can be added and their semantics well-defined
• Strong type keys allow for automatic syntax validity check of a primitive
• No XPATH processing is required• Conference-info-type and its subtypes can be
used as is• Additional types (from multiple .xsd) can be used
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #14
Choosing a preferred syntax
Can the requests be expressed using the same types as the
resulted state?
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #15
Can the requests be expressed using the same types as the resulted state?• Advantages of using common types
– No double specification work– Adding primitives with new semantics and
keys is easy if needed– In implementation terms, minimum mapping is
required from the “request” to the “new state”
• Advantages of defining new types– More explicit, e.g. “dial-out” vs. “dialed-out”
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #16
CCCP Scope
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #17
CCCP Scope• Works on Instance/Occurrence and Reservation
– Also, on Template?
• Resulting Naming Conventions– URI parameters?– Primitive attributes?– Separate primitives?
• Querying of conferencing information– System: get the list of patterns, reservations, or
occurrences– Conference: get specific conference data elements
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #18
Transaction Model
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #19
Proposed Transaction Model
• CCCP is a transaction client-server protocol• Two types of operations: request and response• A client issues requests to a server. A server
MAY reply with multiple provisional responses before replying with the final response
• The server MUST reply with a single final response
• Two final responses are defined: "failure" and "success"
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #20
Proposed Transaction Model (Cont.)
• Transaction ID– requestId: A string generated by the CCCP client and
unique for each CCCP request generated by the client
– from: A URI which identifies the CCCP client– to: A URI which identifies the CCCP server
• Each operation MAY include an 'aaId' attribute– holds a secured identity of the issuer of the CCCP
request– Its value is being used by the CCCP server for
authorization purposes
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #21
Proposed Transaction Model (Cont.)
• A single CCCP operation MAY include multiple primitives
• Multiple primitives within the same request MUST be executed as an atomic operation.
• The primitives within the request operation MUST be performed by the CCCP server one-by-one in the order they appear in the request body.
• The corresponding response operation MUST include the response primitive for each of the issued primitives in the exact same order. Note, that for this reason, the primitives inside the operation bodies are not numbered.
Boston, Jan 5 – 6, 2005 XCON WG Interim Slide #22
Thanks…