[rfc-i] Embedding stuff (code, etc.) in RFCs
hallam at gmail.com
Fri Jul 12 17:36:07 PDT 2013
It is a reasonable solution to the problem. But while people are discussing
this we must make sure that this does not end up recapitualting the problem
the W3C has had with schema URLs that are embedded in their docs. They have
from time to time reported paying non trivial sums of money on the order of
tens or hundreds of thousands of dollars to serve those URLs as idiot
broken software attempts to resolve the URL every time the code runs.
On Fri, Jul 12, 2013 at 8:05 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Jul 12, 2013, at 1:25 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> > Do these tarballs contain copies of stuff that is rendered in the draft?
> > Or do they contain supplementary material that is *not* rendered in the
> > If it is rendered in the draft, how do we assure coherence?
> The same way we assure coherence with the non-canonical PDF and HTML
> versions the RFC Editor publishes: we don't. We assume that the RFC Editor
> is probably doing it right, and will respond to email when someone finds
> something they did wrong. This has worked fine for at least a few decades.
> > I have a problem now because I submit the xml and the txt. There is no
> guarantee that they are consistent. IMO I should only submit *one* form,
> and all others should be algorithmically derived from that.
> You don't actually "submit" anything. The RFC Editor receives the .txt
> from the stream that approved your RFC. The RFC Editor asked you to help
> their process with the XML. Diffs against the .txt are done at many points,
> certainly including in front of the stream leadership during AUTH48.
> --Paul Hoffman
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rfc-interest