[drinks] Some ideas on the Route Records

[Otmar Lendl <[e-mail]>]

On 02.08.2010 22:14, Otmar Lendl wrote:
>> #15
>>>   UC INTERCONNECT #5  Provisioning of a delegated name server: An SSP
>>>                       maintains a Tier 2 name server that contains the
>>>                       NAPTR records that constitute the terminal step
>>>                       in the LUF.  The SSP needs to provision a
>> ===
>> [S] OK :)! I think we agreed to make this abstract at the meeting.
>> ===
> 
> I'll try to write up my suggestions later this week.

Here are my thoughts on how one might approach the data structures in the
route records.

This is based on http://tools.ietf.org/html/draft-ietf-drinks-spprov-01

There they are defined as:

   o  Route Record (RteRecType):
      A Route Record is the data that the resolution systems return in
      response to a successful query with the Public Identifier as the
      query string.  It is associated with a Route Group for routes that
      are not specific to a Public Identifier.
      To support the use cases defined in
      [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines
      three type of Route Records: URIType, NAPTRType, and NSType.
      These Route Records extend the abstract type RteRecType and
      inherit the common attribute 'priority' that is meant for setting
      precedence across the route records defined within a Route Group
      in a protocol agnostic fashion.

The NAPTRType is basically 1:1 the fields in a NAPTR, but the URIType is
more interesting:


       <complexType name="URIType">
         <complexContent>
           <extension base="spppb:RteRecType">
             <sequence>
               <element name="ere" type="string" default="^(.*)$"/>
               <element name="uri" type="string"/>
               <element name="ext" type="spppb:ExtAnyType"
   minOccurs="0"/>
             </sequence>
           </extension>
         </complexContent>
       </complexType>

This is quite nice and tails very closely what the NAPTRs are doing.

But let's step back for a second and look at what's common to all these
Route Records. We have:

* Route Records that map from the PI to an URI
	+ Terminal NAPTR
	+ URIType

* Route Records that only generate a referral, not a full resolution
	+ NSType
	+ non-terminal NAPTR

So, if we would want to create a more resolution-protocol independent set
of Route Records, we could do it in the following way:

That record needs to contain:

* A regex
  - Maybe allow in the XML an alternative to the /^.*$/whatever/ greedy
match by stating "<replaceWith>whatever</replaceWith>.

* What kind of PI it applies to? (what is the input to the regex?)
  - E.164 number
  - SIP uri
  - ...

* What kind of service it applies to?
  - voice calling
  - message service (SMS, MMS)
  - voicemail
  - video calling

* How to interpret the result of the regex?
  - A re-target operation
	(like ENUM, the result becomes the new request-URI)
  - A routing operation
	(The request-URI is not touched (e.g. can remain a tel: URI),
	the result just defines the next SIP hop.)
  - A referral
	This need not be limited to
	"go use ENUM to query the following Nameservers"
	but could also be something like
	"query the following SIP server for a redirect"	
	or even a
	"go to a completely different resolution scheme"
---

This way, we're completely independent of a resolution protocol. Some of
these route records can be used to populate ENUM trees (if it's not a
re-target operation, one would need something like
http://www.ietf.org/mail-archive/web/sip/current/msg23298.html). Others
might drive SIP redirect servers.

Comments?

otmar
-- 
// Otmar Lendl <[e-mail]>at>, T: [phone] - 33, F: - 933 //