Re: [e2md] Action Required: Your version of the Problem statement needed

[Lawrence Conroy <[e-mail]>]

Hi Otmar, folks,
 Regarding non-URI data ...

 (i) Actually, we DID have a perfectly valid URI that can
      be used to contain data; the Data URL.
     Apart from anything else, this IS used in HTML in existing
      web sites that do not cause the interwebs to implode.
     It would have worked just fine;
      use of data: was blocked because IESG folk didn't *like* it.
     Otherwise, we wouldn't be having this extended meditation on
      the number of angels that will fit on a pinhead.

Hence Plan B was to define a DDDS application to use NAPTR to hold
 non-URI data, without the arcane restrictions on use.

(ii) As in all things, the problem lies not with ENUM but in
      the stunning way in which DDDS was written and approved.
     It is perfectly possible** to define a DDDS Application
      that uses NAPTR to produce an output other than URIs
      (viz. SNAPTR, D2U, ...)
     That DDDS application would NOT inherit the same textual
      restrictions as E2U on use of its target -because it is not E2U-.
     That application would have a new flag** indicating that the
      "target output in REGEXP is text", and explaining how the text
       should be interpreted.
**  Speaking of stunningly stupid, someone might raise an erratum on
     3404, as that reserves *all* flags for future versions of itself.

I continue to fail to see what is wrong or hard about this. Either:
- we work on E2U to remove the arcane textual blocks on data that
   does not *directly* lead to making a communications session to
   a remote target, is not definitely an assigned E.164 number, ...
OR
- we create a new DDDS application and rely on resolvers cacheing
   the NAPTR RRset.

My preference is for the former, but I'm easy either way.
Unused & Send-N & CNAM & "SPID" should be out the door quickly once
 folk decide which way they want us to work the Layer 9 problem.
"Small bite", "short timescales", "running code" -- this hits
 the traditional IETF punch points.
It might even be done before I retire.

----

Regarding selective responses ...
Providing different answers based on who's asking is indeed not the
 way that DNS servers according to 1034/1035 are supposed to act.
Perhaps one should raise that with OpenDNS & Google?

Hadriel has already said that this IS happening/going to happen, and
 he's waiting for a DNS code point to do this officially. (see, e.g.
 his posting of 29th march, that I received at 22:17:18 +1:00).

Once that code point is in place, I would imagine that the E2MD output
 would be a description of the data that *could* be returned and how it
 would be used.
Why this particular data was returned to a query by this particular
 client is NOT in scope for E2MD, AFAICT.

----
 
For the other scribes, have a thought to decaf and reducing the
 intake of psychotomimetics.

all the best,
  Lawrence

On 15 May 2010, at 21:33, Otmar Lendl wrote:
> On 2010/05/14 19:05, Richard Shockey <[e-mail]> wrote:
>> Oh certainly all of the below are essential attributes of a successful e2MD
>> system.
> 
> Which contradicts your
> 
>>> Non URI data in ENUM. What about that doesn't people understand?
> 
> statement.
> 
> Plain DNS and thus ENUM do not provide these extended query features,
> and if you need need them in E2MD, then E2MD is not just ENUM with
> non-uri data.
> 
> You can't have it both ways.
> 
> otmar
> 
>> 
>> Ok. Can I take it as a given that you don't need E2MD to support
>> 
>> * different answers based on who's asking
>> * different answers based on source-URI
>> * different answers based on some kind of trunk (or SIP-peer) information
>> 
>> ?
>> 
> 
> -- 
> // Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933
> // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
> // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
> _______________________________________________
> e2md mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/e2md