idnits 2.17.00 (12 Aug 2021) /tmp/idnits3381/draft-stucker-sipping-publish-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 13 instances of lines with control characters in the document. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 243: '...individual event packages, and MUST be...' RFC 2119 keyword, line 265: '...event packages, and MUST be registered...' RFC 2119 keyword, line 327: '...for that domain. The requestURI MAY be...' RFC 2119 keyword, line 335: '... service MUST define and register ...' RFC 2119 keyword, line 341: '... message MUST inspect the contents...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 221 has weird spacing: '... where proxy...' == Line 305 has weird spacing: '...foo.com pro...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Statefulness for the GET action is defined to be both soft-stated and hard-stated. Requests with a GET action are considered hard-stated, but responses MAY or MAY NOT contain an Expires header depending on the statefullness of the data retrieved. If the data retrieved is hard-stated, an Expires header should not be included in the response. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 7311 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 999, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1017, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2068 (ref. '3') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: draft-ietf-simple-presence has been published as RFC 3856 -- Duplicate reference: RFC2543, mentioned in '7', was also mentioned in '1'. ** Obsolete normative reference: RFC 2543 (ref. '7') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Brian Stucker 2 Internet Draft Nortel Networks, Inc. 3 Category: Standards Track November 2001 4 Expires May 2002 5 7 SIP-Specific Network Service Publishing 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or cite them other than as "work in 23 progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document describes an extension to the Session Initiation 37 Protocol (SIP). The purpose of this extension is to create a means 38 for publishing and retrieving information regarding services in the 39 network by using SIP. 41 The methods described in this document allow a framework by which 42 arbitrary service data can be transported into the network for 43 use by services running in the network. It is not intended to be 44 a general-purpose mechanism for transport of arbitrary data as 45 there are better suited mechanisms for this purpose (ftp, etc.), 46 but is intended to be a simple, light-weight, mechanism that 47 employs SIP in order to support SIP-related services. It is 48 envisioned that each service that employs this method may 49 extend and provide more detail as to how that service interacts 50 with the mechanisms put forth in this draft. 52 1. Table of Contents 54 2 Introduction ........................................ 2 55 2.1 Overview of Operation................................ 3 56 3. Syntax............................................... 3 57 3.1 New Methods.......................................... 3 58 3.2 New Headers.......................................... 5 59 3.2.1 "Action" Header...................................... 5 60 3.2.2 "Service" Header..................................... 5 61 3.3 The DATA Method...................................... 6 62 3.4 Usage of the Service Header.......................... 7 63 3.5 Usage of the Action Header........................... 8 64 3.5.1 The PUT Action....................................... 8 65 3.5.2 The GET Action....................................... 9 66 3.5.3 The DELETE Action.................................... 9 67 4. Security Considerations.............................. 9 68 4.1 Authentication....................................... 10 69 4.2 Authorization........................................ 10 70 5. Statefulness of Service Data......................... 10 71 5.1 Soft Stated Service Data............................. 11 72 5.2 Hard Stated Service Data............................. 11 73 6. Error Cases.......................................... 11 74 6.1 Authorization or Authentication Failure.............. 11 75 6.2 Service Location Failure............................. 12 76 6.3 Wrong Data Format.................................... 13 77 6.4 Unsupported Action................................... 14 78 7. Extensibility of Actions............................. 14 79 8. Proof of Concept Example - Presence.................. 16 80 8.1 Message Details...................................... 17 81 9. Compatibility with Proxies........................... 23 82 10. Why use SIP?......................................... 23 83 9. References........................................... 25 84 10. Acknowledgements..................................... 25 85 11. Author's Address..................................... 25 87 2. Introduction 89 The ability for a user to push data into the network has already 90 shown its usefulness. In the case of CPL and presence, both 91 require client devices to publish information regarding how 92 services should behave, based on data pushed into the network. 94 However, the mechanism that is used to place data into the network 95 has not been well defined up to this point, and problems exist 96 with the current ad-hoc approach of using the REGISTER method to 97 do so. 99 Therefore, this document describes a new method that creates a 100 framework by which arbitrarty service data can be transported into 101 the network for use by services. An example of this would be 102 CPL scripting documents, or presence documents. It is not intended 103 to be a general-purpose (non-SIP) data transport as there are 104 better suited mechanisms for this purpose (ftp, etc.) 106 Meeting the data publication requirements for the general problem 107 domain of how to transport any given piece of data between two SIP 108 endpoints is not possible. The goal of this draft is to provide a 109 SIP-specific framework that allows simple pieces of client data to 110 be transported into the network for a specific, SIP-related, 111 purpose. An example of such a purpose would be to transport CPL 112 script data into the network for a CPL call routing service to 113 handle SIP intiated calls appropriately. 115 SIP is chosen as the transport protocol because the services that 116 this mechanism applies to are services created by way of using SIP. 117 Where SIP is not the mechanism by which a service is provided, the 118 use of the mechanisms described in this draft should be thought out 119 very carefully. 121 The framework described in this draft does not outline an extension 122 which may be used directly. It is intended to be extensible, again, 123 because the needs of different services whose data may need to be 124 publish can vary. Each data type that intends to use this mechanism 125 is responsible for defining the complete set of rules as to how 126 this mechanism is to behave. This draft simply sets the framework 127 for this to occur. Guidelines and requirements as to how these 128 extensions must behave and requirements about their definition are 129 described in later sections of this draft. 131 2.1. Overview of Operation 133 The concept of this draft is that entities in the network can 134 notify a resource of changes in their configuration data. Whereas 135 the generalized subscribe-notify framework is used to synchronize 136 two finite state machines, synchronization of data across multiple 137 nodes can be viewed as an event notification. Whenever the data 138 changes at one end, it simply notifies the other side of the 139 change. 141 A typical flow of messages to push data to a service would be: 143 Data Source Service 144 |------------DATA-------->| Provide or change service data 145 |<-----------200----------| 147 Data may be hard-stated, and if so, must be refreshed in exactly 148 the same manner as registrations (see RFC 2543 [1] ). 150 3. Syntax 152 This section describes the syntax extensions required for data 153 notification in SIP. Semantics are described in section 4. 155 3.1. New Methods 157 This document describes one new SIP method: "DATA." 159 This table expands on tables 4 and 5 in RFC 2543 [1] . 161 Header Where DATA 162 ------ ----- --- 163 Accept R o 164 Accept-Encoding R o 165 Accept-Language R o 166 Action Rr m 167 Action 400 - 168 Alert-Info g - 169 Allow Rr o 170 Allow 405 m 171 Authentication-Info 2xx o 172 Authorization R o 173 Call-ID c m 174 Call-Info o 175 Header Where DATA 176 ------ ----- --- 177 Contact R m 178 Contact 1xx, 485 o 179 Contact 2xx, 3xx m 180 Content-Disposition o 181 Content-Encoding o 182 Content-Length o 183 Content-Type m 184 CSeq c m 185 Date o 186 Encryption g o 187 Expires g o 188 From c m 189 In-Reply-To R - 190 Max-Forwards R o 191 Organization g o 192 Priority R - 193 Proxy-Authenticate 407 m 194 Proxy-Authorization R o 195 Proxy-Require R o 196 Record-Route R o 197 Record-Route 2xx, 481, 484 o 198 Require g o 199 Retry-After 404, 413, 480 o 200 Retry-After 486, 500, 503 o 201 Retry-After 600, 603 o 202 Route R o 203 Server r o 204 Service R m 205 Service r o 206 Subject R o 207 Suppported o 208 Timestamp o 209 To gc(1) m 210 Unsupported 420 o 211 User-Agent o 212 Via c m 213 Warning r o 214 WWW-Authenticate 401 m 216 3.2 New Headers 218 This table expands on tables 4 and 5 in RFC 2543 [1] , as amended 219 by the changes described in section 3.1. 221 Header field where proxy ACK BYE CAN INV OPT REG DAT 222 ----------------------------------------------------------------- 223 Action R - - - - - - m 224 Service g - - - - - - m 226 3.2.1. "Action" header 228 The following header is defined for the purposes of this 229 specification. 231 Action = ( "Action" ) ":" action-type 232 *( "," SP action-type ) 233 action-type = ( "Get" | "Put" | "Delete" ) 234 *("." action-subtype ) 235 action-subtype = token-nodot 236 token-nodot = 1*( alphanum | "-" | "!" | "%" | "*" 237 | "_" | "+" | "`" | "'" | "~" ) 239 Action is added to the definition of the element "request-header" 240 in the SIP message grammar. 242 This document does not define values for action-subtypes. These 243 values will be defined by individual event packages, and MUST be 244 registered with the IANA. 246 There must be exactly one action type listed per action header. 247 Multiple actions per message are disallowed except in error 248 responses where the supported actions are listed. 250 3.2.2. "Service" header 252 The following header is defined for the purposes of this 253 specification. 255 Service = ( "Service" ) ":" service-tag 256 *( "," SP service-tag ) 257 service-tag = token-nodot 258 token-nodot = 1*( alphanum | "-" | "!" | "%" | "*" 259 | "_" | "+" | "`" | "'" | "~" ) 261 Service is added to the definition of the element "general-header" 262 in the SIP message grammar. 264 This document does not define values for service. These values will 265 be defined by individual event packages, and MUST be registered 266 with the IANA. 268 There must be exactly one service type listed per action header. 269 Multiple services per message are disallowed except in error 270 responses where the supported services are listed. 272 3.3. The DATA method 274 The DATA method is used to provide a mechanism for publishing data 275 into the network. This is done on a domain basis, and follows the 276 formatting, and routing rules used for the REGISTER method. 278 When the DATA method is routed to the server responsible for the 279 domain listed in the requestURI, that server checks the Service 280 header, and may modify the requestURI so that the message is 281 then forwarded to the correct machine for that service, or may 282 process the message immediately instead. 284 Example: 286 DATA foo.com SIP/2.0 287 Via: SIP/2.0/UDP pc.foo.com 288 To: sip:A@foo.com 289 From: sip:A@foo.com;tag=123 290 Service: cpl 291 Action: put 292 Call-ID: 9876@pc.foo.com 293 CSeq: 1288 DATA 294 Contact: sip:B@pc.foo.com 295 Content-Type: application/cpl+xml 296 Content-Length: ... 298 299 300 301 302 303 304 305 A@foo.com proxy bar.com proxy foo.com registrar foo.com 306 |----DATA----->| | | 307 | |------DATA------>| | 308 | | |------DATA----->| 309 | | |<-----200-------| 310 | |<-----200--------| | 311 |<---200-------| | | 313 In the example shown above, since the "bar.com" proxy was not the 314 definitive controller for "foo.com" the DATA message was forwarded 315 (just like a REGISTER would be). However, once the DATA message 316 hit the proxy at "foo.com" the proxy there was the definitive 317 controller for "foo.com", but forwarded the message anyhow. This is 318 allowed because that proxy may not have had the registrar, where 319 "foo.com" handles cpl information co-located. Therefore the proxy 320 was able to forward the DATA message on to the server that was 321 handling the cpl service for "foo.com". This is allowed. 323 Once a DATA message gets to a server within the domain listed in 324 the requestURI, one additional forwarding of the message is allowed 325 in order to route to a server handling the service described in the 326 Service header to cover the case that the service is not co-located 327 with the inbound server for that domain. The requestURI MAY be 328 changed in order to facilitate this routing, but only by a server 329 in the domain that was listed in the original DATA message. 331 3.4 Usage of the Service Header 333 The Service header in the DATA message is used to denote the 334 service for which the data being acted upon resides within. Each 335 service MUST define and register with IANA it's own service tag 336 to be placed in this header. Service tags used in this document 337 are for example only, and have not necessarily been registered 338 with IANA. 340 Servers within the domain listed in the request URI of the DATA 341 message MUST inspect the contents of this header to see if the 342 service specified is hosted on that machine. If it is not, the 343 DATA message may be forwarded (within the same domain) in order 344 to reach the correct service hosting the service specified. 346 Authors registering new service tags SHOULD pick service tags 347 that as closely mimic the MIME type value for their data where 348 the MIME type is unambiguous to the service the data is for. 350 For instance, if your service's data MIME type is 351 application/voicemail+xml, a good basis for a service tag 352 would be "voicemail" since it forms an identifiable portion of 353 the MIME type header. If the service in question reuses a 354 generic MIME type, the service tag should be descriptive of 355 the service, and not the MIME type. You should always be 356 able to look at the service tag and easily figure out what 357 service it refers to. 359 3.5 Usage of the Action Header 361 The Action header in the DATA message is used to denote what 362 the service should do, at a minimum, upon receiving the DATA 363 message. Three default values are defined, of which the actual 364 operation of each is dependent on the particular service. 366 Actions may be sub-typed as well, so that a service can 367 define a sub-action called "put.merge" in order to have the 368 data merged via rules specific to that service instead of simply 369 overwritten by use of the "put" action. It is up to each service 370 to decide how the data will be processed according to the action 371 specified, including the operation of the three defaul values 372 specified in this draft. 374 3.5.1 The PUT Action 376 The PUT action is used to associate the resource identified 377 within the message body of the DATA message with the TO party 378 and service specified in the DATA message. It is modeled on the 379 HTTP/1.1 PUT method, and acts as such. Services, generally, will 380 take the data in the message body and apply it to the user 381 identified in the TO header (similar to a REGISTER message) for 382 the service specified in the Service header. 384 The result of this operation is denoted by the response to the 385 DATA message, where 200 OK always denotes that the operation 386 requested succeeeded. Other return values may include a warning 387 header or explaination in the reason code as to why the operation 388 failed. 4xx, 5xx, and 6xx return codes should always denote 389 failure of the operation requested. 391 Using a DATA (PUT) message that contains no message body MUST NOT 392 be used in lieu of sending a DATA (DELETE) message, as this can 393 cause information used to filter the data to be deleted to be 394 confused with information to be stored for the resource identified 395 in the DATA message. 397 3.5.2 The GET Action 399 The GET action is used to retrieve the data for the resource 400 identified within the message body of the DATA message with the 401 TO party and service specified in the DATA message. It is modeled 402 on the HTTP/1.1 GET method, and acts as such. The message body of 403 the DATA (GET) message may contain information used to filter 404 which service data is to be returned. For example, a service 405 may define message body elements to denote which version of a 406 piece of service data is to be returned by sending a last-modified 407 timestamp. Normally, the message body of a DATA (GET) message is 408 expected to be empty, however. 410 The result of this operation is denoted by the response to the 411 DATA message, where 200 OK always denotes that the operation 412 requested succeeded. The data requested is returned in the message 413 body of the response to the DATA (GET) request, and absence of data 414 does not imply that the request failed. The value of the response 415 code should always be used to determine success or failure of the 416 get action. 4xx, 5xx, and 6xx return codes should always denote 417 failure of the operation requested (even if data is present in the 418 message body of these responses). 420 3.5.3 The DELETE Action 422 The DELETE action is used to delete the data for the resource 423 identified within the message body of the DATA message with the 424 TO party and service specified in the DATA message. It is modeled 425 on the HTTP/1.1 DELETE method, and acts as such. The message body 426 of the DATA (DELETE) message may contain information used to filter 427 which service data is to be deleted, and MUST NOT be ambiguous. For 428 example, a service may define message body elements to denote which 429 portions of the service data is to be deleted by using a timestamp 430 to delete information before the date noted. 432 The result of this operation is denoted by the response to the 433 DATA message, where 200 OK always denotes that the operation 434 request succeeded. An indication of what data was deleted MAY be 435 included in the message body of the response, if so desired by the 436 service. The value of the response code should always be used to 437 determine success or failure of the delete action. 4xx, 5xx, and 438 6xx return codes should always denote failure of the operation 439 requested (even if data is present in the message body of these 440 responses). 442 4. Security Considerations 443 4.1 Authentication 445 Since the data contained in a DATA message can be potentially 446 sensitive in nature, it is STRONGLY RECOMMENDED that all DATA 447 messages be authenticated as to their source. Additionally, it is 448 RECOMMENDED that they be encrypted. The extent to which SIP is 449 used is up to the implementor as various transport protocols 450 (such as TLS) can mitigate the need to add additional protection 451 using SIP. However, SIP authentication SHOULD be part of any 452 authentication scheme for service data since the service data is 453 part of the SIP service space. Usage of HTTP Basic authentication 454 is NOT RECOMMENDED. 456 4.2 Authorization 458 In order to support third-party service data (much like third-party 459 registrations), the content of the TO header identifies the 460 resource that the data in the message body (or action) is to be 461 applied. In the case where TO and the FROM headers describe 462 different parties, the FROM party must be authorized prior to the 463 sending of the DATA message to take action on the TO party's 464 service data. The means by which this authorization takes place 465 is outside the scope of this document. 467 If the network wishes to conceal whether or not an update to the 468 service data has succeeded or not, when a third-party is involved, 469 it may send back a 200 response to the request, even though the 470 request has failed. It should be stressed however, that such 471 operation should be used sparingly, and only in scenarios where 472 notifying the third party that the request failed would reveal 473 information that could be used in an attack on the network or 474 TO party of the request. This follows the third-party registration 475 model already in SIP [1]. 477 5. Statefulness of Service Data 479 Service data may be soft-stated (expires after a specified period 480 of time) or hard-stated (does not expire until modified 481 explicitly). In order to support both models of statefulness, the 482 presence or absence of an Expires header in the DATA message is 483 utilized. 485 Mixed statefulness of data for the same service in the same 486 request is undefined. If a service contains information that is 487 both hard-stated and soft-stated, requests and responses must 488 be crafted such that information can be kept separate unless 489 such statefulness is identifiable within the message body itself. 491 5.1 Soft-Stated Service Data 493 Soft-stated service data is denoted by inclusion of an Expires 494 header specifying the interval of time the data is to be considered 495 valid. If an Expires value is set in the DATA request, it MUST be 496 included in the response. The expires interval in the request may 497 decreased by the service provider. The actual interval that the 498 service data will be valid for MUST BE INCLUDED in the response. 500 Requests including an Expires header MUST NOT request an interval 501 smaller than 60 seconds for the data to be valid. 503 An Expires header MUST NOT be included in a request containing 504 a GET or DELETE action (or an sub-typed action derived from these 505 actions). Responses to a GET MAY contain an Expires header to show 506 the remaining amount of time soft-stated service data may be 507 valid for. Responses to a DELETE action MUST NOT contain an Expires 508 header. 510 5.2 Hard-Stated Service Data 512 Hard-stated service data is denoted by NOT including an Expires 513 header in the request. Service data contained in such requests 514 SHOULD remain valid until replaced or removed. Responses to 515 requests containing hard-stated data should likewise not contain 516 an Expires header. 518 Statefulness for the DELETE action is defined to be hard-stated 519 since completion of the action removes any material that could 520 be soft-stated. Responses to a DELETE action should therefore 521 always be considered hard-stated, and not contain an Expires 522 header. 524 Statefulness for the GET action is defined to be both soft-stated 525 and hard-stated. Requests with a GET action are considered hard- 526 stated, but responses MAY or MAY NOT contain an Expires header 527 depending on the statefullness of the data retrieved. If the 528 data retrieved is hard-stated, an Expires header should not 529 be included in the response. 531 6. Error Cases 533 6.1 Authorization or Authentication Failure 535 Errors arising from authorization or authentication failures should 536 be handled according to the rules for the REGISTER method defined 537 within SIP. 539 6.2 Service Location Failure 541 In the case that a service is not located, it is possible to return 542 the known set of services that are supported for data publication 543 in the response. This is done by including the list in the 544 Service header returned in the response to the request. The response 545 MUST NOT contain the Action header. 547 Example: 549 DATA foo.com SIP/2.0 550 Via: SIP/2.0/UDP pc.foo.com 551 To: sip:A@foo.com 552 From: sip:A@foo.com;tag=123 553 Service: cpl 554 Action: put 555 Call-ID: 9876@pc.foo.com 556 CSeq: 1288 DATA 557 Contact: sip:B@pc.foo.com 558 Content-Type: application/cpl+xml 559 Content-Length: ... 561 562 563 564 565 566 567 569 SIP/2.0 400 Service Not Supported 570 Via: SIP/2.0/UDP pc.foo.com 571 To: sip:A@foo.com 572 From: sip:A@foo.com;tag=123 573 Service: presence, voicemail 574 Call-ID: 9876@pc.foo.com 575 CSeq: 1288 DATA 576 Contact: sip:B@pc.foo.com 577 Content-Length: 0 579 6.3 Wrong Data Format 581 If the service is known, but the data supplied is not formatted 582 according to the requirements of that service, an error response 583 SHOULD be generated for the request using a 415 Unsupported Media 584 Type, identifying the accepted formats using the Accept, Accept- 585 Encoding, and Accept-Language headers. 587 Example: 589 DATA foo.com SIP/2.0 590 Via: SIP/2.0/UDP pc.foo.com 591 To: sip:A@foo.com 592 From: sip:A@foo.com;tag=123 593 Service: presence 594 Action: put 595 Call-ID: 9876@pc.foo.com 596 CSeq: 1288 DATA 597 Contact: sip:B@pc.foo.com 598 Content-Type: application/cpl+xml 599 Content-Length: ... 601 602 603 604 605 606 607 609 SIP/2.0 415 Unsupported Media Type 610 Via: SIP/2.0/UDP pc.foo.com 611 To: sip:A@foo.com 612 From: sip:A@foo.com;tag=123 613 Service: presence 614 Action: put 615 Call-ID: 9876@pc.foo.com 616 CSeq: 1288 DATA 617 Contact: sip:B@pc.foo.com 618 Content-Length: 0 619 Accept: application/cpim+pidf 621 6.4 Unsupported Action 623 If the service identified does not support the requested action, an 624 error SHOULD be generated. In this case a 400 response is used to 625 denote a failure in the syntax of the request. Since the Action is 626 the incorrect header, the Service header MUST NOT be included. This 627 is done in order to make it clear which header was in error. 629 Example: 631 DATA foo.com SIP/2.0 632 Via: SIP/2.0/UDP pc.foo.com 633 To: sip:A@foo.com 634 From: sip:A@foo.com;tag=123 635 Service: cpl 636 Action: put.merge 637 Call-ID: 9876@pc.foo.com 638 CSeq: 1288 DATA 639 Contact: sip:B@pc.foo.com 640 Content-Type: application/cpl+xml 641 Content-Length: ... 643 644 645 646 647 648 649 651 SIP/2.0 400 Unsupported Action 652 Via: SIP/2.0/UDP pc.foo.com 653 To: sip:A@foo.com 654 From: sip:A@foo.com;tag=123 655 Action: put, get, delete 656 Call-ID: 9876@pc.foo.com 657 CSeq: 1288 DATA 658 Contact: sip:B@pc.foo.com 659 Content-Length: 0 661 7. Extensibility of Actions 663 Services may extend the basic action values of PUT, GET, and 664 DELETE for their purposes. Extending these should be done only 665 when specifying the correct action to take would be difficult 666 using the contents of the message body. 668 Such extensions are denoted by a ".extension". For instance, if 669 an append action were desired for a service data operation, 670 the extended action would be "put.append", etc. 672 Extensions should not violate the basic operation of the base 673 action. For instance, "delete.append" would not be considered 674 a valid extension because to append is to add, which is counter 675 to the base action "delete" which is to remove. 677 Extensions must be defined explicitly for each of the basic 678 actions. Defining a sub-action type for one action does not 679 define it for all other action types. This may result in 680 simply stating that the sub-action type is not defined for 681 a given basic action. 683 Example: 685 In order to define the append sub-action, you might state: 687 put.append - Appends data onto the bottom of the already 688 existing service data. 690 get.append - Unsupported. 692 delete.append - Unsupported. 694 Example: 696 In orde to define that actions should take into account 697 the Date header of the request, you might state: 699 put.date - Overwrites service data older than the date 700 specified in the request. 702 get.date - Retrieves service data newer than the date 703 specified in the request. 705 delete.date - Deletes service data older than the date 706 specified in the request. 708 Note, that any such sub-actions would need to be registered with 709 IANA to ensure that the namespace for the action header is 710 coordinated. This would be done as part of defining a service 711 specific publication package based on this draft. 713 8. Proof of Concept Example - Presence 715 In order to provide a proof of concept example to help illustrate 716 how the DATA method would work with a real-world application, the 717 following section gives an example of how DATA could be used to 718 publish presence documents according to the framework of the 719 SIMPLE draft. The exact rules of how the presence service would 720 handle each of the actions for DATA would need to be further 721 specified in a separate draft. Depending on those rules, and 722 policy uploaded by the user, the actual messaging outcomes may 723 vary from what is put forth here. This section is for 724 demonstration only. 726 Presence 727 Watcher Server PUA 728 | SUBSCRIBE | | 729 |------------------>| | 730 | 200 OK | | 731 |<------------------| | 732 | NOTIFY | | 733 |<------------------| | 734 | 200 OK | | 735 |------------------>| | 736 | | | 737 | | F1 DATA | 738 | |<-------------------| 739 | | F2 200 OK | 740 | |------------------->| 741 | F3 NOTIFY | | 742 |<------------------| | 743 | F4 200 OK | | 744 |------------------>| F5 DATA | 745 | |<-------------------| 746 | | F6 200 OK | 747 | |------------------->| 748 | F7 NOTIFY | | 749 |<------------------| | 750 | F8 200 OK | | 751 |------------------>| | 752 | | F9 REGISTER | 753 | |<-------------------| 754 | | F10 200 OK | 755 | |------------------->| 756 | F11 NOTIFY | | 757 |<------------------| | 758 | F12 200 OK | | 759 |------------------>| | 761 8.1 Message Details 763 F1 DATA PUA->presence server 765 DATA sip:example.com SIP/2.0 766 Via: SIP/2.0/UDP pua.example.com:5060 767 To: 768 From: ;tag=1234 769 Call-ID: 9876@pua.example.com 770 CSeq: 1 DATA 771 Service: presence 772 Action: put 773 Accept: application/cpim-pidf+xml 774 Contact: 776 777 778 779 open 780 available 782 783 im:userA@pua.example.com 784 785 787 F2 200 OK presence server->PUA 789 SIP/2.0 200 OK 790 Via: SIP/2.0/UDP pua.example.com:5060 791 To: ;tag=abcd 792 From: ;tag=1234 793 Call-ID: 9876@pua.example.com 794 CSeq: 1 DATA 795 Contact: sip:example.com 797 F3 NOTIFY presence server-> watcher 799 NOTIFY sip:userB@watcherhost.example.com SIP/2.0 800 Via: SIP/2.0/UDP presence.example.com:5060 801 From: ;tag=ffd2 802 To: ;tag=xfg9 803 Call-ID: 192837@presence.example.com 804 CSeq: 1 NOTIFY 805 Event: presence 806 Content-Type: application/cpim-pidf+xml 807 Content-Length: .. 809 810 811 812 open 813 available 815 816 im:userA@pua.example.com 817 818 820 F4 200 OK 822 Via: SIP/2.0/UDP presence.example.com:5060 823 From: ;tag=ffd2 824 To: ;tag=xfg9 825 Call-ID: 192837@presence.example.com 826 CSeq: 1 NOTIFY 828 F5 DATA PUA->presence server 830 DATA sip:example.com SIP/2.0 831 Via: SIP/2.0/UDP pua.example.com:5060 832 To: 833 From: ;tag=1234 834 Call-ID: 9876@pua.example.com 835 CSeq: 2 DATA 836 Service: presence 837 Action: delete 838 Accept: application/cpim-pidf+xml 839 Contact: 841 842 843 844 open 845 846 847 849 F6 200 OK presence server->PUA 851 SIP/2.0 200 OK 852 Via: SIP/2.0/UDP pua.example.com:5060 853 To: ;tag=abcd 854 From: ;tag=1234 855 Call-ID: 9876@pua.example.com 856 CSeq: 2 DATA 857 Contact: sip:example.com 859 F7 NOTIFY presence server-> watcher 861 NOTIFY sip:userB@watcherhost.example.com SIP/2.0 862 Via: SIP/2.0/UDP presence.example.com:5060 863 From: ;tag=ffd2 864 To: ;tag=xfg9 865 Call-ID: 192837@presence.example.com 866 CSeq: 2 NOTIFY 867 Event: presence 868 Content-Type: application/cpim-pidf+xml 869 Content-Length: .. 871 872 873 874 open 875 876 im:userA@example.com 877 878 880 F8 200 OK 882 Via: SIP/2.0/UDP presence.example.com:5060 883 From: ;tag=ffd2 884 To: ;tag=xfg9 885 Call-ID: 192837@presence.example.com 886 CSeq: 2 NOTIFY 888 F9 REGISTER PUA->registrar/presence server 890 REGISTER sip:example.com SIP/2.0 891 Via: SIP/2.0/UDP pua.example.com:5060 892 To: 893 From: 894 Call-ID: 234897@pua.example.com 895 CSeq: 2 REGISTER 896 Contact: 897 Expires: 0 899 F10 200 OK registrar/presence server->PUA 901 SIP/2.0 200 OK 902 Via: SIP/2.0/UDP pua.example.com:5060 903 To: 904 From: 905 Call-ID: 234897@pua.example.com 906 CSeq: 2 REGISTER 908 F11 NOTIFY presence server-> watcher 910 NOTIFY sip:userB@watcherhost.example.com SIP/2.0 911 Via: SIP/2.0/UDP presence.example.com:5060 912 From: ;tag=ffd2 913 To: ;tag=xfg9 914 Call-ID: 192837@presence.example.com 915 CSeq: 3 NOTIFY 916 Event: presence 917 Content-Type: application/cpim-pidf+xml 918 Content-Length: .. 920 921 922 923 closed 924 925 im:userA@example.com 926 927 929 F12 200 OK 931 Via: SIP/2.0/UDP presence.example.com:5060 932 From: ;tag=ffd2 933 To: ;tag=xfg9 934 Call-ID: 192837@presence.example.com 935 CSeq: 3 NOTIFY 937 9. Compatibility with Proxies 939 Because the DATA method shares the same routing rules as a REGISTER 940 method message, in general, the routing of a DATA message is 941 compatible with the current (bis-05) routing rules contained in 942 SIP [1]. 944 In particular, a stateless proxy is allowed to inspect the service 945 header in order to determine the next hop the message should take. 946 This is allowed for in SIP. However, should a stateless proxy 947 be the definitive domain controller for a given domain, the DATA 948 message may be forwarded an additional time (if needed), instead 949 of the one-more-hop rule stated earlier. Should the stateless 950 proxy forward to another stateless proxy, an additional hop is 951 again allowed until the DATA message reaches the correct server 952 to process the request, or reaches a stateful proxy server. 954 This follows the routing rules set forth in section 16 of (bis-05) 955 SIP. 957 10. Why use SIP? 959 There are several arguments for using SIP as a mechanism by which 960 to publish generic service information. 962 First, there are already several such mechanisms defined 963 within SIP. The REGISTER method is used to publish contact 964 information for network routing services. It is possible to use 965 SIP quite well, without the use of the REGISTER message; at the 966 cost that there is no network based routing. Thus, in order for 967 network based routing services to work, a mechanism for 968 publishing information into the SIP network must be supported: 969 hence REGISTER. 971 Another well-known method of publishing service data is the 972 SUBSCRIBE-NOTIFY framework. There are a number of event packages 973 including presence, watcherinfo, REFER, and voicemail that have 974 defined message bodies to support the transport of service 975 information via SIP. 977 Finally, SIP itself is designed to be open for service data 978 transport. Nearly any message sent using SIP is allowed to 979 contain a message body. It is the very rare case that the 980 message body MUST be empty, and the content-type header is 981 very rarely excluded from any given method defined for SIP. 983 The common thread here, though, is that data that is transported 984 is *directly related* to the service space created by SIP. This 985 is done, presumably, to make the protocol simpler to understand 986 by limiting the number of transports, and easier to implement 987 (again, by using a common protocol). By inspection of the 988 SIP RFC, and the many drafts and extensions that have been 989 created since, the conclusion, therefore, can be made that 990 using SIP to carry service specific information, for services 991 defined in the SIP space (not any arbitrary service), is 992 appropriate. 994 11. References 996 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 997 Session Initiation Protocol", RFC 2543, IETF; March 1999. 999 [2] A. Roach, "SIP-Specific Event Notification", , IETF; November 2001. Work in 1001 progress. 1003 [3] R. Fielding et. al., "Hypertext Transfer Protocol -- 1004 HTTP/1.1", RFC2068, IETF, January 1997. 1006 [4] S. Donovan, "Requirements for Publication of SIP 1007 Related Service Data", , September 2001. Work in progress. 1010 [5] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of 1011 SIP Extensions", RFC Guidelines, March 2001. 1013 [6] Rosenberg, J., et. al., "SIP Extensions for Presence", 1014 draft-ietf-simple-presence-03.txt, September 2001. 1015 Work in pregress. 1017 [7] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg/ 1018 G. Camarillo/A. Johnston/J. Peterson/R. Sparks/E. Schooler, 1019 "SIP: Session Initiation Protocol", , October 2001. Work in Progress. 1022 12. Acknowledgements 1024 The author wishes to thank Steve Donovan for a thorough 1025 presentation of service data publication requirements, as well 1026 as Jennifer Beckman, Trip Ingle, Alex Nava, Mary Barnes, 1027 and Sriram Parameswar for various guidance and support in 1028 the creation of this draft. 1030 13. Author's Address 1032 Brian Stucker 1033 Nortel Networks, Inc. 1034 2375-B Glenville Rd. 1035 Richardson, TX 75082 1036 USA 1037 Phone: +1 972 685 7724 1038 Fax: +1 972 685 3653 1039 E-Mail: bstucker@nortelnetworks.com