Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata

From: Dean Willis <[email-masked]>
Date: Fri, 19 Mar 2010 14:03:10 -0500

We touched on this earlier, but got derailed by the "Why don't we just  
use HTTP for everything" question that Cullen did us the honor to ask.

Current proposals as I understand them call for either:

1) encoding metadata into a "data" URI (which is considered pretty  
hokey by the URI people, as the hunk of data is NOT universal, and  
while it may be a resource, it's not an indicator and also isn't used  
to initiate a communications session directly, making it inconsistent  
with the "u" flag in the Naptr record).

2) creating a new Enumservice name, like "E2MD", that can return a  
text string containing the metadata (the basic model in draft- 
hoeneisen-e164-to-metadata-02). Currently, the expressible range of  
metadata is unbounded by this draft; the same string holds ALL the  
metadata elements, presumably in a syntactically delimited form  
something like name-value pairs.  In some use cases, there is arguably  
a need to privacy-protect some of the values, so we might have to  
encrypt some of them. This raises key management questions.

3) Creating a new Enumservice for each type of metadata, and encoding  
the metadata appropriately. AFAIk, we haven't talked about this one  
much yet

4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned  
string to be an absolute URI.  We're not exactly sure what this URI  
has in it, yet.

Let's talk about what we could do with #4 by using a hybrid of ENUM  
for the lookup and some other protocol, specifically HTTP, for the  
result phase.

We could reasonably put the metadata in a file/record/member (pick  
your own terminology) and stick the URI for that metadata into the  
E2MD NAPTR record as an absolute URI.

In this approach, to find someone's CNAM, I would first get their  
NAPTR from ENUM using the phone number, then do an HTTP GET operation  
on the resulting URI to retrieve the metadata, then pull the CNAM out  
of the metadata.

This has a couple of big options over putting the metadata directly  
into ENUM:

1) The metadata can conceivably be large, which allegedly makes for  
problems with DNS' use of UDP.

2) The web server can use standard AAA mechanisms to decide whether  
the requester is authorized to see the metadata, and if so, which  
metadata to return.

3) HTTP allows the web server to use other information known about the  
requester to decide how to answer the query. This is useful for a lot  
of cases that people have been proposing to build around enum, like  
egress route selections.

4) HTTP request parameters can be used to select a subset of the  
metadata for the query, for example just asking for calling name or in- 
use status.

There are some obvious potential issues:

1) The HTTP server has to be reachable from the requester. We KNOW  
that DNS was in some way reachable already; how much of a burden is to  
expect HTTP to work too?

2) The HTTP server might be capacity-constrained. Of course, we have  
HTTP tricks to deal with this, like load-balancers, anycast, etc.

3) It's arguably more overhead; there's an additional TCP setup,  
perhaps TLS, perhaps a challenge/response sequence.

Would the E2MD working group be willing to consider this sort of  
approach, or are we restricting ourselves to a pure DNS model?

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 19 Mar 2010 15:29:22 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Friday, March 19, 2010 3:03 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata

RS > Yep .. been there done that with my old CNAM draft.

RS> Us old ENUM types have been over this for years. Presumable the syntax
could be E2MD+foo as in E2MD+SIPD where the metadata is SPID=xxxxxx; 

RS I still think this whole concept is undeployable since it would require
the network elements using E2MD to add an additional stack and the resulting
code overhead, though the option I'd certainly keep open since folks might
come up with ideas we haven't thought of yet.  Most of the use cases we've
gone over here are relatively simple text strings. If people want to use
HTTP for stuff fine then write up a use case in the registration procedure
we'll define. But for the first phases here simple text strings will work
just fine.

--
Dean

_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 19 Mar 2010 15:31:31 -0400

The document draft-hoeneisen-e164-to-metadata-02 proposal does not propose what you describe in number 2 below (a new ENUM service called E2MD that contains a single string that holds ALL the metadata).  It proposes a new DDDS service called E2MD (not a new ENUM service), which can be used to serve up sub-sets of meta-data elements that are grouped by a Service-Type:SubType pair (not All the metadata in a single string).  Your number 3 below a *little* more accurately captures what the draft is proposing.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, March 19, 2010 3:03 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata

--
Dean

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Jay Daley <[email-masked]>
Date: Sat, 20 Mar 2010 15:57:39 +1300

On 20/03/2010, at 8:03 AM, Dean Willis wrote:

> 
> We touched on this earlier, but got derailed by the "Why don't we just use HTTP for everything" question that Cullen did us the honor to ask.

HONOR?!!  Has this suddenly become the ITU while I had my back turned?

Jay

