Resource-descriptor Graph:
MIME representation

Introduction

This document defines a representation of a resource descriptor [RDG-FRAMEWORK] as a MIME entity. [RFC2045]

Key words

The key words ‘MUST,’ ‘MUST NOT,’ ‘REQUIRED,’ ‘SHALL,’ ‘SHALL NOT,’ ‘SHOULD,’ ‘SHOULD NOT,’ ‘RECOMMENDED,’ ‘NOT RECOMMENDED,’ ‘MAY,’ and ‘OPTIONAL’ in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Representation

Resource descriptors in MIME are represented as entities of type multipart/prs.inumi.rdg-mime, which are composed of body parts.

Multipart media types are discussed in [RFC2046].

The Content-Transfer-Encoding field SHOULD have the value binary.

The following header fields are REQUIRED on the entity:

• the Content-Base field, value of which is the descriptor identifier.

This value is used as the default base URI for all of its body parts.

Body part

A body part represents a descriptor piece.

The body part MUST be a multipart/signed entity [RFC1847], which consists of one signed body part and one control information.

The signature protocol is application/prs.inumi.rdg-mime-sig.

Since there are more than one signature and their schemes vary, the signed body part must be cached prior to verifying the signatures. Thus, the micalg parameter MUST have the value unknown.

Signed body part

The signed body part represents a piece's identifier and RDF graph.

Implementations MUST support at least the application/prs.inumi.rdg-graph [RDG-GRAPH] and text/turtle serialization formats. [Turtle]

The following header fields are REQUIRED on the signed body part:

• the Content-ID field, value of which is the piece identifier,
• the Content-Type field, value of which is the media type of the representation of the RDF graph (the entity's body).

The Content-ID and Content-Type fields are discussed in [RFC2045].

Submission

When submitting to an endpoint, piece references are represented as a signed body part of type message/external-body.

Only Content-ID is REQUIRED in this case.

Control information

The control information is a series of lines of text. The character encoding is US-ASCII. [RFC20]

A line is either a user signature over the graph or a endpoint signature over user signatures that came before it.

User signatures are ordered by their creation time in descending order, followed by corresponding endpoint signatures, forming blocks of text.

Each line contains, separated by a single space, in order:

1. the letter 'U' (user signature) or 'E' (endpoint signature),
2. <sig-create>: creation time,
3. <sig-clevel>: confidence level (always full if 'E'),
4. <sig-expire>: expiration time,
5. <URI>: signer identifier,
6. <sig-scheme>: signature scheme,
7. <sig-data>: signature data encoded with base64. [RFC4648]
8. An end-of-line sequence indicating the end of the signature.

The syntax is expressed by the following <sig-mime> ABNF rule:

sig-mime = 1*sig-blck
sig-blck = 1*(%s"U" SP sig-line) 1*(%s"E" SP sig-line)
sig-line = sig-create SP sig-clevel SP sig-expire
           SP URI SP sig-scheme SP sig-data CRLF
sig-data = 2*( sig-b64c ) 0*2( "=" )
sig-b64c = ALPHA / DIGIT / "+" / "/"

The <sig-create>, <sig-expire>, <sig-clevel> and <sig-scheme> rules are imported from [RDG-FRAMEWORK]; the <URI> rule is imported from [RFC3986].

Security considerations

None.

IANA considerations

To be written.