Since I will continue to use Google to locate RFCs.. I guess I will
land on the page they consider appropriate.
But we certainly need something like the functionality Paul suggests.
Now it might be realized through a landing page or a menu bar at the
top of the page (like the tools currently does) or whatever.
But one reason we would want this approach is so that there is the
possibility to support the extraction of embedded content such as
schema files etc.
I am starting to lean towards the idea of making the XML version of
the doc 'canonical'. I still think the legal argument is specious, but
it is certainly best that everyone hook their tools onto a single
version of the editorial output rather than have half of them use the
HTML as input and half use the XML as input.
>From a practical point of view it is probably going to serve us best
if the 'tools canonical' format is as stable as possible. This
probably means that we don't want to choose the HTML version as I can
see that being modified for purely cosmetic reasons and that should
not require people to rev their tools.
The only practical implication of this is that the XML format would be
the one used internally by the RFC editor tools. Authors would still
be able to edit in HTML (applying an IETF template) and there would be
a HTML output with the ability to round trip (so updating an RFC can
start from the HTML on the web site).
On Thu, Jun 21, 2012 at 3:05 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> Greetings again. Andrew's and Yoav's last comments indicate a dislike for the idea that the canonical RFC format might be "code" like HTML or XML because those formats are not meant for reading. My proposal for "one canonical, many display" formats assumes that anyone who wants to read an RFC will read it in a format they like, and that format is not likely to be the canonical format. (To be clear, someone doesn't normally *read* an HTML file, they display it in an HTML rendering program like a browser.)
>> Yoav suggests that there be a preferred display format. I don't see a value in publicly preferring any of the formats, and I explicitly reject the idea that we need to become junior lawyers and try to guess what some court in some country would or would not understand.
>> People may be thinking historically about how RFCs are gotten: using a URL that ends in ".txt". My proposal is that the canonical URL for an RFC leads to a page that gives all the display options, including grabbing the canonical document itself. This is a "one extra click" operation. People who use RFCs regularly would be able to go instantly to getting an RFC in their preferred viewing format knowing the naming convention, giving a "no extra click" operation for repeat users who understand patterns.
>> --Paul Hoffman
>> _______________________________________________
> rfc-interest mailing list
>rfc-interest at rfc-editor.org>https://www.rfc-editor.org/mailman/listinfo/rfc-interest
--
Website: http://hallambaker.com/