\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
%\usepackage{rfc}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage[dvips]{changebar}

\title{Binding Generic URIs to SIP URIs}
\author{H. Schulzrinne}
\shorttitle{BIND}
\filename{draft-schulzrinne-sip-bind-00}
\wg{SIP}
\expires{December 2002}
\address{Columbia U.}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\begin{abstract}
For many services, it is useful to be able to associate data,
represented by URLs, with SIP user identifiers, both address-of-records
and host-based user names. This draft proposes a solution that addresses
most of the requirements for such a mechanism.
\end{abstract}
\section{Introduction}

SIP elements need to interact with many other protocols. Examples include:

\begin{itemize}
\item SIP elements need to acquire scripts and other call processing
logic, such as SIP-cgi scripts \cite{rfc3050}, SIP servlets
\cite{JCP0205:SIP} and CPL scripts \cite{draft-ietf-iptel-cpl}.

\item Multiparty conferences may be floor-controlled and configured by a
non-SIP protocols such as SOAP \cite{draft-wu-sipping-floor-control}.

\item Users want to upload presence documents to presence agents
\cite{draft-ietf-simple-presence}.

\item SIP elements may want to obtain configuration data from a
domain-specific configuration server.

\item New users need to be created and their properties configured
(``user provisioning'').
\end{itemize}

For many of these, this relationship can be expressed as a simple
\emph{binding} that maps a SIP URI to a labeled set of URIs which are
then used to retrieve the associated data or affect the desired
operations.  This approach allows the entity retrieving the data to
choose the appropriate mechanism, or delay updating until a more
appropriate time.  For small data elements, the data URI scheme
\cite{rfc2397} can be used to directly include the data in the binding
update.  Also, in some cases, the data can be included as multipart
body, labeled with the mid and cid URIs \cite{rfc2392}.  Thus, the
mechanism is general enough to handle different degrees of indirection.

We assume that such bindings may be needed for individual SIP URLs,
typically associated with SIP UAs, as well as address-of-record URIs,
typically associated with a SIP proxy and a registrar.

These bindings can be queried and updated by SIP elements or non-SIP
elements.  For non-SIP elements, the bindings might be queried and
modified via a web page or a SOAP request, but such mechanisms are
beyond the scope of this document.  We believe that it is useful to have
a mechanism that is closely tied to SIP, as SIP offers the ability to
identify endpoint by a logical address not tied to a particular host or
IP address.  Also, for simplicity, it appears wise not to require user
agents to implement a particular additional non-SIP ``bootstrapping''
protocol, probably tied to a different authentication and management
mechanism.  Using the mechanisms below, the amount of information added
to SIP requests is very small.

This problem is related to the content indirection problem
\cite{draft-ietf-sipping-content-indirect}. In both cases, a SIP
message uses a URI to refer to external data, retrieved via a non-SIP
protocol. However, the semantics are different: for content indirection,
the data referenced by the URI replaces data normally carried in the SIP
message itself, primarily for efficiency reasons. In this application,
data is associated with the address-of-record or other SIP entity.
The semantic differences lead to operations that allow adding and
deleting bindings. 

\section{Terminology}
\label{sec:terminology}

In this document, the key words ``{\MUST}'', ``{\MUSTNOT}'',
``{\REQUIRED}'', ``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'',
``{\SHOULDNOT}'', ``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}''
are to be interpreted as described in RFC 2119 \cite{rfc2119} and
indicate requirement levels for compliant implementations. The terms are
also used for protocol requirements, and then apply to the protocol
properties, not the implementation.

\section{The \header{Binding} Header Field}

In a request, the \header{Binding} header field instructs the recipient
to update the bindings included in the header field.  In a response, the
header field values enumerate all or a subset of the bindings associated
with the request-URI value.

The binding expires after the number of seconds indicated in the
``;expires'' parameter.  The value of ``0'' removes the binding.

The function of the binding is described by the \header{;disposition}
parameter.  Values for the parameter are registered with IANA.  In this
document, we define the following

