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.