A.8 Example signalling flows of HTTP based presence service operation

24.1413GPPPresence service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

A.8.1 Introduction

This subclause shows signalling flows relating to the manipulation of presence service data over the Ut reference point using XCAP. The flows only shows the signalling between the XCAP server and the XCAP client, thus possible proxies located in between the entities are not shown in the example signalling flows.

Each example signalling flow shows several sequences of manipulation of data for the presence service.

NOTE 1: Error conditions are not considered in the examples e.g. if authorization checks fail in the XCAP server, XML Schema compliancy checks fail or the file specified by the URI does not exist then an appropriate 4xx response is sent to the client.

Clarifications how XCAP is using HTTP are described in RFC 4825 [33].

NOTE 2: The authentication proxy resides between UE (XCAP client) and AS (XCAP server), and examples of signalling flows for the authentication proxy are provided in 3GPP TS 24.109 [7].

A.8.2 Signalling flows demonstrating how XCAP clients manipulate resource lists

Figure A.8.2-1: XCAP client manipulating a resource list on XCAP server

Figure A.8.2-1 shows a how a XCAP client may manipulate a resource list on a XCAP server. The details of the signalling flows are as follows:

1. XCAP PUT request (XCAP client to XCAP server – see example in table A.8.2-1

The XCAP client generates an XCAP PUT request to create a new resource list on the XCAP server. The resource list has one entry.

Table A.8.2-1: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.home1.net/services/resource-lists/users/user1/pf.xml HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:17 GMT

Content-Type: application/resource-lists+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:resource-lists">

<list name="Presence_fellows">

<entry uri="sip:user2_public1@home2.net">

<display-name>User2</display-name>

</entry>

</list>

</resource-lists>

2. XCAP 201 (Created) response (XCAP server to XCAP client) – see example in table A.8.2-2

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to create a file, the XCAP server sends an XCAP 201 (Created) response to the XCAP client.

Table A.8.2-2: XCAP 201 (Created) response (XCAP server to XCAP client)

HTTP/1.1 201 Created

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "aaa"

Date: Thu, 08 Jan 2004 10:50:35 GMT

Content-Length: 0

3. XCAP PUT request (XCAP client to XCAP server) – see example in table A.8.2-3

The XCAP client adds a new entry to the previously created resource list by generating a new XCAP PUT request.

Table A.8.2-3: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.home1.net/services/resource-lists/users/user1/pf.xml/~~/resource-lists/list%5b@name=%22Presence_fellows%22%5d/entry HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:17 GMT

Content-Type: application/xcap-el

Content-Length: (…)

<entry uri="sip:user3_public1@home3.net">

<display-name>User3</display-name>

</entry>

4. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.2-4

After the XCAP server has performed the necessary authorization checks, XML document validations and XML schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP client.

Table A.8.2-4: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "aab"

Date: Thu, 08 Jan 2004 10:50:45 GMT

Content-Length: 0

5. XCAP DELETE request (XCAP client to XCAP server) – see example in table A.8.2-5

The XCAP client decides to delete the entry "user2" from the resource list. The XCAP client generates an XCAP DELETE request.

Table A.8.2-5: XCAP DELETE request (XCAP client to XCAP server)

DELETE http://xcap.home1.net/services/resource-lists/users/user1/pf.xml/~~/resource-lists/list%5b@name=%22Presence_fellows%22%5d/entry%5b@name=user2"%5d HTTP/1.1

Host: oper.example.com:9999

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:14:17 GMT

6. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.2-6

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to delete an entry from the resource list, the XCAP server sends an XCAP 200 (OK) response.

Table A.8.2-6: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 11:00:47 GMT

Content-Length: 0

7. XCAP GET request (XCAP client to XCAP server) – see example in table A.8.2-7

The XCAP client wishes to check the result of the previous transaction by generating an XCAP GET request.

Table A.8.2-7: XCAP GET request (XCAP client to XCAP server)

GET http://xcap.home1.net/services/resource-lists/users/user1/pf.xml HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 11:13:17 GMT

Content-Length: 0

8. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.2-8

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to fetch the resource list, the XCAP server sends an XCAP 200 (OK) response to the XCAP client including the resource list in the body of the response.

Table A.8.2-8: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "askdajdsaj"

Date: Thu, 08 Jan 2004 11:50:35 GMT

Content-Type:application/resource-lists+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:resource-lists">

<list name="Presence_fellows">

<entry uri="sip:user3_public1@home3.net">

<display-name>User3</display-name>

</entry>

</list>

</resource-lists>

A.8.3 Signalling flows demonstrating how XCAP clients manipulate presence authorization policy

Figure A.8.3-1: XCAP client manipulating presence authorization policy on XCAP server

Figure A.8.3-1 shows a XCAP client manipulating presence authorization policy on a XCAP server. The details of the signalling flows are as follows:

1. XCAP PUT request (XCAP client to XCAP server) – see example in table A.8.3-1

The XCAP client generates an XCAP PUT request to create a presence authorization policy on the XCAP server. The presence authorization policy has one rule allowing for sip:user2_public1@home2.net to see all service information along with the service related servcaps elements defined in RFC 5196 [25].

Table A.8.3-1: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.home1.net/services/pres-rules/users/user1/ps.xml HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:17 GMT

Content-Type:application/auth-policy+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"

xmlns:sc="urn:ietf:params:xml:ns:pidf:caps"

xmlns:pr="urn:ietf:params:xml:ns:pres-rules"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:pres-rules">

<rule id="dsafa43232">

<conditions>

<identity>

<id entity="user2_public1@home2.net"/>

</identity>

</conditions>

<actions>

<pr:sub-handling>allow</pr:sub-handling>

</actions>

<transformations>

<pr:provide-services>

<pr:all-services/>

</pr:provide-services>

<pr:provide-persons><pr:all-persons/></pr:provide-persons>

<pr:provide-unknown-attribute name="sc:servcaps">true</pr:provide-unknown-attribute>

</transformations>

</rule>

</ruleset>

2. XCAP 201 (Created) response (XCAP server to XCAP client) – see example in table A.8.3-2

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to create a file, the XCAP server sends an XCAP 201 (Created) response to the XCAP client.

Table A.8.3-2: XCAP 201 (Created) response (XCAP server to XCAP client)

HTTP/1.1 201 Created

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "bbb"

Date: Thu, 08 Jan 2004 10:50:35 GMT

Content-Length: 0

3. XCAP PUT request (XCAP client to XCAP server) – see example in table A.8.3-3

The XCAP client adds a new rule to the previously created presence authorization policy by generating a new XCAP request. The new rule blocks the user named sip:user3_public1@home3.net to see presence information.

Table A.8.3-3: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.home1.net/services/pres-rules/users/user1/ps.xml/~~/permission-statements/ruleset/rule%5b2%5d HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:27 GMT

Content-Type: application/xcap-el

Content-Length: (…)

<rule id="fdsjkf">

<conditions>

<identity>

<id entity="user3_public1@home2.net"/>

</identity>

<conditions>

<actions>

<pr:sub-handling>block</pr:sub-handling>

</actions>

4. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.3-4

After the XCAP server has performed the necessary authorization checks, XML document validations and XML schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP client.

Table A.8.3-4: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "bbb2"

Date: Thu, 08 Jan 2004 10:50:45 GMT

Content-Length: 0

5. XCAP DELETE request (XCAP client to XCAP server) – see example in table A.8.3-5

The XCAP client decides to delete the rule for sip:user2_public1@home2.net from the authorization policy. The XCAP client generates an XCAP DELETE request.

Table A.8.3-5: XCAP DELETE request (XCAP client to XCAP server)

DELETE http://xcap.home1.net/services/pres-rules/users/user1/ps.xml/~~/ruleset/rule/statement[@id="dsafa43232"] HTTP/1.1

Host: oper.example.com:9999

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:14:17 GMT

6. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.3-6

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to delete an entry from the resource list, the XCAP server sends an XCAP 200 (OK) response.

Table A.8.3-6: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 11:00:47 GMT

Content-Length: 0

7. XCAP GET request (XCAP client to XCAP server) – see example in table A.8.3-7

The XCAP client wishes to check the result of the previous transaction by generating an XCAP GET request.

Table A.8.3-7: XCAP GET request (XCAP client to XCAP server)

GET http://xcap.home1.net/services/pres-rules/users/user1/ps.xml HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 11:13:17 GMT

Content-Length: 0

8. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.3-8

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to fetch the resource list, the XCAP server sends an XCAP 200 (OK) response to the XCAP client including the authorization rules in the body of the response.

Table A.8.3-8: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "eiuuekksks"

Date: Thu, 08 Jan 2004 11:50:35 GMT

Content-Type:application/auth-policy+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"

xmlns:sc="urn:ietf:params:xml:ns:pidf:caps"

xmlns:pr="urn:ietf:params:xml:ns:pres-rules"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:pres-rules">

<rule id="fdsjkf">

<conditions>

<identity>

<id entity="user3_public1@home2.net"/>

</identity>

<conditions>

<actions>

<pr:sub-handling>block</pr:sub-handling>

</actions>

</ruleset>

A.8.4 Storing external content (successful operation)

Figure A.8.4.-1: XCAP client manipulating hard-state presence document on XCAP server

Figure A.8.4-1 shows a XCAP client manipulating hard-state presence document on a XCAP server when the presence document has an aggregated storing MIME object with the "application/pidf+xml" content type and any of its extensions. The details of the signalling flows are as follows:

1. HTTP PUT request (XCAP client to XCAP server) – see example in table A.8.2-1

In order to store the content, the XCAP client generates an HTTP PUT request containing the MIME object in the body of the request. The request-URI points to the directory where the content is stored and shows the name of the file to be created.

Table A.8.4-1: HTTP PUT request (XCAP client to XCAP server)

PUT http://operator.example.com/services/users/bill/pictureX HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:17 GMT

Content-Type: image/jpeg

Content-Length: (…)

{pictureX.jpg}

2. HTTP 201 (Created) response (XCAP server to XCAP client) – see example in table A.8.4-2

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to create a file the HTTP server sends an HTTP 201 (Created) response to the client.

Table A.8.4-2: HTTP 201 (Created) response (XCAP server to XCAP client)

HTTP/1.1 201 Created

Server: Apache/1.3.22 (Unix) mod_perl/1.27Content-Type: text/html

Date: Thu, 08 Jan 2004 10:50:35 GMT

Content-Length: 0

3. XCAP PUT request (XCAP client to XCAP server) – see example in table A.8.2-3

The XCAP client generates an XCAP PUT request in order to store XML encoded presence document which includes a URI reference to the MIME object stored on the XCAP server. The AUID part of the request URI is ‘pidf-manipulation’ as defined in RFC 4827 [34].

Table A.8.4-3: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.example.com/services/pidf-manipulation/users/bill/pidf.xml HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:13:27 GMT

Content-Type: application/pidf+xml

Content-Length: (…)

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"

xmlns:ext="urn:ietf:params:xml:ns:ext-cont"

xmlns:p="urn:ietf.params:xml:ns:pidf:data-model"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:resource-lists"

entity="sip:bill@example.com">

<tuple id="123sd">

<status>

<basic>open</basic>

</status>

<contact>sip:bill@example.com</contact>

</tuple>

<p:person>

<rp:activities><rp:vacation/></rp:activities>

<ext:photo>

         http://operator.example.com/services/users/bill/pictureX.jpg

</ext:photo>

</p:person>

</presence>

4. XCAP 201 (Created) response (XCAP server to XCAP client) – see example in table A.8.4-4

After the XCAP server has performed the necessary authorization checks, XML document validations and XML schema compliancy checks the XCAP server sends an XCAP 201 (Created) response to the XCAP client.

Table A.8.4-4: XCAP 201 (Created) response (XCAP server to XCAP client)

HTTP/1.1 201 Created

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "ccc1"

Date: Thu, 08 Jan 2004 10:50:45 GMT

Content-Length: 0

5. HTTP GET request (XCAP client to XCAP server) – see example in table A.8.4-5

The XCAP client wishes to fetch the MIME object from the XCAP server. The client generates an HTTP GET request. The request URI points to the directory where the object is stored and indicates the name of the file to be fetched.

Table A.8.4-5: HTTP GET request (XCAP client to XCAP server)

GET http://operator.example.com/services/users/bill/pictureX HTTP/1.1

Host: oper.example.com:9999

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 10:43:17 GMT

Accept: image/jpeg

Content-Length: 0

6. HTTP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.4-6

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to fetch the file the XCAP server sends an HTTP 200 (OK) response having the object in the body to the XCAP client.

Table A.8.4-6: HTTP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 11:00:47 GMT

Content-Type: image/jpeg

Content-Length: (…)

{pictureX}

7. HTTP PUT request (XCAP client to XCAP server) – see example in table A.8.4-7

The XCAP client wishes to modify the earlier stored MIME object by replacing the picture X with a new picture X with new content. To modify the object the XCAP client generates an HTTP PUT request using the same request URI as has been used for the modified (old) object. The new object is conveyed in the body of the request.

Table A.8.4-7: HTTP PUT request (XCAP client to XCAP server)

PUT http://operator.example.com/services/users/bill/pictureX HTTP/1.1

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 11:13:17 GMT

Content-Type: image/jpeg

Content-Length: (…)

{pictureX.jpg}

8. HTTP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.4-8

After the XCAP server has performed the necessary authorization checks on the originator to ensure the XCAP client is allowed to replace the existing MIME object with the new one the XCAP server sends an HTTP 200 (OK) response to the XCAP client.

Table A.8.4-8: HTTP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 11:50:35 GMT

Content-Length: 0

9. XCAP PUT request (XCAP client to XCAP server) – see example in table A.8.4-9

The XCAP client wishes to remove the MIME object from his presence information. The XCAP client generates an XCAP PUT request to modify the XML encoded presence document to remove the reference to the MIME object from the presence document. The request URI contains a node selector to the requested tuple according to RFC 4825 [33].

Table A.8.4-9: XCAP PUT request (XCAP client to XCAP server)

PUT http://xcap.example.com/services/pidf-manipulation/users/bill/pidf.xml/~~/presence/person HTTP/1.1

Date: Thu, 08 Jan 2004 11:13:37 GMT

If-Match: "ccc1"

Content-Type: application/xcap-el

Content-Length: (…)

<p:person>

<rp:activities><rp:vacation/></rp:activities>

</ p:person>

10. XCAP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.4-10

After the XCAP server has performed the necessary authorization checks, XML document validations and XML Schema compliancy checks the XCAP server sends an XCAP 200 (OK) response to the XCAP client.

Table A.8.4-10: XCAP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Etag: "ccc2"

Date: Thu, 08 Jan 2004 11:50:59 GMT

Content-Length: 0

11. HTTP DELETE request (XCAP client to XCAP server) – see example in table A.8.4-11

The XCAP client removes the MIME object from the XCAP server by generating an HTTP DELETE request.

Table A.8.4-11: HTTP DELETE request (XCAP client to XCAP server)

DELETE http://operator.example.com/services/users/bill/pictureX HTTP/1.1

Host: oper.example.com:9999

User-Agent: IMS subscriber

Date: Thu, 08 Jan 2004 11:52:00 GMT

12. HTTP 200 (OK) response (XCAP server to XCAP client) – see example in table A.8.4-12

After the XCAP server has performed the necessary authorization checks on the originator to ensure that the XCAP client is allowed to delete the object, the XCAP server sends an HTTP 200 (OK) response to the XCAP client.

Table A.8.4-12: HTTP 200 (OK) response (XCAP server to XCAP client)

HTTP/1.1 200 OK

Server: Apache/1.3.22 (Unix) mod_perl/1.27

Date: Thu, 08 Jan 2004 11:52:35 GMT

Content-Length: 0

Annex B (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2003-06

Version 0.0.1: Preliminary discussion with editor

2003-06

Version 0.0.2: Results of preliminary discussion with interested parties

2003-08

CN1#31

N1-031176

Version 0.0.3: Revised as a result of conference call and email discussion with interested parties

2003-08

CN1#31

N1-031324

Version 0.0.4: Revised as a result of offline discussions at CN1#31

2003-09

CN1#31

N1-031365

Version 0.1.0: Revised to included allocated TS number and title as amended by MCC.

2003-11

CN1#32

N1-03aaaa

Version 0.2.0: Revised to include agreements made in N1-031366.

2004-05

CN1#34

NP-04xxxx

Version 0.3.0. Revised to include agreements made in N1-040765, N1-040794, N1-040795, N1-040866, N1-040939, N1-040945, N1-040946, N1-040997, N1-040998, N1-040999, N1-041002, N1-041006, N1-041008, N1-041092, N1-041093.

2004-05

CN1#34

NP-040200

Version 2.0.0 identical to version 0.3.0 for presentation for approval to plenary.

2004-06

CN#24

NP-040200

Approved by the plenary.

2.0.0

6.0.0

2004-09

CN#25

NP-040426

3

2

Editorial issues

6.0.0

6.1.0

2004-09

CN#25

NP-040380

4

1

Watcher cleanup and alignment with PUA

6.0.0

6.1.0

2004-09

CN#25

NP-040380

5

3

PUA clause restructuring

6.0.0

6.1.0

2004-09

CN#25

NP-040427

6

2

GAA impacts

6.0.0

6.1.0

2004-09

CN#25

NP-040380

7

1

XCAP roles

6.0.0

6.1.0

2004-09

CN#25

NP-040380

8

1

XCAP Change

6.0.0

6.1.0

2004-09

CN#25

NP-040380

9

Policy Capability References

6.0.0

6.1.0

2004-09

CN#25

NP-040380

11

Filter criteria update

6.0.0

6.1.0

2004-09

CN#25

NP-040380

14

1

Enhanced partial publication description

6.0.0

6.1.0

2004-09

CN#25

NP-040380

15

1

Publication Rate Limiting

6.0.0

6.1.0

2004-09

CN#25

NP-040380

17

1

Correction to processing PUBLISH with the "multipart/related" content type

6.0.0

6.1.0

2004-09

CN#25

NP-040380

18

XML document corrections of message flows

6.0.0

6.1.0

2004-12

CN#26

NP-040503

19

1

Clarifications to Ut

6.1.0

6.2.0

2004-12

CN#26

NP-040503

20

Alignment between PUA and watcher for draft-ietf-geopriv-pidf-lo-01

6.1.0

6.2.0

2004-12

CN#26

NP-040599

21

2

Introduction of XCAP client and XCAP server

6.1.0

6.2.0

2004-12

CN#26

NP-040503

22

1

Correction XCAP change flow

6.1.0

6.2.0

2004-12

CN#26

NP-040503

23

Delete Authentication Proxy Requirements

6.1.0

6.2.0

2004-12

CN#26

NP-040503

24

1

Aligning Presence data model with IETF

6.1.0

6.2.0

2004-12

CN#26

NP-040503

25

1

IETF reference update (SIP specific parts)

6.1.0

6.2.0

2004-12

CN#26

NP-040503

26

1

IETF reference update (XCAP)

6.1.0

6.2.0

2004-12

CN#26

NP-040503

27

1

Updates to Partial publication

6.1.0

6.2.0

2004-12

CN#26

NP-040503

28

1

Correction to Watcher Information message flow

6.1.0

6.2.0

2004-12

CN#26

NP-040503

30

1

Preventing loop in RLS subscriptions

6.1.0

6.2.0

2004-12

CN#26

NP-040503

32

Filter criteria update

6.1.0

6.2.0

2005-03

CN#27

NP-050073

34

1

Resolution of references to 24.228

6.2.0

6.3.0

2005-03

CN#27

NP-050078

35

Authentication proxy for presence

6.2.0

6.3.0

2005-03

CN#27

NP-050078

37

XCAP-change clarrification

6.2.0

6.3.0

2005-03

CN#27

NP-050078

38

XCAP-change correction

6.2.0

6.3.0

2005-03

CN#27

NP-050078

39

IFC corrections

6.2.0

6.3.0

2005-06

CP#28

CP-050063

41

 

SPI to SPT

6.3.0

6.4.0

2005-06

CP#28

CP-050063

43

 

Reference update: event-list

6.3.0

6.4.0

2005-06

CP#28

CP-050063

44

 

Reference update: filter

6.3.0

6.4.0

2005-06

CP#28

CP-050063

45

 

Reference update: xcap

6.3.0

6.4.0

2005-06

CP#28

CP-050063

46

 

Reference update: xcap-list-usage

6.3.0

6.4.0

2005-06

CP#28

CP-050063

47

 

Reference update: policy

6.3.0

6.4.0

2005-06

CP#28

CP-050063

48

 

Reference update: config-framework

6.3.0

6.4.0

2005-06

CP#28

CP-050063

40

1

Editorial corrections

6.3.0

6.4.0

2005-06

CP#28

CP-050063

42

1

xcap-change substitution

6.3.0

6.4.0

2005-09

CP#29

CP-050441

050

3

Data model changes

6.4.0

6.5.0

2005-09

CP#29

CP-050441

051

2

XCAP changes

6.4.0

6.5.0

2005-07

CP-30

Version 7.0.0 created by MCC due to TISPAN references

6.5.0

7.0.0

2006-03

CP-31

CP-060163

053

2

Clarifications to text on presence information

7.0.0

7.1.0

2006-03

CP-31

CP-060109

054

1

Miscellanous Text Changes

7.0.0

7.1.0

2006-03

CP-31

CP-060109

055

1

Reference Change

7.0.0

7.1.0

2006-03

CP-31

CP-060109

056

1

Replace UA-Profile instead of SIP-profile

7.0.0

7.1.0

2006-09

CP-33

CP-060456

063

1

Removal of Editor’s notes in 24.141

7.1.0

7.2.0

2006-11

CP-34

CP-060656

065

draft-ietf-simple-event-list reference update

7.2.0

7.3.0

2006-11

CP-34

CP-060656

067

draft-ietf-sip-content-indirect-mech reference update

7.2.0

7.3.0

2006-11

CP-34

CP-060656

069

draft-ietf-geopriv-pidf-lo reference update

7.2.0

7.3.0

2006-11

CP-34

CP-060656

071

draft-ietf-simple-filter-funct and draft-ietf-simple-filter-format reference update

7.2.0

7.3.0

2006-11

CP-34

CP-060656

073

draft-ietf-simple-presence-data-model, draft-ietf-simple-rpid and draft-ietf-simple-cipid reference update

7.2.0

7.3.0

2006-11

CP-34

CP-060656

075

1

Resolution of editor’s notes relating to draft-rosenberg-simple-presence-processing-model

7.2.0

7.3.0

2006-11

CP-34

CP-060670

078

1

User location query when UE watcher subscribes to presentity presentity

7.2.0

7.3.0

2006-11

CP-34

CP-060670

079

1

User location query when watcher subscribes to resource list

7.2.0

7.3.0

2006-11

CP-34

CP-060670

080

1

User location query when resource list subscribes to presentity

7.2.0

7.3.0

2006-11

CP-34

CP-060670

081

1

User location query when network watcher subscribes to presentity

7.2.0

7.3.0

2007-09

CP-37

CP-070581

086

1

IETF reference updates

7.3.0

7.4.0

2008-03

CP-39

CP-080140

088

3

Network presence

7.4.0

8.0.0

2008-06

CP-40

CP-080348

091

Revision of references to documents from IETF

8.0.0

8.1.0

2008-06

CP-40

087

7

Security mechanisms for presence

8.0.0

8.1.0

2008-09

CP-41

CP-080539

094

1

Removal of redundant references

8.1.0

8.2.0

2008-12

CP-42

CP-080861

099

IETF SIMPLE reference updates

8.2.0

8.3.0

2009-12

CP-46

CP-090891

0102

1

Change of ua-profile package to xcap-diff package

8.3.0

8.4.0

2009-12

CP-46

Upgrade to Rel-9

8.4.0

9.0.0

2010-06

CP-48

CP-100336

0106

4

Remove reference to policy capability internet drafts

9.0.0

9.1.0

2010-12

CP-50

CP-100722

0114

IETF reference updates

9.1.0

9.2.0

2011-03

CP-51

Upgrade to Rel-10

9.2.0

10.0.0

2012-09

CP-57

Upgrade to Rel-11

10.0.0

11.0.0

2013-09

CP-61

CP-130513

0115

1

Updating Presence to RFC 6665

11.0.0

12.0.0

2013-12

CP-62

CP-130770

0116

1

Correction of some editorial errors

12.0.0

12.1.0

2013-12

CP-62

CP-130770

0117

1

Correcting RFC 6665 title

12.0.0

12.1.0

2015-06

CP-68

CP-150328

0118

Aligning TLS profiles used by CT1 specifications with SA3 agreed TLS profile

12.1.0

13.0.0

Change history

Date

Meeting

TDoc

CR

Rev

Cat

Subject/Comment

New version

2017-03

CT75

Upgrade to Rel-14

14.0.0

2018-06

SA80

Update to Rel-15 version (MCC)

15.0.0

2020-07

SA-88e

Update to Rel-16 version (MCC)

16.0.0

2021-12

CT#94e

CP-213031

0119

B

Update of HTTP Digest Access Authentication and reference update for HTTP/1.1 protocol

17.0.0