\begin{description}
\item[expires:] The \header{expires} parameter describes the lifetime of
the binding. Its usage and format is the same as the respective
\header{Contact} parameter.

\item[disposition:] The \header{disposition} parameter describes the
purpose of the URI.

\item[q:] The \header{q} parameter describes the relative preference among bindings with the same disposition. Values between 0 and 1, inclusive, are permitted. The server processing does not depend on the \header{q} value.

\item[etag:] An entity tag, used to identify versions of the same
resource. A user of a binding can compare the entity tag to see if the
object needs to be retrieved again.
\end{description}

A binding update may contain any number of bindings for each disposition. 
The disposition parameter is {\REQUIRED}.

Example:

\begin{verbatim}
Binding: <http://www.tweak-me.com> 
  ;disposition=configuration ;expires=0 ;q=0.1
Binding: <tftp://store.example.com> 
  ;disposition=boot ;expires=36000
Binding: ;disposition=conference ;expires=0
\end{verbatim}

The binding may be stored as a static table, or be generated
dynamically.  The precise meaning of the binding depends on the
\header{disposition} parameter.  The recipient (registrar or UA) does
not have to act on the binding.  It is up to the recipient of the
binding whether it accepts the binding, at all or from a particular
source.  Registrars {\SHOULD} accept all bindings, acting as a
repository for information that user agents can then retrieve.

\section{The \header{Accept-Binding} Header Field}

We define a new header field, \header{Accept-Binding}, that enumerates all
binding dispositions that the server will accept to store. It does not
define the bindings that a client would like to obtain.

The special \header{Accept-Binding} value of ``*'' indicates that the
SIP element will accept bindings with any disposition.  An empty
\header{Accept-Binding} indicates that the SIP element does not support
any disposition.

\section{The Use of {\REGISTER} and {\OPTIONS}}
\label{sec:register}

As discussed below, {\REGISTER} is not appropriate for updating
bindings. However, the \header{Binding} header field may appear in
{\REGISTER} responses to inform the registrand of the list of available
bindings. This avoids the overhead of an extra SIP request.

The {\OPTIONS} response {\MAY} also contain \header{Binding} header
fields. It can be used to obtain bindings for a particular SIP
identifier, typically other than the AoR.

\section{The {\BIND} Method}
\subsection{Motivation}

One of the problems with using {\REGISTER} for maintaining bindings is
that this works only reasonably well for conveying bindings from
registrars to UAs, as that behavior adds no additional failure cases to
the {\REGISTER} behavior.  Also, {\REGISTER} is not appropriate for
associating bindings with a conference, for example, since conference
participants do not typically register for that address.

\subsection{Overview}

This document introduces the SIP {\BIND} request method.  Its behavior
is similar to {\REGISTER}, but it updates and retrieves generic URI
bindings instead of \header{Contact} URIs.  {\BIND} requests are used by
SIP UAs to query, update and delete bindings.

\motivation{The {\REGISTER} mechanisms appear to be relatively well
understood and easy to implement.  It appears likely that the {\BIND}
method can be implemented in a very similar manner.}

\subsection{Operation}

{\BIND} is a non-{\INVITE} method that can be forked.

The {\BIND} method does not create a SIP dialog as part of its
processing.  Creation of a dialog implies that the sender and recipient
need to track the state of the {\BIND} operation itself, which need not
be necessary for its proper operation.  Therefore, there are no
requirements on the use and reuse of the \header{Call-Id}, or tags from
one {\BIND} to the next {\BIND} outside of the normal rules of SIP.

A {\BIND} request {\MAY} contain a body, using the standard MIME headers
to identify the content.  Bodies are used for content references with
``cid'' URI schemes \cite{rfc2392}.

\subsection{Adding and Refreshing Bindings}

Bindings are adding by addressing a {\BIND} request to a SIP URI, with
zero or more \header{Binding} header fields.  The binding target is
identified by the request URI.

