Re: [apps-discuss] [dane]

[Martin Rex <[e-mail]>]

Ned Freed wrote:
> 
> > 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".)


The rfc2223 document title is "Instruction to RFC Authors".  The Updates:
header has a purely editorial meaning for the *new* document, but the
result can certainly be very technical for the *old* document!

Updates: should only be used if the change is supposed to apply not only
to implementations of the *new* document, but that all new implementors of
the *old* (=updated) document should ignore certain parts of the old
document and use the new document instead.  But in order for this to
work,
  - a section in the new document is *REQUIRED* which list exactly
    which pieces of the *old* (=updated) document are completely
    replaced by which pieces of the new document
  - retaining full interop with old implementations based on only
    the full spec, and clear distinction of features that were
    added or dropped in the updated parts.


> 
> > 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.

That is not necessarily a contradiction.

But there is a certain mess in the meta-data of published RFCs.
Publishing a change to specification will not magically change
the behaviour of an installed base, therefore "changes" need to
account for the reality of life.


-Martin