§2.2.7: "Embedded bitmap images (SVG sources, JPEGs, PNGs, etc) should be
embedded."

This reads as a tautology, which I think means that it's not what was
intended. Maybe strike the first "Embedded"?

ok

https://sourceforge.net/projects/sourcesans.adobe/?source=directory

https://sourceforge.net/projects/sourceserifpro.adobe/?source=directory

https://sourceforge.net/projects/sourcecodepro.adobe/?source=directory

are some fixed-width type faces

Doesn’t this section apply to any paginated output format (e.g., plain-text), not just PDF? Seems like it should just be in one place and be referred to from other places. Maybe it’s ok here if the plaintext doc adds a reference to here?

3.  Section 2.1.8 contains a discussion of where hyperlinks to RFCs should point.  I think this is
   

a format-independent question and such discussion belongs in a non-format-specific document
instead.

I agree. Design team, is there a better place for this comment to go?

§3: Apart from its location (see above), it's a little strange that
there is no nod in the text as to why PDF/E is not right for the IETF.
PDF/UA is called for but not explained in the text.

I suggest we add to the text something explaining PDF/E a little more, such as this sentence (paraphrased from the PDF/E FAQ):

As PDF has evolved a broad set of capabilities, additional standards
for PDF files are applicable. These standards establish ground rules
that are important for specific applications. For example PDF/X was
specifically designed for Prepress digital data exchange, with
careful attention to color management and printing instructions.
The PDF/E standard was designed for engineering documents and
is used in dynamic workflows (where a document continues to be
revised after publication) and allows interactive media (including
animation and 3D).

paragraph numbering

I find it a bit obtrusive where it's placed right now (before the paragraph in the left margin). I'd prefer it to be to the right and after the paragraph (or on the last line), to be less obtrusive.

I noted
#73 Recommendation: use PDF/UA and also PDF/A3.

