Subject: [Enum] Impl.Issues: 4 - treatment of ORDER in NAPTRs with non-supported ENUMservices

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 4 Nov 2003 11:46:23 +0000

Hi folks,
   this one's pretty obscure, but it's tied to the way that Clients
select from several possible contact choices. We have seen a few
domains within which NAPTRs with different ORDER field values exist,
and it's not always completely clear how to react (i.e there are corner
cases like this).

The ENUM Client can select which of a set of NAPTRs that share the same
("winning") ORDER field value based on its capabilities; thus, if it
doesn't handle the ENUMservice h323, then even though this appears in
a NAPTR with the best priority/preference, the Client can discard it
and go on to the next best, and so on.

However...
Q: If the Client discards a NAPTR as it specifies an un-supported ENUMservice,
then should the Client re-evaluate the "winning" ORDER field value after
discarding the NAPTR containing the un-supported ENUMservice?

Background: This came up as a corner case when we were testing non-final
NAPTR processing - the "referred" domain had NAPTRs with a new "winning"
Order field value, but none of the NAPTRs in that domain were supported,
so should a Client "return" to try with lower preference/priority NAPTRs,
or just give up, as it had hit one with a new "winning" Order value?

Opinions gratefully received - at present, our client only considers the
Order field value within a single RRset, so if no NAPTRs give useful
results in a "recursive" call, it returns and continues with any unprocessed
NAPTRs in the "referring" domain (i.e. the one with the non-final NAPTR).

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