\motivation{Unlike {\REGISTER}, we use the request URI to identify the
target. This allows SIP entities to register themselves as recipients of
{\BIND} requests by specifying the ``methods'' \header{Contact} parameter.}

If the \header{Binding} URI exists for the particular disposition, it is
refreshed with the new expiration time and \header{q} value.

The {\BIND} method is atomic.  If any of the bindings fail, none of the
other bindings are updated, added, deleted or replaced.  Since there is
currently no mechanism to identify the binding that failed, clients
{\SHOULD} only update one binding in each request.

A server {\MAY} offer other mechanisms, such as a web page or a
database, to add, delete and update bindings.

If the receiver does not support a particular binding disposition, in
general or from the issuer of the request, it responds with a 4?? 
(Binding refused) and includes an \header{Accept-Binding} header field
that summarizes all binding dispositions that it does support for this
particular user.

If the URI scheme is ``cid'', the receiver retrieves the appropriate
body part from the {\BIND} request and stores it.  The ``cid'' URI is
then used to identify this object.  The serve can refuse to store large
objects using the 413 (Request Entity Too Large) status message.

If the receiver considers the expiration time of any of the bindings as
too short, it responds with a 4xx () response and includes a
\header{Min-Expires} header field indicating the minimum allowable
expiration time.

\subsection{Obtaining bindings}

The response to a {\BIND} request enumerates the current bindings in the
\header{Binding} header fields.

\subsection{Deleting Bindings}
\label{sec:deleting}

A particular binding is deleted by refreshing it with an expiration
interval of zero.  All bindings having a particular disposition are
deleted by omitting the specific URI, but including the disposition, in
the \header{Binding} header field.

\section{The Binding-Update Event Package}
\label{sec:event}

We define an event package called ``binding-update'' that allows clients
to subscribe to changes for particular dispositions.  Each disposition
is a sub-event.  If a subscription does not contain a sub-event, the
client wishes to receive notification if any binding has changed.  The
{\NOTIFY} request contains a list of \header{Binding} header fields
listing the bindings that have changed.

Details are TBD.

\section{Requirements Analysis}

The mechanism presented above is believed to satisfy the requirements
for a publication mechanism detailed in
\cite{draft-campbell-pub-bind-reqs}. We quote the requirements below and
indicate how they are met.

\subsection{Publication URI}

\begin{quotation}
The binding mechanism {\MUST} allow a client to discover or infer a URI, or
set of URIs, to which data may be published for a particular service. 
The mechanism {\MUST} allow for any URI scheme, and {\MUSTNOT} make
assumptions about how a specific publication mechanism interprets URIs.
\end{quotation}

The {\BIND} and {\REGISTER} responses contain \header{Binding}
header fields that allow a client to discover the URI.

\subsection{Publication Mechanism}

\begin{quotation}
The binding mechanism {\MUST} allow a client to discover or infer the
mechanism, or set of mechanisms, to use to publish data to a
particular publication URI.
\end{quotation}

The URI scheme indicates the protocol.

\subsection{Address of Record}
\begin{quotation}
The binding mechanism {\MUST} allow clients to determine binding
information based only on knowledge of an AoR.  A client {\MAY} allow
provisioning of individual service publication bindings for an AoR.  The
binding mechanism {\MUST} allow for multiple data-driven services for a
single AoL, and {\MUST} allow the client to distinguish one such service
from another for publication purposes.  (For example, the AoR
"sip:alice@example.com" may have both presence and CPL services
associated with it.  A client must be able to avoid sending CPL to the
presence service, or a presence document to the CPL services.)
\end{quotation}

The \header{Binding} header field is used to return information about the
purpose of each URI and only requires the issuer of the {\BIND} request
to know the AoR. 

\subsection{Enumeration of Services}

\begin{quotation}
The binding mechanism {\SHOULD} offer a way for a client to determine a
list of all services for a given AoR for which it can publish data.
\end{quotation}

