Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Oct 29, 2014, at 6:45 PM, Andy Newton <[e-mail]> wrote:
> It is option 3. However, the implementer wishes to construct a database is up to the implementer. They need to be able to parse IPv6 addresses and use them to construct whatever key their database uses, be it textual or binary. Having implemented both forms, you cannot simply take the textual representation and use that as a key.

You seem to be saying it's option 1, then, not option 3.

> All that being said, I don’t understand the suggested fix. Section 5 of RFC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they are different addresses. There is no collision so the need for canonicalization isn’t obvious. Cutting embedded-IPv4 addresses does make implementation easier, and I don’t think anybody would actually care if they were explicitly forbidden.

It should be the case that there isn't more than one way to represent the IP address.   Or else it should be the case that the server is required to accept the IP address no whether it is canonicalized or not.  You have to tell the client what to expect.   If it's okay for the client to send any old syntactically valid IP address, that's fine, but the document doesn't currently say that, and so a server implementor might _assume_ that you mean that only addresses canonicalized according to section 4 of RFC 5952 are permitted.   The point of normative language is to make sure that we don't rely on the implementor to make the same assumptions we made.

> Nameserver searches return nameserver objects. I don’t know how useful that would be a to a spammer, but to a nameserver operator trying to determine which registrations are pointing to their nameserver, that seems useful.

Wouldn't they already know, since they configured the name server?