Referencing big external files in email messages

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 May 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶

Table of Contents

3. Content-External header field

The Content-External header field can appear multiple times. Each instance describes an externally referenced attachment.¶

The generic syntax of Content-External header field is the same syntax as used by the Content-Type header field [RFC2045], so the same generic parser can be used. The media-type value is the media type of the external attachment being referenced. (Note that if a different media type is returned when the external attachment is retrieved, the value in the header field overwrites the value returned by the retrieval protocol).¶

The list of currently defined attributes of Content-External is included below. See Section 4 for details of the syntax.¶

• URL -- URI [RFC3986] (typically an HTTPS URL) used to access the external attachment. This parameter is required and it can only appear once.¶

• NAME -- The recommended name of the external attachment. This parameter is optional, but can't appear more than once.¶

• DIGEST-<digest-name> -- Value of the specified digest of the external attachment in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter is optional, but can't appear more than once.¶

• EXPIRATION -- The date (in the [RFC5322] "date-time" syntax) after which the existence of the external data is not guaranteed. This parameter is optional, but can't appear more than once.¶

• SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter is optional, but can't appear more than once.¶

• PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read-write" are the only defined values of permission. This parameter is optional, but can't appear more than once.¶

In order to allow for long parameters, [RFC2231] encoding can be used in Content-External parameter values.¶

Simple example 1:

    Content-External: application/postscript; name="BodyFormats.ps";
                   url="https://www.example.com/storage/123";
                   expiration="Thu, 30 Nov 2023 19:13:14 -0400 (EDT)";
                   size=1234567

Example 2:
     Content-type: text/html;
                   URL="https://www.example.org/1/2/3/4/5/6/7/
                        8/9/10/11/12/13/14/15/16/17/18/20/21/
                          file.html"; SIZE=100000000;
                    digest-SHA-256="..."

[[Open Issue: ]] The ability to include Content-ID header field is lost, when compared to message/external-body, so external attachments can't be referenced inside multipart/related? Should we define "id" as a new parameter of Content-External to address this issue?¶

The Content-External header field appears in the header section of the body part that is used to display a message to a user of a MUA that doesn't support this extension. Such body parts MUST have either "text/plain" or "text/html" media types. (Future revisions of or extensions to this document can allow use of Content-External with other media types). If a Content-External header field appears in the header section of a body part which is not listed above, it MUST be ignored. [[Also allow it at the top level message level?]]¶

MUAs compliant with this specification SHOULD hide body parts with one of the media types listed above that also contain a Content-External header field. They MAY present a UI allowing the user to download such external attachments or they MAY do this automatically. [[See Security Considerations. Should we always require user confirmation?]]¶

4. Formal syntax

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].¶

Non-terminals referenced but not defined below are as defined by MIME, part 1 [RFC2045].¶

Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.¶

type-name = <Defined in RFC 6838>
subtype-name = <Defined in RFC 6838>

content-external = "Content-External" ":"
           [FWS] media-type [CFWS]
           *([FWS] ";" [FWS] parameter) [FWS]

media-type = type-name "/" subtype-name
           ; Matching of media type and subtype
           ; is ALWAYS case-insensitive.

parameter = attribute [FWS] "=" [FWS] value

attribute = token
             ; Matching of attributes
             ; is ALWAYS case-insensitive.

value = token / quoted-string

token = 1*<any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

tspecials =  "(" / ")" / "<" / ">" / "@" /
              "," / ";" / ":" / "\" / <">
              "/" / "[" / "]" / "?" / "="
              ; Must be in quoted-string,
              ; to use within parameter values

allowed-display-media-parts = "text/plain" / "text/html"
              ; Allowed media types for display body parts
              ; where Content-External is allowed.


registered-content-external-params = url-param / name-param /
    expiration-param / size-param / permission-param /
    digest-params


url-param = "URL" [FWS] "=" [FWS] url

url = value
      ; Syntax as described by absolute-URI in RFC 3986
      ; When represented as a quoted-string, internal
      ; SP/TAB are stripped from the value before full
      ; URL is reconstructed.

name-param = "NAME" [FWS] "=" [FWS] value
      ; Recommended file name

expiration-param = "EXPIRATION" [FWS] "=" [FWS] expiration-value

expiration-value = quoted-string
                   ; the quote string value is [ day-name "," ] date-strict
                   ; time-strict

day-name = <Defined in RFC 5322>

date-strict = day SP month SP year
       ; day month year

day =   1*2DIGIT

year =  4*DIGIT

month = <Defined in RFC 5322>

time-strict  =   time-of-day zone

time-of-day     =   hour ":" minute [ ":" second ]

hour            =   2DIGIT

minute          =   2DIGIT

second          =   2DIGIT

zone            =   SP ( "+" / "-" ) 4DIGIT

size-param = "SIZE" [FWS] "=" [FWS] number64

number64 = 1*DIGIT
           ; Unsigned 63-bit integer
           ; (0 <= n <= 9,223,372,036,854,775,807)

permission-param = "PERMISSION" [FWS] "=" [FWS] permission-value

permission-value = "read" / "read-write"
          ; The values are case-insensitive

digest-params = 1*digest-param
          ; Multiple attributes of this form are allowed,
          ; as long as they all use different hashes

digest-param = "DIGEST-" digest-name [FWS] "=" [FWS] digest-value

digest-name = atom
          ; IANA registered. E.g. SHA-1, SHA-256

digest-value = value
          ; Define exact syntax...

FWS = <Defined in RFC 5322>

CWFS = <Defined in RFC 5322>

Authors' Addresses