> 1) encoding metadata into a "data" URI (which is considered pretty hokey by the URI people, as the hunk of data is NOT universal, and while it may be a resource, it's not an indicator and also isn't used to initiate a communications session directly, making it inconsistent with the "u" flag in the Naptr record).
> 
> 2) creating a new Enumservice name, like "E2MD", that can return a text string containing the metadata (the basic model in draft-hoeneisen-e164-to-metadata-02). Currently, the expressible range of metadata is unbounded by this draft; the same string holds ALL the metadata elements, presumably in a syntactically delimited form something like name-value pairs.  In some use cases, there is arguably a need to privacy-protect some of the values, so we might have to encrypt some of them. This raises key management questions.
> 
> 
> 3) Creating a new Enumservice for each type of metadata, and encoding the metadata appropriately. AFAIk, we haven't talked about this one much yet
> 
> 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to be an absolute URI.  We're not exactly sure what this URI has in it, yet.
> 
> 
> 
> 
> Let's talk about what we could do with #4 by using a hybrid of ENUM for the lookup and some other protocol, specifically HTTP, for the result phase.
> 
> We could reasonably put the metadata in a file/record/member (pick your own terminology) and stick the URI for that metadata into the E2MD NAPTR record as an absolute URI.
> 
> In this approach, to find someone's CNAM, I would first get their NAPTR from ENUM using the phone number, then do an HTTP GET operation on the resulting URI to retrieve the metadata, then pull the CNAM out of the metadata.
> 
> This has a couple of big options over putting the metadata directly into ENUM:
> 
> 1) The metadata can conceivably be large, which allegedly makes for problems with DNS' use of UDP.
> 
> 2) The web server can use standard AAA mechanisms to decide whether the requester is authorized to see the metadata, and if so, which metadata to return.
> 
> 3) HTTP allows the web server to use other information known about the requester to decide how to answer the query. This is useful for a lot of cases that people have been proposing to build around enum, like egress route selections.
> 
> 4) HTTP request parameters can be used to select a subset of the metadata for the query, for example just asking for calling name or in-use status.
> 
> 
> 
> 1) The HTTP server has to be reachable from the requester. We KNOW that DNS was in some way reachable already; how much of a burden is to expect HTTP to work too?
> 
> 2) The HTTP server might be capacity-constrained. Of course, we have HTTP tricks to deal with this, like load-balancers, anycast, etc.
> 
> 3) It's arguably more overhead; there's an additional TCP setup, perhaps TLS, perhaps a challenge/response sequence.
> 
> 
> 
> Would the E2MD working group be willing to consider this sort of approach, or are we restricting ourselves to a pure DNS model?
> 
> --
> Dean
> 
> 
> 
> 
> 
> 

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Mar 2010 12:20:55 -0500

Cartwright, Kenneth wrote:
> The document draft-hoeneisen-e164-to-metadata-02 proposal does not
> propose what you describe in number 2 below (a new ENUM service
> called E2MD that contains a single string that holds ALL the
> metadata).  It proposes a new DDDS service called E2MD (not a new
> ENUM service), which can be used to serve up sub-sets of meta-data
> elements that are grouped by a Service-Type:SubType pair (not All the
> metadata in a single string).  Your number 3 below a *little* more
> accurately captures what the draft is proposing.
> 

Thanks, that's helpful.

I've been a little sloppy on the difference between an ENUM service and
a DDDS service -- the outside world seems to use the terms
interchangeably, as in "any use of a NAPTR record to point to a phone
number thingy".

As I understand it, ENUM is a DDDS service more properly called E2U, and
Bernie's proposal defines a new DDDS service E2M which has similar
properties to E2U, except that the strings returned are metadata instead
of URIs used to initiate a session. This proposal also extends the NAPTR
syntax of RFC 2915 to add a "t" flag for "text" to get around the "data
isn't a URI" debate. For each named metadata type, it uses a subtype
name that attaches to the E2M service name to indicate that metadata
type (ex. E2M+CNAM). For each metadata element (for example, a CNAM)
there is one record in the DNS. Additional elements require additional
records. Individual metadata elements are therefore size-limited by the
fact that they're in a DNS record, which raises size issues for privacy
protection techniques such as encryption.

Does this more accurately match your read of Bernie's draft?

Open question in my head: Why are we extending the RFC 2915 syntax with
a "t" flag instead of using its "p" flag? There's probably a good
reason, but it isn't apparent to me at the moment.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 20 Mar 2010 12:22:40 -0500

Jay Daley wrote:
>> We touched on this earlier, but got derailed by the "Why don't we
>> just use HTTP for everything" question that Cullen did us the honor
>> to ask.
> 

Sorry, too much Dumas in my childhood reading. Cullen's question was in
the nature of something that starts a duel, making it a matter of honor.

