A Document Format for Requesting Consent
RFC 5361

Document Type RFC - Proposed Standard (October 2008; No errata)
Last updated 2013-03-02
Replaces draft-camarillo-sipping-consent-format
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5361 (Proposed Standard)
Telechat date
Responsible AD Jon Peterson
Send notices to sipping-chairs@ietf.org
Network Working Group                                       G. Camarillo
Request for Comments: 5361                                      Ericsson
Category: Standards Track                                   October 2008

                A Document Format for Requesting Consent

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines an Extensible Markup Language (XML) format for
   a permission document used to request consent.  A permission document
   written in this format is used by a relay to request a specific
   recipient permission to perform a particular routing translation.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  2
   3.  Permission Document Structure  . . . . . . . . . . . . . . . .  3
     3.1.  Conditions . . . . . . . . . . . . . . . . . . . . . . . .  3
       3.1.1.  Recipient Condition  . . . . . . . . . . . . . . . . .  3
       3.1.2.  Identity Condition . . . . . . . . . . . . . . . . . .  4
       3.1.3.  Target Condition . . . . . . . . . . . . . . . . . . .  6
       3.1.4.  Validity Condition . . . . . . . . . . . . . . . . . .  7
       3.1.5.  Sphere Condition . . . . . . . . . . . . . . . . . . .  7
     3.2.  Actions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Translation Handling . . . . . . . . . . . . . . . . .  7
   4.  Example Document . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  XML Namespace Registration . . . . . . . . . . . . . . . . 11
     7.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13

Camarillo                   Standards Track                     [Page 1]
RFC 5361               Permission Document Format           October 2008

1.  Introduction

   The framework for consent-based communications in the Session
   Initiation Protocol (SIP) [RFC5360] identifies the need for a format
   to create permission documents.  Such permission documents are used
   by SIP [RFC3261] relays to request permission to perform
   translations.  A relay is defined as any SIP server, be it a proxy,
   B2BUA (Back-to-Back User Agent), or some hybrid, which receives a
   request and translates the Request-URI into one or more next-hop URIs
   to which it then delivers a request.

   The format for permission documents specified in this document is
   based on Common Policy [RFC4745], an XML document format for
   expressing privacy preferences.

2.  Definitions and Terminology

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

   This document uses the terms defined in [RFC5360].  For completeness,
   these terms are repeated here.  Figure 1 of [RFC5360] shows the
   relationship between target and recipient URIs in a translation
   operation.

   Recipient URI:

      The Request-URI of an outgoing request sent by an entity (e.g., a
      user agent or a proxy).  The sending of such request can have been
      the result of a translation operation.

   Relay:

      Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or
      some hybrid, that receives a request, translates its Request-URI
      into one or more next-hop URIs (i.e., recipient URIs), and
      delivers the request to those URIs.

   Target URI:

      The Request-URI of an incoming request that arrives to a relay
      that will perform a translation operation.

   Translation logic:

      The logic that defines a translation operation at a relay.  This
      logic includes the translation's target and recipient URIs.

Camarillo                   Standards Track                     [Page 2]
Show full document text