exteNsible markuP laNguage ocumeNt maNagemeNt · 2018. 3. 13. · 189 18 exteNsible markuP laNguage documeNt maNagemeNt Themergence e of novel applications for the next-generation

189

18exteNsible markuP laNguage

documeNt maNagemeNt

Theemergenceofnovelapplicationsforthenext-generationnetwork(NGN) highlights the need to overtake the traditional “data silo”model,wheretheintegrationofdifferentservicesisoftenperformedverticallyandperservice.Tofitthisneed,theOpenMobileAlliance(OMA) defined standard reusable common components calledenablers.Enablersbroughtseveraladvantages,suchasthereductionofcosts,aconsistentdefinitionofuser interfacesacross several ser-vices,andauniformmanagementoftheincreasingamountofuser-relateddata.The lastwas facilitatedby thegradual introductionoftheExtensibleMarkupLanguage (XML)DocumentManagement(XDM)technology.

XDMleveragesonXMLConfigurationAccessProtocol(XCAP)andSessionInitiationProtocol(SIP)toallowservicestoaccessuser-relatedinformation.InXDM,auserisidentifiedbyanXCAPuseridentifier (XUI), which takes the form of either an SIP UniformResource Identifier (URI) or a TEL URI. (The SIP URI is thepreferredone in case the sameuserpresentsboth identifiers.)Userinformation is assumed to be stored in the form of a collection ofXMLdocumentsresidinginlogicalrepositories,calledXDMservers(XDMSs),whicharespecializedXCAPservers.

There are two different kinds of XDMSs. An enabler-specificXDMS is an XCAP server that allows a given service enabler (theterminologyadoptedbytheOMAtorefertoagenericserviceblock)oroneofitsfunctionalentitytomanageXMLdocumentsforpersis-tencepurposes,forinstance,theResourceListServer(RLS)usedinOMAPresenceSIPforInstantMessagingandPresenceLeveragingExtension(SIMPLE).

Anenabler is a functional entity that accepts andmanages sub-scriptionstoresourcelistsanddistributestheresourcestateofthelist

Identification and Management of Distributed Data NGN, Content-Centric Networks and the Web Giovanni Bartolomeo and Tatiana Kováciková

© 2013 by Taylor & Francis Group, LLC

190 IdentIfICatIon and ManageMent

to subscribers.RLSuses anRLSXDMSto storepersistentXMLdocumentscontaininginformationontheresourceliststate.

Onthecontrary,asharedXDMSisanXCAPserverthatstorescommonXMLdocumentscontaininginformationthatmaybereusedacrossvariousserviceenablers.TheinformationcontainedinsharedXDMSs, as in any other XCAP server is governed by its applica-tionusage.Earlyexamplesofcommonapplicationusages inOMAincludedURI list andgroupusage list,bothextending the resource lists application usage* described in RFC 4826 (Rosenberg 2007b).TheURIlistisintendedtoprovidethecapabilitytomanageasimplelistofURIscommontomanyenablers;aresourcelistwithinaRLSXDMS, for instance,maycontain references to commonURI listsstoredinashared-listXDMS.ThegroupusagelistdefinesalistofgroupnamesorserviceURIswhosetypeisaprioriundefinedbutcanbedefinedbyspecificapplications.InXDM2.0,sharedXDMSsmayrun more complex application usages intended to provide facilitiestomanagegroupsofusers,shareduserprofiles,andcommon-accesspolicyrulesgoverningcommunicationrequests.

XDM Aggregation Proxy

XDMSs are accessed not only by enabler-specific servers but alsoby XDM clients. Both an application server and end-user equip-mentcanplaytheroleofanXDMclient.Inthelattercase,however,whenevertheclientisnotinatrustworthylocation,theaccessisnotdirectbut isproxiedthrougha functionalentitycalledanaggrega-tionproxy.Theaggregationproxy isaHypertextTransferProtocol(HTTP) reverse proxy (i.e., a proxy server that hides the XDMSsfromtheclientandactsonhisorherbehalf),which,afterperformingauthenticationoftheXDMclientandsecuringtheconnectionusingTransportLayerSecurity(TLS),routesXCAPrequeststothecorrectXDMS.Toperformauthentication, theaggregationproxyuses the3rdGenerationPartnershipProject(3GPP)–definednetworkauthen-ticationforGenericAuthenticationArchitecture(GAA)or,alterna-tively,aweakerHTTPDigestauthentication.Theaggregationproxy

* Aresourcelistsapplicationisanyapplicationthatneedsaccesstoalistofresources.ThelistofresourcesisaresourceitselfandisidentifiedbyaURI.



191xMl doCuMent ManageMent

isresponsibleforprovidingtheidentityoftheusertotheXDMSsbyinsertingaspecialentityheader*intoXCAPrequests.

Inaddition, theaggregationproxymay implementchargingandcompressing requests for clients with narrow bandwidth; however,thesefeaturesarenotmandatory intheXDMspecificationbutareoptional.

