1 / 68

XCAP Tutorial

XCAP Tutorial. Jonathan Rosenberg. Ground Rules. This is a session for level setting People are at different points We will start from the beginning NO QUESTION IS TOO STUPID Disrespect will not be tolerated Please interrupt and ask PLEASE!. Understanding XML Basic XML Concepts

merle
Download Presentation

XCAP Tutorial

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XCAP Tutorial Jonathan Rosenberg

  2. Ground Rules • This is a session for level setting • People are at different points • We will start from the beginning • NO QUESTION IS TOO STUPID • Disrespect will not be tolerated • Please interrupt and ask • PLEASE!

  3. Understanding XML Basic XML Concepts Namespaces Schema XPath in Brief HTTP Concepts of Note Etags XCAP Problem Definition XCAP Basics Agenda

  4. XML is a mechanism for representing structured data Data is represented by a tree Each node in the tree is an element Elements have attributes Attributes qualify the data “Leaf” Elements can contain text content XML Basics <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book>

  5. XML Comments Elements can be empty <el-name/> shorthand XML Declaration Version Encoding IETF uses UTF-8 XML Basics <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book>

  6. XML Terms • Well-formed • Meets basic constraints for all XML documents • Each open tag has a matching close • Unique attribute names • Valid • Meets the constraints defined by a schema or DTD

  7. Problem Want to combine content from different systems into one document What if both sources define the same name? Example Add information to address book on whether data is synced with PC <state>synchronized</state> Which state is it? XML Namespaces <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book>

  8. Solution: XML Namespace Elements and attributes are bound to a namespace when defined Namespace is identified with a unique URI A prefix is bound to that URI through a declaration in the document Each element is named with its qualified name The prefix, followed by a colon, followed by the local-name XML Namespaces <?xml version="1.0" encoding="UTF-8"? xmlns:post=“http://www.post.com” xmlns:sync=“http://www.sync.com”> <post:address-book> <!—This guy is a bozo -- <post:entry> <post:name>Jonathan Rosenberg</post:name> <post:email>jdrosen@dynamicsoft.com</post:email> <post:postal> <post:street paved=“true”>600 Lanidex Pl</post:street> <post:city>Parsippany</post:city> <post:state>NJ</post:state> <post:country>USA</post:country> </post:postal> <post:ietf-participant/> <sync:state>synchronized</sync:state> </entry> </address-book>

  9. Importance of Namespaces • Namespaces are like option tags in SIP • Group a bunch of things together and give it a name • Are useful for talking about extensibility • Are useful for negotiating extensibility • Provide a generic grouping facility

  10. XML Schema • Need a way to define the constraints on an XML document • Analagous to a database schema • Similar to a grammar • W3C has specified two ways • DTD • Original method • Not an XML document • Limited expressiveness • Schema • Newer • XML-based • Much more expressive • Much more complex • Works well with namespaces • Trend is towards schema

  11. Schema Example <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://www.post.com" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.post.com" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="address-book"> <xs:complexType> <xs:sequence> <xs:element name="entry" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="email" type="xs:string"/> <xs:element name="postal"> <xs:complexType> <xs:sequence> <xs:element name="street" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="state"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="NJ"/> <xs:enumeration value="NY"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="country" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="ietf-participant"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

  12. XPath • XCAP selection is based on XPath • Happens to be a subset • Not a normative usage • XPath problem statement • How to point to specific pieces of an XML document • Example: “The third element named entry” • Example: “All of the elements in a document that have the attribute paved equal to true.” • XPath = XML Addressing

  13. Want to point to the email element XPath expressionaddress-book/entry/email Just like a unix filesystem path Each “directory” identifies an element name Basic Example <?xml version="1.0" encoding="UTF-8"? xmlns:post=“http://www.post.com” xmlns:sync=http://www.sync.com xmlns=“http://www.post.com”> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan R<name> <email>jr@dsoft.com</email> <postal> <street paved=“true”>600 Lx Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> <sync:state>synchronized</sync:state> </entry> </address-book>

  14. What if there are multiple elements with that name? Can supply predicates which select one of the matching ones Predicates appear in square brackets One such predicate is position Indicates which one by its place in the ordered sequence of matching elements Select second bar:foo/bar[2] Select first bar:foo/bar[1] Positional Selectors <foo> <bar>Hello</bar> <bar>There</bar> </foo>

  15. You can select elements that have attributes with specific valueselement[@name=“value”] foo/bar[@attr=“1”] foo/bar[@attr=“2”] foo/bar[@stuff=“LOTR”] Select by Attribute Name <foo> <bar attr=“1”>Hi</bar> <bar attr=“2”>How</bar> <bar stuff=“LOTR”>Are</bar> </foo>

  16. The result of selecting an element includes The element Its children Its attributes Everything between open bracket of open element to close bracket of close element XPath allows selecting multiple elements XCAP does not use this feature Selecting Elements

  17. An attribute is selected by prefixing its name with an “@” foo/bar[1]/@attr foo/bar[@attr=“2”]/@bool foo/movie/@stuff The selected object is JUST the value Different from elements Name would be redundant Selecting Attributes <foo> <bar attr=“1”>Hi</bar> <bar attr=“2” bool=“y”>How</bar> <movie stuff=“LOTR”>Are</bar> </foo>

  18. XCAP Problem Space • Motivating use cases • Buddy Lists • Authorization Policies • Hard state presence data

  19. Client wants to subscribe to a list of users Send SUBSCRIBE to server using SIP event list extension Server retrieves list associated with buddylist URI Generates SUBSCRIBEs to them Client can manage that list Add, remove, modify entries Buddy List Use Case Subscribe List Subscribe Joe Subscribe Bob Subscribe Mary Read List Write List Data Manipulation Server Standard Ifaces Client

  20. User Hiroshi subscribes to Petri No auth policy in place, generates a winfo NOTIFY to Petri Petri needs to be able to set authorization decision for Hiroshi Want to be able to set such policies outside of a subscription as well Authorization Use Case Subscribe Petri Read List Write List Data Manipulation Server winfo Standard Ifaces Client

  21. Hiroshi subscribes to Petri Petri has been offline for weeks Server sends NOTIFY with current presence state Petri wants to control default state when offline Set it to <activity>vacation</activity> Hard State Presence Management Subscribe Petri Notify Read PIDF Write PIDF Data Manipulation Server Standard Ifaces Client

  22. Functional Requirements • Create resource list/auth policies/default presence doc • Associate resource list/auth policies/default presence doc with URI • Have client define URI • Have server assign URI • Modify contents of resource list/auth policies/default presence doc • Extend resource list/auth policies/default presence doc in hierarchical way • Delete a piece of resource list/auth policies/default presence doc • Fetch currentresource list/auth policies/default presence doc • Allow multiple clients to access and modify a sharedresource list/auth policies/default presence doc

  23. Performance Requirements • Protocol will be used on wireless air interfaces • Means that it is • unacceptable to push the entire resource list/auth policies/default presence doc when a change is needed • Unacceptable to get the entire resource list/auth policies/default presence doc when the client needs to look at it • Implies local cache • Pushing and pulling partial pieces of the data is essential • Invalidation of cached data • Synchronization of data

  24. Key Observations • Clearly a general problem here • Allowing a user to managed provisioned data that is accessed by a network application • Apply some basic design principles • Separate protocol machinery from data schema • Don’t box yourself into a corner with the data schema • Bandwidth efficiency important • Lower the deployment bar • This is a well-trod space • LDAP, ACAP, SNMP, relational DB cover related spaces, none successfully deployed to broad end client bases

  25. Same as previous pictures Scope limited to client to XCAP server Access from Network App could be XCAP Acts as a client There may be no network app XCAP server is repository for client data XCAP Architecture Network App Not Standardized Not Standardized XCAP Server XCAP Client

  26. The Big “Aha” • XCAP is about clients getting, deleting and putting pieces of hierarchically organized data • Ideally XCAP should leverage technologies widely found in phones, PCs and other client devices • XCAP can just BE HTTP, by defining the URI hierarchy to extend into “web documents” • HTTP URIs can represent any resource • Don’t need to exist on a disk • Interpretation is up to the server • XCAP defines that interpretation

  27. HTTP in Brief • Clients invoke methods on server • GET – retrieve content • PUT – place content • POST – pass data to a process • HEAD – get meta-data, not content • OPTIONS – query server for capabilities • DELETE – remove a resource from a server • Requests and responses contain bodies

  28. Fetch a document GET http://server.com/dir/foo HTTP/1.1 <foo> <bar attr=“1”>Hi</bar> <bar attr=“2” bool=“y”>How</bar> <movie stuff=“LOTR”>Are</bar> </foo> HTTP/1.1 200 OK Content-Type: application/xml Content-Length: … <foo> <bar attr=“1”>Hi</bar> <bar attr=“2” bool=“y”>How</bar> <movie stuff=“LOTR”>Are</bar> </foo>

  29. XCAP Scope • Application Usages • Details how you use XCAP for a new app (i.e., CPCP) • Server assigned data • Naming convention for URIs • Document selector – picks the “XML Document” based on a defined document hierarchy • Component selector – picks an element or attribute within the document • Using GET, PUT and DELETE for management of elements and attributes • Error content • Extensibility of data • Etag advice

  30. Application Usage • Defines what an application needs to do to be used with XCAP • Define an Application Unique ID • Define the XML Schema for the data • Define data semantics • Specify naming conventions – binding between application and XCAP • Data interdependencies (aka server computed data) • Authorization policies

  31. AUID • Unique Identifier for each application • Two sub-namespaces • IETF tree: tokens in RFC documents • IANA Registry • Vendor tree: proprietary data • Start with reverse DNS name of enterprise • Examples • IETF Tree • “resource-lists” draft-ietf-simple-xcap-list-usage • “pidf-manipulation” draft-isomaki-simple-xcap-pidf-manipulation-usage-00 • “rules” draft-rosenberg-simple-rules • Vendor Tree • “com.example.customer-list”

  32. AUID Grammar AUID = global-auid / vendor-auid global-auid = auid auid = alphanum / mark vendor-auid = rev-hostname "." auid rev-hostname = toplabel *( "." domainlabel ) domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

  33. Naming Conventions • An app will have “hooks” into XCAP • Points of operation of application when XCAP is used • Need to define how that is done • Example: Presence List • Fetch document whose uri attribute of <resource-list> is equal to request URI of SUBSCRIBE • Example: Authorization • Fetch authorization policy documents underneath http://server.com/rules/users/<username> where username identifies the presentity

  34. Data Interdependencies • In many cases a user defines all of their own data • PIDF manipulation usage • Authorization policies • In some cases a few pieces of it are “filled in” by the server • Resource list URIs for lists – need to be unique, can be server assigned • Client can also define them • Application usage specifies what pieces server fills in, and how

  35. Handset Application XCAP Server Database Think of the application usage as a client of XCAP Handset puts a new resource list, URI not present (1) Application learns of change (4) Acting as a client, application modifies data, setting URI (5) This is a model, not an implementation requirement Impacts Etag usage (later) (1) PUT Resource List (2) 200 OK (3) store (4) Data Change (5) PUT (set URI) (6) 200 OK (7) store Modeling Server Computed Data

  36. Authorization Policies • Who is allowed to access (R/W) XCAP data? • Application specific • Policies are specified by application usage • XCAP defines a “default” • A user can read and write their own data • A user can only access their own data • Global data is readable by everyone, writeable by no one except privileged users

  37. Definition Example • Basic address book from before • Would author an RFC structured as follows

  38. AUID Want this to be global Pick an appropriate AUID address-book Add an IANA Considerations section registering the AUID XML Schema Include it IANA registry for schema and namespace Naming Conventions No server app No naming conventions No data interdependencies Default authorization policy Document Contents

  39. Semantics • An address book is a series of <entry> elements • Each <entry> is information about an entry in the address book • It has a <name>, which is the use persons first and last name • It has an <email> element, which contains the email address of the person • It has a <postal> element that has the postal address

  40. The Document Hierarchy • XCAP defines URIs as two parts • Document selector – chooses the XML document • Node selector – chooses the XML component (element, attribute) • XPath subset discussed previously • XML documents organized into a mandatory hierarchy • Borrows from ACAP concepts

  41. Hierarchy Structure • Top is the Root Services URI • Identifies start of XCAP tree • http://server.example.com/xcap-root • http://www.example.com/docs/xml/ietf/xcap/root • Next is the AUID • Next is “users” or “global” • “users” are for per-user documents • “global” are for data that is not user specific – for reading by all users of the app • Within users, next is username • Underneath username is anything • Eventually leads to document

  42. The Hierarchy Root services AUID 1 AUID 2 users global petri hiroshi doc1 dir1

  43. http://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/namehttp://xcap.example.com/address-book/users/petri/adbook1/address-book/entry/name Example 1 adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book>

  44. Retrieving Document Element Attribute Deleting Document Element Attribute Modifying Document Element Attribute Adding Document Element Attribute Client Operations KEY CONSTRAINTCan only affect one element, attributeor document at a time

  45. Fetching a Document GET http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1 adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK Content-Type: application/adbook+xml Content-Length: … <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book>

  46. Fetching an Element GET http://xcap.example.com/address-book/users/petri/adbook1/ address-book/entry/name HTTP/1.1 adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK Content-Type: application/xml-fragment-body Content-Length: … <name>Jonathan Rosenberg</name>

  47. Fetching an Attribute GET http://xcap.example.com/address-book/users/petri/adbook1/ address-book/entry/street/@paved HTTP/1.1 adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK Content-Type: application/xml-attribute-value Content-Length: … true

  48. Delete a Document DELETE http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1 adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK NULL

  49. Deleting an Element adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> DELETE http://xcap.example.com/address-book/users/petri/adbook1/ address-book/entry/name/email HTTP/1.1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK

  50. Deleting an Attribute adbook1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <email>jdrosen@dynamicsoft.com</email> <postal> <street paved=“true”>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> DELETE http://xcap.example.com/address-book/users/petri/adbook1/ address-book/entry/name/postal/street/@paved HTTP/1.1 <?xml version="1.0" encoding="UTF-8"?> <address-book> <!—This guy is a bozo -- <entry> <name>Jonathan Rosenberg</name> <postal> <street>600 Lanidex Pl</street> <city>Parsippany</city> <state>NJ</state> <country>USA</country> </postal> <ietf-participant/> </entry> </address-book> HTTP/1.1 200 OK

More Related