4 ms·

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 applicat

by Zr40 13y ago

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.

teddyh 13y ago
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.
- MichaelGG 13y ago
  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.
  - teddyh 13y ago
    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.

by Zr40 13y ago

teddyh 13y ago

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.

MichaelGG 13y ago
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.
- teddyh 13y ago
  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.