Re: [apps-discuss] [dane]

[Ned Freed <[e-mail]>]

> Ned Freed wrote:
> >
> > > I don't think is there a definite need e.g. for something that
> > > says how to use DANE with XMPP or SMTP to update the TLSA RFC -
> > > that might or might not be needed but we won't know until its
> > > being done.
> >
> > But that's what it currently says is needed.
> >
> > > Nevertheless, how about if it said:
> >
> > > "Note that this document does not cover how to associate
> > > certificates with domain names for application protocols that depend
> > > on SRV, NAPTR, and similar DNS resource records. It is expected that
> > > future documents will cover methods for making those associations.
> > > Those documents may or may not need to update this one."
> >
> > That's essentially the change I suggested making.


> Writing that those apps-protocol-specific documents (defining how to
> use a particular protocol with TLSA/DANE-protocol) might need to update the
> TLSA/DANE-protocol document is misleading (and IMHO should be avoided).

> http://tools.ietf.org/html/rfc2223#section-12

> defines the "Updates:" metadata for RFCs to have a very narrow and purely
> editorial meaning.  "Updates:" is meant to refer to those situations
> where a paragraph or section of a new document **completely** replaces
> the same paragraph or section of a previous RFC.

That section doesn't say or even imply that the change has to be purely
editorial in nature. (The word "editorial" appears nowhere in the section and
neither do the words "paragraph" or "section".)

And even if it did, the facts are that Updates: is routinely used by documents
that make a substantial technical change to a previous document. A particularly
relevant example of this is the EAI specification RFC 6532, which states that
it "Updates: RFC 2045" and the nature of this update is to remove a MUST NOT,
which is just about as substantial a technical change as you can make.

So if there's a bug here (and I don't think there is), the bug is in RFC 2223.
Not in this use of Updates:.

> It is probably much more common to "extend" an existing protocol or
> describe/define additional usage scenarios without changing the original
> specification, simply by using the extensibility of the original protocol.

Sure, but it is also common to make a technical change and call it an update.
You may not like that, but that's how it works.

> Normally, such "expected usage" should not use the editorial
> rfc2223-Updates: metadata.  But the use of the Updates:&Obsoletes:
> meta-data tags in RFCs is not consistent, a number of RFC seem to
> ignore the rfc2223 definitions of what these headers are supposed
> to indicate.

Again, if there's any inconsistency, it's in RFC 2223.

				Ned