EachXDMS,beinganXCAPserver,conformstothexcap-capsapplicationusage,whichconsistsinasingleXMLdocument,avail-able in theglobaldirectory and listing theAUIDs, extensions, andnamespacesunderstoodbytheserver.

However,sincetheremaybeseveralXDMSsinasinglenetwork,itwouldnotbeveryefficientforanXDMclienttoretrieveallxcap-capsdocumentsdirectlyfromtheXDMSs.TohelptheXDMclienttodiscovertheXCAPcapabilitiesexposedbyanetwork,theaggrega-tionproxycollectstheXCAPservercapabilitiesfromalltheXDMSs,anduponclient request, it conveys all theAUIDs, extensions, andnamespacesmergedintoasingledocument.

OneadditionalmandatoryapplicationusagedefinedbyXDMisXMLDocumentsDirectory(org.openmobilealliance.xcap-directory).Thisapplicationusageallowsaclienttoretrievealistofdocumentspergivenusercollectedeitheracrossall theXDMSsor from a given XDMS serving a specified AUID. DocumentsDirectorymaintainsamanagedXMLdocumentineachusertreebranch named directory.xml. For each supported applicationusage (provided there are managed documents in the correspond-ingusertreebranch),directory.xmllistsinformationsuchastheDocumentselectorsidentifyingtheuserdocuments,theirETag,theirsize,andthetimeoflastmodification.Asforxcap-caps,theaggrega-tionproxyactsasacollectorand,uponrequest,servestotheclienta singledirectory.xml (peruser)mergingall theentries in thedifferentdirectory.xmldocumentsofeachavailableapplicationusage.

* Theheaderfieldnamedependsontheauthenticationprocedure inuse.InGAA,itcouldbeavalidX-3GPP-Intended-Identityifprovided,or,alternatively,itisanX-3GPP-Asserted-Identityprovidedbytheaggregationproxyitself.InHTTPDigestauthentication,theX-XCAP-Asserted-Identityentityheaderisused.




XDM Reference Points

ThereferencepointbetweentheXDMclientandtheaggregationproxy,forhistoricalreasonsexplainedlater,iscalledXDM-3andcor-respondstotheUtreferencepointintheIMS(Figure18.1).Asecondreference point is XDM-4, defined between the aggregation proxyandthesharedXDMS.BothofthemusetheXCAPprotocol.

Reference points XDM-1 and XDM-2 are no longer supportedinthecurrentreleaseoftheXDMstandard(atthetimeofwriting,XDM1.1,releasedinJune2008).*Previously,theywereusedtosup-portsubscriptionstochangesandnotificationsofchanges inXMLdocumentsstoredinXDMSsthroughtheSIPprotocol.Nevertheless,thesecapabilitieshavebeenreintroducedinXDM2.0.

Inparticular,XDM-1 supports the communicationbetween theXDMclientandtheSIP/IPCorenetwork.IntheIMS(Figure 14.5),when the XDM client is implemented in the user equipment, theXDM-1referencepointconformstotheGmreferencepoint.Whenitisimplementedinanapplicationserver,XDM-1conformstotheIMSServiceControl (ISC) referencepoint.TheXDM-2 referencepointsupportsthecommunicationbetweentheXDMSsandtheSIP/IPCore,and,intheIMS,itconformstotheISCreferencepoint.

* XDM2.0specifications,stableattheendof2010,arenotyetastandardbutareacandidatestandard.

XDM-3

XDM-4

AggregationProxy

EnablerSpeci�c XDMS

XDMClient

Shared XDMSEnabler

Speci�c Server

Figure 18.1 xDm architecture, functional entities, and reference points.




Subscription and Notification Capabilities

SubscriptiontochangesisperformedbytheXDMclientsendinganSIPSUBSCRIBErequest.Thesimplestformofsubscriptionispersingleuserandsingleapplicationusage. In theSUBSCRIBEmes-sage, theRequest-URIcontains the targetXUIwithanadditionalparameter used to specify the AUID of interest (in the followingexampleasharedgroupapplication):

SUBSCRIBE sip:[email protected];auid=org.openmobilealliance.groups SIP/2.0

TheclientinsertsapublicidentifieridentifyingtheoriginatinguseragentintheP-Preferred-Identityheaderfield(RFC3325;Jennings,Peterson, and Watson 2002); in addition, it specifies the valueapplication/xcap-diff+xml(whichisanXML-basedformathereafter described later) in the Accept header field. The Content-Encoding header field may indicate that the XDM client supportscompression(e.g.,thegzipalgorithm).Finally,thebodyincludestheXCAPresourcestowhichtheclientisgoingtosubscribe(inthefol-lowingexcerptagroupnamedfriends):

<?xml version="1.0" encoding="UTF-8"?><resource-list xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="org.openmobilealliance.groups/users/sip:[email protected]/friends"/> </list></resource-list>

The SUBSCRIBE message is sent through the SIP/IP Core totheXDMS.TheP-Preferred-IdentityheaderfieldisreplacedbytheP-Asserted-IdentityheaderfieldwhenthemessageisroutedthroughtheSIP/IPCore.ThetwofieldsareusedwithinthetrustedSIPinfra-structureonbehalfoftheFromheaderfieldtoidentifytheuseragent,makingitpossibletosupportAnonymousrequests,wheretheFromheaderfieldissettoAnonymous.

TheXDMS,afterverifyingthatthetargetresourceexistsandthattheclientisauthorizedtosubscribetochanges(bydefaultorbylocalpolicy rules), creates a subscription to changes of XCAP resourceslistedinthebodyoftheSUBSCRIBEmessageandreplieswithanSIP200OKresponsemessage.Then,theXDMSgeneratesaninitial




SIPNOTIFYrequestmessagetowardthesubscribedXDMclient.ThemessagebodycontainsaninitialreferencetoXDMdocumentscontainingtheresourceforwhichchangeshavebeensubscribed.Theformatiscompliantwiththeschemadefinedin(RFC5874;RosenbergandUrpalainen2010)torepresentchangesinXCAPresources,whichallowsspecifyingtheXCAProotURI,theinteresteddocument,itsEtag,anditschangesetintermsofelementorattributes.

<?xml version="1.0" encoding="UTF-8"?> <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" xcap-root="http://xcap.example.com/" <document new-etag="18a22f" sel="org.openmobilealliance.groups/users/sip:[email protected]/friends"/> </xcap-diff>

Subsequent changes are likewise sent to the client using SIPNOTIFYrequestmessages.Thefollowingexcerptreportsthatachangehasoccurredinthesubscribedsharedgroupdocumentandanewentryhasbeenadded.Notethatthevalueoftheprevious-etagattributematchesthevalueofthenew-etagattributeofthepreviousrequest:

<?xml version="1.0" encoding="UTF-8"?> <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" xmlns:list="urn:oma:xml:poc:list-service" xcap-root="http://xcap.example.com"> <document previous-etag="18a22f" sel="org.openmobilealliance.groups/users/sip:[email protected]/friends" new-etag="937bc4"> <change-log> <add sel="list:group/list:list-service/list:list"> <list:entry list:uri="sip:[email protected]"> </add> </change-log> </document> </xcap-diff>

Subscription Proxy

XDM2.0allowsformorecomplexformsofsubscriptions;thesameclientcansubscribetochangesoccurringinmorethanoneapplicationandformorethanoneXUIveryefficiently,usingasinglesubscriptionrequest.This is realizedbymeansofa subscriptionproxy towhichtheclientsubscriptionrequest issent.Thesubscriptionproxy,upon




receivingthesubscriptionrequest,takescareofgeneratingasmanyback-endsubscriptionsasthenumberofinvolvedapplicationusagesandXUIsandcollectschangesfromback-endXDMSes;changesareconveyedtotheclientusingamultipart/relatedSIPNOTIFYrequestmessage whose body merges occurred changes in the subscribedresources(RFC4662;Roach,CampbellandRosenberg2006).

Policy Rules

AsinXCAP,theinitialcreatorofadocumentisconsidereditspri-maryprincipal,andassuch,sheisenabledtoperformalloperationsonthedocument.Itisnotpossibletoassignpermissionstomanip-ulate adocument to anyone except its primaryprincipal or trustedapplications.However,applicationusagesmaydefineadditionalrulesetstodescribeauthorizationsforaccessingXCAPresourcessuchasglobaldocuments.Tofacilitatethistask,XDMborrowsfromRFC4745(Schulzrinneetal.2007)thedefinitionsofauthorizationpolicyrulesthroughanXML-basedpolicyframework.

Authorization policy rules are represented according to a simpleschemaandconsistofthreeparts:conditions,actions,andtransfor-mations.ThetransformationspartisobsoleteandisignoredinXDMspecifications.Theactionspartdefineswhatshouldoccurwhentheconditionsaremetandisextendedbythirdpartiesaccordingtotheirapplication-specific needs. The conditions part is standardized byXDMandallowsspecifyingidentitiestobematchedthroughtheirchildelements:forexample,asingleuseridentity,multipleenumer-ated identities, all identities belonging to a given domain. XDMextendstheoriginalpolicyframeworkbyprovidingfewmorecases:external-list,wheretheidentity istakenfromalistof identi-tiesstoredexternallyandavailablethroughanXCAPURI(e.g., ina sharedXDMS);anonymous-request, intended tomatch anyincomingrequeststhathavebeenidentifiedasanonymous(aslongasauthenticated);andother-identity,whichmatchesallidentitiesnot identified inanyprevious rules, allowingadefaultpolicy tobespecified.

For instance, the followingexcerpt representsa rule setmadeoftworulescontaining,respectively,oneandtwoconditions(theactionsandtransformationspartsareempty).