It's unclear whether that results in a logical and or a logical or of the profiles. It would be better to write either:
Recommendation: documents have to conform to both PDF/UA and PDF/A3.
or
Recommendation: documents have to conform to either PDF/UA or PDF/A3.
(even if you don't want to use 'have to' (or MUST) at the moment, please make sure that the logical relationship is clear form the text)

§2.3: Normally, the authenticity of RFC files is not an issue, since the
RFC editor maintains a repository of all RFCs which is widely
replicated. However, the RFC Editor and staff are at times called to
provide evidence that a particular RFC is the "original" and has not
been visually modified, and there may be other use cases.

This makes no sense to me: the whole point of the signature is to be
able to show that the version you got from one of the wide replicas is
in fact legit. So how is the authenticity not an issue? Indeed,
that's precisely the issue when called to provide the evidence, no?

I'm not sure how to best handle this comment. I'm thinking of just striking the first sentence and having it read (including the entire paragraph instead of just a clip):

The RFC Editor and staff are at times called to
provide evidence that a particular RFC is the "original" and has not
been visually modified, and there may be other use cases. As
signatures also apply to embedded content, embedding the XML source
will provide a way of signing the source XML as well.

2.  Section 2.1.5 is really a discussion around pagination requirements independent of which
   

paginated format is being discussed. That is, doesn’t it apply equally to the plaintext format,
and any other (future) paginated format? Seems like it should just be in one place and be referred
to from other places. Maybe it’s ok here if the plaintext doc adds a reference to here?

If plaintext were paginated, it would apply there as well. At the current time, it's not clear to me whether the plaintext form will be paginated or not. If it does wind up being paginated, then a pointer to here would probably be appropriate from the plaintext doc.

Re: [rfc-i] not just 'lineprinter' (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)

Date: Wed, 02 Jul 2014 08:31:55 +1200

From: Brian E Carpenter [email protected]

Indeed. The utility is not so much in having a FF every 58 lines. It's having a FF where needed to avoid widowed text and split artwork. Since we need that same logic in paginated PDF anyway, I don't quite know what people are perturbed by.

paraphrase of above: PDF needs to do widow and orphan processing

Remove "Recommendation:" in bullet, as it is redundant with the heading above the bullets, and the other bullets don’t start with “Recommendation:”.

will use an canonical format

will use a canonical format

Should the NOTE be marked as to be removed at publication time, or is
the github tracker part of the implementation stuff that is expected
to change? (Clarifying one way or the other would be good. I prefer
the former but don't care that much.)

Yeah ok, we should add "remove before publication".

"acessibility" => "accessibility"

A discussion of preferences in terms of PDF readers that fully support the features utilized in RFC files (features such as links, digital signatures, Tagged PDF and others as already mentioned in the paper, and others as may occur) would be a worthy addition.

"insuring" => "ensuring"

"sentence sentence"

"auxiliar" => "auxiliary"

1. Note that RFC 6838 changed the registration template slightly;
   please align the new draft with the new template (the changes are
   minor, so it's easy).
2. For the change controller:
   Author/Change controller: Duff Johnson [email protected],
   Cherie Ekholm [email protected], ISO 32000 Project Leaders
   I suggest making it clear that it's ISO that's the change controller,
   and that Duff and Cherie are the current representatives. Something
   like this:
   Author/Change controller: ISO, via the ISO 32000 Project Leaders,
   who are currently Duff Johnson [email protected] and
   Cherie Ekholm [email protected]
3. It would be nice to have a section "Changes Since RFC 3778", which
   summarizes what has changed.
4. I note that stuff has gone away, such as the encryption and
   signature sections. Why? (And if they stay gone, you should explain
   why in the "Changes Since RFC 3778" section.

Nit: s/showing if/showing whether/

ok

It strikes me that a recommendation here of
fonts appropriate to RFCs would be helpful, though I can see how that
could get hard; perhaps a forward reference to §B.4?

I agree that a forward reference would be useful.

§2.1.5: For whatever it's worth, I hate the neologism "page break" as
a verb. Surely this is just "do not break pages"?

ok, use "insert a page break" instead of using a verb "page break"

a) Inaccurate information

I see few notable and no consequential errors in the draft as it stands.

b) Missing information that should be covered

The document appears to cover most relevant subjects, however, since I’m unfamiliar with the full scope of content types in RFC documents I can’t really offer a complete opinion on this point.

not currently mentioned. How big are the PDFs, which compression methods should be used, which version of PDF?

'nit checker' is what we can probably get, but it would be nice to have a 'validator'.

If PDF files are always generated by xml2rfc, perhaps this is less important, or just an xml2rfc test suite.

Leonard Rosenthal gave some pointers to software packages to investigate:

Commercial:

• Prince (http://www.princexml.com/) for HTML->PDF
• The granddaddy of XSL:FO formatters is from AntennaHouse http://www.antennahouse.com/),
• RenderX (http://www.renderx.com/).
• Adobe InDesign (and ID Server)
• Adobe FrameMaker

Open source:

• a common alternative to FOP (for XSL:FO) is xmlroff http://sourceforge.net/projects/xmlroff/).

There are numerous open source projects that can input either XML or HTML and output PDF. To name a few:

• iText (http://itextpdf.com/),
• ReportLab (http://www.reportlab.com/opensource/),
• wkhtmltopdf (http://wkhtmltopdf.org/),
• xhtml2pdf(http://www.xhtml2pdf.com/)
• HTMLDoc (http://www.msweet.org/projects.php?Z1)

change inobtrusive to unobtrusive

§2.1.6: I don't get why it is merely preferable that the software is
going to generate PDF/A files directly. Since the recommendation in
§3 is to use PDF/A for RFCs, and since this document is about PDF for
RFCs, I don't see how there's an alternative. At least explaining the
thinking might help.

This is a comment about the 2nd paragraph, which says:

In addition, the PDF/A standards mandate the embedding of fonts.
Preferably, the software generating the files would produce PDF/
A-conforming files directly, thus ensuring that all glyphs include
Unicode mappings and embedded fonts from the outset.

The way it's written IS kind of wishy-washy. The text is more a comment in how PDF/A can be generated versus plain PDF. How about (adding to the end of the 2nd sentence):

In addition, the PDF/A standards mandate the embedding of fonts.
Preferably, the software generating the files would produce PDF/
A-conforming files directly, thus ensuring that all glyphs include
Unicode mappings and embedded fonts from the outset, instead
of using additional software to embed the fonts.

1.  On the paper size issue, what is most commonly used in other international publishing
   

contexts such as IEEE standards, ACM conference papers, etc.? Stating some such precedents
would help.

Anyone have input on this they can share?

§2.1.3: This format defnition is keeping the existing running headers
even as the "plain text" version ditches them. It'd be good to
explain why one and not the other (in one of the documents, or perhaps both).

I don't believe that such a discussion belongs in this doc, but am not sure where such discussion should go.

Not terribly readable as is. Move to informative references?

remove the ...

"adherance" => "adherence"

"suhmitted" => "submitted"

(See https://en.wikipedia.org/wiki/Portable_Document_Format for a history of PDF. Also see https://en.wikipedia.org/wiki/PDF/A and https://en.wikipedia.org/wiki/PDF/UA for descriptions of PDF/A and PDF/UA, respectively.)

Shouldn’t these links be moved to be Informative References?

Change "Insure that" to "Ensure that"

Change "insuring that" to "ensuring that"

Joe

One more time on the technical questions I've been trying to ask: If we had a pdf format that had nice widow-and-orphan control, could keep art on a single page, could produce long tables with repeating headers, etc, would we need a manually-produced text version that had labor-intensive ^Ls? Or alternately, is there an existence proof of tooling that could produce such output from the XML? If so, would the page breaks be useful to anyone that could also download the PDF?

Chris

I for one would be quite happy with a PDF format as you describe. OK, there are few bells and whistles I'd add to that description (page numbers in table of contents, ability of author to put something into XML to influence the page breaking, intelligent table breaking with header rows repeat). But those are refinements, and belong in an XML v3 discussion - the PDF specification could mostly just say it will support all XML v3 page management features.

From: Leonard Rosenthol [email protected]

Date: Tue, 1 Jul 2014 18:51:31 +0000

Subject: [rfc-i] PDF compliance choices (was Re: Fwd: I-D Action: draft-hansen-rfc-use-of-pdf-00.txt)

I would challenge this position concerning PDF compliance.

PDF/A compliance is most certainly a requirement, but unless you plan to embed the original XML inside the PDF, I would stick with PDF/A-2. That said, I think having the original XML as part of the PDF/A file is an excellent choice and worth doing in which case you would need PDF/A-3. There are many tools out there that either already support or should have support for PDF/A-2 and PDF/A-3 shortly. (NOTE the - between the A and the #)

That said - the next question is which level of conformance for PDF/A-2 or 3? I would recommend at least "u", though "a" would be appropriate if you are also targeting PDF/UA.

So on the topic of PDF/UA - While I agree that having an accessible document that also provides rich semantics has numerous benefits - the biggest problem you will have is that it is technically IMPOSSIBLE to do machine validation on such a file. A qualified human must be involved in the process. And you need tools - and there aren't any freely available ones that I know of (and even few commercial ones). So this might be a gating factor.

"oould" => "could"

Should "non-intrusive" be change to "unobtrusive"?

regarding the "One question that ...",
why is this question specific to the PDF format? Seems like this discussion doesn’t belong in any of the format-specific documents.

§C: nit:just about any layout for those URIs would be better than this.

agreed

http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#output.pdf.fop

they do not not

"A4 size by default"

What is most commonly used in other international publishing contexts such as IEEE standards, ACM conference papers, etc.?

"some differences from the HTML rendition might be:
(1) visually searching or scanning should be facilitated."

What's that about? I just took that out, please re-add with explanation.

note Duff, Leonard in it.

§B.1 It's a little strange to see Adobe's software on the list and yet
not Apple's Preview.

It can certainly be added.

§2: First, it's really strange that this is all here before §3, which
talks about a much more fundamental decision. If it were me, I'd move
§3 up.

meh, either way.

§2.1.2: I don't have strong preferences about paper size, but given
that the PDF is what we were expecting to use for the purposes of the
Trust one of the considerations probably has to be whence the Trust
gets subpoenas. If they're mostly USian, that might change the
balance here.

I suggest we keep it saying A4.

§1: Is there really no better source for PDF definition than
wikipedia? I hate wikipedia references anyway, because they're not
stable; but given that §4 has references to various PDF specs, it's
really strange to see the wikipedia references here.

I think replacing the wikipedia specs with other references is fine.

"See those document" to "See those documents"

from Brian E Carpenter [email protected]

US Letter page size, but margins chosen so it will print and look good on (the slightly taller but narrower) A4 paper size.

Please, let's choose the international standard (A4) as the size, with margins that allow for the slightly shorter and fatter US national standard.

Dov Isaacs [email protected]

... I find:

Require PDF/X2 for RFCs. It captures the archivability and long-term stability of PDF 1.7 files.
Use PDF/X3 for embedding additional data (incluing the source files) in RFCs and Internet Drafts.

I suspect you mean PDF/A-2 and PDF/A-3 instead of PDF/X2 and PDF/X3. The word “including” is also misspelled.

change email address to "[email protected]"