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 |
|