idnits 2.17.1 draft-ietf-sipcore-6665-clarification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2015) is 3346 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft Mozilla 4 Updates: 6665 (if approved) February 27, 2015 5 Intended status: Standards Track 6 Expires: August 31, 2015 8 A clarification on the use of Globally Routable User Agent URIs (GRUUs) 9 in the Session Initiation Protocol (SIP) Event Notification Framework 10 draft-ietf-sipcore-6665-clarification-00 12 Abstract 14 Experience since the publication of the most recent SIP Events 15 framework has shown that there is room for interpretation around the 16 use of Globally Routable User Agent URIs in that specification. This 17 document clarifies the intended behavior. 19 This document updates RFC 6665. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 31, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Clarification of GRUU Handling . . . . . . . . . . . . . . . 2 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 This document is intended to clarify a point of implementor confusion 65 arising from lack of clarity in [RFC2119]. 67 2. Clarification of GRUU Handling 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 [RFC6665] section 4.5.1 contains the following normative requirement 74 on implementations: 76 Notifiers MUST implement the Globally Routable User Agent URI 77 (GRUU) extension defined in [RFC5627], and MUST use a GRUU as 78 their local target. This allows subscribers to explicitly target 79 desired devices. 81 The second sentence of this paragraph attempted to set context for 82 the normative statement: the reason GRUUs are required in this 83 context is to allow you to send SUBSCRIBE or REFER requests to a 84 specific user agent, with the target of the subscription request 85 being something like an INVITE dialog on that device. Consequently, 86 the requirement to include a GRUU as a local target was intended to 87 apply not just to the local target for SUBSCRIBE-created dialogs, but 88 for *all* dialogs, even those created by INVITE. This requirement 89 has been interpreted in a variety of ways by implementors, so a 90 clarification is in order. 92 Discussion subsequent to the publication of [RFC6665] has highlighted 93 obscure cases in which implementations might be notifiers in some 94 contexts, but may not wish to act as notifiers in others. Under 95 these narrow circumstances, the restriction described above is not 96 necessary for dialogs about which the notifier will never accept 97 subscriptions (although the use of GRUUs in such a context causes no 98 harm, either). 100 This document updates [RFC6665] to clarify the actual requirements: 101 "Notifiers MUST implement the Globally Routable User Agent URI (GRUU) 102 extension defined in [RFC5627]. Notifiers MUST use a GRUU as their 103 local target for all dialog-forming methods and all target-refresh 104 methods, except for those dialogs for which they will reject all 105 subscription requests (implicit or explicit). For clarity: an 106 implementation that uses a non-GRUU local contact under the exception 107 described above MUST reject a request that might create a 108 subscription to the associated dialog, regardless of whether such 109 subscription would be created by a SUBSCRIBE or a REFER message. The 110 rejection code under such conditions SHOULD be 403 (Forbidden) unless 111 some other code is more appropriate to the circumstances. The 112 foregoing requirements to implement and use GRUUs specifically 113 include dialogs created by the INVITE method." 115 3. Security Considerations 117 This mechanism does not introduce any security issues beyond those 118 discussed in [RFC6665]. 120 4. IANA Considerations 122 This document requests no actions of IANA. 124 5. Normative References 126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 127 Requirement Levels", BCP 14, RFC 2119, March 1997. 129 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 130 Agent URIs (GRUUs) in the Session Initiation Protocol 131 (SIP)", RFC 5627, October 2009. 133 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 134 July 2012. 136 Author's Address 138 Adam Roach 139 Mozilla 140 Dallas, TX 141 US 143 Phone: +1 650 903 0800 x863 144 Email: adam@nostrum.com