Hacker News Reader

Comment by viraptor | Hacker News Reader

NAPTR is already misused for sip location imho... but this is even worse. The cryptic string

    "u" "E2U+web:http" "!^.*$!http://www.windley.com!"

means that "E2U" is a protocol (E2U doesn't seem to be defined in the same RFC as NAPTR - it means "E.164 to URI" even though the NAPTR query didn't send an E.164 request), "web:http" is a "resolution service" (they should be used the other way around if you believe the RFC, although wikipedia also uses this order). "u" indicates that the original query should be passed through the regex substitution to get a URI.

Could they make it any more complicated than this?

View on HN

>they should be used the other way around if you believe the RFC, although wikipedia also uses this order

FYI the spec changed between rfc2916 and rfc3761:

  The format of the service field has changed.  The old format was of the form "example+E2U", while the new format is "E2U+example".

  Reason for this change have to with the added subtypes in the enumservice, the ability to support more than one enumservice per NAPTR RR, and a general agreement in the IETF that the main selector between different NAPTR with the same owner (E2U in this case) should be first."

Also see: http://www.iana.org/assignments/enum-services

>NAPTR is already misused for sip location imho

Why?

>Could they make it any more complicated than this?

It may look messy, but complicated? You can write a parser in a few minutes. It's simple and it works.

Misused, because why should the client care about your routing? SIP already provides a way to drop the router from the path after relaying the first packet - why put the same exact capability onto DNS then? There are caching issues, routing delays caused by 3 resolver queries (NAPTR -> SRV -> A), etc. etc. Imho enum should be available only explicitly - not as the base routing mechanism.

Complicated - because of regexes and usage of prefixes such as E2U which don't make sense here. Someone created a service based on a custom TLD and marks the entries as E2U even though they don't use E.164 numbers at all. If they cannot get it right, how can users understand it?

Reply on news.ycombinator.com