Comment by Zr40 | Hacker News Reader

Comment by Zr40 | Hacker News Reader

Parent Full thread

RFC2782 does not prohibit the use of SRV records with those protocols.

    In general, it is expected that SRV records will be used by clients
    for applications where the relevant protocol specification indicates
    that clients should use the SRV record. Such specification MUST
    define the symbolic name to be used in the Service field of the SRV
    record as described below. It also MUST include security
    considerations. Service SRV records SHOULD NOT be used in the absence
    of such specification.

RFC2119 defines 'SHOULD NOT' as follows:

    This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

Maybe “prohibit” was the wrong word. On the other hand, I would argue that a “SHOULD NOT” is stronger than you think: The HTTP standard (RFC 2616) says that:

“[…] the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

I would argue that very few people would claim that it’s OK for HTTP servers to have HEAD and GET requests be non-idempotent just because they feel like it. “SHOULD NOT” prohibitions should not be ignored just because you really want to do it.

Do you really think that's the reason? Specs should be ignored when they state things beyond their scope. The a restriction on DNS depending on if a newer HTTP spec definitely something that can and should be ignored if it helps clients.

I really think that a “SHOULD NOT” in an RFC is a sufficient reason to not do a thing, yes. I further think that specifying the usage of SRV record is wholly in scope of the RFC specifying the SRV record.

Reply on news.ycombinator.com