[drinks] More polishing on intro based on discussion between Ken and David

[Dean Willis <[e-mail]>]

Ken and David wrangled on "targeting".

David provided references, and I've been looking at those. We seem to be talking about two things that are both "routing" in RFC 3261.  But SIP has no "lookup" function, just a redirect response to a "send" function that's been perverted as a lookup function, and that dual-usage is part of what makes the discussion confusing. In other words, sending an INVITE to a server that is going to send back a 302 is "routing", but we're David is calling it "targeting" in his terminology.

So here's what I'm thinking we have:

Starting with a "query" protocol that is distinct from a session-establishment protocol:

LUF  returns another place at which we need to do a query. 

LRF  returns a session-protocol destination towards which we would issue a session-estabishment request (aka, SIP INVITE).

Both might also return "seed" information for the second query, basically some sort of regex transformation that we might apply to the querystring.

Confusingly, I think we think that SIP can be both a query protocol and a session-establishment protocol. This requires a priori knowledge that the target-URI of a SIP INVITE request is not a UA with which one wishes to establish a session, but is actually a "location server" that is expected to send a 302 response. In other words, if it sent a 200 OK, you'd be very confused and have some kind of call failure. If we have this assumption, then we cannot tell by examination of a naked target URI whether that URI is to be used as an LRF or an LUF. We need additional metadata telling us how to use that URI, and we get this from the schema.

In other words, if we send a query to a server using our "query" protocol and said server responds with a naked SIP URI, we don't know whether we should treat that SIP URI as an LRF or an LUF, and we really need to know, because those are two very different use cases.

The other option is to follow the "if it hurts, stop doing it" model and assume that a SIP URI is a SIP URI; that is, it is always a LRF and not a LUF. Even if in practice it responds with a 302 to another domain. Note that SIP does not have a regex-transform 302 response.


Anyhow, with that in mind, let's see if the Intro can be made to make any more sense

Please excuse my use of MHTML. People seem to want diff-indicators so they can see what has changed. Here I have struck-out excised text, and placed new text in an oblique (italic) font.


1.  Introduction

Service providers and enterprises use registries to make session routing/targeting establishment decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning framework for these registries.  In other words, the goal is to allow users to put session establishment data (SED) into a registry, to share that SED selectively with other users of that registry, and to allow those other users to further select a subset of that SED for use in their own applications.  The requirements and use cases driving this framework have been documented in [RFC 6461], and the reader is expected to be familiar with the terminology defined therein. Additional vocabulary, particularly location-routing function (LRF) and look-up function (LUF) are as defined in RFC 5486.

The SED described in this framework is limited to simple routing/targeting LUF and LRF data, typically expressed as URIs along with supporting metadata. Although the terms "peer" and "peering" are used, these refer only to the sharing of basic call routing/targeting LRF and LUF information between users of the registry, and do not address the broad range of policy factors that might be used in a commercial peering "clearinghouse" an operation driven by more complex criteria such as cost, differential routing by time of day, QoS, or the many other factors that might be negotiated in a peering agreement. In short "peering organizations" are other users of the same registry, and "peers" are users of that registry to whom the offer of sharing specific SED has been extended, and who have accepted that offer.

Three types of data flows are described in [RFC 6471]: client to/from registry, registry to local data repository and registry to registry, as shown here:



    *--------*               *------------*               *------------*
    |        | (1). Client   |            | (3).Registry  |            |
    | Client | <-----------> |  Registry  |<------------->|  Registry  |
    |        |   to Registry |            |  to Registry  |            |
    *--------*               *------------*               *------------*
                                  /  \                          \
                                 /    \                          \
                                /      \                          \
                               /        \                          v
                              /          \                         ...
                             /            \
                            / (2). Distrib \
                           / Registry data  \
                          /  to local data   \
                         V      store         V
                    +----------+         +----------+
                    |Local Data|         |Local Data|
                    |Repository|         |Repository|
                    +----------+         +----------+

                     Three Registry Provisioning Flows


This document addresses only the (1) Client to Registry aspect.  This document defines an abstract framework for the interaction of registry clients with registries, referred to as the Session Peering Provisioning Framework (SPPF).  This abstract framework is to be mapped into specific protocol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap].

The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain.  These systems typically use a local data store ("Local Data Repository") as their source of session routing information.  More specifically, the SED data is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session.  See [RFC5486] for more details.

A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other SSPs. Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP).  In some cases, the registry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query resolution service will be something like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.

The roles of  "client" and "server" are abstract and only apply to the requesting and responding roles in given transactions and are not related in any way to the type of entity participating in a protocol exchange.  For example, a registry might also include a "client" when such a registry initiates a connection (for example, for data distribution to an SSP).

... continue with existing text from "A key requirement..."