Subject: [Enum] One more quality "experience"

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 25 Feb 2004 12:05:28 +0000

Hi Folks,
   I did say that the experiences draft was a living document, didn't I?

If an ENUM client can't handle//support//understand fields (or the 
result) of a NAPTR,
then it can discard it and carry on with processing of any remaining 
NAPTRs. This seems
reasonable to me (see 2.9 of the "experiences" draft).

RFC2916bis (section 1.3) requires a client to process NAPTRs sorted on 
the ORDER field,
and to always deal with NAPTRs with a "winning" ORDER value first. They 
can take the
PREFERENCE field "under advisement", but they MUST consider the ORDER 
field value.

However, if a client can't handle any of the NAPTRs with this winning 
ORDER value, what
do they do - give up or carry on?
At least some clients appear to be sorting all of the NAPTRs in a 
domain first on ORDER
and then on PREFERENCE, and processing entries from this sorted list 
one by one. If they
can't handle the "current" NAPTR, then they go on to the next.

This does have a (fairly subtle) implication for Registrants; if you 
just want to "disable"
a NAPTR, you shouldn't just change the ORDER value (to, say, 250) but 
leave it in the zone.
At least some clients will (eventually) get around to processing it if 
they can't handle
any of the other ones.

Thus, please don't put in a test NAPTR with an ORDER field value of 250 
knowing that it
won't get processed (and you won't get called at 3 in the morning). If 
(for example) the
other "winning" NAPTRs all have a syntax error, it may, and you will :|

On the grounds that this is very close to the logic of section 2.9 of 
the "experiences"
draft, I don't think it needs its own section, but I await any 
comments. Failing that,
I'll re-jig 2.9 to spell this out once we come out of shadow.

all the best,
   Lawrence

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