RFC 7621 PROPOSED STANDARD SIP · EVENTS · URI

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

Clarifies when SIP notifiers must use a GRUU as their local target.

On rfc-editor.org ↗
PUBLISHED
August 2015
AUTHORS
A.B. Roach
STREAM
IETF
BUILDS ON
RFC 6665 — SIP Events
RFC UPDATED
RFC 6665
SUGGESTED REJECTION CODE
403 (Forbidden)
DOI
10.17487/RFC7621

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                        A.B. Roach
Request for Comments: 7621                                       Mozilla
Updates: 6665                                                August 2015
Category: Standards Track
ISSN: 2070-1721


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

Abstract

   Experience since the publication of the most recent SIP Events
   framework (in July 2012) has shown that there is room for
   interpretation around the use of Globally Routable User Agent URIs in
   that specification.  This document clarifies the intended behavior.

   This document 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 Notice

   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

   This document is intended to clarify a point of implementor confusion
   arising from lack of clarity in [RFC6665].

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].

   Section 4.5.1 of [RFC6665] contains the following 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 of this paragraph attempted to set context for
   the normative statement: the reason GRUUs are required in this
   context is to allow you to send SUBSCRIBE or REFER requests to a
   specific user agent, with the target of the subscription request
   being something like an INVITE dialog on that device.  Consequently,
   the requirement to include a GRUU as a local target was intended to
   apply not just to the local target for SUBSCRIBE-created dialogs, but
   to *all* dialogs, even those created by INVITE.  This requirement has
   been interpreted in a variety of ways by implementors, so a
   clarification is in order.

   Discussion subsequent to the publication of [RFC6665] has highlighted
   obscure cases in which implementations might be notifiers in some
   contexts, but may not wish to act as notifiers in others.  Under
   these narrow circumstances, the restriction described above is not
   necessary for dialogs about which the notifier will never accept
   subscriptions (although the use of GRUUs in such a context causes no
   harm, either).

   This document updates [RFC6665] to clarify the actual requirements.
   The replacement text is as follows:

      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].

4.  IANA Considerations

   This document requests no actions of IANA.

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

ISO Plain Language

On this page
PROBLEMImplementers interpreted the GRUU requirement in the SIP event notification framework in different ways, including whether it covered dialogs created by INVITE.
MECHANISMThe RFC clarifies that notifiers must use a GRUU for all dialog-forming and target-refresh methods, with a narrow exception for dialogs that reject every subscription request.
WHY IT MATTERSRFC 7621 updates RFC 6665 with explicit requirements for GRUU handling.

§1The Source of Confusion

Experience after publication of the SIP event notification framework in RFC 6665 showed that its instructions for Globally Routable User Agent URIs (GRUUs) could be interpreted in different ways. RFC 7621 clarifies the intended behavior and updates RFC 6665.

The original requirement said notifiers must implement the GRUU extension and use a GRUU as their local target. The clarification explains which dialogs that requirement covers.

Implementers read the GRUU rule in RFC 6665 differently. This memo states clearly which SIP dialogs must use a GRUU.

§2When a Notifier Must Use a GRUU

Notifiers MUST implement the GRUU extension and use a GRUU as their local target for all dialog-forming methods and all target-refresh methods. This includes dialogs created by INVITE, not only dialogs created by SUBSCRIBE.

The exception is a dialog for which the notifier will reject all subscription requests, whether implicit or explicit. If the notifier uses a non-GRUU local contact under this exception, it MUST reject any SUBSCRIBE or REFER request that might create a subscription. The rejection code SHOULD be 403 (Forbidden), unless another code is more appropriate.

Use a GRUU for every dialog-forming and target-refresh method, including INVITE. A notifier using the exception must reject every request that could create a subscription.

§3Security and IANA

The RFC says this clarification introduces no security issues beyond those discussed in RFC 6665. It requests no actions from IANA.

The clarification adds no new security issues, and it requires no IANA changes.

§4References