Subject: [Enum] [ticket.frobbit.se #871] DDDS - RFC3403/RFC3404 generation of target FQDN for Non-Terminal NAPTR

From: "lconroy via RT" <[email-masked]>
Date: Sun, 26 Mar 2006 15:17:32 +0200 (CEST)

Sun Mar 26 15:17:32 2006: Request 871 was acted upon.
Transaction: Ticket created by [email-masked]
       Queue: 3761bis
     Subject: DDDS - RFC3403/RFC3404 generation of target FQDN for Non-Terminal NAPTR
       Owner: Nobody
  Requestors: [email-masked]
      Status: new
 Ticket <URL: http://ticket.frobbit.se/Ticket/Display.html?id=871 >

RFC 3403 section 4.1 (and RFC 3404) imply that the REGEXP field can  
be used to generate a FQDN as the target for a non-terminal rule.
RFC 3404 in particular suggests that one can choose which to use, and  
that one should look in both fields to see which one is not empty.

I have problems with this "look at both and then use whatever is  
there" policy.
AFAICT, the only ENUM clients that DO handle NTNs expect the target  
FQDN only to be in the replacement field.
The other DDDS Applications that use non-terminal NAPTRs ALL put the  
target FQDN in the replacement field.

I also have problems with the basic mechanism for generating a FQDN  
from the REGEXP field.
How does one do this, when each DDDS Application works on its own  
kind of Application Unique String?

Options:
(i)   Clarify in RFC3403 (and in RFC3404) that the target FQDN in a  
Non-Terminal NAPTR MUST be in the replacement field always.

(ii)  Clarify in RFC3403 that with an empty flags field (i.e. the  
absence of a flag), a target FQDN MUST be in the replacement field.
If a DDDS Application wants to generate a target FQDN from the REGEXP  
field content, then it must define a specific flag to do this (and  
define how the AUS and REGEXP is used to generate a FQDN).

[I prefer the latter option, as it means that we do not have to  
change RFC3404, and it gives more flexibility]

Note: We could also spell out (in RFC3403) that an empty flags field  
ALWAYS means that this is a non-terminal NAPTR.

atb,
     Lawrence

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