Subject: [Enum] D3S details redux

From: Lawrence Conroy <[email-masked]>
Date: Fri, 13 Sep 2002 09:42:53 +0100

Hello esteemed authors, folks,
   I did ask for a couple of clarifications on the operation of D3S.
This was swamped by the policy discussion, so here's a slightly expanded list.
(I think that anyone implementing ENUM will need to know these details).

The questions are on the D3S algorithm when using DNS, and particularly
using the ENUM D3S application (surprise, surprise :)

*    for a non-terminal NAPTR, it seems that the "replacement field" 
is not used
      to evaluate the "next round" of D3S processing - the regexp is 
used instead.
      => the regexp field has data => the replacement field is empty.

      Is this correct?

*    for a non-terminal NAPTR, when evaluating the next key for the 
ENUM algorithm,
      the usual order and precedence fields are used to prioritise 
processing as usual.
      Also, the service field is used to match against the end user's interests
      - i.e. the NAPTR is rejected if the service field is "E2U+beer" 
and the client
      is not interested in the enumservice "beer" (must be in the 
U.S., I guess :).

      Is this correct?

*    for a non-terminal NAPTR, I THINK that the result of regexp 
processing should
      be a "pure" E.164 number (e.g. "+441794833666", which means the next round
      should continue at the ENUM domain 6.6.6.3.3.4.9.7.1.4.4.e164.arpa). This
      fits with the flow diagram in the D3S Algorithm draft, and with 
the "output
      of first rule" section in RFC2916bis.

      Is this correct?

I do need these clarified fairly quickly, as they have an impact not 
only on the
implementation (you can't interwork without knowing what to put into 
the regexp)
and as I don't know what the syntax should be in any "non-terminal" examples.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

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

---

From: Michael Mealling <[email-masked]>
Date: Mon, 16 Sep 2002 16:53:58 -0400

>      => the regexp field has data => the replacement field is empty.

Close but not exactly. Either the regexp field or the replacement field
are empty. If the regexp field is empty then the replacement field
will contain the next key. The replacement field is a shortcut way
of saying this:

/^.*$/example.com/

and was required by the DNS folks so that domain-names could be
compressed. Since then 'per-field' compression is out and if we
had the ability to predict the future we wouldn't have had a 
replacement field....

>      is not interested in the enumservice "beer" (must be in the 

Correct. There is an assumption in the document that any subsequent
NAPTR records requested will also adhere to the "E2U+beer" service
statement but it isn't clear if ENUM has that requirement or not.

>      of first rule" section in RFC2916bis.

Not really. The key has to be database specific. If this wasn't the case
then it would be very hard to use ENUM with other databases beyond DNS.

> only on the implementation (you can't interwork without knowing what to 
> put into the regexp) and as I don't know what the syntax should be in 
> any "non-terminal" examples.

I'm finally back from vacation so fire away with the questions. Sorry it
took so long but Alaska was particularly beautiful this time of year:
http://bailey.neonym.net/vacation/

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net
--------------------------------------------------------------------------------
!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !!
!! you can send something along with it! Business cards, momentos, cremains,  !!|| anything! See http://www.transorbital.net for details!                     !!

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 17 Sep 2002 13:28:27 +0100

At 4:53 pm -0400 16/9/02, Michael Mealling wrote:
>  > *    for a non-terminal NAPTR, it seems that the "replacement 
>field" is not used
>  >      to evaluate the "next round" of D3S processing - the regexp 
>is used instead.

If it were that simple :) - a better (and valid for ENUM) example would
be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/

See my other mail on "E2U replacement field usage" for more on this.

<snip>

>  >      fits with the flow diagram in the D3S Algorithm draft, and 
>with the "output

This has me perplexed - I don't think I understand the answer.

I think that the key should NOT be database-specific as generated by the output
of the first well known rule and the output of non-terminal regexp processing.

Otherwise, it's very hard to use another database, which is a major feature
of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition the
issues so that one could data hide - e.g. the database-specific forms 
are hidden
within the rule retrieval step (step 2 in section 3.3 of ddds-07.txt).

That includes the re-write from a "stripped" E.164 number to a domain name -
it's the first thing that the rule retrieval function does.

If we do want to expose this database-specific format, then I guess what your
comment means is that the regexp output for a non-terminal will be a domain
name, and rfc2916 needs a re-write to explain that the "domain name 
translation"
is actually part of the first well known rule rather than the start of the rule
retrieval process (as does section 6.2 of dns-ddds-database-09.txt).

I have to say I HATE this interpretation - writing a regular expression to
convert from the AUS to a domain name is non-trivial and very prone to error
(and makes the NAPTR much longer).

<nice slides, BTW - ice is really that blue?>

All the best,
  Lawrence

---

From: Michael Mealling <[email-masked]>
Date: Tue, 17 Sep 2002 10:46:54 -0400

> be /^.*$/6.6.6.3.3.4.9.7.1.4.4.e164.arpa/

Actually, it was that simple. Remember, the replacement field on a non-terminal
NAPTR is never seen or used beyond that cycle in the algorithm. Just as
long as the resulting domain-name has the correct NAPTR records associated
with it. I.e.

First loop produces a query for 2.3.7.0.7.1.7.0.7.7.1.e164.arpa that
returns a NAPTR that is non-terminal and has "neonym.net" in its 
replacement field. "neonym.net" is queried for NAPTRs and it gets back
a series of NAPTR records with the correct ENUM NAPTRs that contain
the valid terminal records...

> I think that the key should NOT be database-specific as generated by the 
> output of the first well known rule and the output of non-terminal regexp 
> processing.

Keys are internal to the algorithm. You should never see or use them 
outside it. The input to the algorithm is the Application Unique String
and the output is the output of the last matching rule. Keys are internal
and database dependent.

> of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition 
> the issues so that one could data hide - e.g. the database-specific forms 
> are hidden within the rule retrieval step (step 2 in section 3.3 of 
> ddds-07.txt).

Its the Rules that are mostly database independent. They still must
produce a key that is meaningful to the database, but the semantics
are somewhat portable (not that some databases may have interesting 'semantics'
like DNS that impact Rules). I looked at how other databases would be used
and it became immediately clear that keys (and to some extent Rules) had
to be database dependent. Its the inputs and outputs that are visible.
All the data hiding is internal to the algorithm. Once you get
beyond the First Well Known Rule you should consider DDDS to be a black box....

> it's the first thing that the rule retrieval function does.

One of the requirements built into DDDS was that the output of one rule
is not allowed to be the input of another rule. All Rules must only ever
consider the AUS. What I think you are suggesting is that a non-terminal
Rule be able to produce a telephone number and not a domain-name. The only
value I can see in doing that is being able to switch database types
mid-algorithm which would, IMHO, be a bad thing. If you really need to 
do it then there is the old 'p' flag from the URI Resolution application.

> If we do want to expose this database-specific format, 

Actually, I don't want to expose it. It should never be seen outside the
algorithm....

> then I guess what your comment means is that the regexp output for a 
> non-terminal will be a domain name, and rfc2916 needs a re-write to explain 
> that the "domain name translation" is actually part of the first well known 
> rule rather than the start of the rule

Correct. I'll go correct what I wrote latter today...

> (and makes the NAPTR much longer).

Nope. You won't ever need to use a regexp to convert an AUS into a 
domain-name. Remember, internal to the algorithm the domain-name can
be _anything_.

> <nice slides, BTW - ice is really that blue?>

Even blue-er than the pictures made it look. Its a shade I've never
really seen before. Very stricking... and _cold_.

-MM