--
Dean

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 20 Mar 2010 13:51:37 -0400

Hi all,

You should be thinking outside of the E164 box.
the proposal is equally applicable to another major
ITU-T namespace - OIDs - that are about to be
instantiated in DNS exactly as has the E164 namespace.
It is known as the OID Resolver proposal and about
to be adopted by joint ISO/ITU-T action.

Interestingly, the only existing means for doing any
OID lookups for metadata is an HTTP adjunct
that was built several years ago.  See
http://www.oid-info.com/

Many of those working in this area are looking
forward to great things from the new IETF
e2md effort.  The operative focal point on the
ITU-T side is a group known as Q.12/17 which
manages the OID namespace standard together
with ISO|IEC SC6.

Among other things, the namespace is positioned
to be the principal global home for providers (i.e.,
using IETF Enterprise Number OIDs), RFIDs, and
eHealth objects, in addition to legacy uses like
SNMP MIBs and X.509 certificate policies.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 20 Mar 2010 14:48:32 -0400

Brother Tony!  Identity .. sure there is certainly no limit to the kinds of
things that can be defined here its just defining the protocol and a simple
registration procedure like we did in the ENUM WG. E.164 is the low hanging
fruit and some carrier need some specific things but the E.164 use case is a
good start.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Rutkowski
Sent: Saturday, March 20, 2010 1:52 PM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata

Hi all,

--tony

---

From: [email-masked]
Date: Sat, 20 Mar 2010 11:07:38 -0800

> records.
> ...

Yes, exactly.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 20 Mar 2010 21:16:08 +0000

Hi Folks,
Spot on ... With the minor clarification that this is NOT anything to do with
RFC2915 -- that was obsoleted years ago. It was replaced by RFCs 3401-3405.

RFC2915 (and 2916) were considered too sloppy (or short :), so we ended up
with the Bible written in High Martian that is RFC 340x.

E2MD is going to be a new DDDS application (specified in keeping with the
template in RFC3402). It uses the DNS as its database, with rules formatted
as NAPTR resource records, both as specified in RFC3403 (which is the doc
that deep sixed RFC2915).

Re. just using the 'p' flag ... good point, but I'm not sure anyone knows
what "application specific and outside the scope of this document" means.
The text talks about the protocol part of the services field -- we don't
have such a part any more, and it also says that DDDS processing stops
when a record with this flag is processed, which is at least dodgy.
Section 4.3 of RFC3404 (where that flag is "defined") needs a "review
with menaces" anyway -- it goes on to reserve all alphabetical flags
for "this specification", which is patent tosh.

all the best,
 Lawrence

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 20 Mar 2010 23:24:39 +0100 (CET)

Hi Dean et al.

On Fri, 19 Mar 2010, Dean Willis wrote:

> 1) encoding metadata into a "data" URI (which is considered pretty hokey by 
> the URI people, as the hunk of data is NOT universal, and while it may be a 
> resource, it's not an indicator and also isn't used to initiate a 
> communications session directly, making it inconsistent with the "u" flag in 
> the Naptr record).

As you say this has not worked out

> 2) creating a new Enumservice name, like "E2MD",

This is _not_ about a new Enumservice, but about a new DDDS application.
E2MD specififies a framework that allows to register E2MD services. 
Each E2MD service will go through Expert Review and Specification 
Required process (RFC 5226). Pretty much the same way as we go with 
Enumservices.

> that can return a text string containing the metadata (the basic model 
> in draft-hoeneisen-e164-to-metadata-02). Currently, the expressible 
> range of metadata is unbounded by this draft; the same string holds ALL 
> the metadata elements, presumably in a syntactically delimited form 
> something like name-value pairs.

Each E2MD service registration must set these boundaries. If a E2MD 
service registration tries to keep it unbounded, the expert is unlikely 
to accept the proposal (there will be guidance in the base spec about 
this).

> In some use cases, there is arguably a need to privacy-protect some of 
> the values, so we might have to encrypt some of them. This raises key 
> management questions.

Privacy also must be addressed with each E2MD service registration.

> 3) Creating a new Enumservice for each type of metadata, and encoding the 
> metadata appropriately. AFAIk, we haven't talked about this one much yet

If I understand you correctly, here you are talking about the E2MD service 
registration as described above.

> 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to 
> be an absolute URI.  We're not exactly sure what this URI has in it, yet.

This is intentional to allow the 'indirection' case, where a URI is 
returned, and the actual metadata can be retrieved using this URI.

In some cases this is the only way to go, in particular if the metadata 
returend is going to be large and/or if answers to queries are source 
dependend and/or if privacy issues can not be addressed by other means.

cheers,
  Bernie