reply to comments on draft-hardy-pdf-mime

Larry Masinter <> Sun, 04 September 2016 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA40D12B0B8 for <>; Sun, 4 Sep 2016 16:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8GyUXmJOvnoa for <>; Sun, 4 Sep 2016 16:25:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0A6C12B097 for <>; Sun, 4 Sep 2016 16:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ObRcpmgwfPwFlLjSd8bpGS/KCvGIRALQzo3vDj+H+fg=; b=UEA7aDe2IOTSuuRMFsQt6F/Jo8HZ03im0sESGcldtW4nuMHkm1Q9YkoU96gyMUeeUcnl8Q1XnbGJ+5M0Hhz0U2/FosRKMuN6i+viV4rerozONgpc1znvb75JmydL7NsL1rUSo/TlWpHpPnF+XC/+x9fesfQZRW8YC07tVanxwrQ=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Sun, 4 Sep 2016 23:25:49 +0000
Received: from ([]) by ([]) with mapi id 15.01.0599.016; Sun, 4 Sep 2016 23:25:49 +0000
From: Larry Masinter <>
To: "Ietf@Ietf. Org" <>
Subject: reply to comments on draft-hardy-pdf-mime
Thread-Topic: reply to comments on draft-hardy-pdf-mime
Thread-Index: AQHSBwOrxaYt4L14T06Z1K0Hrts06A==
Date: Sun, 04 Sep 2016 23:25:49 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.19.0.160817
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 45cdb623-0281-4fc5-dfa0-08d3d51ace57
x-microsoft-exchange-diagnostics: 1; CY4PR02MB2567; 6:FCUQQLzp8J2uTQ+QTxOdE/6j1uNHChh+GRJ7RdxdRXB9/xgSb/JQruIMaU/i+FvBX6ftaoWkqR1sBUOuqbIbDiV+8Wj01wvjgwfwMhCtJlNWQDxm5FvRaA2Pvlkp2AorEqul1woxvs7d/f/aXLnpKOVP/V3TKjr82fA0OFWYBalFwZRsa5ewF3jmGSYmc6EKWKTK3qSux7lV4Rp9eBvX5f/zqF8VdjBJ9qTvToGmz488Lhc0zghcQtDvFs6FOKUCtIVm/tPKkm0b/6efUYpomlQhLjQW7kPfrhepTtJwfghBUIqXgTUF1tVYsS6IEDr0Zeh2Sall1iwEp9benzqRhQ==; 5:+jrtQm5e2nKhSIiVhHjthuua+p7xGve7Vo0iyH0vTK1F1u1nlwK7Z7YF9zici90v4ESIKZM4TmNLdBvW2lDp+AGQcC87FmxB1VQm8SiMtk6NtzSHu9Vid8xuZgAdIYarFVToSx7+37iZ2cuEb7+P/Q==; 24:9QQag6rZNSiYymBymfHHPQjLJ1SbSQ1fZufv3LfT2s149nyrNGyGfUDX9F3+q0mQIksOBdxhjtfrPay3+otf+IM8jqESN0g2KVHi9RaEzk0=; 7:2KgWYmRfu35kuoVJcegarIzhaWRU/kcD3SzfoGknmGDXoX3U+5Vq65FLQA/zfh1sy1aXnO8fs4RP7RWKBvTTD3FtXNbv+Kz1hUJFFIeoUt4QzW/pxgaXugVKVLHGPDDu2nqGy/2ZLCe5OkP/gtUMXgWeMPVIyPbV1vHfZSwJxpny/FGRF8fbKH/RrvYB6K65Bm/YDSUPaGzqJ2oMfpXyts1jqIW6xn5arY4QkEN3CrudqnE1d+RCjst3FIbqrn4U
x-microsoft-antispam: UriScan:(22321516928792); BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2567;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(201822940525970)(278428928389397)(166708455590820)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY4PR02MB2567; BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2567;
x-forefront-prvs: 00550ABE1F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51444003)(189002)(199003)(97736004)(230783001)(82746002)(87936001)(83506001)(4001350100001)(5660300001)(122556002)(450100001)(5002640100001)(99286002)(83716003)(106116001)(106356001)(105586002)(189998001)(586003)(3846002)(6116002)(102836003)(86362001)(107886002)(110136002)(2906002)(7846002)(2900100001)(15975445007)(66066001)(7736002)(305945005)(81156014)(77096005)(10400500002)(10090500001)(92566002)(8936002)(8676002)(68736007)(81166006)(11100500001)(36756003)(229853001)(54356999)(50986999)(3280700002)(19580395003)(101416001)(3660700001)(19625735002)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR02MB2567;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2016 23:25:49.3770 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2567
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Sep 2016 23:25:55 -0000

This is my (personal) response to comments on draft-hardy-pdf-mime -02 and -03. I haven't had a chance to review all of these with all of the co-authors.

There is a new -04 draft now.

