Hi, Nico, On Sep 12, 2011, at 5:56 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch <touch@xxxxxxx> wrote: >> On 9/12/2011 2:43 PM, Nico Williams wrote: >>> >>> On Mon, Sep 12, 2011 at 3:57 PM, Joe Touch<touch@xxxxxxx> wrote: >>>> >>>> My claim is that: >>>> >>>> SRVs represent services as they are currently assigned by IANA >>>> >>>> a new RR could be useful for things that aren't sufficiently >>>> expressible in the IANA service/port registry >>> >>> Existence proofs show that this is not *actually* so. >> >> The existence proof is that many SRV names have defined TXT fields, >> including the following: > > I meant existence as in "how it's used". I don't see why > Windows/AD/Samba/... can use SRV RRs the smart way while the rest of > us must not. That would be silly. It's not our fault that RFC2782 is > outdated. Nor is it our job to update it. The Windows examples explain their use as basically a naming convention for servers, where they a) add a few prefixes to the FQDN b) some of which violate DNS specs c) where the FQDN doesn't match the hostname i.e., they add foo._bar.nsf.example.net when they intend a FQDN of nsf.example.net There are three problems with that - which could interfere with other interpretations of those SRV records (e.g., tools that might scan those records to monitor service liveness). > But, let's see if we can change the direction of this thread (we're > going in circles). > > Would you oppose an update to RFC2782 to standardize different SRV > RRset _name_ conventions? I would, as per above. That would be pushing context-dependent syntax into the SRV record rather than using a separate RR - where that syntax belongs. Note that SRVs changed DNS RRset name conventions but only for the SRV RR. I.e., the precedent is that changing the syntax requires a new RR. > If not, are you aware of any others who might? > > If you don't object, who should be responsible for making the update, > keeping in mind that these alternative SRV RRset naming conventions > shipped long ago? There are plenty of cases of protocols and extensions that are deployed that don't meet spec. If we should take a cue from deployed code, we should (IMO) follow Apple not Microsoft in this case. Joe _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf