Subject: Re: [Enum] One more quality "experience"

From: [email-masked]
Date: Thu, 26 Feb 2004 16:04:57 +0900 (JST)

Dear, Mr. Conroy and enum list members,

I'm Kazunori Fujiwara, and I'm developing ENUM client and registry.

I agree with you.

I read rfc2916bis and DDDS RFC.
In RFC3403 page 9, there is a E164 Example.

   $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
   IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:[email-masked]!i"     .
   IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:[email-masked]!i"  .

If we MUST process in ORDER-field order without checking SERVICE-field,
we MUST choose order=100 entry only.

# RFC3404 Appendix A. Pseudo Code seems to be such code.

But in RFC3403 page 9 E164 Example,

     "These state that the available protocols used to access that
     telephone's service are either the Session Initiation Protocol or
     SMTP mail."

So, I assume ENUM client can check SERVICE-field(enumservice match)
before ORDER-field sorting.

Is it correct?

Regards,

-- 
Fujiwara, Kazunori	JPRS

> From: "Conroy, Lawrence (SMTP)" <[email-masked]>
> Subject: [Enum] One more quality "experience"
> 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
> 

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