|
I’d like to echo Brian’s
comment, it is what some in the design team think. The NAPTR gives us quite a
bit of flexibility to express what a response to a LUF or LUF+LRF resolution
query could be. When trying to build something
more generic than a DNS RR like NAPTR, you basically end up doing the
following: -
Take NAPTR fields
out of that structure and put them as attributes of a new object -
Define ways to
properly return URIs -
Try and re-create
the meaning of svces in NAPTR -
Add something close
to order and preference fields in NAPTR Bottom
line, given the implementations of NAPTRs in the space we’re targeting, is
there really something you can’t do with a NAPTR? Jean-Francois From:
drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Brian
Rosen We haven’t found anything we
can’t do with a NAPTR, with parameters. Could someone cite an example of
what you can’t do with a NAPTR? Brian From:
drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Guyton,
Deborah A The protocol design team has been working on a data model
and protocol for the registry provisioning interface. We have associated with each public identifier routing
information in the form of resolution answers on the name server.
Initially we looked at specific types of routing info – such as NS and NAPTR
Resource Records. We have heard feedback that this is too DNS-centric. We are
discussing collapsing these into a “generic” Route Object. This may lead to a
long set of attributes, one would be route type, but many others would be
optional and may only apply to a given route type. We would appreciate some feedback –does it make sense to
collapse into a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.