<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy" xmlns:ocr="urn:oma:xml:xdm:common-policy"> <rule id="20c1a"> <conditions> <identity> <one id="sip:[email protected]"/> <one id="tel:+1-212-555-1234"/> </identity> </conditions> <actions/> <transformations/> </rule> <rule id="20c1b"> <conditions> <identity> <many> <except domain="example.org"/> <except domain="example.net"/> <except id="sip:[email protected]"/> </many> </identity> </conditions> <conditions> <ocr:external-list> <ocr:entry anc=”http://xcap.example.com/resource-lists/users/sip:[email protected]/index/~~/resource-lists/list%5b@name=%22list_A%22%5d/”> <ocr:entry anc=”http://xcap.example.com/resource-lists/users/sip:[email protected]/index/~~/resource-lists/list%5b@name=%22list_B%22%5d/”> </ocr:external-list> </conditions> <actions/> <transformations/> </rule> </ruleset>

Thefirstruleexposesaconditionmatchingtwoidentities,oneintheformofanSIPURIandtheotherofaTELURI.Theconditionisevaluatedtotruewheneveratleastoneofthelistedidentitiesismatched.

Thesecondrulepresentstwoconditions.Thefirstconditionidenti-fiesanyauthenticatedidentity(evenanonymous)exceptspecifieduseridentities,whichcanalsobeexpressedbyreferringtotheirdomains.Theconditionisevaluatedtotruewhenevernoneoftheidentityspeci-fiedinthe<except>elementismatched.Thesecondconditionusesele-mentsfromtheOMAextensionofthepolicyframework,whichallowsforreferraltoidentitiesstoredintwoexternalURIlistsdocuments.




XDM2.0definestwoadditionalchildrenforthe<conditions>element: <media-list> and <service-list>. The <media-list>elementmatchesincomingrequestsassociatedwithparticularmediatypes.Mediatypesaredefinedaselements;someofthemarenotedinTable 18.1.The<service-list>elementmatchesincom-ingrequestsassociatedwithaparticularservice.Servicesaredefinedas<service>elements,eachofwhichcontainstheenablerattributethat specifies aparticular service enabler.Examplesof values tobeinsertedintothisattributearegiveninTable 18.2.Eachvaluecor-respondstoanenabler,whichhasassociatedarootnamespace.Therootnamespaces,oneforeachenabler,arefurtherdividedaccordingtoenablerspecificcapabilitiesandspecificationversionnumber,fol-lowingthetemplate:

urn:oma:xml:{enabler}:{SchemaSpecificTag}

Table 18.1 omA-Defined media types to be used in Policy Rule Conditions

xmL eLemeNt NAme DesCRIPtIoN

<message-session> Applications based on the message session Relay Protocol (msRP), a protocol for transmitting a series of related instant messages in the context of an sIP session

<pager-mode-message> Pager messaging: Instant messaging applications that relies on sIP messAge requests; contrary to message-session, each instant message stands alone

<file-transfer> file transfer applications<audio> Applications using audio and video capabilities<video> <poc-speech> Push to talk over Cellular speech (a walkie-talkie–like

communication service implemented on top of the cellular network)<group-advertisement> Advertisements for recently created groups of users

Table 18.2 omA-Defined service enablers to be used in Policy Rule Conditions

NAme uRN PRefIx DesCRIPtIoN

Im urn:oma:xml:im: Instant messagingmms urn:oma:xml:mms: multimedia messaging servicePoc urn:oma:xml:poc: Push to talk over CellularPrs urn:oma:xml:prs: Presence servicesupm urn:oma:xml:supm: user Profile managementxdm urn:oma:xml:xdm: xmL Document management




ThesenamespacesactuallydefineXMLschemasassociatedwitheachapplicationusage.

Policy rules usually come from particular domains to meet spe-cific application needs. For instance, Push-to-Talk over Cellular (awalkie-talkie–likecommunicationserviceimplementedontopofthecellularnetwork) extends thepolicy frameworkbydefiningactionsthatgovernthemanagementofincominginvitations.However,withtimesomeoftheseneeds(e.g.,controlofincomingcommunication)havealsobecomeusefultomanyotherapplications.Toaccommodatethereuseofcommonaccesspolicyinauniformway,XDM2.0hasdefinedasharedapplicationusagecalleduser access policy,whoserulesarecontainedinanXMLdocumentstoredinasharedXDMScalledsharedpolicyXDMS.

Search Capabilities

XDM2.0allowsaclienttosearchinformationinanycollectionofXML documents stored in XDMS using a limited subset* of theXQueryfunctions.

Both the search query and the results are transported using theHTTPprotocol.Toissueaquery,theXDMclientsendsaHTTPPOSTrequesttoasearchproxyserver(ortotheaggregationproxyiftheclientisnotinatrustworthylocation)implementingtheorg.openmobilealliance.search application usage. The HTTPrequestURIcontainsthefollowingparametersasHTTPURIqueryparameters(e.g.,askey-valuepairsappendedtotheURIusingaques-tionmarkandseparatedbytheampersandsign):

The target, that is, a parameter identifying the collections ofdocumenttosearch

Thedomain,anoptionalparameterallowingthespecificationofadditionaldomainstosearch†

Forinstance,thefollowingrequestURI

* Each applicationusagemay support only someof the capabilitiesdefinedby thestandard.

† Aswillbedescribed,otherthanthehomedomain,itispossibletoperformXDMoperations (manipulationsof, subscriptions to,andsearches indocuments)acrossdifferentdomains.