I'll send individual responses as requested with references to this discussion; I’m trying to reply to reviews by:
S Moonesamy, Phillip Hallam-Baker, John Klensin, Kathleen Moriarty, Stephen Farrell, Dan Romascanu, Mirja Kuehlewind, Ben Campbell


I volunteered to help with draft-hansen-rfc-use-of-pdf;  the history
 history of PDF wasn't right, and the registration in 3778 did need
to reflect the ‘change controller’. This draft was started in the same
github repo, until

I talked the ISO committee working on PDF 2 to take on owning the
"fragment identifier" semantics; it wasn't part of the PDF 1.7
definition that got fast tracked, but it belonged with the PDF spec.
(In general, those defining file formats and registering them need to
be prodded into owning the "fragment identifier semantics".)

I don't know of any other instance of an ISO committee defining a
media type. The ISO committee wants to put the RFC number into the
PDF 2 spec, while this spec wants to make normative reference to the
(likely-to-be-approved-in-2017) PDF-2 spec.

Note that application/pdf was FIRST registered in 1993 (23 years ago)
by Paul Lindner for use in the gopher protocol. I was one of the
GopherCon '93 attendees to urge him to do so (and TimBL to use
content-type in HTTP/1.0).

"application/pdf" was chosen before the introduction of the
vnd. prefix.  When the "standards tree" and "vendor tree" distinction
was introduced, application/pdf was grandfathered rather than forced
to application/vnd.adobe.pdf.  It's only relatively recently that it
now qualifies for "standards tree".

Just to update the media type registry might not even be necessary.
(The text/html registration was updated without an RFC to obsolete
RFC 2854.) 

Does any of this history belong in the document? I didn't think so.

The paragraph numbers are a feature of xml2rfc. I turned them off.

Yes, the Introduction should say "It obsoletes [RFC3778]."  and
RFC3778 added to Informative references.

Interoperability considerations:

I put in a reference to ISO 32000-1 Annex I "PDF Versions and
Compatibility" talks about the use of version numbers and backward

There's a lengthier blog post/paper by Jim King:

... but it's older, Jim has retired and unlikely to update it, I don't
know if the URL is stable (it's a blog, not an official document).
Is it worth referencing? I thought not.

Security considerations:

There were a lot of comments about Security Considerations.

It's true that lots of RFC 3778's security considerations got
replaced, here's the commit:

As I understood it, the feeling was that the previous text was wrong
or misleading, that these days many formats allow scripting, and the
techniques and reasons for sandboxing well known.

 Version -04 adds to the end of “Security Considerations”:

   PDF interpreters executing any scripts or programs related to these
   constructs must be extremely careful to insure that untrusted
   software is executed in a protected environment.

PDF has been around a long time; a search for "PDF malware" turns up
lots of hits. I too wish there were an ISO or other document that
could be cited, but I haven't found one.  Is it necessary to say more,
in the MIME type registration? 

It might help to clarify who "Security Considerations" in MIME
registrations are mainly for. Don't think of developers of PDF
viewers/interpreters, think of system administrators, makers of
firewalls, proxies. People who don't really care about PDF, who won't
study the spec, just want to know what they should watch for, beyond
the usual for every file type. Having a target audience might help.

(PH-B) MIME types should identify content which has scripts/macros:

I wasn't sure if you meant the type itself, or that content should be
labeled.  I'm not sure how this applies to the application/pdf registration. 

In general, a label "I have no scripts" isn't helpul because bad guys
can lie [RFC 3514]. You can refuse to run scripts, or run them with
limited access.

Signatures add trust:

> PDF also has a signature capability which is relevant. If the Macros are
> signed by a trustworthy party, they are less of a concern than random
> Macros.

Is this true? malware that reproduces itself can't be signed and

Subsets without scripting?

> ...  some of the subsets do not allow
> embedded scripting.  If that is correct, it should certainly be
> mentioned.

I mentioned it for PDF/A in passing, although it is not clear how this helps.
A file could lie and say it was PDF/A but still have scripts.

Adobe PDF vs ISO specs

> how the current ISO version of PDF compares to the Adobe version

ISO 32000-1 was adopted using ISO Fast-Track process and is
technically identical to Adobe Portable Document Format version
1.7. The Fast-Track process doesn't allow any technical changes; it
was just rewritten in ISO-spec style.

> If the difference is significant, then a new
> media type, not reuse of an old one, is required.  Even if it is
> not that significant, it appears to me (as a co-author of RFC
> 6838) that there is a strong case to be made for parameters that
> identify versions and/or specific subsets to help applications
> to identify viewers or processors that will not fail.  The
> authors may have good reasons to not include either parameter,
> but it seems to me that the I-D should then explain why not.

There are no technical differences between Adobe PDF 1.7 and ISO

I don't see a case for version or subset parameters in content-type
headers here or most anywhere that backward and forward compatibility
has been carefully planned.

As with most living file formats, if you want to consume files
using the latest features in their fullest, you want to have an
up-to-date viewer; publishers can target earlier versions for wider
applicability and reliability.

I think that’s it.  Thanks all for your reviews,