RFC 7621

A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework

πŸ“… published August 2015, from ietf

A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework πŸ¦‹

Okay bestie, the title block is giving very important info, so here's the tea 🫢 This is RFC 7621, written by A.B. Roach at Mozilla, dated August 2015. It's a Standards Track document (ISSN 2070-1721), so it's an actual Internet standard and not just a vibe. It updates RFC 6665, which means it tweaks the rules from that doc. The title block doesn't list anything it obsoletes, so RFC 6665 is the only one getting an update πŸ’…

Abstract ✨

Ever since the SIP Events framework came out in July 2012, people have noticed there's room for interpretation when it comes to Globally Routable User Agent URIs πŸ‘€ This document is here to clear that up and say what was meant all along. It also updates RFC 6665 🌸

Status of This Memo πŸ“

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7621.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents πŸ—‚οΈ

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Clarification of GRUU Handling  . . . . . . . . . . . . . . .   2
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
5.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1. Introduction 🧚

Okay so this doc exists because implementors were getting confused by something that wasn't clear enough in [RFC6665] 😭 It's basically a clarification sesh.

2. Clarification of GRUU Handling πŸ’œ

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Here's what Section 4.5.1 of [RFC6665] says. It's a normative requirement on implementations:

   Notifiers MUST implement the Globally Routable User Agent URI
   (GRUU) extension defined in [RFC5627], and MUST use a GRUU as
   their local target.  This allows subscribers to explicitly target
   desired devices.

The second sentence was trying to give context for that rule. The reason GRUUs are required here is so you can send SUBSCRIBE or REFER requests to a specific user agent, where the subscription target is something like an INVITE dialog on that device πŸ“ž So the requirement to use a GRUU as a local target was meant to cover not just SUBSCRIBE-created dialogs, but all dialogs, even the ones created by INVITE. Implementors read that in a bunch of different ways, so yes, a clarification was definitely needed πŸ™ˆ

After the original spec came out, people found some obscure cases where an implementation might act as a notifier in some contexts but not want to be one in others πŸ€” In these narrow situations, the restriction above isn't necessary for dialogs where the notifier will never accept subscriptions. (Using GRUUs there doesn't cause any harm either, btw.)

This document updates [RFC6665] to clarify the actual requirements. The replacement text is below, and it's the official version now πŸ’…

   Notifiers MUST implement the Globally Routable User Agent URI
   (GRUU) extension defined in [RFC5627].  Notifiers MUST use a GRUU
   as their local target for all dialog-forming methods and all
   target-refresh methods, except for those dialogs for which they
   will reject all subscription requests (implicit or explicit).  For
   clarity: an implementation that uses a non-GRUU local contact
   under the exception described above MUST reject a request that
   might create a subscription to the associated dialog, regardless
   of whether such subscription would be created by a SUBSCRIBE or a
   REFER message.  The rejection code under such conditions SHOULD be
   403 (Forbidden) unless some other code is more appropriate to the
   circumstances.  The foregoing requirements to implement and use
   GRUUs specifically include dialogs created by the INVITE method.

3. Security Considerations πŸ”

This mechanism does not introduce any security issues beyond those discussed in [RFC6665]. No new drama here, just go check that doc πŸ’€

4. IANA Considerations πŸ“š

This document requests no actions of IANA. Nothing to register, no forms to file, we're chilling ✨

5. Normative References πŸ”—

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
           Agent URIs (GRUUs) in the Session Initiation Protocol
           (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
           <http://www.rfc-editor.org/info/rfc5627>.

[RFC6665]  Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
           DOI 10.17487/RFC6665, July 2012,
           <http://www.rfc-editor.org/info/rfc6665>.

Author's Address πŸŽ€

Adam Roach
Mozilla
Dallas, TX
United States

Phone: +1 650 903 0800 x863
Email: adam@nostrum.com

Bestie, that's the whole RFC 🫢 Go be a notifier with GRUUs everywhere 🌈✨

πŸ“¦ where this page comes from