idnits 2.17.1 draft-kaplan-martini-vermouth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 212: '...istration events MAY contain a body. T...' RFC 2119 keyword, line 217: '...stration package MAY be sent without a...' RFC 2119 keyword, line 242: '... course, clients MAY include an Expire...' RFC 2119 keyword, line 255: '...o. All subscribers and notifiers MUST...' RFC 2119 keyword, line 257: '...ubscribe request MAY contain an Accept...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (October 25, 2010) is 4925 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) == Missing Reference: 'RFC3265' is mentioned on line 329, but not defined ** Obsolete undefined reference: RFC 3265 (Obsoleted by RFC 6665) -- Looks like a reference, but probably isn't: '1' on line 277 -- Looks like a reference, but probably isn't: '4' on line 352 -- Looks like a reference, but probably isn't: '5' on line 357 -- Looks like a reference, but probably isn't: '6' on line 358 -- Looks like a reference, but probably isn't: '7' on line 358 == Missing Reference: '5-9' is mentioned on line 580, but not defined == Missing Reference: '0-9' is mentioned on line 580, but not defined == Unused Reference: 'RFC3327' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC4244' is defined on line 532, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARTINI WG H. Kaplan 2 Internet Draft Acme Packet 3 Intended status: Standards-Track 4 Expires: April 25, 2011 October 25, 2010 6 SIP Verification with Event-package 7 for Resolution of Managed Open-ended Username Target Handles 8 (VERMOUTH) 9 draft-kaplan-martini-vermouth-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 25, 2011. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the BSD License. 49 Abstract 51 The Martini Working Group is defining a mechanism for SIP IP-PBX 52 type devices to REGISTER and obtain SIP service for E.164-based 53 Address of Records, using the GIN mechanism defined in [draft-gin]. 54 Two other drafts, [draft-olive] and [draft-glass], propose the same 55 for non-E.164-based AoRs. This document defines a means by which 56 the IP-PBX can verify the resolution entries in the SSP for open- 57 ended or full AoRs of any GIN-based mechanism, using a new Event- 58 Package named "vermouth". 60 Table of Contents 62 1. Introduction..................................................2 63 2. Definitions...................................................3 64 3. The Solution - an Overview....................................4 65 4. Event Package Definition......................................4 66 4.1. Event Package Name.......................................4 67 4.2. Event Package Parameters.................................5 68 4.3. SUBSCRIBE Bodies.........................................5 69 4.4. Subscription Duration....................................5 70 4.5. NOTIFY Bodies............................................6 71 4.6. Notifier Processing of SUBSCRIBE Requests................6 72 4.7. Notifier Generation of NOTIFY Requests...................6 73 4.8. Subscriber Processing of NOTIFY Requests.................7 74 4.9. Handling of Forked Requests..............................7 75 4.10. Rate of Notifications...................................7 76 4.11. State Agents............................................8 77 5. Username Information..........................................8 78 5.1. Structure of Username Information........................8 79 5.2. The "range" Attribute...................................10 80 6. Examples.....................................................11 81 7. IANA Considerations..........................................11 82 8. Security Considerations......................................11 83 9. Normative References.........................................11 84 10. Informative References......................................12 85 Author's Address.................................................12 86 Appendix A - Rationale for Constraining the Expansion Pattern....12 88 1. Introduction 90 In many deployed SIP Service Provider (SSP) architectures, it is 91 common to use REGISTER requests to provide the reachability 92 information for IP-PBXs, instead of DNS-based resolution and 93 routing. An IETF-defined mechanism for doing so is defined in 94 [draft-gin]. Another draft, [draft-olive], uses the [draft-gin] GIN 95 mechanism for Local-Number AoRs as well; and a new draft [draft- 96 glass] does the same for literal alpha-numeric/email-style AoRs. 98 In all cases, the IP-PBX or another SIP entity may wish to learn 99 about all of the AoRs which were implicitly Registered by [draft- 100 gin] or [draft-olive], or to learn about changes in their 101 provisioned AoRs through asynchronous notifications. Even in non- 102 Registration scenarios, where requests for specific AoRs in a SSP 103 may instead be statically routed to an IP-PBX, it may be useful for 104 the IP-PBX to learn what those AoRs are in order to detect 105 mismatches or changes. 107 In theory, the [draft-gin] mechanism is simply a short-hand single 108 REGISTER transaction for a bulk set of AoRs in lieu of multiple, 109 separate REGISTER transactions for each AoR. In practice, however, 110 the E.164 user numbers may be an "open" numbering plan/range, such 111 that the SSP only really knows about a certain number of digits and 112 the rest are only known to the IP-PBX. Likewise, when [draft-olive] 113 is used, the Local-Number may be only partially known to the SSP. 115 Therefore, it is not possible for the SSP to actually provide state 116 information for each possible unique AoR instance. Instead, it 117 needs to provide an indication for the registration state of the 118 prefix or digit portion it does know about. 120 This document proposes to provide such information using a new 121 Event-Package. 123 2. Definitions 125 For brevity's sake, this document uses the word "request" instead of 126 "out-of-dialog request", but in all case means out-of-dialog 127 request. 129 AoR: address-of-record, as defined by RFC 3261: a URI by which the 130 user is canonically known (e.g., on their business cards, in the 131 From header field of their requests, in the To header field of 132 REGISTER requests, etc.). 134 Bulk-AoR: a SIP or SIPS address-of-record with a "range" URI user 135 parameter which expands the user string based on a heuristic. 137 Local-Number: an AoR which follows the form of local-number in 138 [RFC3966], but may be encoded in a SIP or TEL URI. The local-number 139 contains a 'phone-context' parameter identifying the scope of its 140 number. 142 Email-style URI: a SIP AoR which does not identify a global E.164 143 number or Local-Number. 145 Implicit Registration: implicitly providing the reachability 146 information for something other than the AoR explicitly indicated in 147 the Register transaction. 149 Reachability Information: a set of URI's identifying the host and 150 path of Proxies to reach that host; like any URI, these URI's may 151 identify the specific connection transport, IP Address, and port 152 information, or they may only identify FQDN's. 154 SSP: SIP Service Provider, as defined by [RFC5486]. 156 3. The Solution - an Overview 158 The general concept is a SIP device, such as an IP-PBX, Subscribes 159 to a new "vermouth" Event-Package by issuing a SUBSCRIBE request 160 targeted at the SIP URI AoR it explicitly registered using GIN, or 161 some other mutually-agreed-upon SIP-URI if GIN was not used. 163 If the Subscription is successful, the returned NOTIFY contains a 164 userinfo XML document that lists all of the usernames of the AoR's 165 domain that the SSP will route to the IP-PBX. The XML document does 166 not contain the Contact/Path routing reachability information, since 167 that information is already in the reg-event package information for 168 the explicitly registered AoR of the IP-PBX, and may also be more 169 sensitive in nature. 171 To handle the open-numbering-plan problem, an XML "range" attribute 172 is used, which is similar to a regular expression pattern but with a 173 very limited, specified syntax. The limited syntax is used to avoid 174 ambiguities and reduce confusion - rationale for this is provided in 175 Appendix A. 177 Furthermore, this document specifies that the To-URI used for the 178 [draft-gin] REGISTER request, be usable as the target for the 179 SUBSCRIBE request, both for the new 'vermouth' Event-Package, and 180 for Subscribing to the [RFC3680] registration event-package for that 181 explicitly registered AoR. 183 4. Event Package Definition 185 This section fills in the details needed to specify an event package 186 as defined in Section 4.4 of [RFC3265]. 188 4.1. Event Package Name 190 The SIP Events specification requires package definitions to specify 191 the name of their package or template-package. 193 The name of this package is "vermouth". As specified in [RFC3265], 194 this value appears in the Event header present in SUBSCRIBE and 195 NOTIFY requests. 197 4.2. Event Package Parameters 199 The SIP Events specification requires package and template-package 200 definitions to specify any package specific parameters of the Event 201 header that are used by it. 203 No package specific Event header parameters are defined for this 204 event package. 206 4.3. SUBSCRIBE Bodies 208 The SIP Events specification requires package or template-package 209 definitions to define the usage, if any, of bodies in SUBSCRIBE 210 requests. 212 A SUBSCRIBE for registration events MAY contain a body. This body 213 would serve the purpose of filtering the subscription. The 214 definition of such a body is outside the scope of this 215 specification. 217 A SUBSCRIBE for the registration package MAY be sent without a body. 218 This implies that the default registration filtering policy has been 219 requested. The default policy is: 221 o Notifications are generated every time there is any change in 222 the state of any of the registered contacts for the resource being 223 subscribed to. Those notifications only contain information on the 224 contacts whose state has changed. 226 o Notifications triggered from a SUBSCRIBE contain full state (the 227 list of all contacts bound to the address-of-record). 229 Of course, the server can apply any policy it likes to the 230 subscription. 232 4.4. Subscription Duration 234 The SIP Events specification requires package definitions to define 235 a default value for subscription durations, and to discuss 236 reasonable choices for durations when they are explicitly specified. 238 The Event Package defined herein is not tied to registration state, 239 nor to any value that has natural expiry times. Therefore, the 240 suggested subscription duration is 86400 seconds (1 day). 242 Of course, clients MAY include an Expires header in the SUBSCRIBE 243 request asking for a different duration. 245 4.5. NOTIFY Bodies 247 The SIP Events specification requires package definitions to 248 describe the allowed set of body types in NOTIFY requests, and to 249 specify the default value to be used when there is no Accept header 250 in the SUBSCRIBE request. 252 The body of a notification of a change in provisioned usernames 253 contains a user information document. This document describes some 254 or all of the username expansions associated with the particular 255 address-of-record subscribed to. All subscribers and notifiers MUST 256 support the "application/userinfo+xml" format described in Section 257 5. The subscribe request MAY contain an Accept header field. If no 258 such header field is present, it has a default value of 259 "application/userinfo+xml". If the header field is present, it MUST 260 include "application/userinfo+xml", and MAY include any other types 261 capable of representing registration information. 263 Of course, the notifications generated by the server MUST be in one 264 of the formats specified in the Accept header field in the SUBSCRIBE 265 request. 267 4.6. Notifier Processing of SUBSCRIBE Requests 269 The SIP Events framework specifies that packages should define any 270 package-specific processing of SUBSCRIBE requests at a notifier, 271 specifically with regards to authentication and authorization. 273 Provisioned usernames can be sensitive information. Therefore, all 274 subscriptions to it SHOULD be authenticated and authorized before 275 approval. Authentication MAY be performed using any of the 276 techniques available through SIP, including digest, S/MIME, TLS or 277 other transport specific mechanisms [1]. Authorization policy is at 278 the discretion of the administrator, as always. However, a few 279 recommendations can be made. 281 It is RECOMMENDED that an IP-PBX be allowed to subscribe to its own 282 provisioned usernames. Such subscriptions are useful for detecting 283 errors and changes. 285 4.7. Notifier Generation of NOTIFY Requests 287 The SIP Event framework requests that packages specify the 288 conditions under which notifications are sent for that package, and 289 how such notifications are constructed. 291 Instead of delivering the full list every time a notification is 292 sent, it is RECOMMENDED that notifications only list the username 293 entries that have changed state (i.e., been added or removed). 295 Notifications triggered as a result of a fetch operation (a 296 SUBSCRIBE with Expires of 0) or a new Subscription SHOULD result in 297 the full list of all usernames to be present in the NOTIFY. 299 4.8. Subscriber Processing of NOTIFY Requests 301 The SIP Events framework expects packages to specify how a 302 subscriber processes NOTIFY requests in any package specific ways, 303 and in particular, how it uses the NOTIFY requests to construct a 304 coherent view of the state of the subscribed resource. 306 Typically, the NOTIFY will only contain information for usernames 307 whose state has changed. To construct a coherent view of the total 308 state of all usernames, the subscriber will need to combine NOTIFYs 309 received over time. The details of this process depend on the 310 document format used to convey registration state. Section 5 311 outlines the process for the application/userinfo+xml format. 313 4.9. Handling of Forked Requests 315 The SIP Events framework mandates that packages indicate whether or 316 not forked SUBSCRIBE requests can install multiple subscriptions. 318 Provisioned usernames are normally stored in some repository 319 (whether it be co-located with a proxy/registrar or in a separate 320 database). As such, there is usually a single place where the 321 username information for a particular address-of-record is resident. 322 This implies that a subscription for this information is readily 323 handled by a single element with access to this repository. There 324 is, therefore, no compelling need for a subscription to username 325 information to fork. As a result, a subscriber MUST NOT create 326 multiple dialogs as a result of a single subscription request. The 327 required processing to guarantee that only a Section 4.4.9 of the 328 SIP single dialog is established is described in Events framework 329 [RFC3265]. 331 4.10. Rate of Notifications 333 The SIP Events framework mandates that packages define a maximum 334 rate of notifications for their package. 336 For reasons of congestion control, it is important that the rate of 337 notifications not become excessive. As a result, it is RECOMMENDED 338 that the server not generate notifications for a single subscriber 339 at a rate faster than once every 5 seconds. 341 4.11. State Agents 343 The SIP Events framework asks packages to consider the role of state 344 agents in their design. 346 State agents have no role in the handling of this package. 348 5. Username Information 350 5.1. Structure of Username Information 352 Username information is an XML document [4] that MUST be well-formed 353 and SHOULD be valid. Username information documents MUST be based 354 on XML 1.0 and MUST be encoded using UTF-8. This specification 355 makes use of XML namespaces for identifying registration information 356 documents and document fragments. The namespace URI for elements 357 defined by this specification is a URN [5], using the namespace 358 identifier ietf defined by [6] and extended by [7]. This URN is: 360 urn:ietf:params:xml:ns:userinfo 362 A username information document begins with the root element tag 363 "userinfo". It consists of any number of "userlist" sub-elements, 364 each of which contains the provisioning state for a particular list 365 of usernames, associated with the address-of-record subscribed to. 366 The username information for a particular address-of-record MUST be 367 contained within a single "userlist" element; it cannot be spread 368 across multiple "userlist" elements within a document. Other 369 elements from different namespaces MAY be present for the purposes 370 of extensibility; elements or attributes from unknown namespaces 371 MUST be ignored. 373 There are two attributes associated with the "userinfo" element, 374 both of which MUST be present: 376 version: This attribute allows the recipient of username 377 information documents to properly order them. Versions start at 0, 378 and increment by one for each new document sent to a subscriber. 379 Versions are scoped within a subscription. Versions MUST be 380 representable using a 32 bit integer. 382 state: This attribute indicates whether the document contains the 383 full list of provisioned usernames, or whether it contains only 384 information on those registrations which have changed since the 385 previous document (partial). 387 Note that the document format explicitly allows for conveying 388 information on multiple addresses-of-record. This enables 389 subscriptions to groups of usernames, where such a group is 390 identified by some kind of URI. For example, a domain might define 391 sip:allusers@example.com as a subscribe-able resource that generates 392 notifications when the provisioning state of any address-of-record 393 in the domain changes. 395 The "userlist" element has a list of any number of "user" sub- 396 elements, each of which contains information on a single username 397 entry, which may itself be a range-patterned name. Other elements 398 from different namespaces MAY be present for the purposes of 399 extensibility; elements or attributes from unknown namespaces MUST 400 be ignored. 402 There are three attributes associated with the "userlist" element, 403 all of which MUST be present: 405 aor: The aor attribute contains a URI which is the address-of- 406 record this list is associated with. 408 id: The id attribute identifies this list. It MUST be unique 409 amongst all other id attributes present in other userlist elements 410 conveyed to the subscriber within the scope of their subscription. 411 Furthermore, the id attribute for a "userlist" element for a 412 particular address-of-record MUST be the same across all 413 notifications sent within the subscription. 415 state: The state attribute indicates the state of the username 416 list. The valid values are "active" and "removed". 418 The "user" element contains the username. There are several 419 attributes associated with the "contact" element which MUST be 420 present: 422 id: The id attribute identifies this user name. It MUST be unique 423 amongst all other id attributes present in other user elements 424 conveyed to the subscriber within the scope of their subscription. 426 state: The state attribute indicates the state of the user name. 427 The valid values are "active" and "removed". 429 type: The type attribute identifies the user name type. Valid 430 values are "e614", "private", and "alpha". 432 range: the range attribute is defined in the next section. 434 context: the context attribute is only meaningful when the type 435 attribute is "private", and in such a case the context identifies 436 the context of the private name space. 438 5.2. The "range" Attribute 440 The range attribute's value defines the expansion of the username, 441 using a syntax similar to regular expressions. The range pattern 442 applies after the last character of the user element's value. 444 range-value = exp-char-set exp-char-count 446 exp-char-set = digit-char-set / any-char-set 447 digit-char-set = "[" dsc-begin "-" dsc-end "]" 448 dsc-begin = DIGIT 449 dsc-end = DIGIT 450 any-char-set = "." 452 exp-char-count = "{" exp-min "," exp-max "}" 453 exp-min = DIGIT 454 exp-max = DIGIT 456 The "digit-char-set" defines a range of digit characters, for 457 example 0-9 or 3-5, inclusive. The "dsc-begin" digit value must be 458 less than or equal to the "dsc-end" digit value. 460 The "any-char-set" defines any single character allowed in the 461 'user' token field of [RFC3261]. 463 The "exp-char-count" defines a minimum and maximum number of times a 464 character within the exp-char-set may be repeated, inclusive. The 465 "exp-min" digit value must be less than or equal to the "exp-max" 466 digit value. 468 6. Examples 470 Detailed scenario examples will be provided once the WG decides 471 which way to go with this mechanism. 473 The following is an example username information document: 475 477 481 483 +12345678901 486 bob 488 +1781555 491 495 497 499 7. IANA Considerations 501 This document makes no request of IANA yet, but will if it goes 502 forward. 504 8. Security Considerations 506 This section is still TBD. 508 9. Normative References 510 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 511 A., Peterson, J., Sparks, R., Handley, M., and E. 513 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 514 June 2002. 516 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 517 Package for Registrations", RFC 3680, March 2004. 519 [draft-gin] Roach, A. B., "Registration for Multiple Phone Numbers 520 in the Session Initiation Protocol (SIP)", draft-ietf- 521 martini-gin-10, October 2010. 523 10. Informative References 525 [RFC3327] Willis, D., and Hoeneisen, B., "Session Initiation 526 Protocol (SIP) Extension Header Field for Registering 527 Non-Adjacent Contacts", RFC 3327, December 2002. 529 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 530 3966, December 2004. 532 [RFC4244] Barnes, M. (ed.), "An Extension to the Session Initiation 533 Protocol (SIP) for Request History Information", RFC 534 4244, November 2005. 536 [RFC5486] Malas, D., and Meyer, D., "Session Peering for Multimedia 537 Interconnect (SPEERMINT) Terminology", RFC 5486, March 538 2009. 540 Author's Address 542 Hadriel Kaplan 543 Acme Packet 544 71 Third Ave. 545 Burlington, MA 01803, USA 546 Email: hkaplan@acmepacket.com 548 Appendix A - Rationale for Constraining the Expansion Pattern 550 This document's mechanism defines a limited set of patterns which 551 may be used in the "" portion of the Bulk-AoR. This is 552 in contrast to the "Wildcarded AoR" mechanism used in some 553 deployments, which use any regular expressions (regex) for the 554 pattern. One of the reasons this document restricts the regex 555 syntax is to maintain [RFC3261] compliance, which does not allow 556 common regex characters such as '^', '[', ']','{', and '}' to appear 557 in SIP URIs. 559 The other reason this document does not use any arbitrary regex is 560 that one of the goals of this document is to be useful for an IP-PBX 561 to determine provisioning mismatches. An arbitrary regex is 562 typically useful for verifying a given input string matches the 563 pattern, and not for actually determining the complete set of 564 strings the regex pattern implies. In other words, a regex is 565 useful for authenticating a given number matches the pattern, but 566 not for determining what all of the provisioned numbers are. 568 For example, a regex syntax model for "sip:1234![5-9][0- 569 9]*!@example.com" is useful for checking if "sip:123456@example.com" 570 is a matching number, but is extremely difficult for an IP-PBX to 571 verify that the SSP does not include numbers the PBX does not have 572 provisioned. The IP-PBX could check each of its locally provisioned 573 numbers against the regex pattern, but has no clean way to determine 574 if the set allowed by the regex is not *greater* than its locally 575 provisioned set. 577 Furthermore, numerous regex patterns can be used to mean the exact 578 same set. For example "sip:1234!(5|6|7|8|9)[0-9]*!@example.com", 579 "sip:1234![5-9][0-9]{0,}!@example.com", "sip:1234![5- 580 9][[:digits:]]*!@example.com", and "sip:123!4[5-9][0- 581 9]*!@example.com" all represent the same set of user strings as the 582 first regex example. 584 Therefore, to avoid such issues, this document uses a very narrow 585 set of possible "patterns", which can be used for both matching and 586 provisioning verification.