The \header{Binding} header field enumerates all such services. The
\header{Accept-Binding} allows the AoR to provide an indication of which
service bindings can be updated.

\subsection{Lifetime of Publication URIs}

\begin{quotation}
The binding mechanism {\MUST} allow a service element to manage the
lifetime of a publication URI.  It {\MUST} allow long-lived publication
URIs.  It {\MAY} also allow very short-lived publication URIs; for
example, the URI may be single-use only.
\end{quotation}

URI bindings are similar to {\REGISTER} bindings and can have any
lifetime, subject to server policy constraints and the
\header{Min-Expires} header field value.

The {\BIND} mechanism currently does not support single-use URIs since
such a mechanism appears to be hard to specify completely and no
applications have been defined.  For example, a server could only hand
out a single-use URI once, but would have no way of knowing whether the
client actually made use of it.

\subsection{Communication of Publication URIs}

\begin{quotation}
The binding mechanism {\MUST} allow a service provider to communicate
publication URIs to a client, directly or through a third party.  For
example, the client might directly query a service element, or query a
directory service.  The mechanism {\MAY} also provide a method for a
client to infer publication URIs from an AoR without directly
contacting the service elements, for example by using an algorithmic
transformation, schema mapping, or the DNS.
\end{quotation}

The mechanism uses standard SIP name translation mechanisms to obtain
the publication URIs.

\subsection{Separate publication points}

\begin{quotation}
The mechanism {\MUSTNOT} require all publication URIs for a given AoR to
share the same host, address, or even domain.  The mechanism {\MUSTNOT}
require the publication point for a data-driven service to be colocated
with the network element(s) that provide the service itself.
\end{quotation}

URIs in this mechanism can point to any network resource.

\subsection{Publication URIs that are not easily guessable}

\begin{quotation}
The binding mechanism {\SHOULD} allow the use of publication URIs that
are not easily guessable.
\end{quotation}

In the context of this binding mechanism, it is up to the client or
registrar to ensure that URIs are not guessable. The mechanism neither
prevents or enforces this requirement.

Since this mechanism and content indirection employ URIs for
indirection, some of the requirements in
\cite{draft-ietf-sipping-content-indirect} are applicable here.  For
example, the following seem particularly relevant, quoted verbatim:

\begin{itemize}
\item It {\MUST} be possible to specify the timespan for which a given
URL is valid.  Applications of this mechanism MUST specify a lifetime
for the URL.  This may or may not be the same as the lifetime for the
content itself.

\item It {\MUST} be possible to specify the purpose and disposition of each
URL independently.

\item It {\MUST} be possible to label each URL to identify if and when
the content referred to by that URL has changed.  Applications of this
mechanism may send the same URL more than once.  The intention of this
requirement is to allow the receiving party to determine if the content
referenced by the URL has changed without having to actually retrieve
that content.  Example ways the URL could be labelled include a sequence
number, timestamp, version number, etc.
\end{itemize}

\subsection{Security}

\begin{quotation}
The binding mechanism {\MUST} allow a client to authenticate the source of
a publication URI.  The mechanism {\MAY} allow a publication URI provider
to authenticate clients.  The mechanism {\MUST} allow a client to ensure
that publication URIs have not been tampered with.
\end{quotation}

Appropriate SIP security mechanisms can be used to ensure the integrity
of the binding data and the identity of the requestor. Details are in
Section~\ref{sec:security}.

\section{Alternatives Considered}
\label{sec:alternatives}

The original binding mechanism \cite{draft-ietf-iptel-sip-reg-payload}
included scripts in {\REGISTER} requests.  That mechanism had a number
of problems that motivated the more general mechanism described here: 
Including the data in the REGISTER request made it difficult to
distinguish the lifetime of the {\REGISTER} \header{Contact} binding
from the lifetime of the script.  Typically, the script would need to be
refreshed far less frequently.  Also, if the script update failed for
some reasons, it was not clear if the {\REGISTER} update itself failed
or succeeded.  The mechanism for removing scripts, XXX, was a bit of a
kludge.

