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