The application/pdf Media Type
RFC 8118

Note: This ballot was opened for revision 03 and is now closed.

Alexey Melnikov Yes

Comment (2016-08-04 for -03)
No email
send info
A reply to SecDir review is needed from editors.

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-08-31 for -03)
No email
send info
I agree with all the security comments. I also agree with Suresh that the paragraph numbers are distracting. While they may be useful in the review process, they will distract readers down the road.

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2016-08-31 for -03)
No email
send info
Agree with others' comments about the security considerations.

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2017-02-27)
No email
send info
Thanks for handling my discuss point. I think the
security considerations text now seems sufficient.
Though I would still encourage adding some more
references if possible, but that's a non-blocking 
comment, so no need to do anything if you think 
it's right as-is.

OLD COMMENT text below, still happy to chat about
it if that's useful.

My old comment and discuss point-2 below. I think 
Larry answered opint-2 well enough in [2].

I'd suggest adding a reference to [3] would be useful
as well.


(2) section 6: It's a pity there's no ISO document to
reference in this section as PDF files have been the
vector for various threats over the years. Can't you
find some reference (from ISO or not) that a viewer or
author developer would find helpful? That section seems
pretty vague to me as-is. (In particular the last clause
of the last sentence in this section is not useful.) And
I see from the discussion of the secdir review ([1], did
any authors respond to that? If so I didn't see it,
sorry).  The discuss point here is that we seem to have
less good security considerations compared with RFC3778,
and I think that ought be justified if it's the right
thing to do. (Not necessarily in the document if that's
not correct, but at least as part of the record, e.g. in
response to this.)

- section 4: why no reference for PDF/A? I'd have
thought that was the most important one for which a good
reference is needed? The referred document is [ISOPDFA]
in 8.2 so I guess this is just an editing glitch.

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Comment (2016-08-30 for -03)
No email
send info
Why are there "<x>" paragraph numbers in this document? They feel distracting.

Mirja Kühlewind No Objection

Comment (2016-08-31 for -03)
No email
send info
I agree with others that the security section doesn't provide much: it neither describes how attacks could look like, nor how to handle them concretely. However, it also not clear to me if this is the right document to discuss these things or if a different doc would be needed.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-08-30 for -03)
No email
send info
In the Security considerations, the text starts off saying:

   The PDF file format allows several constructs which may compromise
   security if handled inadequately by PDF processors. 

Shouldn't this go a step further to also include the consideration that the feature could be exploited by an attacker?  I don't see how it is enough for the processor to handle all possible exploits.  If I am wrong, please explain.

Alvaro Retana No Objection