We assume that URLs are sufficient to obtain data or cause the desired
actions to occur. Beyond URIs, there does not seem to be a more generic,
but generally accepted means, of referencing data objects.

Stucker \cite{draft-stucker-sip-publish} proposed a new method, DATA, to
push content to a service.  A slightly different version of the approach
presented here would be to combine DATA with the content indirection
mechanism discussed earlier.  One advantage of the approach in this
document is that it is easy to update multiple bindings at once.  The
major disadvantage of the indirection approach of the {\BIND} method
described here (or the DATA method with content indirection) is that
authentication is likely to be more difficult.  For example, if a client
wants to update the server binding for CPL scripts, the server has to be
told what identity and secrets to use to access that resource, if that
resource is read-protected.  The {\BIND} approach does allow carrying
literal data as message bodies, mitigating this problem.  It seems
likely that random URIs, effectively embedding a secret in the URI, will
be the only easily configured mechanism for publication. That approach
only improves upon the deprecated Basic authentication of plain-text
passwords if the {\BIND} bindings are end-to-end encrypted.

There are other non-SIP mechanisms that can be used for this purpose. 
For example, we could map the SIP URI \texttt{sip:alice@example.com} to
the DNS RR \texttt{alice.example.com} and then use recent DNS mechanisms
to obtain the data.  Practically speaking, administering such bindings
appears to be significantly more complicated, since most DNS servers are
not set up to allow users to modify DNS entries.  DNSsec is not widely
available, making protecting the information difficult in practice. 
Often, the DNS service is run by somebody other than the owner of the
SIP AoR, further complicating the process.  A simpler, per-domain
mapping, for bindings that are the same or defaults for a whole domain
may well be of interest.  It does not offer any obvious functional
advantages compared to the method described in this draft.

Alternatively, directory services such as LDAP \cite{rfc2251} could be
employed, with an appropriate transformation of the AoR into an LDAP DN. 
A common schema needs to be designed. Such an approach could be easily
integrated into a general whitepages services that stores other
information about users, but adds significant complexity to SIP UAs that
now also need to support LDAP.

Unlike {\REGISTER}, we chose not to include the ability to delete all
bindings, e.g., using the ``*'' notation.  Such a feature appears to be
potentially dangerous, as it is common that many entities need to bind
different URIs, without knowing about the uses other URIs may have.

\section{Open Issues}
\label{sec:open}

Should there be a new status code, 5xx (Maximum number of bindings
exceeded)?  This could presumably also be used for \header{Contact}
registrations.

Would it make sense to use random tags to identify bindings for removal
or update?  This avoids having to remove a binding first and then add
another one, but does not seem strictly necessary.

\section{IANA Considerations}

New \header{disposition} parameters need to be registered by IANA.

\section{Security Considerations}
\label{sec:security}

The {\BIND} method is subject to similar attacks as the {\REGISTER}
method.  Given that {\BIND} can be considered a generalization of the
{\REGISTER} method, this should not be surprising.

Since the nformation transported by this mechanism may control how a
server directs private information intended for a user, the server
{\MUST} reject all unauthenticated attempts to update bindings, and
{\SHOULD} require that the authentication method used verifies the
integrity of the submitted data.  Note, in particular, that Digest
authentication does not ensure the integrity of header fields.  As
proposed \cite{draft-undery-sip-auth}, the sensitive parts of the SIP
message can be carried as a SIP message fragment.

A UA {\SHOULD} only accept bindings with a disposition that it can
handle, to prevent being abused as a data storage mechanism. 
Alternatively, it {\MAY} limit the number or total size of bindings
stored.

\section{Acknowledgements}

Many of the mechanisms above have been discussed informally within the
SIP and SIPPING WG.  Ben Campbell and James Undery provided helpful
comments.

\bibliographystyle{ieeetr}
\bibliography{string,i-d,rfc,dnd,net02}

\section{Authors' Addresses}
\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\input{copyright}
\end{document}
