idnits 2.17.1 draft-campbell-pub-bind-reqs-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** 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 135: '...inding mechanism MUST allow a client t...' RFC 2119 keyword, line 137: '.... The mechanism MUST allow for any UR...' RFC 2119 keyword, line 143: '...inding mechanism MUST allow a client t...' RFC 2119 keyword, line 149: '...inding mechanism MUST allow clients to...' RFC 2119 keyword, line 150: '...owledge of an AoR. A client MAY allow...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 114 has weird spacing: '... server and a...' -- 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 2, 2002) is 8027 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) ** Downref: Normative reference to an Informational RFC: RFC 2824 (ref. '2') == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-06 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft dynamicsoft 4 Expires: October 31, 2002 May 2, 2002 6 Requirements for Binding Published Data to SIP Services 7 draft-campbell-pub-bind-reqs-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 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 Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 31, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 A growing number of SIP based services depend on the idea that 39 clients may publish service-related information to network elements. 40 This information may then affect further processing of the service. 41 Examples of such services include presence and CPL. 43 Multiple protocols may exists for the actual publication of such 44 data. But regardless of the protocol, a client must know where to 45 send it. This document describes requirements for a mechanism to 46 inform clients where and how to publish service related information. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Scope of This Document . . . . . . . . . . . . . . . . . . . . 3 52 3. Publication Mechanism Assumptions . . . . . . . . . . . . . . 3 53 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1 Publication URI . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.2 Publication Mechanism . . . . . . . . . . . . . . . . . . . . 4 56 4.3 Address of Record . . . . . . . . . . . . . . . . . . . . . . 4 57 4.4 Enumeration of Services . . . . . . . . . . . . . . . . . . . 4 58 4.5 Lifetime of Publication URIs . . . . . . . . . . . . . . . . . 5 59 4.6 Communication of Publication URIs . . . . . . . . . . . . . . 5 60 4.7 Separate publication points . . . . . . . . . . . . . . . . . 5 61 4.8 Publication URIs that are not easily guessable . . . . . . . . 5 62 4.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 A growing number of SIP [1] related services depend on client 72 publication of some form of service data to network elements. This 73 data is then either distributed as part of the service, or affect the 74 processing of the service in some way. Examples include SIMPLE [3], 75 where a client may publish a presence document to a remote Presence 76 Agent which distributes the document to presence watchers. Another 77 example is the Call Processing Language [2], where users may publish 78 CPL scripts to SIP registrars. 80 The actual mechanisms for such publications are somewhat 81 controversial. There is general agreement in the SIP and SIPPING 82 working groups that the SIP REGISTER method is not adequate to the 83 task. To a lesser degree, there has been agreement that the 84 publication mechanism should not be SIP at all. There is, however, 85 no consensus as to what the publication mechanism should be, or that 86 a single mechanism makes sense in all situations. 88 Regardless of the publication mechanism or mechanisms chosen, clients 89 will require a way to determine where to send such service data, and 90 to bind that data to a particular service element or resource. This 91 is essentially a matter of client configuration, and could 92 conceivably handled through provisioning; however such a provisioning 93 effort would likely become prohibitively complex for large 94 installations. 96 2. Scope of This Document 98 This document discusses requirements for a service data binding 99 mechanism. It does not propose a mechanism for realizing those 100 requirements. 102 It does not attempt to address requirements or mechanism for the 103 actual publication of service data. We make only a few very basic 104 assumptions about such mechanisms. 106 3. Publication Mechanism Assumptions 108 We assume any service data publication mechanism or mechanisms will 109 use a URI based addressing scheme. It is possible that the mechanism 110 will not use URIs natively in its internal addressing scheme, but it 111 will be possible to express such addresses in terms of URIs 112 externally to the mechanism. For example, FTP does not natively use 113 URIs, but there exists an FTP URI scheme that can be used to express 114 the combination of an FTP server and a location in its file system. 116 We assume that more than one publication mechanism will exist, and 117 that a single service may actually use multiple mechanisms. 119 We assume the existence of mechanisms which directly push service 120 data to the publication points, as well as mechanisms where a client 121 tells a service a URI where it can find the service data. (It is 122 interesting to notice that indirect publication is also a type of 123 binding operation and may have requirements similar to those in this 124 document.) 126 4. Requirements 128 This section describes the requirements that are known at the time of 129 this draft. Requirement discussion is still underway in the SIPPING 130 working group. This document attempts to capture the requirements 131 discussed so far. 133 4.1 Publication URI 135 The binding mechanism MUST allow a client to discover or infer a URI, 136 or set of URIs, to which data may be published for a particular 137 service. The mechanism MUST allow for any URI scheme, and MUST NOT 138 make assumptions about how a specific publication mechanism 139 interprets URIs. 141 4.2 Publication Mechanism 143 The binding mechanism MUST allow a client to discover or infer the 144 mechanism, or set of mechanisms, to use to publish data to a 145 particular publication URI. 147 4.3 Address of Record 149 The binding mechanism MUST allow clients to determine binding 150 information based only on knowledge of an AoR. A client MAY allow 151 provisioning of individual service publication bindings for an AoR. 152 The binding mechanism MUST allow for multiple data-driven services 153 for a single AoL, and MUST allow the client to distinguish one such 154 service from another for publication purposes. (For example, the AoR 155 "sip:alice@example.com" may have both presence and CPL services 156 associated with it. A client must be able to avoid sending CPL to 157 the presence service, or a presence document to the CPL services.) 159 4.4 Enumeration of Services 161 The binding mechanism SHOULD offer a way for a client to determine a 162 list of all services for a given AoR for which it can publish data. 164 4.5 Lifetime of Publication URIs 166 The binding mechanism MUST allow a service element to manage the 167 lifetime of a publication URI. It MUST allow long-lived publication 168 URIs. It MAY also allow very short-lived publication URIs; for 169 example, the URI may be single-use only. 171 4.6 Communication of Publication URIs 173 The binding mechanism MUST allow a service provider to communicate 174 publication URIs to a client, directly or through a third party. For 175 example the client might directly query a service element, or query a 176 directory service. The mechanism MAY also provide a method for a 177 client to infer publication URIs from an AoR without directly 178 contacting the service elements, for example by using an algorithmic 179 transformation, schema mapping, or the DNS. 181 4.7 Separate publication points 183 The mechanism MUST NOT require all publication URIs for a given AoR 184 to share the same host, address, or even domain. The mechanism MUST 185 NOT require the publication point for a data-driven service to be 186 colocated with the network element(s) that provide the service 187 itself. 189 4.8 Publication URIs that are not easily guessable 191 The binding mechanism SHOULD allow the use of publication URIs that 192 are not easily guessable. 194 4.9 Security 196 The binding mechanism MUST allow a client to authenticate the source 197 of a publication URI. The mechanism MAY allow a publication URI 198 provider to authenticate clients. The mechanism MUST allow a client 199 to ensure that publication URIs have not been tampered with. 201 5. Security Considerations 203 We make the working assumption that service publication bindings are 204 somewhat public knowledge. This document does not contain strong 205 requirements for confidential transmission of bindings. On the 206 contrary, algorithmic transformations, DNS approaches, etc. could 207 cause such bindings to be completely public. 209 The service data to be published may, on the other hand, be very 210 sensitive. Security of published data is in general an aspect of the 211 publication method, and is out of scope for this document. But it is 212 very important that a client can determine that a publication binding 213 comes from a known source, and has not been tampered with. 214 Otherwise, it would be possible for an attacker to provide a false 215 binding, and trick a client into publishing potentially sensitive 216 data to an unauthorized party. 218 6. Acknowledgements 220 Robert Sparks, Adam Roach, Sean Olson, Henning Schulzrinne, Jonathan 221 Rosenburg, and James Undery all contributed substantially to the 222 discussion about this subject. 224 References 226 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 227 Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), 228 February 2002. 230 [2] Lennox, J. and H. Schulzrinne, "Call Processing Language 231 Framework and Requirements", RFC 2824, May 2000. 233 [3] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for 234 Presence", draft-ietf-simple-presence-06 (work in progress), 235 April 2002. 237 Author's Address 239 Ben Campbell 240 dynamicsoft 241 5100 Tennyson Parkway 242 Suite 1200 243 Plano, TX 75024 245 EMail: bcampbell@dynamicsoft.com 247 Full Copyright Statement 249 Copyright (C) The Internet Society (2002). All Rights Reserved. 251 This document and translations of it may be copied and furnished to 252 others, and derivative works that comment on or otherwise explain it 253 or assist in its implementation may be prepared, copied, published 254 and distributed, in whole or in part, without restriction of any 255 kind, provided that the above copyright notice and this paragraph are 256 included on all such copies and derivative works. However, this 257 document itself may not be modified in any way, such as by removing 258 the copyright notice or references to the Internet Society or other 259 Internet organizations, except as needed for the purpose of 260 developing Internet standards in which case the procedures for 261 copyrights defined in the Internet Standards process must be 262 followed, or as required to translate it into languages other than 263 English. 265 The limited permissions granted above are perpetual and will not be 266 revoked by the Internet Society or its successors or assigns. 268 This document and the information contained herein is provided on an 269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 275 Acknowledgement 277 Funding for the RFC Editor function is currently provided by the 278 Internet Society.