Subject: [Enum] Impl.Issues: 3 - service field in Non-final NAPTRs

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

Hi folks,
  there don't seem to be any non-final NAPTRs "out there" yet and I'm not
sure what should be the solution, so this is a pair of straight questions:

Q: MUST a Client ignore the content of the service field in a non-final
NAPTR (i.e. one with an empty flags field)?

Q: MUST a Registrant NOT populate a non-final NAPTR with a non-empty services
field?

Background: We were unclear over whether or not a non-final NAPTR acted
regardless of DDDS application, or instead it could include a non-empty
services field, including E2U and, potentially, ENUMservice token(s).
In the latter case, one could treat the non-final NAPTR as being DDDS
Application specific and possibly even have more than one non-final NAPTR
with each one being tied to a different application (e.g. one for E2U,
one for D2U, one for ...). Furthermore, one could traverse the non-final
if and only if the specified ENUMservice was supported by the Client.

In effect, the intent of the Registrant would be "for contact info for
the h323 ENUMservice within ENUM, look here" or "for contacts for the
sip ENUMservice, look there".

Against that, the Registrant might have decided to leave the services
field of a non-final NAPTR blank, or the Client may choose to ignore
the service field content in this case, so the Client has to be able
to handle the other case (I guess as a "catch-all").

At present, we ignore the services field in our Clients, but I'm
interested in the group's opinions.

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