Subject: [Enum] E2U replacement field usage

From: Lawrence Conroy <[email-masked]>
Date: Tue, 17 Sep 2002 12:34:16 +0100

Hi Michael, Patrik, folks,

I contend that a D3S application will not change, in mid-search, to
another D3S application. Thus, if an E2U search has been initiated,
the valid outputs will either be a terminal rule OR a non-terminal
rule, both of which MUST have E2U within their service field.

Given that rfc2916bis specifies both a particular D3S application
AND the application-specific usage of DNS, why can't we simply specify
that the replacement field MUST be empty, and the regexp field MUST
be non-empty?

This simplifies the processing, test cases, and so on. It also removes
the one place where there is a database-specific item "outside" the
rule retrieval process.

It also avoids a quirk in the D3S algorithm/D3S database/ ENUM (E2U
Application)/ specifications. The conversion from key to DNS domain
is "hidden" inside the rule retrieval step. If there is no replacement
field, then there's no need to bypass this conversion when looping
back from a non-terminal NAPTR as we won't have a domain name already.

Thus the question is:
- can we specify that the replacement field is ALWAYS empty for ENUM
   (the E2U D3S Application), and if not, why not?

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: Tue, 17 Sep 2002 10:29:05 -0400

> rule, both of which MUST have E2U within their service field.

That is correct. Changing application inside the algorithm is 
absolutely illegal (I wouldn't know where to begin in figuring
out that one!)

> that the replacement field MUST be empty, and the regexp field MUST

You can do that. The replacement field is an easy, BIND-checked way
of handling the simple regexp case though. BIND will even include
records about anything in the replacement field as additional data.

> the one place where there is a database-specific item "outside" the

True...

> back from a non-terminal NAPTR as we won't have a domain name already.

You won't have a domain-name? A non-terminal NAPTR will have to produce
a domain-name either as the output of the regexp or be found in the
replacement field. Even if you specify that the replacement field is
always blank then a non-terminal NAPTR will still have to produce a 
valid domain-name for the next set of records. Or did I read that
last paragraph wrong?

>   (the E2U D3S Application), and if not, why not?

Yes. You can tie the replacement field down as always null since the
regexp can still produce the same value. Since we don't have per-field
compression anymore anyway you really won't take a hit on the packet size.
The only feature you won't get is BIND 8 and 9 have a default behavior where
they _always_ insert additional information about domain-names when they
are inserted into a response packet. 

-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!                     !!