Re: [drinks] Following up on SED data types from today's design call

Yes - I know, Penn recommended a URN and I am inclined to agree as it is far too tempting to make use of the host part of a URI for things other than identification and a URN while more limiting makes the distinction clear.

On Apr 10, 2012, at 7:56 PM, Dean Willis wrote:

You may recall there's another IETF thread on defining SPID or something like it. We're sortof stuck on a "standard" representation for SPID until that completes, although one would hop it a UR-something.

On Thu, Apr 5, 2012 at 4:11 AM, David Schwartz <dschwartz@xconnect.net<mailto:dschwartz@xconnect.net>> wrote:
Hi Dean

I agree with point 1.

Regarding point 2, the SPID is still the problem. You have shown two options, Next-hop URI and transformation - but how about the "non-next-hop" URI as in the case of a URI being used basically as an opaque string (e.g. SPID)?

Does anyone remember why we went with a URI and not a URN for the SPID use case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN and transformation...

:D

On Apr 5, 2012, at 4:05 AM, Dean Willis wrote:

>
> David S. sent out an email before the call today that proposed an abstracted restructuring of the Route Record into a SED Type, with subtypes Location and Target.
>
> Discussion on today's call seemed to reveal that we might be able to address his concerns with something simpler.
>
> I think we've been getting tangled up between the two basic questions about SED data:
>
> 1) What is the data?
>       Is it a SIP URI?
>       An NS record?
>       A NAPTR record?
>       A routing number?
>       A SPID?
>       An XMPP URI?
>       A tel: URI?
>       An H.323 URI?
>       An arbitrary string?
>       A template to which we apply a regex transform using the
>
> 2) What are we supposed to DO with the data once, we have it in hand?
>       Route the request there?
>       Retarget the call to that destination?
>       Use the service indicated by the SED data to look up a next action?
>       Use the SED data as a key into some other routing database
>
>
> I'd argue that most of the "What is it" problems become moot if we simple say "It's a URI", because examination of a naked URI tells us a lot about the encoded data. We know to use a SIP URI with SIP, an XMPP URI with XMPP, and so on. For NSType and NAPTRType, we have RFC 4501 "Domain Name System Uniform Resource Identifiers". We probably also need an optional regular expression for further processing of the SED data.
>
> So if we answer #1 by saying "It's a URI, dude! And it might have a regex with it!" we have answered half the question space. This might not cover SPIDs (still a standards-undefined-thing) and telephone number ranges (which are partially specified in RFC 3966). But it does cover the cases in draft-ietf-drinks-spp-framework-01.
>
> As for question #2:
>
> David seems to think that there are are a couple of roles for SED data, mostly using RFC 5486 terms, and that we need to tell the recipient of the SED data how to use that data; that is, what the role of the data is. So far, this makes sense to me. The next step is where it gets fuzzy....
>
> We seem to have:
>
> LUF, which we query for a new target domain to which we should route the request.  I THINK David called this a TargetType in his morning email.
>
> LRF, which we  query for a signaling-function to which we will send the actual request. I THINK David called this a LocationType in his morning email.
>
> SPID, which we somehow use magically as sort of a LUF for an LRF; in other words, we use the SPID to find a LUF which will give us an LRF.
>
> RN, or routing number, which seems to work like a SPID but is itself a phone number.
>
>
> I'm not sure this makes sense, either. Then again, the subtlety of LRF and LUF has always escaped me. A SIP proxy in domain X might route an INVITE, or it might redirect it, and in either case the "target" might be in domains X or Y, and if you send it a request, you have to be prepared for it to do either.
>
>
> I think instead we have two possible "types" of responses.
>
> 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the user queries it. If it's the sort of URI that you send the request to and it routes or redirects (SIP, XMPP), the user sends the request to it, and the right thing happens. Given a URI, why does a user need to know whether it's an LUF or an LRF?
>
> 2) A transformation. The user takes the response, applies it to the existing data using a regex-replacement, and tries again.
>
>
> In the framework, this "transformation" is muddled up in a combination of the URIRteRecType (framework-01, bottom of page 33) and its <ere> pattern, and the EgrRteType (framework-01, page 38). This confuses me beyond all comprehension.
>
>
> Could we solve the whole can of worms by replacing "Egress Route" and "Route Record" with a "SED Record" containing the base type plus a URI plus a regex?
>
> --
> Dean
>
>
>
>
>
>
> _______________________________________________
> drinks mailing list
> drinks@ietf.org<mailto:drinks@ietf.org>
> https://www.ietf.org/mailman/listinfo/drinks