Re: Send-N draft: draft-bellis-enum-send-n-02 published
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <OFED895661.E27DDF0D-ON8025748A.004AA4F5-8025748A.004C8181@nominet.org.uk> |
> I am puzzled, however, by this long and peregrinating thread. > There is one question that seems to have been missed - does this need > to be an E2U NAPTR, or instead could it use another DDDS Application > (i.e. use a different collision-avoidance string)? That's a very interesting question, and one I don't have an obvious answer for. Peter Koch said that Send-N isn't actually an ENUM Service, and technically he is of course correct. > There is nothing in 3761 (or 3761bis) that says that E2U NAPTRs are > the only ones that can appear in a domain under e164.arpa. > If this were another DDDS Application, any Send-N will come back in > the same DNS response to a type 35 question. There would continue to > be no overhead for the en bloc case. There is certainly some sense in clients being able to filter by type rather than subtype, particularly as the processes for filtering and ordering based on subtype are less than crystal clear. If I have any niggle with the idea it's that this would effectively interleave two separate DDDS applications in one DNS lookup. That doesn't really bother me, although I can imagine some might object. > There would, however, be more flexibility, instead of being constrained > with a comedy URI. Public ENUM clients will automatically discard any > such NAPTR in the RRSet as it doesn't have the right collision-avoidance > string (E2U) -- assuming that the client is not totally broken. > > So... what's wrong with moving this (and maybe other PSTN-internal > meta-information specifications) into their own DDDS Application? For reasons already outlined it would still need to be a DDDS NAPTR, and therefore it would still need to use the regexp rewrite fiel. I'm not convinced that it would make sense to radically alter the currently proposed Send-N URI format, particularly if Send-N is just one of a set of future meta-data types. Richard - what plans (if any) do you have for your CNAM draft? Obviously I've borrowed heavily from that for my URI syntax. Ray