[rfc-i] draft-iab-rfcformatreq comments

Marc Blanchet marc.blanchet at viagenie.ca
Mon Dec 17 14:24:21 PST 2012

my comments on the draft-iab-rfcformatreq document, filed in the IAB tracker as http://trac.tools.ietf.org/group/iab/trac/ticket/246

Regards, Marc.

Début du message réexpédié :

> De : "iab issue tracker" <trac+iab at trac.tools.ietf.org>
> Objet : [IAB] #246: Marc Blanchet review
> Date : 17 décembre 2012 17:22:21 HNE
> Renvoyé-À : rfc-ise at rfc-editor.org, rse at rfc-editor.org
> À : draft-iab-rfcformatreq at tools.ietf.org, marc.blanchet at viagenie.ca
> Cc : iab at ietf.org
> #246: Marc Blanchet review
> <comment>
> <quote>
> Arguments in support of a markup language as the Revisable format:
>       *  Having a markup language such as XML or HTML allows for greater
>          flexibility in creating a variety of Publication formats, with
>          a greater likelihood of similarity between them.
> </quote>
> <t>I disagree that XML and HTML should be put together here. Only XML is
> appropriate here in the sentence.  HTML can be generated from XML using a
> stylesheet, the inverse is much more complicated... I think we need the
> least amount of display formatting in our document. just the basics which
> are mostly what we have with XML2RFC. </t>
> <t>Text change suggestion: "Having a markup language such as XML allows
> for greater ..."</t>
> </comment>
> <comment>
> <quote>RFC Editor goals</quote>
> <t>I'm surprise to see only one goal from RFC editor. It seems to me that
> the RFC editor should have goals such as efficiency, quality, availability
> of tools, not-too-complex-requirements-for-rfceditor-staff, ...  If the
> community end up with a format that the RFC editor staff becomes so slow
> and unefficient, I think this is really bad. More goals from the RFC
> editor?
> </comment>
> <comment>
> <quote>  While several Publication formats must be allowed, the
>          Publication formats must include support for plain-text
>          printing.
> </quote>
> <t>I agree with that, but we may decide that the plain text version is no
> more the normative version of the RFC. If we have multiple publication
> formats, one has to be identified as the normative one.</t>
> <t>Personally speaking, I think it is time to move to better graphics
> support and therefore the plain text version would not be normative
> anymore.</t>
> </comment>
> <comment title="Additional requirement">
> Some of our RFCs are actually parsed by programs. Good example are the
> MIBs, ABNF, ..., where programs just keep a copy of the RFC and parse
> them, either offline or realtime.  So we should have a clear requirement
> about that the new format should be easily parsable for these kinds of
> data. Therefore:
> - The canonical format should be structured to enable easy program
> identification and  parsing of code or specifications, such as MIB, ABNF,
> ...
> </comment>
> <comment title="Additional requirement">
> We do a lot of text scraping currently on the .txt files, such as ID-nits,
> tools displaying in HTML with href to other documents. These tools are
> great, but rely on really bad design from the source format. Our tools
> should parse structured documents so we can have structured stats,
> references, cross-references, display, ... Therefore, I would like to add
> the following requirement
> - The canonical format should be structured, such as using XML markup or
> similar.
> </comment>
> -- 
> -------------------------------------+-------------------------------------
> Reporter:                           |      Owner:  draft-iab-
>  marc.blanchet at viagenie.ca          |  rfcformatreq at tools.ietf.org
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:
> Component:  draft-iab-rfcformatreq   |    Version:
> Severity:  -                        |   Keywords:
> -------------------------------------+-------------------------------------
> Ticket URL: <http://wiki.tools.ietf.org/group/iab/trac/ticket/246>
> IAB <http://tools.ietf.org/iab/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20121217/b2c90636/attachment.htm>

More information about the rfc-interest mailing list