RFC 7681

Email Exchange of Secondary School Transcripts

Independent Submission J. Davin
Request for Comments: 7681 October 2015
Category: Informational
ISSN: 2070-1721
Email Exchange of Secondary School Transcripts
Abstract
A common format simplifies exchange of secondary school academic
transcripts via electronic mail. Existing standards are applied to
prevent unauthorized alteration of transcript content and to deliver
transcripts directly and securely from each student to his or her
chosen recipients. By eliminating third-party intervention and
surveillance, the defined protocol better protects student privacy
and independence than does current practice.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7681.
Copyright Notice
Copyright (c) 2015 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
(http://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.

it to her so that she might forward that transcript to whomever she
pleases. In order to prevent forgery of academic transcripts, the
paper record presented to the student often includes various marks of
its authenticity, such as an imprint of the school seal or the
signature of an authorized school official. In order to prevent
unauthorized alteration of transcript content, the prepared document
is sometimes presented to the student inside a sealed postal envelope
that cannot easily be opened without detection -- perhaps aided by
tamper-proof tape, signed envelope flaps, or even imprinted wax
seals. The integrity of the envelope's physical seal assures the
recipient that its contents have not been altered in transit; seals
and signatures affixed to the enclosed document assure the recipient
of the transcript's legitimacy. The student's privacy is assured by
her ability to forward the sealed transcript to whomever she pleases
without the knowledge of or further consultation with the school.
+++
/ \
/\ Digital Transcript / \
/ \ Via Web or Database Connection / \
/ 88 \ / \
/ 88 \ \\ // | College |
/ \ (---) +-------------->> | |
| School | +--------->> (###) +---------+
| | | |
+--------+ <<... | | Copies of Digital Transcript
School Guidance Dept \@| |@ Via Web or Database Connection
| |
+ + +-------+ +++
+------------>> / \
Third-Party Processor / \
Monitors and Controls / \
Student Communication / \
| College |
| |
+---------+
Figure 1: Corrupted Model for Exchanging Secondary School Transcripts
While the traditional process of distributing academic transcripts
admirably protects student privacy and prerogatives, that process
also requires manual effort from the school staff for the preparation
of each transcript. On the premise of reducing that effort, some
school officials have gratuitously misapplied technology in a way
that guts student privacy and effectively excludes students from
their own business. Figure 1 illustrates an increasingly common
aberration. Rather than adopting standardized, readily available
technology to protect the integrity of transmitted student data -- as

it had once been protected by their own signatures on sealed
envelopes -- school officials interpose themselves (or their agents)
between students and transcript recipients, claiming falsely that no
other approach adequately assures the confidentiality, origin, and
integrity of transcript content or the reliability of transcript
transmission. By introducing the role of "third-party processor" in
Figure 1, educators disrupt what should be private, bilateral
relationships between students and their chosen correspondents,
implicitly denying the legitimacy of any technical means by which a
student might manage and secure his/her own communication.
By coercing students into a false choice between surrendering their
privacy or accepting the limitations of a neglected, largely manual
system, educators and allied service providers gain significant new
benefits at student expense. Among these benefits is the creation of
an otherwise unneeded educational services industry to mediate
communication between students and transcript recipients --
communication that, by the most natural operation of the Internet,
would otherwise be end-to-end. A second consequence of coerced
mediation is that the mediators gain unfettered control over school
records that would otherwise be private and often protected by law.
A third consequence of coerced mediation is that mediators can
harvest candid data on student behavior outside the secondary school
domain. Even the most basic information about college and employment
applications, successful or not, individual or in the aggregate, can
have significant value for secondary school officials, college
administrators, employers, and general marketing professionals.
Moreover, although such data is historically private, it is also more
valuable and legally less well protected than internal secondary
school records.
Mediated transcript distribution vitiates student privacy while
endowing school bureaucrats and their confederates with undeserved
privilege, but these political concessions are utterly unnecessary to
automated transcript distribution. As suggested by Figure 2, the
political concessions intrinsic to mediated transcript exchange can
be largely eliminated by the most straightforward automation of the
traditional transcript process.
This memo specifies a common format for exchanging secondary school
academic transcripts via electronic mail. Because the defined format
supports digital signature of transcripts by their originator, a
student cannot fabricate or alter transcript information provided by
school officials. Because the described format supports encrypted
transmission of school transcripts, the distribution of each
student's information can remain private and under his or her
control. Because the format supports asymmetric cryptography, the
origin and integrity of received transcripts can be verified

The acronym EESST (Email Exchange of Secondary School Transcripts)
names the format and methods defined here for securely conveying
student academic records under student control. Requirements for
implementors of this specification are expressed here using a keyword
vocabulary [RFC2119] that is widely understood within the Internet
community.
2. Design Motivation
Implicit in any protocol definition is some assignment of functions
to the various protocol participants. When those participants are
administratively independent one from another, binding assignments of
protocol function -- which might otherwise seem purely technical
choices -- are politically significant. For the sake of
transparency, this protocol specification explicitly reckons the
political consequences of its implicit design choices.
Preparation and delivery of secondary school transcripts most affects
the interests of individual students. After all, the process is
entirely motivated by a student's need to certify his or her personal
academic achievements as evidence of merit for employment, higher
education, or other social advancement or reward. Accordingly,
individual student needs properly dominate the design of a common
system for transcript exchange. Because a secondary school
transcript certifies a student's personal merit, students need
transcript documents that are credible to recipients -- for which the
origin and integrity of transcript content is assured. Because a
school transcript records personal information about an individual
student, student privacy is paramount: control of transcript
distribution must be closely held by the individual student, and each
student must be able to protect the confidentiality of his or her
transcript in transit.
Communication of transcript content between originator, student, and
ultimate recipient is most secure only if that communication is end-
to-end. While the end-to-end argument [Sal84] is fundamental to the
design of the Internet, it is also critical to the design of secure
communication protocols (see Section 6.2 of RFC 1958 [RFC1958]). In
contrast, securely communicating student information to a centralized
(and otherwise uninvolved) third party clearly degrades student
privacy and increases cost. Claims to the contrary are at best
logically absurd and at worst darkly motivated.
After students, transcript handling must address the interests of
transcript recipients, which may include college admission officers,
prospective employers, and scholarship foundations. Recipients must
be able to evaluate the origin and integrity of received transcript

documents easily and independently. Secondarily, recipients may
benefit from mechanical extraction and summary of transcript content
to support their own internal decision processes.
Finally, common transcript handling must address the needs of the
transcript originator -- typically a secondary school guidance
counselor or other school official. An originator's legitimate
interests are reducing the cost of preparing transcript documents and
meeting any legal or moral obligations to protect student privacy.
Insofar as the very notion of electronic school transcripts implies
their automated preparation by computers, dramatic cost reductions
over traditional manual processes are also implicit. An originator's
obligation to protect student privacy is most elegantly and
inexpensively met by simply not conveying transcript information
about a particular student to anyone other than that student.
A protocol by which students must request transcript distributions
addresses no actual student need but, rather, only the legal needs of
third parties seeking to intervene in otherwise private
communications. The additional effort of formal transcript requests
is needed only when a mediating third party is involved, because, in
many jurisdictions, sharing personal information with the third party
legally requires student consent, and an electronic transcript
request may be conveniently construed as implicit consent. Moreover,
a formal transcript request-response protocol is not needed to
document delivery of a transcript to its intended recipient. When
the student, rather than a third party, directly conveys his/her
transcript to a chosen recipient, that student has the greatest
interest in successful communication, can observe any communication
failures firsthand, and can take corrective action if needed.
Familiar, standardized protocols provide unambiguous feedback to the
student about successful transcript delivery. The SMTP protocol, in
particular, is defined and implemented to be fail-safe, as described
in Section 4.1.1.4 of its specification [RFC5321]:
Receipt of the end of mail data indication requires the server to
process the stored mail transaction information. This processing
consumes the information in the reverse-path buffer, the forward-
path buffer, and the mail data buffer, and on the completion of
this command these buffers are cleared. If the processing is
successful, the receiver MUST send an OK reply. If the processing
fails, the receiver MUST send a failure reply. The SMTP model
does not allow for partial failures at this point: either the
message is accepted by the server for delivery and a positive
response is returned or it is not accepted and a failure reply is
returned. In sending a positive "250 OK" completion reply to the
end of data indication, the receiver takes full responsibility for

the message (see Section 6.1). Errors that are diagnosed
subsequently MUST be reported in a mail message, as discussed in
Section 4.4.
3. Protocol Overview
Existing, standardized technology simplifies the process of preparing
and distributing secondary school transcripts. Using a computerized
procedure, a secondary school administrator prepares a digital
transcript document that records the academic achievements of a
particular student and presents that document to that student. Using
postal delivery, secure email, or other method, the student conveys
digital copies of the prepared transcript to recipients of his or her
choice. Using a computerized procedure, each recipient may
independently verify that the received transcript has not been forged
or altered in transit. Because the received transcript is digital,
each recipient may use computerized procedures to extract and
summarize transcript content for local review and processing.
Preparing and delivering a secondary school transcript entails
interaction among three kinds of participant -- transcript
originator, student, and transcript recipient -- each of whom
performs a distinct functional role. Interactions between each kind
of participant are proscribed below.
3.1. Student and Originator
A transcript originator assembles and digitally signs academic
transcripts that document the achievements of individual students in
a secondary school. The role of transcript originator is frequently
filled by the director of a high-school guidance department or other
secondary school official. At fixed times throughout the school
year, using then-current information from a student database, the
guidance director executes a computer program that, for each relevant
student, automatically creates an individual transcript report and
digitally signs that report on the director's behalf. The format of
each signed transcript document is defined in Section 5 below.
The principal responsibilities of a transcript originator are:
1. Generate an OpenPGP key pair that can be used to sign school
transcripts.
2. Create and securely store a key revocation certificate for the
signing key pair for possible future use should it be
compromised.

3. Publish on the World Wide Web the public component of the
transcript signing key pair, together with its OpenPGP
fingerprint.
4. Securely store the private component of the signing key pair and
protect its use with a judiciously chosen passphrase known only
to the transcript originator.
5. Use the signing key pair to create and digitally sign transcripts
for individual students.
6. Present each signed transcript confidentially to the individual
student to which it pertains.
Once generated by the transcript originator, each transcript is
conveyed to the relevant student using any means that protects the
confidentiality of individual student data. For example, a digital
transcript may be written to a CD-ROM storage disk and presented to
the relevant student when he comes to school. Alternatively, that
same CD-ROM could be sealed in an envelope and sent to the student
via postal delivery. A student could present a USB flash drive in
person at the school guidance office, and her digital transcript
could be copied onto that drive. A digital school transcript could
also be presented to the relevant student as a MIME attachment to an
email message that is encrypted according to the OpenPGP
specification. When email is used to convey school transcripts to
students, formatting such messages as specified in Section 6 below
will foster security and interoperability.
After a student receives his/her transcript from its originator, that
student is solely responsible for conveying that transcript to any
recipients of his/her choosing, as described in Section 3.2 below.
3.1.1. Transcript Requests
For several reasons, how students request generation of an academic
transcript from their secondary school is a local matter that need
not and ought not be addressed here.
First, the volume of requests for transcripts is likely to be
relatively low, because transcripts can be pre-issued to most
students (e.g., graduating seniors) who are likely to need them.
When transcripts are digital and easily duplicated by the student,
there is no need to generate a new transcript document for each
desired recipient. Accordingly, most transcript generation is driven
not by student requests but rather by content updates arising from
the predictable passing of marking periods or academic sessions
throughout the school year. Thus, explicit requests for transcript

generation will be the exception rather than the rule -- from
students who have lost a previously issued transcript, or students
leaving the school prior to their graduation.
Second, a historical motivation for formalizing transcript requests
has been to satisfy the school's legal obligation to protect student
privacy. In many legal jurisdictions, school officials are required
to seek student authorization for releasing information to a third
party. Elaborate procedures for requesting transcripts are attempts
to codify or automate that authorization process. However, because,
under the procedure defined here, each student's information is
provided only to that student, no authorization for releasing
information to a third party is required.
Third, a codified transcript request protocol affords almost no
benefit beyond enabling third-party processors to assume the role of
transcript originator and/or distributor. Students need no formal
"acknowledgment" of their transcript requests: the transcript itself
serves that purpose. Because a digital transcript is easily
generated by an automated procedure, there is no benefit to returning
a request acknowledgment rather than the document actually requested.
The primary goal of this protocol design is to strengthen student
privacy and agency by eliminating third-party intrusion into what
would otherwise be private, bilateral interactions between a student
and his school. To codify transcript requests is to undercut
directly that fundamental purpose, while gratuitously restricting
local interactions between student and school.
When each student -- rather than a school official or mediating third
party -- exercises principal control of distributing his or her own
transcript information, any need for transcript requests is largely
obviated. Thus, exchanging and processing such requests is properly
a local matter and not further addressed here.
3.2. Student and Recipient
When a student is asked (e.g., by a college admissions office or
prospective employer) to provide an official transcript of his or her
academic achievements, that student may send to the requesting party
a copy of the digitally signed transcript document that he has
previously received from his secondary school. In this context, the
party requesting that the student send a transcript is called a
transcript recipient. Because it is the student who conveys his own
transcript information, he or she unambiguously controls the set of
recipients, and neither the secondary school nor any third party is
responsible for or privy to the identities of his correspondents.
Similarly, the student is responsible for assuring the privacy of his
or her personal information as he conveys it to these recipients.

The student may convey his transcript to his chosen recipient using
any mutually agreeable strategy. For example, he may print a copy of
his transcript onto a postcard and send it via postal delivery. This
strategy does not strongly protect the confidentiality of the
student's information in transit, nor does this strategy allow the
recipient to automate verification or other processing of the
received transcript information. Sending a paper transcript sealed
in a postal envelope better protects student confidentiality, but
similarly restricts the recipient's ability to verify or process
transcript contents. By copying his digital transcript onto a CD-ROM
storage disk and sending that disk, sealed in a postal envelope, via
surface mail, the recipient can automatically verify and process the
transcript content, although protection of student confidentiality in
transit might be stronger.
Alternatively, a student could send a copy of the digital transcript
provided by his secondary school merely by attaching the relevant
computer file to an email message addressed to the recipient. If the
student completely trusts the end-to-end email transmission path from
himself to his intended recipient (e.g., if student and recipient are
connected by a common, private network), then the student could send
his transcript in a plaintext email; otherwise, the student SHOULD
encrypt the email contents to protect his privacy during
transmission.
If a student chooses to convey his/her school transcript to a
transcript recipient via electronic mail, then the principal
responsibilities of that student are:
1. Create a personal email account and associated email address from
which transmissions of the student's signed school transcript may
be sent.
2. For each potential recipient of the student's signed school
transcript, discover and record the email address and the public
OpenPGP key published by that transcript recipient.
3. Import the OpenPGP public key for each chosen recipient into the
local OpenPGP key database.
4. Use an email client application that implements the OpenPGP/MIME
specification [RFC3156] in order to encrypt and transmit a copy
of the signed school transcript to each chosen recipient.
Using common formats and methods to convey transcript content
protects students while also simplifying processing for transcript
recipients. The representation of transcripts as specified in
Section 5 and the use of the transmission formats specified in

Section 6 afford privacy and autonomy to students. By using these
formats, recipients may independently verify the origin and integrity
of the transcript information that students provide. Common
transcript representation also allows recipients to automate the
storage, analysis, and review of received transcripts.
However, a student cannot use the format specified here to convey
his/her transcript to a chosen recipient unless that recipient is
prepared to participate in the exchange. The principal
responsibilities of a transcript recipient are:
1. Generate an OpenPGP key pair that can be used to encrypt student
transmissions of signed school transcripts to the recipient.
2. Create and securely store a key revocation certificate for the
key pair generated above for possible future use in the event
that the private key component is compromised.
3. Create a (preferably dedicated) email address and mailbox to
which students may direct transmissions of signed school
transcripts.
4. Publish on the World Wide Web both the dedicated transcript email
address and the public component of the OpenPGP key pair
generated above, together with its OpenPGP fingerprint.
5. Securely store the private component of the OpenPGP key pair
generated above and guard its use with a judiciously chosen
passphrase known only to the transcript recipient.
6. Assemble a collection of public OpenPGP keys published by
legitimate transcript originators.
7. Receive and decrypt transcripts transmitted by students.
8. Validate the origin and integrity of each received transcript
using the public OpenPGP key of the relevant transcript
originator.
The similarity between the EESST transcript format and generic
OpenPGP/MIME email messages allows transcript recipients to inspect,
verify, and extract received school transcripts using existing,
widely deployed email clients. By using email client applications
that support both the MIME and OpenPGP specifications, transcript
recipients should easily be able to verify the signature of the
transcript originator and to save the various transcript components
locally for later review or processing.

Using familiar email client applications for receiving and reviewing
small numbers of received school transcripts does not preclude using
more automated systems to meet the needs of university admissions
departments or large employers. Larger-volume transcript recipients
might ask students to direct their school transcripts to a particular
email mailbox. Transcripts so delivered could be periodically
received, validated, and otherwise organized by specialized
application software. Information in the computational component of
received transcripts might be incorporated into a candidate database
to simplify more quantitative evaluations of the applicant pool.
4. Transcript Content
The content of a school transcript is represented as a single MIME
body part whose content type is "multipart/mixed". This multipart
representation comprises individual MIME elements that represent (in
order) prefatory comments from the transcript originator regarding
the validation and interpretation of the represented transcript
(described in Section 4.1), a rendering of the relevant school
transcript suitable for automated processing (described in
Section 4.2), and a rendering of that same school transcript suitable
for human review and consideration (described in Section 4.3).
Figure 3 below schematically presents the MIME structure used to
represent transcript content; Figure 4 illustrates an example
representation of transcript content.
Every representation of transcript content MUST include exactly the
following set of MIME content headers:
Content-Type: This header is defined in Section 5 of the MIME format
specification [RFC2045] and, when associated with the content of
a signed school transcript, MUST have the value "multipart/
mixed".
Content-Description: This header is defined in Section 8 of the MIME
format specification [RFC2045]. Its value provides humans with
"descriptive information" about the content of the represented
school transcript. Notwithstanding the statement in RFC 2045
that a content description header is optional, this header MUST
be included in the MIME representation of school transcript
content.
MIME-Version: This header is defined in Section 4 of the MIME format
specification [RFC2045]. Its value identifies the version of
the MIME specification to which the associated body part
conforms. Currently, the value of this header MUST always be
"1.0". Sometimes, the EESST specification can require an
appearance of the MIME-Version header where it is not otherwise

strictly required by the MIME format specification. These
seemingly gratuitous MIME-Version headers are deliberately
introduced to help users who may need to apply less-capable
email clients recursively in order to navigate and display a
transmitted transcript.
Eesst-Version: The value of this header identifies the version of
the EESST format to which the represented school transcript
conforms. Currently, the value of this header MUST always be
"1.0".
From: The value of this header identifies the originator of the
represented school transcript. This value names the originating
official, his organizational title, and includes, enclosed
within angle brackets, the identity of the OpenPGP key with
which the represented school transcript has been digitally
signed.
Organization: The value of this header identifies the organization
or institution to which the originator of the relevant message
belongs. Within a school transcript document, the value of this
header identifies the secondary school that has issued the
represented school transcript. By convention, the value of this
header names the originating institution along with its
geographical location.
Subject: The value of this header provides humans with "descriptive
information" about the semantic content of the represented
school transcript. Inclusion of this header is optional, but,
if included, its value MUST match that of the "Content-
Description" header above. The presence of the "Subject" header
helps some email reader applications to present school
transcript transmissions more elegantly.
Date: The value of this header identifies the date on which the
represented school transcript was created, and its format MUST
be consistent with Section 3.3 of the specification for email
messages [RFC5322].
With the exception of the optional "Subject" header, each header
enumerated above must appear in the MIME body part that represents
the aggregate content of a school transcript. No other headers are
permitted, and the allowed set of headers may appear in any order.
Example MIME headers for transcript content are presented in
Figure 4. In the figure, "PESC" stands for the Postsecondary
Electronic Standards Council; see Section 4.2 for more information.

4.1. School Transcript Preface
A school transcript preface conveys generic comments about a school
transcript from the originating school official. This commentary is
in a form that is widely readable by humans without special
application tools. This commentary SHOULD be generic in character,
providing general information about the preparation and
interpretation of transcripts issued by the originating institution;
the transcript preface SHOULD NOT provide information about an
individual student. The rhetorical form of a transcript preface is
sometimes that of a cover letter addressed to a generic transcript
recipient. For example, a preface could provide instructions on how
to verify the digital signature on the transcript or an explanation
of unusual grading practices at the issuing school. A school
transcript preface is represented as a MIME body part whose content
type is "text/plain".
When a school transcript is encapsulated for transmission into a
larger email message, arbitrary text within a transcript preface
could be accidentally misinterpreted as structural MIME boundaries or
email headers. The likelihood of such errors is reduced when preface
content does not include lines that begin with hyphen (-) characters,
angle bracket (>) characters, or the word "From." Although, ideally,
the transcript preface should be readable by humans without special
assistance, when these constructs absolutely cannot be avoided within
preface text, transcript originators SHOULD apply a content transfer
encoding to the preface that insulates it from misinterpretation by
intermediary mail transfer agents.
The representation of a transcript preface SHOULD NOT include any
header fields beyond those enumerated in the specification for the
format of MIME message bodies [RFC2045].
4.2. Computational School Transcript
A computational school transcript represents the academic
accomplishments of an individual student in a form suitable for
automated processing. Accordingly, the content of a computational
school transcript is rendered in Extensible Markup Language (XML)
[XML11] and conveyed as a MIME body part whose content type is
"application/xml". The syntax of the data conveyed by a
computational transcript MUST conform to the XML schema for High
School Transcripts, Version 1.3.0 [Fun12b], published by the
Postsecondary Electronic Standards Council (PESC). This XML schema
depends in turn upon the Academic Record XML schema, Version 1.7.0
[Fun12a] and the Core Main XML schema, Version 1.2.0 [Mar06], also

published by PESC. Detailed semantics for the data elements defined
by these XML schema are defined in the PESC XML implementation guide,
Version 1.3.0 [Ste12], which also provides usage examples.
In order to protect student privacy, this specification does not
require a school transcript to convey any particular student
information but, rather, defines only a common format for whatever
student information may be voluntarily exchanged between consenting
parties. The scope of the information exchanged is a completely
local matter, and a transcript originator MAY omit from transcript
content any information (e.g., a student's social security number,
the identity and location of a student's parents, a student's race,
ethnicity, or transgender status) that might be regarded locally as
sensitive or irrelevant. Indeed, the requirement that a
computational transcript conform syntactically to the PESC XML schema
imposes few, if any, constraints upon the transcript originator's
choices regarding transcript content. Figure 5 illustrates a minimal
set of XML elements that satisfies the syntactic requirements of the
PESC XML schema. A computational transcript need convey no more
information about an individual student than what little is conveyed
by that figure.
In order to prevent implicit monitoring and control of student
interactions with transcript recipients, this specification restricts
certain uses of the PESC XML schema by transcript originators. In
every computational transcript, the "Destination" sub-element of the
"DataTransmission" element MUST convey no distinguishable information
and have the particular representation
"<Destination><Organization/></Destination>"
that is illustrated in Figure 5. This requirement assures that a
student may use self-made copies of a signed transcript document for
whatever purposes he/she chooses without further consultation with
issuing school officials. If the transcript originator is allowed to
brand particular destinations onto each copy of a student transcript,
then the originator can easily monitor and (to some degree) control
the set of college admissions officers, prospective employers, or
other third parties to whom the student is providing that transcript.
Transcript recipients MUST reject any transcript whose content in any
way specifies or restricts the audience, recipient, or distribution
for that transcript. Notwithstanding this restriction upon the
"Destination" element, the "Source" element SHOULD be included within
a computational transcript and convey information sufficient to
identify the secondary school or other institution by which the
relevant transcript is issued.

<HSTrn:HighSchoolTranscript
xmlns:HSTrn="urn:org:pesc:message:HighSchoolTranscript:v1.3.0"
xmlns:AcRec="urn:org:pesc:sector:AcademicRecord:v1.7.0"
xmlns:core="urn:org:pesc:core:CoreMain:v1.12.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:pesc:message:HighSchoolTranscript:v1.3.0
HighSchoolTranscript_v1.3.0.xsd">
<TransmissionData>
<DocumentID>X</DocumentID>
<CreatedDateTime>2011-04-04T09:30:47-05:00</CreatedDateTime>
<DocumentTypeCode>StudentRequest</DocumentTypeCode>
<TransmissionType>MutuallyDefined</TransmissionType>
<Source>
<Organization/>
</Source>
<Destination>
<Organization/>
</Destination>
</TransmissionData>
<Student>
<Person>
<Name/>
</Person>
<AcademicRecord/>
</Student>
</HSTrn:HighSchoolTranscript>
Figure 5: A Minimal Set of PESC XML Elements
Additional restrictions on the use of the PESC XML schema foster
common, unambiguous interpretation and simplified processing of
computational transcripts:
1. In order to satisfy the minimal syntactic requirements of the
PESC XML schema, every computational transcript MUST comprise at
least those XML elements that appear in Figure 5. Even when a
transcript originator seeks to convey no information within a
computational transcript, the computational transcript must be
included within the relevant transcript content, and its payload
must have the form illustrated in Figure 5.
2. Consistent with the PESC XML schema, any value ascribed to the
"DocumentID" XML element must be at least one non-whitespace
character in length.

3. Consistent with the PESC XML schema, any value ascribed to the
"CreatedDateTime" XML element must have the form of an XML
"dateTime" value, as defined in Section 3.2.7 of the XML Schema
Datatype specification [XSD].
4. Lest the origin and correct handling for a computational
transcript be misunderstood, the value ascribed to the
"DocumentTypeCode" XML element MUST be "StudentRequest".
5. Lest the origin and correct handling for a computational
transcript be misunderstood, the value ascribed to the
"TransmissionType" XML element MUST be "MutuallyDefined".
6. With the exception of those XML elements that appear in Figure 5,
information that is not provided in a computational transcript
MUST be represented by entirely omitting the relevant XML data
element; omitted information MUST NOT be represented by including
an XML element whose textual value is of zero length or contains
only whitespace.
The representation of a computational transcript SHOULD NOT include
any header fields beyond those enumerated in the specification for
the format of MIME message bodies [RFC2045]. Although any valid
content transfer encoding is acceptable for a computational school
transcript, the "quoted-printable" encoding is preferred.
4.3. Display School Transcript
A display school transcript describes the academic accomplishments of
an individual student in a form suitable for human reading and
review. A display school transcript is represented as a MIME body
part whose content type is "application/pdf" and whose content
conforms to the Portable Document Format (PDF) specification [PDF17].
A display school transcript may comprise one or more physical pages.
In order to reduce the chance that the recipient of a signed school
transcript could misinterpret its content, the computational
component (described in Section 4.2 above) and the display component
(defined here) of each signed school transcript SHOULD convey, to the
greatest degree possible, identical information about the academic
accomplishments of the relevant student.
Nothing in this specification should be construed as requiring
implementation or use of digital signature features embedded in
individual PDF documents pursuant to the PDF specification. Rather,
the data integrity and origin identity of all components in a school
transcript --- including the PDF display transcript --- are
adequately protected by the OpenPGP signature of the transcript

originator, required by this specification. Accordingly,
implementation of PDF-specific signature features is optional and
largely unwarranted; although transcript recipients MUST accept
transcripts that include PDF signatures, recipients SHOULD neither
verify nor depend upon the embedded signatures themselves.
Transcript originators MUST NOT use the encryption features described
in the PDF specification to encrypt a display school transcript. The
OpenPGP encryption mechanisms specified in Section 6 below adequately
protect the confidentiality of student information while in transit.
Thus, separately encrypting the display transcript is redundant.
Double encryption increases implementation complexity while also
increasing security risk by requiring additional key distributions.
Transcript recipients MUST NOT accept or process school transcripts
for which the PDF display component is independently encrypted.
Previous work [RFC3778] identifies security considerations arising
from using the PDF as a MIME media type. Among these considerations
is that PDF documents may include executable "scripts" or references
to external, executable plug-in modules. Including arbitrary
executable programs (or references thereto) in a PDF transcript
document poses a security risk to transcript recipients. Digitally
signing PDF documents (or even the transcripts that contain them)
does not help transcript recipients to evaluate the safety of
executing any embedded programs or plug-ins. The primary purpose of
using PDF is to present static transcript information in an
attractive format for human review. Because this limited purpose is
admirably served without embedding executable elements in PDF files,
any risk posed by their inclusion is unwarranted. Accordingly,
transcript originators MUST NOT include in a PDF display transcript
any executable scripts or external plug-in references. In order to
preclude execution of untrusted programs on their local system,
transcript recipients SHOULD use only trusted tools to process and
view display transcripts.
The representation of a display school transcript SHOULD NOT include
any header fields beyond those enumerated in the specification for
the format of MIME message bodies [RFC2045].