[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc
peter.sylvester at edelweb.fr
Tue Jul 17 02:47:02 PDT 2012
On 07/17/2012 09:54 AM, Julian Reschke wrote:
> On 2012-07-17 09:04, Martin Rex wrote:
>>> I believe there is emerging consensus that that reference point should
>>> be section numbers.
>> I frankly do not see that consensus, I believe section numbers
> Indeed, I should have said "rough".
Hm. Isn't consensus when all but one agree on the topic and agree
that the "one" is wrong (one could be 2, 3)
>> to be the sole reference points much to coarse, and I don't
>> think that pathological fragmentation of text into subsections
>> is a universal solution (let alone sensical).
>> There may be multiple-pages examples, long lists, where being
>> able to point to a page is sometimes useful.
> If you do indeed have multi-page examples then adding more structure
> to the examples, or adding line numbers, will probably be more useful
> to the reader.
It hasn't been mentioned, but n or to comment drafts I think that "line"
would be a very useful thing, i.e. all places where html forces a line
i.e a floating paragraph treated as one line.
>> I really want to see the pre-formatted for printing (rfcmarkup)
>> RFC format be retained for future RFCs as well, and *I* will continue
>> to exclusively use URLs into the the pre-formatted online RFCs
>> during discussions, if at all.
> On the other hand, I have stopped using them whenever I can (when
> there's a better real HTML version around).
This thread is about INPUT format.
Preformatted output, e.g. a PDF/A version and a "line-printer version",
where is the problem to pre-produce them. I am not talking
about potential inconsistencies among them.
>>>> I don't mind that you use XML or HTML, and I also don't mind when the
>>>> RFC Editor creates HTML versions of RFCs.
>>>> But I want the RFC Editor to continue to accept nroff submissions
>>>> for those that don't want to waste their authoring time on XML/HTML
>>>> bike shedding.
>>> Depending on what we agree on, allowing formats that are "too
>>> simple" is
>>> likely going to cause additional work for the RFC Editor, which
>>> needs to
>>> be paid. This is something we need to keep in mind. Optimally, the new
>>> format will make the actual formatting *easier* for the production
>> There can not be a "too simple" format, only a too complex format
> The current submission format is "too simple" in that it requires
> heuristics to extract essential information like contact information,
> copyrights, and abstract (which sometimes fail), and requires
> additional work during RFC publication that could easily be avoided.
i.e. it is "too complex", in the sense that it needs complex heuristics
asn1 with context tags like  :-)
A submission format that needs heuristics to compile desirable
is not exactly desirable I think. Applying such tools to transform existing
pure text rfcs is an activity of an archivist or 'conservateur de
in order to make things more accessible, like scanning paper docs etc.
That is not the problem in this discussion.
>> that puts excessive and completely unnecessary burden on RFC authors.
>> And I continue to be heavily opposed to all those lobbying with the sole
>> objective to kill all other submission formats besides xml2rfc.
xml2rfc is the format to be killed (almost). ;-)
I used to produce html using a set of m4 macros 15 years ago.
> My main concern continues to be the *publication* format, because it
> affects the *readers*, not the *authors*.
Thus the document structure should be sufficiently rich and identifiable
> We can of course decide to retain a primitive submission format, but
> it that causes the publication format to be primitive as well, I'll
> have to agree with those who claim that the IETF is stuck in the 1980s.
In the 1970s or earlier. :-)
More information about the rfc-interest