http://xcap.example.com/org.openmobilealliance.search?target=org.openmobilealliance.user-profile/users/&domain=home%20example.org

instructsthesearchproxytoperformasearchinthehomedomain(example.com)andinaremotedomain(example.org).

XDMprovidesthefacilityofaggregatingmorethanonequeryina“searchset,”whichisusefultoreducetheoverheadofexchangingmultiple HTTP requests and response messages. The actual queryis contained within thequery element of eachsearch entry inthesearchsetencodedascharacterdata.Thesearchelementalsospecifiesaper-clientuniquequeryidentifier(idattribute)and,opti-mally, an indication of the wanted maximum number of returnedresults(max-resultsattribute).Thefollowingexcerptillustratesasearchset:

<?xml version="1.0" encoding="UTF-8"?><search-set xmlns="urn:oma:xml:xdm:search"><search id="af200a" max-results="2"> <request> <query> <![CDATA[ xquery version "1.0"; declare default element namespace "urn:oma:xml:poc:list-service"; declare namespace rl = " urn:ietf:params:xml:ns:resource-lists”; for $l in collection("org.openmobilealliance.groups/users/sip:[email protected]/friends")/group/list-service where ($l/max-participant-count<4) and ($l/list/entry[@rl:uri=’sip:[email protected]’]) order by $l/max-participant-count descending return $l ]]> </query> </request></search></search-set>

This search set contains one query. The query defines a singlevariable$l, which iterates over elements (identified by the XPathexpression/group/list-service)insideXMLdocumentsrelatedtotheapplicationusageurn:oma:xml:poc:list-service.Thesedoc-umentsaretakenfromthefriendsbranchoftheuserjoe@example.org.TheconventionhereusedtoidentifyXMLdocumentsissimilartotheoneadoptedbytheXCAPdocumentselector.However,unlikeatraditionalXCAPexpression—whichmaycontainoneandonlyonedocumentselector—theresultoftheXQuerycollection()func-tionisasequenceofdocuments,notonespecificdocument.




Thewhereclausedefinesconditionstofilterouttheelements;itispossibletodefinemanyconditionsinsideasinglewhereclauseusinglogicaloperators(inthepreviousexamplethelogicaloperator“and”isused).Theorderbystatementdefinesanorderamongthereturnedresults,basedononeormorevariables’value.

The return statement, concluding the query, defines whichresultsshouldbereturned.Inthepreviousexample,justonecollec-tionofnodesisreturned;however,therearealsootherpossibilities,rangingfromreturningsinglevaluestowholeXMLdocuments.

Based on the AUID contained in the target parameter, thesearchproxy takescareofdispatching thequery to theappropriateXDMS.This latterexecutesthequeryoverallXMLdocumentsofthespecifiedcollections,andreturnstheresults(akaqueryresponse)asanXMLdocumentcontained inthebodyoftheHTTPPOSTresponsemessage.Thedocumentconsistsofasearchsetsimilartotheonesentintherequestmessage;unlikethelatter,however,itcontainsresponse elements. The following excerpt illustrates a search setcontainingresponses:

<?xml version="1.0" encoding="UTF-8"?><search-set xmlns="urn:oma:xml:xdm:search" xmlns:list="urn:oma:xml:poc:list-service"xmlns:rl="urn:ietf:params:xml:ns:resource-lists"><search id="af200a"> <response> <list:list-service uri="sip:[email protected]"> <list:display-name lang="en">Tour-1</list:display-name> <list:list> <list:entry uri="sip:[email protected]"> <rl:display-name lang="en">Trudy Smith</rl:display-name> </list:entry> <list:entry list:uri="sip:[email protected]"> <rl:display-name lang="en">Alice Doe</rl:display-name> </list:entry> <list:entry list:uri="sip:[email protected]"> <rl:display-name lang="en">Mark Lee</rl:display-name> </list:entry> </list:list> <list:max-participant-count>3</list:max-participant-count> </list:list-service> <list:list-service uri="sip:[email protected]"> <list:display-name lang="en">Tour-2</list:display-name> <list:list> <list:entry uri="sip:[email protected]"> <rl:display-name lang="en">Alice Doe</rl:display-name>




</list:entry> <list:entry uri="sip:[email protected]"> <rl:display-name lang="en">Joe Smith</rl:display-name> </list:entry> </list:list> <list:max-participant-count>2</list:max-participant-count> </list:list-service> </response></search></search-set>

Theidattributeofthesearchelementisusedtoassociateeachresponsetothecorrespondingquery.TheHTTPresponsemessageiseventuallyreturnedtotheXDMclient.

Communication with Remote Networks

XDM2.0introducesthecapabilitytohandle,subscribe,andsearchonXMLdocumentshostedinXDMSsresidinginadomainotherthanthehomedomain.Thisisachievedbymeansoftworeferencepoints:

1.IP-1 reference point, which conforms to the Ici referencepointintheIMS,basedontheSIPprotocol(whichisnativelycross-domain). Subscriptions and notifications to remoteXMLdocumentchangespassthroughIP-1.

2.NNI-1 reference point, supporting the HTTP-based com-municationbetweenXDMSsindifferentdomainsviafunc-tionalelementsnamedcross-networkproxies.

The cross-network proxy is a novel reverse proxy server introducedin theXDM2.0architecture.Communicatingwith itspeer cross-networkproxyintheforeigndomain,itprovidesauniformXCAP-andXQuery-basedinterfacetowardtheXDMinfrastructureintheremotenetwork.

Thelocalcross-networkproxyacceptsincomingrequestsfromthelocalaggregationproxy(orfromthelocalsearchproxy)targetedtoaforeigndomain.ThetargetdomainnameisdeterminedbyinspectingtheXUIoftheXCAPURIintheoutgoingrequest(orthedomainparameterintheHTTPrequestURIinthecaseofasearchrequest).Thelocalcross-networkproxycheckswhetherthetargetdomainisatrusteddomain,andifthisisthecase,itforwardstherequesttotheremotecross-networkproxythroughtheNN-1referencepoint.The




remotecross-networkproxy,inturn,forwardstherequesttoitslocalaggregationproxy(orsearchproxy).

SincealltheseelementsareHTTPproxies,theresponsemaysim-plycomebacktotheclientbyfollowingthereversepath.



Identification andManagement ofDistributed Data

NGN, Content-CentricNetworks and the Web

Giovanni BartolomeoTatiana Kováciková



CRC PressTaylor & Francis Group6000 Broken Sound Parkway NW, Suite 300Boca Raton, FL 33487-2742

© 2013 by Taylor & Francis Group, LLCCRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Printed on acid-free paperVersion Date: 20130503

International Standard Book Number-13: 978-1-4398-7907-8 (Hardback)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information stor-age or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copy-right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro-vides licenses and registration for a variety of users. For organizations that have been granted a pho-tocopy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe.

Visit the Taylor & Francis Web site athttp://www.taylorandfrancis.com

and the CRC Press Web site athttp://www.crcpress.com



v

Contents

Preface ix

acknowledgments xiii

about the authors xv

section i naming and addressing on the internet

chaPter 1 iP addresses 3InternetProtocol,Version4 3IPClasses 4Subnetting 6SpecialIPAddresses 9InternetProtocol,Version6 10

chaPter 2 domain naming system 13DomainNames 14DNSArchitecture 17ResourceRecords 20DNSOperations 25

chaPter 3 hyPertext transfer Protocol 31BriefHistoryofHTTP 31URL,URN,URI,andIRI 33HTTPMethods 35ChunksandCookies 42RepresentationalStateTransferArchitecturalStyle 42Non-RESTHTTP-BasedProtocols 45HTTPAuthenticationMethods 46SSL/TLS,X.509,andHTTPS 47



vi Contents

section ii managing xml data

chaPter 4 extensible markuP language basics 51XPath 57XQuery 59

chaPter 5 web services 63WSDL 63SimpleObjectAccessProtocol 66WebServiceRepositoryandOrchestration 68NotificationandAddressing 69

chaPter 6 xml configuration access Protocol 71XCAPAddressing 72XCAPandHTTPMethods 75ConditionalOperations 80ErrorHandling 81ExposingApplicationUsageCapabilities:XCAP-CAPS 82

chaPter 7 oPen data Protocol 83EntityDataModel 83InteractingwithODataServices 85ODataEntities 86ODataCollections 90HandlingEntities 92

section iii content-centric networks

chaPter 8 content-oriented communication and conversational communication 99CleanSlate,Overlay,andEvolutionaryApproaches 100NamingScheme 101

chaPter 9 web content delivery networks 103

chaPter 10 Peer-to-Peer networks 107Napster 108Gnutella 108

chaPter 11 distributed hash table 111Chord 112Pastry 114

chaPter 12 Jxta ProJect 117Peers 118Pipes 119PeerGroups 120ModulesandCodats 121AdvertisementsandRendezvousPeers 121MessageRoutingandForwarding 123



viiContents

chaPter 13 named data networking ProJect 125HowNDNWorks 126Naming 128Security 130Advantages 130RoutingandForwarding 131CCNx 132

section iv next-generation networks

chaPter 14 evolution of the cellular telePhony networks 137NGNFunctionalArchitecture 138IMSComponents 142OtherNGNSubsystems 143CommonComponents 144

chaPter 15 session initiation Protocol 147SIPFeatures 148SIPEntities 150SIPMessages 153SIPTransactions 157ExampleofanSIPTypicalScenario 158

chaPter 16 identifiers in communication networks 159BackgroundtoIdentifiersforNext-GenerationNetworks 1603GPPConceptontheUseofIdentifiers 162IdentityandIdentifiersinNGN 164IdentifiersforUsers 165IdentifiersforServices 170UniversalCommunicationsIdentifier 170E.164NumberMapping(ENUM) 174

chaPter 17 generic authentication architecture and generic bootstraPPing architecture 177GenericAuthenticationArchitecture 177GenericBootstrappingArchitecture 180SupportforSubscriberCertificates 183X-3GPPHeaderExtensions 187

chaPter 18 extensible markuP language document management 189XDMAggregationProxy 190XDMReferencePoints 192SubscriptionandNotificationCapabilities 193SubscriptionProxy 194PolicyRules 195SearchCapabilities 198CommunicationwithRemoteNetworks 201



viii Contents

section v linked data

chaPter 19 resource descriPtion framework 205RDFTriples 205RDF/XML 207Turtle 210N-Triples 211

chaPter 20 advanced rdf 213RDFSchemaandOWL 213Reification,Quads,andNamedGraphs 220RDFandXML 224

chaPter 21 rdf Query language: sParQl 229TriplePatternsandQuery 229GraphPatterns 232QueryingfromMultipleGraphs 235

chaPter 22 linking oPen data ProJect 239ClassifyingOpenData:TheFive-StarRatingSystem 240FourLinkedDataPrinciples 242CoolURIsfortheSemanticWeb 243LinkingDataSets 246

references 251

index 263



ix

Preface

Themotivationforthisbookwastoprovidestudentsandfutureinfor-mationengineerswithausefulcollectionofInternetstandards,tech-nologies, and techniques that derive from research projects for themanagementofdistributeddata.Wewrote thebookduringaveryexcitingperiodoftheInternet.TheubiquitousaccessoftheInternetindailylifebyallhasallowedtheemergenceofnewsortsofbusinesses,basedonthestaggering—andat timespuzzling—amountof infor-mation on the Internet. Search engines, social networking, onlineadvertising,andonlinecommercehavebeenbuiltontheaggregationandsharingofpersonaldata.Carrierscloselycooperatewithcontentproviderstoallowadeeperintegrationbetweentheirservicesandtheunderlyingnetwork,thereforeimprovingthequalityoftheircustom-ers’experience.Governmentsandpublicadministrationshavebeguntosimplifythewaypublicdataareaccessedbyopeningtheirarchivestocitizensthroughtheweb.

Although several academic courses are offered that discuss datamanagementandnetworking,fewofthemfocusontheconvergenceofnetworkingandsoftwaretechnologiesforidentifying,addressing,andmanagingdistributeddata.Thisbookfocusesonthisconvergence—aresultofaseriesoflongprocessesinthehistoryoftheInternetinwhichdatamanagementhasbeenthoughtandrethoughtmanytimes.



x PrefaCe

ThedifferentlayersoftheInternetprotocolstackalreadyprovidedif-ferentfunctionsaswellasusefulanalogiesthatprovideinformationengineers with the opportunity and knowledge to design efficientsystems.

The best way to read this book is to be aware of some of therecurringthemeswedealwith in itsfivesections.Thefirst threethemesare explicitly related todata identification,while the restdealwithdatamanagement.

What or Where?

Theambiguitybetweenwhere andwhathashaunted thehistoryoftheInternetsinceitsearlydays.Doesanidentifiergiveaclearindi-cationofwhatisbeingidentified?AnInternetProtocol(IP)addressindicates only the network address of a likely unknown host. TheDomainNameSystem(DNS)isrequiredtodeliveramorehuman-readableandmemorabledomainname.Otheridentifiersareintendedtoprovidefinergranuleidentificationofresourcesbyname(UniformResource Name [URN]) or location (Uniform Resource Locator[URL]),but although theymaybemeaningful to thehumanuser,theyremainunintelligibletothemachine.

Flat or Hierarchical Names?

Shouldnamesoraddressesbe issuedinacentralizedordistributedmanner?ThewidespreadDNSisanefficient,hierarchical,andcen-tralized mechanism. Some peer-to-peer networks also provide anequally efficient and scalable lookup system by implementing theDistributedHashTable(DHT)algorithm,whichcreatesanumericaddressspaceintowhichdecentralizedflatnamesaremapped.

Trustworthiness

Are there inherent mechanisms to ensure that a user accessing aresource can trust its information and the validity of its variousparameters,suchasitsownership?Todaymanymechanismsrelyonthetrustworthinessofthehostandnotonthatoftheactualresourcebeingaccessed.



xiPrefaCe

Efficient Data Distribution

Multicast backbone (Mbone) was the first attempt at multicastingon the Internet, but several factors—such as the lack of semanticsforcontrollingitschannels—madeitlessappealingandledtosolu-tionsbasedonamultiunicastapplicationlevelprotocol(i.e.,HTTP).However,tobeeffectivethesesolutionsrequirecachingmechanismsimplementedinspecializednetworkappliancesintheInternet.Novelcontent-centric paradigms aim to simplify and improve these solu-tions,introducingcachingdirectlyintothenetworklayer.

Representational State Transfer

TheRepresentationalStateTransfer (REST)architectural stylewasformallydefinedmorethan10yearsago,butonlyrecentlyhasitsuni-fying power been fully understood. REST applies to every kind ofresourceanddefinesuniformaddressingmechanisms,commonseman-tics foroperations,flexiblewaysof transferring resource representa-tions, and support for caching.Datamanagement applicationsbuiltonRESTareefficient,avoidduplications,andimproveperformances.

Resource-Oriented Models versus Representation-Oriented Markup Languages

ExtensibleMarkupLanguage(XML)andmorerecentlyJavaScriptObjectNotation (JSON)areopenandextendible standard formatsadopted by several technologies to model, store, and transmit datathroughthewire.Theseformatsarerepresentationoriented,however,astheyrelyonconcreteencoding.ResourceDescriptionFramework(RDF)models,onthecontrary,intheformofgraphs,areindepen-dentinhowtheyareencoded.RDFisaversatileresource-orienteddatamodelratherthanaspecificserializationformat.

Linking Data

Datalinkagehasbeenreinventedseveraltimesindatamanagementapplications.RDFhasultimatelyprovidedanativemechanismallow-ingclients to linkdata thewaypagesare linkedon the traditional



xii PrefaCe

web.An ideal “giantRDFgraph” isunder construction, and thereareexpectationsofhowitcouldbeusedtoanswerqueriespreviouslythoughtimpossible.

Duetotheextensivenatureofthesubject,thisbook,farfrombeingexhaustive,providesonlyhintsofa limitednumberofrel-evant technologies. But we think this is a good starting point.Indeed,inwritingthebookwehaveputmoreemphasisonillus-trating how the existing Internet stack already provides all thenecessary functions to handle and distribute data rather thandescribingnewspecializedlayers.Somespecifictechnologiesmaybeobsolete.However,webelievethatthethemesweaddressarerelevantinthattheyhavebeentheresincetheoriginsofnetwork-ingandsoftwareengineering,anditislikelytheywillbethereforalongtimeintothefuture.

From networks addressing basics to controversial questions onequivalenceandidentity,ourlongjourneycannowbegin.



xiii

Acknowledgments

Thisbookwouldnothavebeenpossiblewithoutthevaluableinput,contributions, feedback, and even criticism of our colleagues andfriends.Wethankallthepeoplewhohavebeeninvolvedinthedevel-opmentofthismanuscript.

Giovanniacknowledges theextraordinarypeoplehehashad thehonorofworkingwithduringhis eight yearswith thenetworkinggroupintheDepartmentofElectronicEngineeringattheUniversityof Rome Tor Vergata. In particular, he wishes to thank StefanoSalsanoandMatteoCancellieri,whoprovidedoutstandingguidanceintheunderstandingofcontent-centricnetworkingaswellasotherpreciousrelatedmaterial.

Tatiana acknowledges Pavel Segec, from the Department ofInfoCom Networks at the University of Žilina, Slovakia, for theirlong-term and fruitful collaboration in the area of next-generationnetworks.

Weoweaspecial thankstoourfriendsDionDrislaneandUmaArunachalam,whokindlyofferedtocleanupournonnativeEnglish.

We also wish to acknowledge all the editorial staff at Taylor &Francis,particularlyRichardO’Hanley,whofirstcontacteduswiththe proposal to write this book and then maintained remarkablepatienceinlightofourmanydelaysindeliveringthefinalmanuscript.





xv

About the Authors

Giovanni Bartolomeo earnedhisLaureadegree in software engi-neeringin2004fromtheUniversitàdegliStudidiPalermo;hewonaNortelNetworks–fundedprizethatsupportedhisresearchactivityduring his thesis development. As a research collaborator with theConsorzioNazionale Italianoper leTelecomunicazioni, hepartici-patedinseveralEuropeanUnion–fundedresearchanddevelopmentprojects and contributed to theWorldWireless Initiative “BookofVision2008.”Between2008and2010,heservedasanexpertontheEuropeanTelecommunicationsStandards Institute (ETSI)HumanFactorsTechnicalCommittee.Currently,Bartolomeo isa technicalofficerat theItalianMinistryof Justiceand is involved indifferentstandardizationeffortsattheOrganizationfortheAdvancementofStructuredInformationStandards(OASIS).

Tatiana KováčikováearnedherMScdegree intelecommunicationengineeringfromtheUniversityofTransportandTelecommunicationsinŽilina,formerCzechoslovakia.SheearnedherPhDintelecommu-nicationsystemsfromthesameuniversityin1995.In2004,shewasappointedassociateprofessorofinformationandmanagementsystemsattheUniversityofŽilina.From1984to1988sheworkedatSlovakTelecom,andsincethenshehasworkedattheUniversityofŽilina,Slovakia. In June2010 shewasappointedheadof theDepartment



xvi about the authors

ofInfoComNetworksthere.Kováčiková’sresearchinterestsincludeInternetProtocolandnext-generationnetworkarchitecture,protocols,andapplications,onwhichshehasbeeninvolvedinseveralnationalandinternationalresearchprojects.Asaleaderofaresearchgroup,shereceivedthe2003SiemensAwardinthefieldofInternetProtocoltelephony.Since2002,KováčikováhasbeenactivelyinvolvedintheEuropean Telecommunications Standards Institute (ETSI) GRID,TelecomsandInternetconvergedServiceandProtocolforAdvancedNetworks (TISPAN), Human Factors, and User Group TechnicalCommittees.

