> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of Ned
> > Freed
> > Sent: Tuesday, July 19, 2011 8:08 AM
> > To: John C Klensin
> > Cc: Ned Freed; S Moonesamy; [email protected]
> > Subject: Re: [yam] Updating multipart/report
> >
> > This is one of the reasons why I prefer to see such restrictions lifted
> > in separate documents. Once the separate document (which can either be
> > one limited to removing the restriction or something more general) advances
> > the restriction can be removed from the original document without a
> > reset.
> I'm concerned that this approach essentially leaves two versions of
> multipart/report around, because it's easy for someone to find the current RFC
> and not know about the other standards track document that updates it because
> it's not so noted on that RFC. My preference would be to obsolete the old one
> with the new one. I know that we update the RFC index with "updated by"
> information but people often don't know, or forget, to look there.
Such concerns may have some validity in the general case, but in this
particular case it's seriously overblown. For one thing, software that actually
implements a restriction requiring multpart/report to only be used at
top-level is seen by users as just plain broken - to the point that it's very
doubtful it's honored by anyone except initial DSN/MDN generators - which is
the one place where the restriction does make sense and should be retained.
And if people are going to miss an updates clause, what makes you think they're
going to find the Obsoletes: any easier to locate? I still get stuff from
people that refers to RFCs 1891-1894 as the current specifications for this
stuff. It's not like the handling of obsoleted RFCs is materially different
from updated RFCs.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
