Independent Submission J. Davin
Request for Comments: 7681 October 2015
Category: Informational
ISSN: 2070-1721
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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Motivation . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Student and Originator . . . . . . . . . . . . . . . . . 8
3.1.1. Transcript Requests . . . . . . . . . . . . . . . . . 9
3.2. Student and Recipient . . . . . . . . . . . . . . . . . . 10
4. Transcript Content . . . . . . . . . . . . . . . . . . . . . 13
4.1. School Transcript Preface . . . . . . . . . . . . . . . . 17
4.2. Computational School Transcript . . . . . . . . . . . . . 17
4.3. Display School Transcript . . . . . . . . . . . . . . . . 20
5. Signed School Transcript . . . . . . . . . . . . . . . . . . 21
6. Transcript Transmission . . . . . . . . . . . . . . . . . . . 24
6.1. Encrypted Format . . . . . . . . . . . . . . . . . . . . 27
6.2. Encrypted and Signed Format . . . . . . . . . . . . . . . 28
6.3. Encrypted File Format . . . . . . . . . . . . . . . . . . 30
6.4. Traditional Inline Format . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1. Originator Private Key . . . . . . . . . . . . . . . . . 35
7.2. Originator Public Key . . . . . . . . . . . . . . . . . . 35
7.3. Originator Certification . . . . . . . . . . . . . . . . 35
7.4. Recipient Public Key . . . . . . . . . . . . . . . . . . 35
7.5. Secure Clients . . . . . . . . . . . . . . . . . . . . . 36
7.6. Automatic Replies . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.1. Registration of Eesst-Version Header . . . . . . . . . . 37
8.2. Registration of Organization Header . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Motivation . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Student and Originator . . . . . . . . . . . . . . . . . 8
3.1.1. Transcript Requests . . . . . . . . . . . . . . . . . 9
3.2. Student and Recipient . . . . . . . . . . . . . . . . . . 10
4. Transcript Content . . . . . . . . . . . . . . . . . . . . . 13
4.1. School Transcript Preface . . . . . . . . . . . . . . . . 17
4.2. Computational School Transcript . . . . . . . . . . . . . 17
4.3. Display School Transcript . . . . . . . . . . . . . . . . 20
5. Signed School Transcript . . . . . . . . . . . . . . . . . . 21
6. Transcript Transmission . . . . . . . . . . . . . . . . . . . 24
6.1. Encrypted Format . . . . . . . . . . . . . . . . . . . . 27
6.2. Encrypted and Signed Format . . . . . . . . . . . . . . . 28
6.3. Encrypted File Format . . . . . . . . . . . . . . . . . . 30
6.4. Traditional Inline Format . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1. Originator Private Key . . . . . . . . . . . . . . . . . 35
7.2. Originator Public Key . . . . . . . . . . . . . . . . . . 35
7.3. Originator Certification . . . . . . . . . . . . . . . . 35
7.4. Recipient Public Key . . . . . . . . . . . . . . . . . . 35
7.5. Secure Clients . . . . . . . . . . . . . . . . . . . . . 36
7.6. Automatic Replies . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.1. Registration of Eesst-Version Header . . . . . . . . . . 37
8.2. Registration of Organization Header . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 38
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
Traditional, paper-based communication of individual student records protects the rights and interests of all stakeholders -- the secondary school officials who curate student records, the students who are both the subjects and distributors of their own individual records, and the college admission officers, prospective employers, and others who, with the permission of individual students, receive and review such records. In the traditional process, when a graduating student applies for employment or admission to an institution of higher learning, she asks the guidance counselor at her secondary school for a transcript of her academic achievements to support her application. In response, the guidance counselor prepares a paper record of that student's achievements and presents
个人学生记录的传统纸质传播保护了所有利益相关者的权利和利益——负责管理学生记录的中学官员、既是自己个人记录的主体和分发者的学生、大学招生官、潜在雇主和其他人，在学生个人许可的情况下，接收和审查此类记录。在传统的过程中，当毕业生申请就业或进入高等学校时，她会要求中学的指导顾问提供学业成绩的成绩单，以支持她的申请。作为回应，指导顾问准备了一份该学生成绩的纸质记录，并提交
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 |
| |
+---------+
+++
/ \
/\ 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
图1：交换中学成绩单的损坏模型
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
虽然传统的分发成绩单的过程令人钦佩地保护了学生的隐私和特权，但这一过程也需要学校工作人员手动准备每份成绩单。在减少这种努力的前提下，一些学校官员无缘无故地滥用了技术，破坏了学生的隐私，并有效地将学生排除在自己的业务之外。图1显示了一种日益常见的畸变。而不是采用标准化的、现成的技术来保护传输的学生数据的完整性
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.
学校官员（或其代理人）在学生和成绩单接受者之间插手干预，谎称没有其他方法能够充分保证成绩单内容的机密性、来源和完整性或成绩单传输的可靠性。通过在图1中引入“第三方处理者”的角色，教育工作者破坏了学生与其选定的通信员之间本应是私人的双边关系，含蓄地否定了学生管理和保护自己通信的任何技术手段的合法性。
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.
调解的成绩单分发损害了学生的隐私，同时赋予学校官员及其同盟者不应有的特权，但这些政治让步对于自动成绩单分发是完全没有必要的。如图2所示，通过最直接的传统转录过程自动化，调解转录本交换所固有的政治让步可以在很大程度上消除。
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
本备忘录规定了通过电子邮件交换中学学业成绩单的通用格式。由于定义的格式支持发起者对成绩单进行数字签名，学生不能伪造或更改学校官员提供的成绩单信息。由于所述格式支持学校成绩单的加密传输，因此每个学生信息的分发可以保持隐私，并在其控制下进行。由于该格式支持非对称加密，因此可以验证收到的转录本的来源和完整性
independently by the recipient; confidential content can be independently recovered by an intended recipient while remaining protected from unauthorized access. Because the Internet email protocol provides fail-safe delivery, transcripts are reliably delivered to their intended recipients, and the sending student is directly notified of any exceptions. No centralized, trusted authority is needed to mediate communication between students, transcript originators, or transcript recipients. Thus, a student's need for an authoritative record of his education cannot be exploited to restrict or monitor his/her free and private interactions with colleges, employers, or others. Students can reclaim control over their own personal information and their relationships with prospective employers and admissions officers; students can prevent surreptitious harvesting of information about their affairs. Last but not least, specialized software is not required by most participants in the school transcript exchange protocol: the needs of all students and many transcript recipients can be met by existing, standards-based, secure email clients.
由接收方独立进行；机密内容可以由指定的收件人独立恢复，同时防止未经授权的访问。由于互联网电子邮件协议提供了故障安全传递，成绩单可以可靠地传递给预期的收件人，并且发送学生会直接收到任何异常情况的通知。学生、成绩单发起者或成绩单接收者之间的沟通不需要集中、可信的权威机构。因此，不能利用学生对其教育的权威记录的需求来限制或监控他/她与大学、雇主或其他人的自由和私人互动。学生可以重新控制自己的个人信息以及与潜在雇主和招生官员的关系；学生们可以防止秘密获取有关他们事务的信息。最后但并非最不重要的一点是，学校成绩单交换协议的大多数参与者并不需要专门的软件：现有的基于标准的安全电子邮件客户端可以满足所有学生和许多成绩单接收者的需求。
+++
/ \
/\ Digitally Signed Transcript / \
/ \ Via CD-ROM, Secure Email, etc. / \
/ 88 \ / \
/ 88 \ --- | College |
/ \ (0 0) +-------------->> | |
| School | +--------->> ( - ) +---------+
| | | | Copies of
+--------+ | | Digitally Signed Transcript
School Guidance Dept | | Via Secure Email, CD-ROM, etc.
| |
| | +-------+ +++
8 8 +------------>> / \
Student / \
Privately and Autonomously / \
Forwards Digitally Signed Transcript / \
| College |
| |
+---------+
+++
/ \
/\ Digitally Signed Transcript / \
/ \ Via CD-ROM, Secure Email, etc. / \
/ 88 \ / \
/ 88 \ --- | College |
/ \ (0 0) +-------------->> | |
| School | +--------->> ( - ) +---------+
| | | | Copies of
+--------+ | | Digitally Signed Transcript
School Guidance Dept | | Via Secure Email, CD-ROM, etc.
| |
| | +-------+ +++
8 8 +------------>> / \
Student / \
Privately and Autonomously / \
Forwards Digitally Signed Transcript / \
| College |
| |
+---------+
Figure 2: Traditional Model for Exchanging Secondary School Transcripts
图2：交换中学成绩单的传统模式
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.
首字母缩略词EESST（中学成绩单电子邮件交换）指定了此处定义的格式和方法，用于在学生控制下安全地传递学生学业成绩。本规范实施者的要求在这里使用互联网社区广泛理解的关键词词汇表[RFC2119]表达。
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.
只有在端到端通信的情况下，发起者、学生和最终接收者之间的成绩单内容通信才是最安全的。虽然端到端参数[Sal84]是互联网设计的基础，但它对安全通信协议的设计也至关重要（参见RFC 1958[RFC1958]第6.2节）。相比之下，将学生信息安全地传达给集中的（或其他无关的）第三方显然会降低学生隐私并增加成本。相反的主张充其量在逻辑上是荒谬的，充其量也有黑暗的动机。
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]:
学生必须要求分发成绩单的协议不涉及学生的实际需要，而只涉及寻求干预其他私人通信的第三方的法律需要。只有当涉及调解第三方时，才需要正式成绩单请求的额外努力，因为在许多司法管辖区，与第三方共享个人信息在法律上需要学生同意，而电子成绩单请求可以方便地解释为默示同意。此外，不需要正式的成绩单请求-响应协议来记录成绩单交付给预期收件人的情况。当学生（而不是第三方）直接将其成绩单传达给选定的接收者时，该学生对成功沟通最感兴趣，可以直接观察任何沟通失败，并在需要时采取纠正措施。熟悉的、标准化的协议为学生提供关于成功交付成绩单的明确反馈。具体而言，SMTP协议的定义和实现是故障安全的，如其规范[RFC5321]第4.1.1.4节所述：
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
接收邮件结束数据指示需要服务器处理存储的邮件事务信息。此处理消耗反向路径缓冲区、正向路径缓冲区和邮件数据缓冲区中的信息，并且在完成此命令后，这些缓冲区将被清除。如果处理成功，接收方必须发送一个OK回复。如果处理失败，接收方必须发送失败回复。SMTP模型此时不允许部分失败：服务器接受邮件进行传递并返回肯定响应，或者不接受邮件并返回失败响应。在向数据指示结束发送肯定的“250 OK”完成回复时，接收方对
the message (see Section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in Section 4.4.
信息（见第6.1节）。如第4.4节所述，随后诊断的错误必须在邮件中报告。
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.
准备和交付中学成绩单需要三种参与者之间的互动——成绩单的创始者、学生和成绩单接收者——每个人都扮演着不同的职能角色。下文禁止各类参与者之间的互动。
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.
成绩单的创始者将记录中学生个人成绩的成绩单汇总并进行数字签名。成绩单发起者的角色通常由高中指导部主任或其他中学官员担任。在整个学年的固定时间，指导主任使用来自学生数据库的当前信息，执行一个计算机程序，为每个相关学生自动创建一份个人成绩单报告，并代表指导主任对该报告进行数字签名。下文第5节规定了每份签署的成绩单文件的格式。
The principal responsibilities of a transcript originator are:
成绩单发起人的主要责任是：
1. Generate an OpenPGP key pair that can be used to sign school transcripts.
1. 生成可用于签署学校成绩单的OpenPGP密钥对。
2. Create and securely store a key revocation certificate for the signing key pair for possible future use should it be compromised.
2. 为签名密钥对创建并安全地存储密钥吊销证书，以备将来可能会被泄露时使用。
3. Publish on the World Wide Web the public component of the transcript signing key pair, together with its OpenPGP fingerprint.
3. 在万维网上发布抄本签名密钥对的公共组件及其OpenPGP指纹。
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.
4. 安全地存储签名密钥对的私有组件，并使用只有转录本发起人知道的明智选择的密码短语保护其使用。
5. Use the signing key pair to create and digitally sign transcripts for individual students.
5. 使用签名密钥对为个别学生创建成绩单并对其进行数字签名。
6. Present each signed transcript confidentially to the individual student to which it pertains.
6. 将每份签名的成绩单秘密地交给相关学生。
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.
一旦由成绩单创建者生成，每份成绩单将通过任何保护学生个人数据机密性的方式传达给相关学生。例如，数字成绩单可以写入CD-ROM存储盘，并在相关学生到校时呈现给他。或者，同样的CD-ROM可以密封在信封中，通过邮递发送给学生。学生可以亲自在学校指导办公室出示USB闪存驱动器，她的数字成绩单可以复制到该驱动器上。数字学校成绩单也可以作为电子邮件的MIME附件呈现给相关学生，该电子邮件根据OpenPGP规范进行加密。当使用电子邮件向学生传递学校成绩单时，按照下文第6节的规定格式化此类消息将促进安全性和互操作性。
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.2节所述，该学生应全权负责将成绩单传递给其选择的任何接收者。
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.
当每个学生——而不是学校官员或中介第三方——对分发他或她自己的成绩单信息行使主要控制权时，对成绩单请求的任何需求在很大程度上都被消除了。因此，交换和处理此类请求是本地事务，此处不再进一步讨论。
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.
学生可使用任何双方同意的策略将其成绩单传达给其选定的收件人。例如，他可以将成绩单打印到明信片上，然后通过邮递发送。这一策略不能很好地保护传输中学生信息的机密性，也不允许接收者对收到的成绩单信息进行自动验证或其他处理。寄一份密封在邮寄信封中的纸质成绩单可以更好地保护学生的机密性，但同样也限制了收件人核实或处理成绩单内容的能力。通过将他的数字成绩单复制到CD-ROM存储磁盘上，并通过普通邮件将该磁盘密封在邮政信封中，接收者可以自动验证和处理成绩单内容，尽管在传输过程中对学生保密性的保护可能会更强。
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.
1. 创建一个个人电子邮件帐户和相关的电子邮件地址，从中可以发送学生签名的学校成绩单。
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.
2. 对于学生签名学校成绩单的每个潜在收件人，发现并记录该成绩单收件人发布的电子邮件地址和公开OpenPGP密钥。
3. Import the OpenPGP public key for each chosen recipient into the local OpenPGP key database.
3. 将每个选定收件人的OpenPGP公钥导入本地OpenPGP密钥数据库。
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.
4. 使用实现OpenPGP/MIME规范[RFC3156]的电子邮件客户端应用程序，以加密签名学校成绩单的副本并将其发送给每个选定的收件人。
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
使用通用格式和方法传达成绩单内容可以保护学生，同时简化成绩单接收者的处理。第5节中规定的成绩单表示和第5节中规定的传输格式的使用
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.
第6节为学生提供隐私和自主权。通过使用这些格式，收件人可以独立验证学生提供的成绩单信息的来源和完整性。通用成绩单表示还允许收件人自动存储、分析和审阅收到的成绩单。
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.
1. 生成OpenPGP密钥对，该密钥对可用于加密学生向收件人发送的签名学校成绩单。
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.
2. 为上面生成的密钥对创建并安全存储密钥吊销证书，以便在私钥组件受损的情况下将来可能使用。
3. Create a (preferably dedicated) email address and mailbox to which students may direct transmissions of signed school transcripts.
3. 创建一个（最好是专用的）电子邮件地址和邮箱，学生可以将签名的学校成绩单发送到该邮箱。
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.
4. 在万维网上发布上述生成的OpenPGP密钥对的专用成绩单电子邮件地址和公共组件，以及其OpenPGP指纹。
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.
5. 安全地存储上面生成的OpenPGP密钥对的私有组件，并使用只有转录本接收者知道的明智选择的密码短语保护其使用。
6. Assemble a collection of public OpenPGP keys published by legitimate transcript originators.
6. 收集由合法转录本创建者发布的公开OpenPGP密钥集合。
7. Receive and decrypt transcripts transmitted by students.
7. 接收和解密学生发送的成绩单。
8. Validate the origin and integrity of each received transcript using the public OpenPGP key of the relevant transcript originator.
8. 使用相关成绩单发起人的公开OpenPGP密钥验证每个收到成绩单的来源和完整性。
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.
EESST成绩单格式和通用OpenPGP/MIME电子邮件消息之间的相似性允许成绩单收件人使用现有的、广泛部署的电子邮件客户端检查、验证和提取收到的学校成绩单。通过使用支持MIME和OpenPGP规范的电子邮件客户端应用程序，成绩单接收者应该能够轻松地验证成绩单发起人的签名，并将各种成绩单组件保存在本地，以供以后审查或处理。
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.
使用熟悉的电子邮件客户端应用程序接收和审核少量收到的学校成绩单并不排除使用更自动化的系统来满足大学招生部门或大型雇主的需求。成绩单数量较大的收件人可能会要求学生将其学校成绩单直接发送到特定的电子邮件邮箱。这样交付的成绩单可以由专门的应用软件定期接收、验证和组织。收到的成绩单的计算部分中的信息可能会被纳入候选数据库，以简化对申请人库的更多定量评估。
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.
学校成绩单的内容表示为单个MIME主体部分，其内容类型为“多部分/混合”。该多部分表述包括单个MIME元素，这些元素表示（按顺序）来自成绩单创始者关于所述成绩单的验证和解释（如第4.1节所述）的序言评论，以及适用于自动处理的相关学校成绩单的呈现（如第4.2节所述），以及同一学校成绩单的呈现，该成绩单适合人类审查和考虑（如第4.3节所述）。下面的图3示意性地展示了用于表示转录本内容的MIME结构；图4展示了转录本内容的示例表示。
Every representation of transcript content MUST include exactly the following set of MIME content headers:
转录本内容的每个表示形式必须完全包含以下MIME内容头集：
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".
内容类型：此标题在MIME格式规范[RFC2045]第5节中定义，当与签名学校成绩单的内容关联时，必须具有值“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格式规范[RFC2045]的第8节中定义。它的值为人类提供有关所代表学校成绩单内容的“描述性信息”。尽管RFC 2045中声明内容描述头是可选的，但该头必须包含在学校成绩单内容的MIME表示中。
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
MIME版本：此标头在MIME格式规范[RFC2045]的第4节中定义。其值标识关联的主体部分所符合的MIME规范的版本。当前，此标题的值必须始终为“1.0”。有时候，EESST规范可能需要MIME版本头的外观，而不是其他外观
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.
MIME格式规范严格要求。这些看似免费的MIME版本头被故意引入，以帮助可能需要递归应用功能较差的电子邮件客户端的用户导航和显示传输的成绩单。
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".
Eesst版本：此标题的值标识所代表的学校成绩单符合的Eesst格式版本。当前，此标题的值必须始终为“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.
From：此标题的值标识所代表学校成绩单的发起人。该值命名发起官员、其组织头衔，并包括（括在尖括号内）OpenPGP密钥的标识，所代表的学校成绩单已使用该密钥进行数字签名。
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].
日期：此标题的值标识创建所代表学校成绩单的日期，其格式必须与电子邮件规范[RFC5322]第3.3节一致。
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.
除了可选的“主题”标题外，上面列举的每个标题必须出现在MIME正文部分中，该部分表示学校成绩单的汇总内容。不允许有其他标题，允许的标题集可以以任何顺序出现。图4显示了转录本内容的MIME头示例。图中，“PESC”代表专上电子标准委员会；更多信息请参见第4.2节。
+--------------------------------------------------+
| TRANSCRIPT CONTENT |
| Content-Type: multipart/mixed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT PREFACE | |
| | Content-Type: text/plain | |
| | | |
| | Body represents transcript preface | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | COMPUTATIONAL TRANSCRIPT | |
| | Content-Type: application/xml | |
| | | |
| | Body represents PESC XML computational | |
| | transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | DISPLAY TRANSCRIPT | |
| | Content-Type: application/pdf | |
| | | |
| | Body represents PDF display transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
+--------------------------------------------------+
| TRANSCRIPT CONTENT |
| Content-Type: multipart/mixed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT PREFACE | |
| | Content-Type: text/plain | |
| | | |
| | Body represents transcript preface | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | COMPUTATIONAL TRANSCRIPT | |
| | Content-Type: application/xml | |
| | | |
| | Body represents PESC XML computational | |
| | transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | DISPLAY TRANSCRIPT | |
| | Content-Type: application/pdf | |
| | | |
| | Body represents PDF display transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 3: MIME Structure of Transcript Content
图3：转录本内容的MIME结构
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============BBBBBBBBBB==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="preface.txt"
Content-Description: School Transcript Preface
--===============BBBBBBBBBB==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="preface.txt"
Content-Description: School Transcript Preface
To Whom It May Concern:
与之相关的人员：
This academic transcript describes the accomplishments of an ...
这本学术成绩单描述了一个。。。
--===============BBBBBBBBBB==
Content-Type: application/xml
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="transcript.xml"
Content-Description: School Transcript rendered as PESC XML
--===============BBBBBBBBBB==
Content-Type: application/xml
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="transcript.xml"
Content-Description: School Transcript rendered as PESC XML
<HSTrn:HighSchoolTranscript=20xmlns:AcRec=3D"urn:org:pesc:sector:Acad
...
cord></Student></HSTrn:HighSchoolTranscript>
--===============BBBBBBBBBB==
Content-Type: application/pdf
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="transcript.pdf"
Content-Description: School Transcript rendered as PDF
<HSTrn:HighSchoolTranscript=20xmlns:AcRec=3D"urn:org:pesc:sector:Acad
...
cord></Student></HSTrn:HighSchoolTranscript>
--===============BBBBBBBBBB==
Content-Type: application/pdf
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="transcript.pdf"
Content-Description: School Transcript rendered as PDF
JVBERi0xLjMNCiWTjIueIFJlcG9ydExhYiBHZW5lcmF0ZWQgUERGIGRvY3VtZW50IGh0d
...
IC9Sb290IDEwIDAgUg0KIC9TaXplIDE2ID4+DQpzdGFydHhyZWYNCjE3OTIzDQolJUVPR
JVBERi0xLjMNCiWTjIueIFJlcG9ydExhYiBHZW5lcmF0ZWQgUERGIGRvY3VtZW50IGh0d
...
IC9Sb290IDEwIDAgUg0KIC9TaXplIDE2ID4+DQpzdGFydHhyZWYNCjE3OTIzDQolJUVPR
--===============BBBBBBBBBB==
--===============BBBBBBBBBB==
Figure 4: Example Transcript Content
图4：文本内容示例
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".
学校成绩单前言传达了原始学校官员对学校成绩单的一般评论。本评论采用的形式可供人类广泛阅读，无需特殊的应用工具。本评注应为一般性评注，提供关于编写和解释发起机构发布的成绩单的一般信息；成绩单序言不应提供有关单个学生的信息。成绩单前言的修辞形式有时是写给一般成绩单收件人的求职信。例如，序言可以提供关于如何验证成绩单上的数字签名的说明，或者解释发证学校的不寻常评分做法。学校成绩单前言表示为MIME正文部分，其内容类型为“文本/普通”。
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.
当学校成绩单被封装成更大的电子邮件时，成绩单前言中的任意文本可能会意外地被误解为结构性MIME边界或电子邮件标题。如果序言内容不包括以连字符（-）开头的行、尖括号（>）字符或“From”一词开头的行，则此类错误的可能性会降低。尽管在理想情况下，抄本序言应该在没有特殊帮助的情况下供人阅读，但如果序言文本中绝对无法避免这些结构，抄本发起者应在前言中应用内容传输编码，以避免中间邮件传输代理对其进行误解。
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].
转录本前言的表示不应包括MIME消息正文格式规范[RFC2045]中列举的标题字段以外的任何标题字段。
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
计算学校成绩单以适合自动处理的形式表示单个学生的学业成绩。因此，计算学校成绩单的内容以可扩展标记语言（XML）[XML11]呈现，并作为内容类型为“application/XML”的MIME主体部分传递。计算成绩单传递的数据语法必须符合中学后电子标准委员会（PESC）发布的高中成绩单XML模式1.3.0版[Fun12b]。此XML模式又取决于学术记录XML模式版本1.7.0[Fun12a]和核心主XML模式版本1.2.0[Mar06]
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.
由PESC出版。由这些XML模式定义的数据元素的详细语义在PESC XML实现指南1.3.0版[Ste12]中定义，该指南还提供了使用示例。
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.
为了保护学生隐私，本规范不要求学校成绩单传达任何特定的学生信息，而是仅为同意方之间自愿交换的任何学生信息定义了通用格式。交换的信息范围完全是本地事务，成绩单创建者可以从成绩单内容中省略任何信息（例如，学生的社会安全号码、学生父母的身份和位置、学生的种族、民族或变性身份）这在当地可能被视为敏感或无关。事实上，计算成绩单在语法上符合PESC XML模式的要求对成绩单创建者关于成绩单内容的选择施加了很少的约束（如果有的话）。图5展示了满足PESC XML模式语法要求的最小XML元素集。一份计算成绩单所传达的关于一个学生的信息并不比该数字所传达的信息多。
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
为了防止隐式监视和控制学生与成绩单接收者的交互，本规范限制成绩单创建者对PESC XML模式的某些使用。在每个计算记录中，“数据传输”元素的“目的地”子元素必须不传递任何可区分的信息，并且具有特定的表示形式
"<Destination><Organization/></Destination>"
"<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.
如图5所示。这项要求确保学生可以将已签署成绩单文件的自制副本用于他/她选择的任何目的，而无需进一步咨询发证学校官员。如果允许成绩单发起者在每份学生成绩单上标注特定目的地，那么发起者可以轻松监控和（在某种程度上）控制学生提供成绩单的大学招生官员、潜在雇主或其他第三方。成绩单收件人必须拒绝其内容以任何方式指定或限制该成绩单的受众、收件人或分发的任何成绩单。尽管对“目的地”元素有此限制，“来源”元素应包含在计算成绩单中，并传递足以识别发布相关成绩单的中学或其他机构的信息。
<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>
<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
图5:PESC XML元素的最小集合
Additional restrictions on the use of the PESC XML schema foster common, unambiguous interpretation and simplified processing of computational transcripts:
对使用PESC XML模式的附加限制有助于对计算成绩单进行通用、明确的解释和简化处理：
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.
1. 为了满足PESC XML模式的最低语法要求，每个计算转录本必须至少包含图5中显示的XML元素。即使转录本发起人试图在计算转录本中不传递任何信息，计算转录本也必须包含在相关转录本内容中，其有效载荷必须具有图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.
2. 与PESC XML模式一致，归属于“DocumentID”XML元素的任何值的长度必须至少为一个非空白字符。
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].
3. 与PESC XML模式一致，归属于“CreatedDateTime”XML元素的任何值必须具有XML“dateTime”值的形式，如XML模式数据类型规范[XSD]第3.2.7节所定义。
4. Lest the origin and correct handling for a computational transcript be misunderstood, the value ascribed to the "DocumentTypeCode" XML element MUST be "StudentRequest".
4. 为避免误解计算成绩单的来源和正确处理，指定给“DocumentTypeCode”XML元素的值必须是“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".
5. 为避免误解计算成绩单的来源和正确处理，指定给“TransmissionType”XML元素的值必须是“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.
6. 除了那些出现在图5中的XML元素外，计算成绩单中未提供的信息必须通过完全省略相关的XML数据元素来表示；省略的信息不能通过包含文本值为零或仅包含空格的XML元素来表示。
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.
计算成绩单的表示不应包括MIME消息体格式规范[RFC2045]中列举的头字段以外的任何头字段。尽管计算学校成绩单可以接受任何有效的内容传输编码，但首选“引用的可打印”编码。
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.
展示学校成绩单以适合人类阅读和审查的形式描述单个学生的学业成就。显示学校成绩单表示为MIME正文部分，其内容类型为“application/pdf”，其内容符合可移植文档格式（pdf）规范[PDF17]。显示学校成绩单可以包括一个或多个物理页面。
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.
为了减少签名学校成绩单接收者可能误解其内容的可能性，每个签名学校成绩单的计算组件（如上文第4.2节所述）和显示组件（此处定义）应尽可能传达：，有关相关学生学业成绩的相同信息。
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
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.
本规范要求的发起人。因此，特定于PDF的签名功能的实现是可选的，而且在很大程度上是没有根据的；尽管成绩单接收人必须接受包含PDF签名的成绩单，但接收人不应验证或依赖嵌入的签名。
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.
成绩单发起人不得使用PDF规范中描述的加密功能来加密显示学校成绩单。下文第6节中规定的OpenPGP加密机制在传输过程中充分保护了学生信息的机密性。因此，单独加密显示记录是多余的。双重加密增加了实现的复杂性，同时还需要额外的密钥分发，从而增加了安全风险。成绩单收件人不得接受或处理PDF显示组件独立加密的学校成绩单。
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.
先前的工作[RFC3778]确定了将PDF用作MIME媒体类型时产生的安全注意事项。在这些考虑因素中，PDF文档可能包括可执行的“脚本”或对外部可执行插件模块的引用。在PDF成绩单文档中包含任意可执行程序（或其引用）会给成绩单收件人带来安全风险。数字签名PDF文档（甚至包含它们的抄本）无助于抄本接收者评估执行任何嵌入式程序或插件的安全性。使用PDF的主要目的是以吸引人的格式呈现静态成绩单信息，供人查阅。由于这一有限的用途在PDF文件中没有嵌入可执行元素的情况下得到了很好的实现，因此包含这些元素所带来的任何风险都是毫无根据的。因此，成绩单发起人不得在PDF显示成绩单中包含任何可执行脚本或外部插件引用。为了防止在本地系统上执行不受信任的程序，成绩单收件人应仅使用受信任的工具来处理和查看显示成绩单。
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].
显示学校成绩单的表示不应包括MIME消息正文格式规范[RFC2045]中列举的标题字段以外的任何标题字段。
A signed school transcript is a MIME body part whose form corresponds to that of a signed OpenPGP/MIME message, as described in section 5 of the OpenPGP/MIME specification [RFC3156]. Accordingly, the MIME content type of a signed school transcript is "multipart/signed", and its form reflects the traditional use of multipart MIME structures to secure email communication [RFC1847]. Thus, the body of a signed school transcript comprises exactly two parts, as illustrated in
如OpenPGP/MIME规范[RFC3156]第5节所述，签名学校成绩单是MIME正文部分，其形式与签名OpenPGP/MIME消息的形式相对应。因此，签名学校成绩单的MIME内容类型为“多部分/签名”，其形式反映了传统上使用多部分MIME结构来保护电子邮件通信[RFC1847]。因此，签名学校成绩单的正文正好由两部分组成，如中所示
Figure 6. The first part of the signed transcript body conveys the transcript content, in MIME canonical format, including an appropriate set of MIME content headers. The form and interpretation of the transcript content is described in Section 4 above. The second part of the signed transcript body is the school transcript signature. The signature part represents the OpenPGP digital signature of the transcript originator as it has been applied to the transcript content conveyed by the first part of the signed transcript. The transcript signature is assigned the content type "application/pgp-signature". Transcript recipients MUST reject transcripts that are not validly signed pursuant to the specification for OpenPGP signatures [RFC3156].
图6。签名成绩单正文的第一部分以MIME规范格式传递成绩单内容，包括一组适当的MIME内容头。转录本内容的形式和解释见上文第4节。签名成绩单正文的第二部分是学校成绩单签名。签名部分代表转录本发起人的OpenPGP数字签名，因为它已应用于签名转录本第一部分传递的转录本内容。成绩单签名被指定为内容类型“应用程序/pgp签名”。成绩单接收人必须拒绝未根据OpenPGP签名规范[RFC3156]有效签名的成绩单。
+--------------------------------------------------+
| SIGNED TRANSCRIPT |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT CONTENT | |
| | Content-Type: multipart/mixed | |
| | | |
| | Body represents transcript content | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body represents OpenPGP signature over | |
| | transcript content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
+--------------------------------------------------+
| SIGNED TRANSCRIPT |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT CONTENT | |
| | Content-Type: multipart/mixed | |
| | | |
| | Body represents transcript content | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSCRIPT SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body represents OpenPGP signature over | |
| | transcript content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 6: MIME Structure of Signed Transcript
图6：签名成绩单的MIME结构
With the sole exception of the "Content-Type" header, the MIME content headers for each signed school transcript MUST correspond exactly to those for the embedded transcript content, as described above in Section 4. For a signed school transcript, the value of the "Content-Type" header MUST be "multipart/signed", its parameters MUST conform to those described in Section 5 of the MIME/OpenPGP specification [RFC3156], and the value of the "boundary" parameter shall, of course, differ from all other boundary parameter values within the same message. Figure 7 presents example headers for a signed school transcript. Although the allowed headers may appear in any order, transcript recipients MUST reject signed transcripts for which the set of included headers differs from the set of headers associated with the embedded transcript content.
除“内容类型”标题外，每个签名学校成绩单的MIME内容标题必须与嵌入成绩单内容的MIME内容标题完全对应，如上文第4节所述。对于签名学校成绩单，“内容类型”标题的值必须为“多部分/签名”，其参数必须符合MIME/OpenPGP规范[RFC3156]第5节中所述的参数，并且“边界”参数的值当然应不同于同一消息中的所有其他边界参数值。图7显示了签名学校成绩单的示例标题。尽管允许的标题可能以任何顺序出现，但如果包含的标题集与嵌入的成绩单内容相关联的标题集不同，则成绩单收件人必须拒绝签名成绩单。
Content-Type: multipart/signed;
protocol="application/pgp-signature";
micalg="pgp-sha256";
boundary="===============AAAAAAAAAA=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
Content-Type: multipart/signed;
protocol="application/pgp-signature";
micalg="pgp-sha256";
boundary="===============AAAAAAAAAA=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
Subject: Official School Transcript for Hermione Granger
From: Transcript Authority at Hogwarts School
<transcript-authority@hogwarts.edu.example>
Organization: Hogwarts School for Witchcraft and Wizardry
Eesst-Version: 1.0
Date: Fri, 22 Mar 2013 09:55:06 -0600
--===============AAAAAAAAAA==
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
... Transcript Content as illustrated in Figure 4 ...
--===============AAAAAAAAAA==
Content-Type: multipart/mixed; boundary="===============BBBBBBBBBB=="
MIME-Version: 1.0
Content-Description: Official School Transcript for Hermione Granger
... Transcript Content as illustrated in Figure 4 ...
--===============BBBBBBBBBB==--
--===============BBBBBBBBBB==--
--===============AAAAAAAAAA==
Content-Type: application/pgp-signature; name="signature.asc"
MIME-Version: 1.0
Content-Description: OpenPGP signature
Content-Disposition: attachment; filename="signature.asc"
--===============AAAAAAAAAA==
Content-Type: application/pgp-signature; name="signature.asc"
MIME-Version: 1.0
Content-Description: OpenPGP signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX
...
8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA=
=8QLW
-----END PGP SIGNATURE-----
iQEcBAABAgAGBQJRmkkLAAoJEBzD54azv/d4j4gH/1Aj8poEHLsEhxdv26H76URX
...
8/SQRZGUGUC0xSej5uQMVI59Yriy3dedlzib7EadK6fnz70SsEzUcQy5lHFkNNA=
=8QLW
-----END PGP SIGNATURE-----
--===============AAAAAAAAAA==--
--===============AAAAAAAAAA==--
Figure 7: Example Signed School Transcript
图7：签名学校成绩单示例
The "Eesst-Version" header serves a crucial if non-obvious purpose for protocol implementors. The presence of this header unambiguously distinguishes a signed school transcript from elements of an enveloping email message by which that transcript may be conveyed.
“Eesst版本”标题对于协议实现者来说是一个至关重要的（如果不是显而易见的）目的。此标题的存在明确区分了签名学校成绩单和可传递成绩单的信封电子邮件的元素。
For good reason, the format defined here for signed school transcripts intentionally shares many characteristics with the standard format for OpenPGP/MIME messages [RFC3156]. This similarity
出于充分的理由，这里为签名学校成绩单定义的格式有意地与OpenPGP/MIME消息的标准格式[RFC3156]共享许多特征。这种相似性
not only admits some code reuse within recipient implementations, but, most importantly, also allows transcript recipients to inspect, verify, and extract received school transcripts using existing, widely deployed email clients.
不仅允许在收件人实现中重用一些代码，而且最重要的是，还允许成绩单收件人使用现有的、广泛部署的电子邮件客户端检查、验证和提取收到的学校成绩单。
However, the formal similarity between signed school transcripts and generic signed messages can complicate recipient implementations of the transcript exchange protocol, because every signed body part must be fully evaluated to determine its status. When a signed school transcript is conveyed to its recipient enclosed within a signed OpenPGP email message, both transcript and conveying message share the common MIME type "multipart/signed". Moreover, both signed transcript and its conveying message share a common, high-level structure comprising exactly two MIME body parts, independently representing the signed content and the applied digital signature. When a "multipart/signed" MIME body part is encountered as part of a received email message, should that body part be construed as a proper signed school transcript, a signed email message by which a school transcript is conveyed, ill-formed school transcript, or something else altogether? Without additional information, unambiguously answering these questions requires that every signed body part be fully verified, parsed, validated, and checked, because, absent additional information, a receiving implementation cannot know what tests need to be applied.
然而，签名学校成绩单和一般签名邮件之间的形式相似性可能会使成绩单交换协议的收件人实现复杂化，因为必须对每个签名身体部位进行全面评估，以确定其状态。当签名的学校成绩单传送给其收件人时，包含在签名的OpenPGP电子邮件消息中，成绩单和传送消息共享公共MIME类型“multipart/signed”。此外，签名的抄本及其传递的消息共享一个共同的高级结构，该结构正好由两个MIME正文部分组成，分别表示签名内容和应用的数字签名。当在收到的电子邮件中遇到“多部分/签名”MIME正文部分时，该正文部分是否应解释为正确的签名学校成绩单、传递学校成绩单的签名电子邮件、格式不正确的学校成绩单或其他内容？如果没有额外的信息，明确地回答这些问题需要对每个签名的主体部分进行充分的验证、解析、验证和检查，因为在没有额外信息的情况下，接收实现无法知道需要应用哪些测试。
Thus, the "Eesst-Version" header serves at least two important functions. Most obviously, this header identifies what version of the EESST format has been applied in preparation of the relevant transcript. Although, currently, the only acceptable version of the EESST format is 1.0, to deny even the possibility of future protocol evolution is to deny the lessons of history. Less obviously, the "Eesst-Version" header allows simple, unambiguous detection of signed school transcripts while still allowing transcript recipients to validate and review school transcripts using familiar, widely available email clients. For these reasons, the "Eesst-Version" header MUST be included in signed school transcripts and their content component, but, in order to most fully realize its value as syntactic disambiguator, the "Eesst-Version" header MUST NOT appear anywhere else.
因此，“Eesst版本”标题至少有两个重要功能。最明显的是，该标题确定了在准备相关成绩单时采用的EESST格式的版本。尽管目前唯一可接受的EESST格式版本是1.0，但否认未来协议演变的可能性就是否认历史教训。不太明显的是，“Eesst版本”标题允许简单、明确地检测签名的学校成绩单，同时仍然允许成绩单收件人使用熟悉的、广泛可用的电子邮件客户端验证和审查学校成绩单。出于这些原因，“Eesst版本”标题必须包含在签名学校成绩单及其内容组件中，但为了最充分地实现其作为句法消歧器的价值，“Eesst版本”标题不得出现在其他任何地方。
Provided that the transcript originator is prohibited from disclosing personal information without student consent, use of the EESST protocol empowers each student to limit sharing of his or her own school transcript to recipients chosen by that student. The design of the protocol not only protects the confidentiality of transcript content in transit but also increases the cost of surveillance by the
如果未经学生同意，禁止成绩单创建者披露个人信息，则使用EESST协议授权每个学生限制将其自己的学校成绩单分享给该学生选择的接收者。该协议的设计不仅保护了传输过程中转录本内容的机密性，而且增加了网络监控的成本
school or other interested parties of the student's interactions with colleges, prospective employers, or other third parties.
学校或学生与大学、潜在雇主或其他第三方互动的其他相关方。
A student may convey his signed school transcript to his chosen recipient using any medium or technology that is agreeable to them both. For example, a student may copy his signed digital transcript onto a CD-ROM storage disk and send that physical medium to his intended recipient via a postal mail service. However, because email will frequently be the most convenient means for students to distribute their transcripts, this specification defines a common email format by which each student may privately convey his/her signed school transcript to each recipient. A common form for transcript transmission simplifies implementations of the transcript exchange protocol and fosters their interoperability. A common format allows high-volume transcript recipients to automate decryption and validation of received transcripts as well as their preparation for subsequent review and analysis. A common format that derives from existing email standards allows low-volume transcript recipients to use popular email client software to receive, decrypt, validate, and review transcripts.
学生可以使用双方都同意的任何媒介或技术将其签名的学校成绩单传达给其选定的接收者。例如，学生可以将其签名的数字成绩单复制到CD-ROM存储磁盘上，并通过邮政服务将该物理介质发送给其预期收件人。然而，由于电子邮件通常是学生分发成绩单的最方便方式，因此本规范定义了一种通用的电子邮件格式，每个学生可以通过该格式私下将其签名的学校成绩单传递给每个收件人。转录本传输的一种常见形式简化了转录本交换协议的实现，并促进了它们的互操作性。一种通用格式允许大量成绩单接收者自动解密和验证收到的成绩单，并为后续审查和分析做好准备。一种源自现有电子邮件标准的通用格式允许低容量成绩单收件人使用流行的电子邮件客户端软件来接收、解密、验证和审阅成绩单。
When a student conveys his transcript to a recipient via email, that student's confidential transcript information is vulnerable to interception and disclosure. In order to mitigate this threat, this specification generally requires that the conveying email message be encrypted as described in the OpenPGP standard [RFC3156]. Every transcript recipient MUST be prepared to accept all transcript transmissions that are encrypted as described in any of the sections below. A student SHOULD use either the encrypted transmission format (Section 6.1) or the encrypted and signed transmission format (Section 6.2), if he or she independently trusts that the transmitting computer will correctly transmit his or her transcript according to the OpenPGP/MIME specification without disclosing its plaintext content. Otherwise, students MAY use the encrypted file transmission format (Section 6.3) or traditional inline transmission format (Section 6.4) below. These latter formats simplify using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
当学生通过电子邮件将其成绩单传递给收件人时，该学生的机密成绩单信息容易被截获和泄露。为了减轻这种威胁，本规范通常要求传送的电子邮件按照OpenPGP标准[RFC3156]中的描述进行加密。每个成绩单接收人必须准备好接受所有按照以下任何章节所述进行加密的成绩单传输。学生应使用加密传输格式（第6.1节）或加密和签名传输格式（第6.2节），前提是他或她独立相信传输计算机将根据OpenPGP/MIME规范正确传输其成绩单，而不披露其明文内容。否则，学生可以使用下面的加密文件传输格式（第6.3节）或传统内联传输格式（第6.4节）。后一种格式简化了使用更可信的计算机对学生的成绩单进行加密，然后将加密后的成绩单传输到不太可信的计算机，以便传输给选定的收件人。
Because transcript transmissions must be encrypted in order to assure student privacy, every potential transcript recipient MUST generate an OpenPGP key pair and publish its public component for use by students in the preparation of those transmissions. The public key for each transcript recipient should be published (together with its OpenPGP fingerprint) on the web page for that recipient or in the global OpenPGP key database. To protect the privacy of personal information transmitted to each chosen recipient, a student need only
由于成绩单传输必须加密以确保学生隐私，因此每个潜在成绩单接收者必须生成OpenPGP密钥对，并发布其公共组件，供学生在准备这些传输时使用。每个成绩单接收者的公钥（连同其OpenPGP指纹）应发布在该接收者的网页或全局OpenPGP密钥数据库中。为了保护发送给每个选定收件人的个人信息的隐私，学生只需
retrieve the published key for that recipient and use it to encrypt the transcript transmission.
检索该收件人的已发布密钥，并使用它加密转录本传输。
With some effort, however, an attacker could, by masquerading as a legitimate transcript recipient, perhaps trick a student into transmitting private information to the attacker, encrypted in a key that is known to the attacker. In order to protect student privacy in the face of such attacks, a transcript recipient should resist successful forgery of his/her OpenPGP identity by asking other trustworthy individuals (e.g., respected colleagues or institutional officers) to certify that identity. An OpenPGP identity is certified by affixing another's digital signature to the associated OpenPGP key (see Section 12 of the OpenPGP message format specification [RFC4880] and Section 3 in the GNU Privacy Handbook [GPH]). Those who sign a recipient's public key are implicitly vouching for the association between that key and the true identity of the recipient. Consistent with the view that the student bears primary responsibility for the privacy of his/her transcript information, the student is ultimately responsible for evaluating the authenticity of public keys that he/ she uses to encrypt that information while in transit. Adding certifying signatures to a recipient's key reduces the chance that a student could be deceived by an imposter.
然而，经过一些努力，攻击者可能会伪装成合法的成绩单接收者，诱骗学生向攻击者传输私人信息，并使用攻击者已知的密钥进行加密。为了在此类攻击面前保护学生隐私，成绩单接收人应通过要求其他值得信赖的个人（如受尊敬的同事或机构官员）证明其身份，防止成功伪造其OpenPGP身份。通过将他人的数字签名附加到相关的OpenPGP密钥（参见OpenPGP消息格式规范[RFC4880]第12节和GNU隐私手册[GPH]第3节）来认证OpenPGP身份。那些签署接收者公钥的人会隐式地证明该密钥与接收者的真实身份之间存在关联。与学生对其成绩单信息的隐私负有主要责任的观点一致，学生最终负责评估其在传输过程中用于加密该信息的公钥的真实性。在收件人的钥匙上添加认证签名可以减少学生被冒名顶替者欺骗的机会。
In order to maximize student privacy and autonomy, the operation of this protocol sharply separates the function of transcript creation from the function of transcript transmission. The former function is assigned exclusively to the issuing secondary school (the transcript originator), while the latter function is assigned exclusively to the individual student. Participants in the protocol must behave so as to preserve the privacy afforded by this separation. A transcript originator MUST NOT transmit, share, or distribute a school transcript or any component thereof to any party other than the individual student to whom it pertains. A transcript recipient MUST reject any transcript that seems to have been transmitted by or on behalf of anyone but the student. Although non-student transcript transmission can be difficult to detect reliably, certain transmission characteristics unambiguously suggest abuse of student prerogatives. Accordingly, all recipient implementations MUST detect and reject transcript transmissions with any of the following characteristics:
为了最大限度地提高学生的隐私和自主性，该协议的操作将成绩单创建功能与成绩单传输功能分离开来。前者只分配给发放成绩的中学（成绩单的发起者），而后者只分配给个别学生。协议的参与者必须采取行动，以保护这种分离所提供的隐私。成绩单创始者不得将学校成绩单或其任何组成部分传输、共享或分发给与之相关的学生个人以外的任何一方。成绩单接收人必须拒绝任何似乎由学生以外的任何人或其代表传送的成绩单。尽管非学生成绩单的传播很难被可靠地检测到，但某些传播特征明确表明学生特权被滥用。因此，所有接收者实现必须检测并拒绝具有以下任何特征的转录本传输：
o A transcript recipient MUST reject any transcript that is delivered in the same email message or on the same physical storage medium as any other.
o 成绩单收件人必须拒绝在同一电子邮件中或在同一物理存储介质上发送的任何成绩单。
o A transcript recipient MUST reject any transcript for which the transcript originator and the sender of the transcript transmission are identical.
o 抄本接收人必须拒绝抄本发送人和抄本发送人相同的任何抄本。
o A transcript recipient MUST reject any transcript for which the transcript originator (who signs that transcript) and the signer of the transcript transmission are identical.
o 成绩单接收人必须拒绝任何成绩单发起人（签署成绩单的人）和成绩单传输签名人相同的成绩单。
o A transcript recipient MUST reject any transcript for which the received transcript transmission is addressed to multiple recipients.
o 成绩单收件人必须拒绝将收到的成绩单发送给多个收件人的任何成绩单。
In the encrypted transmission format, the signed school transcript is conveyed to a single recipient as a MIME attachment to an OpenPGP encrypted email message. Consistent with Section 4 of the OpenPGP/ MIME specification [RFC3156], the transmission email message must have MIME content type "multipart/encrypted", and, as illustrated in Figure 8, the body of the message must comprise exactly two parts. The first body part must have MIME content type "application/ pgp-encrypted", and its content must include only the literal value "Version: 1" on a line by itself. The second body part must have MIME content type "application/octet-stream". Its content is the result of applying the OpenPGP encryption algorithm to the MIME canonical representation of the relevant signed school transcript.
在加密传输格式中，签名的学校成绩单以MIME附件的形式传递给单个收件人，并附在OpenPGP加密的电子邮件消息中。与OpenPGP/MIME规范[RFC3156]的第4节一致，传输电子邮件必须具有MIME内容类型“multipart/encrypted”，并且如图8所示，消息体必须正好包含两个部分。第一个主体部分必须具有MIME内容类型“application/pgp encrypted”，并且其内容本身必须在一行上仅包含文本值“Version:1”。第二个主体部分必须具有MIME内容类型“application/octet stream”。其内容是将OpenPGP加密算法应用于相关签名学校成绩单的MIME规范表示的结果。
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed school transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed school transcript | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 8: MIME Structure of Encrypted Transcript Transmission
图8：加密成绩单传输的MIME结构
In the encrypted and signed transmission format, the signed school transcript is conveyed to a single recipient as an attachment to an OpenPGP encrypted and signed email message. Consistent with Section 6.1 of the OpenPGP/MIME specification [RFC3156], preparation of a message in this format is a two-stage process. During this process, the transcript transmission is, first, digitally signed by the transmitting student and, second, encrypted to protect student information from disclosure to anyone but the lone recipient.
在加密和签名传输格式中，签名学校成绩单作为OpenPGP加密和签名电子邮件的附件传送给单个收件人。与OpenPGP/MIME规范[RFC3156]第6.1节一致，此格式消息的准备过程分为两个阶段。在此过程中，成绩单传输首先由传输学生进行数字签名，其次进行加密，以保护学生信息不被泄露给任何人，但唯一的接收者除外。
+--------------------------------------------------+
| SIGNED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | SIGNED TRANSMISSION CONTENT | |
| | Content-Type: multipart/signed | |
| | | |
| | Body is signed school transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSMISSION SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body is OpenPGP signature over signed | |
| | transmission content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
+--------------------------------------------------+
| SIGNED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/signed |
| |
| +-------------------------------------------+ |
| | SIGNED TRANSMISSION CONTENT | |
| | Content-Type: multipart/signed | |
| | | |
| | Body is signed school transcript | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | TRANSMISSION SIGNATURE | |
| | Content-Type: application/pgp-signature | |
| | | |
| | Body is OpenPGP signature over signed | |
| | transmission content | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 9: MIME Structure of Signed Transcript Transmission
图9：签名转录本传输的MIME结构
The first stage of preparing an encrypted and signed transcript transmission is applying the student's signature to the transmission content. As illustrated in Figure 9, the resulting MIME body part has content type "multipart/signed" and comprises exactly two parts. The first part is the signed transmission content and corresponds to the signed school transcript in its entirety, whose structure is illustrated in Figure 6. The second part is the transmission signature. Its MIME content type is "application/pgp-signature", and its content is the result of applying the OpenPGP signature algorithm, using the student's private key, to the transmission content, the canonical representation of the signed school transcript, which is already signed by the transcript originator.
准备加密和签名的成绩单传输的第一阶段是将学生的签名应用于传输内容。如图9所示，生成的MIME主体部分的内容类型为“multipart/signed”，并且只包含两个部分。第一部分是签名传输内容，与签名学校成绩单整体相对应，其结构如图6所示。第二部分是传输签名。其MIME内容类型为“应用程序/pgp签名”，其内容是使用学生私钥将OpenPGP签名算法应用于传输内容的结果，传输内容是已签名学校成绩单的规范表示形式，已由成绩单创建者签名。
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed transcript transmission | |
| +-------------------------------------------+ |
+--------------------------------------------------+
+--------------------------------------------------+
| ENCRYPTED TRANSCRIPT TRANSMISSION |
| Content-Type: multipart/encrypted |
| |
| +-------------------------------------------+ |
| | GRATUITOUS TEXTUAL PREAMBLE | |
| | Content-Type: application/pgp-encrypted | |
| | | |
| | Body is literal "Version: 1" | |
| +-------------------------------------------+ |
| |
| +-------------------------------------------+ |
| | ENCRYPTED SIGNED TRANSCRIPT | |
| | Content-Type: application/octet-stream | |
| | | |
| | Body represents OpenPGP encryption of | |
| | signed transcript transmission | |
| +-------------------------------------------+ |
+--------------------------------------------------+
Figure 10: MIME Structure of Encrypted Transcript Transmission
图10：加密成绩单传输的MIME结构
The second stage of preparing an encrypted and signed transcript transmission is wrapping the result of the first stage into an OpenPGP encrypted message, protecting student information from disclosure to anyone but the lone recipient. As illustrated in Figure 10, the encrypted transcript transmission has the form proscribed in Section 6.1 of the OpenPGP/MIME specification. The MIME content type is "multipart/encrypted" and the result comprises exactly two body parts. The first body part must have MIME content type "application/pgp-encrypted", and its content must include only the literal value "Version: 1" on a line by itself. The second body part must have MIME content type "application/octet-stream". Its content is the result of applying the OpenPGP encryption algorithm to the MIME canonical representation of the relevant signed transcript transmission, which was produced during the first stage of the two-stage process.
准备加密和签名的成绩单传输的第二个阶段是将第一个阶段的结果包装到OpenPGP加密消息中，以保护学生信息不被泄露给任何人，但唯一的接收者除外。如图10所示，加密的转录本传输具有OpenPGP/MIME规范第6.1节中禁止的形式。MIME内容类型为“multipart/encrypted”，结果正好包含两个主体部分。第一个主体部分必须具有MIME内容类型“application/pgp encrypted”，并且其内容本身必须在一行上仅包含文本值“Version:1”。第二个主体部分必须具有MIME内容类型“application/octet stream”。其内容是将OpenPGP加密算法应用于相关签名转录本传输的MIME规范表示的结果，该传输是在两阶段过程的第一阶段生成的。
Privacy protections afforded by the EESST protocol depend upon the assumption that the computer used by the student to transmit his or her school transcript reliably executes the required EESST protocol operations without disclosing confidential information. In particular, the transmitting computer is assumed to prevent any access to the plaintext form of a school transcript by anyone but the student. The hardware and software of the transmitting computer is assumed to be free of any flaws that could weaken the encryption applied to his or her transcript. The transmitting computer is also assumed to send the transcript reliably and directly to each chosen recipient without reporting to any third party either the fact of this transmission or the identity of the recipient. Validating these assumptions can be especially problematic when the student does not unilaterally own and control the transmitting computer.
EESST协议提供的隐私保护取决于学生用于传输其学校成绩单的计算机可靠地执行所需的EESST协议操作而不披露机密信息的假设。特别是，传输计算机被假定为阻止除学生以外的任何人访问学校成绩单的明文形式。传输计算机的硬件和软件被认为没有任何可能削弱对其成绩单进行加密的缺陷。传输计算机也被认为可以将抄本可靠地直接发送给每个选定的接收者，而无需向任何第三方报告传输的事实或接收者的身份。当学生没有单方面拥有并控制传输计算机时，验证这些假设可能特别困难。
Sometimes the computer from which a student must transmit his or her transcript cannot reasonably be trusted. Indeed, some email client implementations manifestly do not permit students to compose a secure email message without sharing private information with either their email provider, system administrator, or other third party. Web-based email clients are perhaps the most obvious and widespread example of intrinsically insecure email platforms: neither cryptographic keys nor plaintext message content can be safely stored or processed on such systems. Another example of intrinsically insecure platforms are computers and email servers provided for student use by schools, to which, as a practical matter, school administrators and technical staff enjoy unrestricted access.
有时，学生必须从计算机上传送成绩单的计算机是不可信的。事实上，一些电子邮件客户端实现显然不允许学生在不与其电子邮件提供商、系统管理员或其他第三方共享私人信息的情况下撰写安全的电子邮件。基于Web的电子邮件客户端可能是本质上不安全的电子邮件平台中最明显和最普遍的例子：加密密钥和明文消息内容都不能在此类系统上安全存储或处理。本质上不安全的平台的另一个例子是学校提供给学生使用的计算机和电子邮件服务器，实际上，学校管理员和技术人员可以不受限制地访问这些平台。
A student may use the encrypted file transmission format when the computer that he or she must use to transmit his or her transcript cannot be trusted to perform the necessary encryption correctly or without disclosing the plaintext transcript. This format simplifies using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
当学生必须用来传输其成绩单的计算机不能被信任正确执行必要的加密或不披露明文成绩单时，学生可以使用加密文件传输格式。这种格式简化了使用更可信的计算机对学生的成绩单进行加密，然后将其加密的表格传输到不太可信的计算机，以便传输给选定的收件人。
For example, the student may use an implementation of the OpenPGP cryptographic algorithms on a trusted computer to encrypt the plaintext version of his or her signed school transcript, received from the transcript originator. The key used for this encryption is the public OpenPGP key of the intended transcript recipient. The binary file that results from this encryption is then transferred (e.g., via a USB flash drive or networked file transfer protocol) to a less trusted computer for email transmission to the chosen recipient. On this less trusted computer, the student invokes an email client application to compose and send a plaintext email
例如，学生可以在受信任的计算机上使用OpenPGP加密算法的实现来加密他或她的签名学校成绩单的明文版本，从成绩单创建者处接收。用于此加密的密钥是预期转录本收件人的公开OpenPGP密钥。然后，由该加密产生的二进制文件被传输（例如，通过USB闪存驱动器或网络文件传输协议）到不太可信的计算机，以便向所选收件人发送电子邮件。在这台不太受信任的计算机上，学生调用电子邮件客户端应用程序来编写和发送明文电子邮件
message (for example, see Figure 11) to the recipient that is formatted according to the MIME specification [RFC2045]. The binary file containing the encrypted version of the student transcript is included in the message as a MIME attachment whose content type is "application/octet-stream".
发送给收件人的消息（例如，请参见图11），该消息根据MIME规范[RFC2045]进行格式化。包含学生成绩单加密版本的二进制文件作为MIME附件包含在消息中，其内容类型为“应用程序/八位字节流”。
When the email message is received by the transcript recipient, the MIME attachment containing the encrypted school transcript may be detached and saved as a binary file on the local disk. A local OpenPGP implementation is invoked to decrypt the saved file using the private OpenPGP encryption key generated by the transcript recipient. The process of detaching and decrypting the attached school transcript may be automated by large-volume transcript recipients.
当成绩单收件人收到电子邮件时，包含加密学校成绩单的MIME附件可能会被分离并保存为本地磁盘上的二进制文件。调用本地OpenPGP实现，使用转录本收件人生成的私有OpenPGP加密密钥对保存的文件进行解密。大容量成绩单接收者可以自动分离和解密随附的学校成绩单。
Message-ID: <55650A7F.7090800@granger-dentistry.com.example>
Date: Tue, 26 May 2015 20:06:23 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
MIME-Version: 1.0
To: Dean Vernon Wormer <transcript-receiver@faber.edu.example>
Subject: Transmission of School Transcript
Content-Type: multipart/mixed;
boundary="------------010307000006020005010307"
Message-ID: <55650A7F.7090800@granger-dentistry.com.example>
Date: Tue, 26 May 2015 20:06:23 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
MIME-Version: 1.0
To: Dean Vernon Wormer <transcript-receiver@faber.edu.example>
Subject: Transmission of School Transcript
Content-Type: multipart/mixed;
boundary="------------010307000006020005010307"
This is a multi-part message in MIME format.
--------------010307000006020005010307
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
This is a multi-part message in MIME format.
--------------010307000006020005010307
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Dear Dean Wormer:
亲爱的迪安·沃默：
Please find attached my high school transcript, encrypted in the public encryption key published by Faber College for transcript transmission. I stored the plaintext signed transcript that I received from my high school on my own secure computer under the filename TrnGranger.eml and encrypted its contents for transmission by invoking the following command:
请查收附件中我的高中成绩单，用费伯学院公布的公开加密密钥加密，用于成绩单传输。我将从高中收到的明文签名成绩单存储在自己的安全计算机上，文件名为TrnGranger.eml，并通过调用以下命令对其内容进行加密以供传输：
gpg --encrypt --recipient transcript-receiver@faber.edu TrnGranger.eml
gpg --encrypt --recipient transcript-receiver@faber.edu TrnGranger.eml
The resulting encrypted file, TrnGranger.eml.gpg, is attached to this email message. Save that file to the disk on your local computer and decrypt the transcript by invoking the command:
生成的加密文件TrnGranger.eml.gpg附在此电子邮件中。将该文件保存到本地计算机上的磁盘上，并通过调用以下命令解密成绩单：
gpg --output TrnGranger.eml --decrypt TrnGranger.eml.gpg
gpg—输出TrnGranger.eml—解密TrnGranger.eml.gpg
Sincerely, Hermione Granger
真的，赫敏·格兰杰
--------------010307000006020005010307
Content-Type: application/octet-stream; name="TrnGranger.eml.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TrnGranger.eml.gpg"
--------------010307000006020005010307
Content-Type: application/octet-stream; name="TrnGranger.eml.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TrnGranger.eml.gpg"
hQEMA4Fu2Js7ulkaAQf/aeiLeoy9L+YddGr0HieHd3KH3wiqLnaImsBaLfboGx+EdTIRn
...
cSJlVDOZKj6nPULT5zqYsfTEHPf+5escZab4J2Rkt/w1BhNDtulNJrbv6q2lk3xBzlt+Z
kQ==
--------------010307000006020005010307--
hQEMA4Fu2Js7ulkaAQf/aeiLeoy9L+YddGr0HieHd3KH3wiqLnaImsBaLfboGx+EdTIRn
...
cSJlVDOZKj6nPULT5zqYsfTEHPf+5escZab4J2Rkt/w1BhNDtulNJrbv6q2lk3xBzlt+Z
kQ==
--------------010307000006020005010307--
Figure 11: Encrypted File Transcript Transmission
图11：加密文件副本传输
A student may use the traditional inline transmission format when the computer that he or she must use to transmit his or her transcript cannot be trusted to perform the necessary encryption correctly or without disclosing the plaintext transcript. In common with the encrypted file transmission format described above (Section 6.3), the traditional inline format simplifies using a more trusted computer to encrypt a student's transcript and later transferring its encrypted form to a less trusted computer for transmission to the chosen recipient.
当学生必须使用计算机传输其成绩单时，如果无法信任该计算机正确执行必要的加密或不披露明文成绩单，则学生可以使用传统的内联传输格式。与上述加密文件传输格式（第6.3节）一样，传统的内联格式简化了使用更可信的计算机对学生的成绩单进行加密，然后将其加密形式传输到不太可信的计算机，以便传输给选定的收件人。
The traditional inline format allows a student to use an implementation of the OpenPGP cryptographic algorithms on a trusted computer to encrypt the plaintext version of his or her signed school transcript, received from the transcript originator. The key used for this encryption is the public OpenPGP key of the intended transcript recipient. The encrypted transcript is represented as an ASCII-armored text file that is then transferred (e.g., via a USB flash drive or networked file transfer protocol) to a less trusted computer for email transmission to the chosen recipient. On this less trusted computer, the student invokes an email client application to compose and send a plaintext email message to the recipient. The content of the ASCII-armored file containing the encrypted version of the student transcript is pasted (or otherwise inserted) into the new email message as the sole content of its body.
传统的内联格式允许学生在受信任的计算机上使用OpenPGP加密算法的实现来加密他或她的签名学校成绩单的明文版本，该版本是从成绩单发起人处收到的。用于此加密的密钥是预期转录本收件人的公开OpenPGP密钥。加密的成绩单表示为ASCII铠装文本文件，然后将其传输（例如，通过USB闪存驱动器或网络文件传输协议）到不太可信的计算机，以便向选定的收件人发送电子邮件。在这台不太受信任的计算机上，学生调用电子邮件客户端应用程序编写并向收件人发送明文电子邮件。包含学生成绩单加密版本的ASCII铠装文件的内容作为其正文的唯一内容粘贴（或插入）到新电子邮件中。
A traditional inline transcript transmission has the form of a simple email message (in the Internet Message Format [RFC5322]) whose body is exclusively and entirely the encrypted form of the signed school transcript being transmitted. Representation of the included transcript MUST conform to the OpenPGP Message Format specification [RFC4880] for the ASCII-armored encoding of the OpenPGP encryption of the canonical MIME representation of the relevant signed school transcript. An example inline transcript transmission is illustrated in Figure 12.
传统的内联成绩单传输采用简单电子邮件的形式（互联网消息格式[RFC5322]），其正文完全是传输的签名学校成绩单的加密形式。所含成绩单的表示必须符合OpenPGP消息格式规范[RFC4880]，该规范用于相关签名学校成绩单的规范MIME表示的OpenPGP加密的ASCII铠装编码。图12显示了一个内联转录本传输示例。
When the email message is received by the transcript recipient, a local OpenPGP implementation is invoked to extract and decrypt the inline representation of the encrypted school transcript, using the private OpenPGP encryption key generated by the transcript recipient. The process of extracting and decrypting the transmitted school transcript may be automated by large-volume transcript recipients.
当成绩单收件人收到电子邮件时，将调用本地OpenPGP实现，以使用成绩单收件人生成的私有OpenPGP加密密钥提取和解密加密学校成绩单的内联表示。提取和解密传输的学校成绩单的过程可以由大容量成绩单接收者自动化。
While the traditional inline format is an acceptable method of secure transcript transmission, it is probably best suited to students who lack ready alternatives. Because inline representation of OpenPGP messages can sometimes be incompatible with other email features and
虽然传统的内联格式是一种可接受的安全抄本传输方法，但它可能最适合缺乏现成替代方案的学生。因为OpenPGP消息的内联表示有时可能与其他电子邮件功能和
conventions, the encrypted file format may be a better alternative for transcript transmissions when the transmitting computer cannot be trusted. A brief essay by Josefsson [Jos07] identifies multiple difficulties that can arise from use of inline OpenPGP, although none is strictly relevant to a correctly formed EESST transcript transmission. Accordingly, the traditional inline format may be used when needed but only with full consideration of its potential limitations on interoperability.
根据惯例，当传输计算机不可信时，加密文件格式可能是转录本传输的更好选择。Josefsson[Jos07]的一篇短文指出了使用内联OpenPGP可能会产生的多个困难，尽管没有一个与格式正确的EESST转录本传输严格相关。因此，在需要时可以使用传统的内联格式，但必须充分考虑其对互操作性的潜在限制。
Return-Path: <hermione@granger-dentistry.com.example>
Delivered-To: transcript-receiver@faber.edu.example
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain
Date: Wed, 3 Jul 2013 12:40:01 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
To: Transcript Receiver at Faber College
<transcript-receiver@faber.edu.example>
Subject: Encrypted Inline Transmission of School Transcript
X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz
Content-Transfer-Encoding: 8bit
Message-ID: <1372869801.14441.1.camel@hermione>
Return-Path: <hermione@granger-dentistry.com.example>
Delivered-To: transcript-receiver@faber.edu.example
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain
Date: Wed, 3 Jul 2013 12:40:01 -0400
From: Hermione Granger <hermione@granger-dentistry.com.example>
To: Transcript Receiver at Faber College
<transcript-receiver@faber.edu.example>
Subject: Encrypted Inline Transmission of School Transcript
X-Mailer: smtp-cli 3.3, see http://smtp-cli.logix.cz
Content-Transfer-Encoding: 8bit
Message-ID: <1372869801.14441.1.camel@hermione>
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h
zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW
...
hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy
jxUAN8thZooRj/jHgq23EZaNyKxD
=Dga7
-----END PGP MESSAGE-----
hQEMA4Fu2Js7ulkaAQf9Fm4+75kE6gQ1T8pjzf4GJhtBqxTTh2AaGtKZkZy9TW8h
zsbSNzZuTVf8QvJRSfk0mZywRG42dilf4Zoygpj3xJgKf7JlCEXnY5m4Luq5hvnW
...
hKgY5Kye/cu/4qwYdFOiljkMR1tv1Avh37OmmcMOZ6Hy9gbdrgQzHsPVWLDQNUYy
jxUAN8thZooRj/jHgq23EZaNyKxD
=Dga7
-----END PGP MESSAGE-----
Figure 12: Traditional Inline Signed Transcript Transmission
图12：传统的内联签名成绩单传输
The security of the EESST protocol depends upon the security of the OpenPGP protocols on which it is based. Although the cryptographic algorithms included in OpenPGP are among the strongest used in any known protocol, the integrity, authenticity, and confidentiality of conveyed student information is not assured unless EESST protocol implementors and users faithfully observe all requirements and recommendations of the relevant specifications ([RFC4880], [RFC3156], and [RFC4270]). In particular, the SHA-256 digest algorithm and RSA key lengths of at least 2048 bits MUST be used. Happily, these are supported by all major OpenPGP implementations.
EESST协议的安全性取决于它所基于的OpenPGP协议的安全性。尽管OpenPGP中包含的加密算法是任何已知协议中使用最强的算法之一，但除非EESST协议实施者和用户忠实遵守相关规范的所有要求和建议（[RFC4880]），否则无法确保传输的学生信息的完整性、真实性和机密性[RFC3156]和[RFC4270]）。特别是，必须使用SHA-256摘要算法和至少2048位的RSA密钥长度。幸运的是，所有主要的OpenPGP实现都支持这些功能。
The authority and integrity of generated school transcripts depend on the continued secrecy of the private cryptographic key by which those transcripts are signed. For greatest security, the guidance director should be physically present when and where the computer program is invoked to generate and sign the transcripts.
生成的学校成绩单的权威性和完整性取决于这些成绩单签名所用的私钥的持续保密性。为了最大程度的安全，当调用计算机程序生成并签署成绩单时，指导主任应亲自在场。
When an OpenPGP public-private key pair is generated for use by a transcript originator, a key revocation certificate should also be generated and securely stored. In the event that the generated key pair is compromised, the stored revocation certificate may be used to notify others to reject subsequent uses of that key.
当生成OpenPGP公钥-私钥对供转录本发起人使用时，还应生成并安全存储密钥撤销证书。在生成的密钥对被泄露的情况下，存储的撤销证书可用于通知其他人拒绝该密钥的后续使用。
The public cryptographic key for each transcript originator should be published (together with its OpenPGP fingerprint) on the web page for the originating institution and/or in the global OpenPGP key database. Instructions for retrieving and validating the originator's public key should be included in the preface of all issued transcripts.
应在发起机构的网页和/或全球OpenPGP密钥数据库中公布每个成绩单发起人的公钥（及其OpenPGP指纹）。检索和验证发起者公钥的说明应包含在所有已发布成绩单的前言中。
An association of school guidance professionals may wish to publish an online collection of OpenPGP public keys submitted by their members. A college admissions officer (or other high-volume transcript recipient) could then download and import this key collection into a local key database for use in verifying received transcripts.
学校指导专业人士协会可能希望发布其成员提交的OpenPGP公钥的在线集合。然后，大学招生官（或其他高容量成绩单接收者）可以下载并将此密钥集合导入本地密钥数据库，以用于验证收到的成绩单。
In order to reduce the chance that an imposter might successfully masquerade as a particular transcript originator and substitute a false key for the authentic one, the identification of each transcript originator with a particular OpenPGP key should be certified by other well-known, trustworthy officials. To this end, the public key for a transcript originator should be signed by other officials of the originating secondary school, e.g., its principal, senior faculty, or local school board members. The OpenPGP public keys of these certifying officials should be published.
为了减少冒名顶替者成功伪装成特定转录本原始人并用假密钥替换真实密钥的可能性，每个具有特定OpenPGP密钥的转录本原始人的身份应由其他知名、值得信赖的官员认证。为此，成绩单创建者的公钥应由原籍中学的其他官员签字，例如校长、高级教员或当地学校董事会成员。应公布这些认证官员的OpenPGP公钥。
The public cryptographic key for each transcript recipient should be published (together with its OpenPGP fingerprint) on the web page for the receiving institution and/or in the global OpenPGP key database.
应在接收机构的网页和/或全球OpenPGP密钥数据库中公布每个成绩单接收人的公钥（及其OpenPGP指纹）。
The cryptographic operations upon which the security properties of this protocol depend must be performed in private by the relevant stakeholder. The confidentiality of a student's personal transcript information cannot be sustained if others enjoy unauthorized access to that content during the process of encryption. The integrity of an originator's signature on each transcript cannot be assured if others can learn the originator's secret key by observing the signature process. The confidentiality of personal information sent by many students to a particular transcript recipient cannot be assured if others can learn that recipient's secret key by observing the decryption of received transcripts. Therefore, every stakeholder should perform the cryptographic operations proscribed here only when present at a physically isolated computer that is entirely controlled by that stakeholder and that locally stores all keys and confidential information. Using "thin clients" or web-based computing to perform sensitive cryptographic operations forfeits whatever protections this protocol might have otherwise afforded.
本协议的安全属性所依赖的加密操作必须由相关利益相关者私下执行。如果其他人在加密过程中未经授权访问某个学生的个人成绩单信息，则该学生的个人成绩单信息的保密性无法维持。如果其他人可以通过观察签名过程了解发起者的密钥，则无法确保发起者在每份抄本上签名的完整性。如果其他人可以通过观察收到的成绩单的解密情况了解到收件人的秘密密钥，那么许多学生发送给特定成绩单收件人的个人信息的保密性就无法得到保证。因此，每个利益相关者仅当在完全由该利益相关者控制且本地存储所有密钥和机密信息的物理隔离计算机上时，才应执行此处禁止的加密操作。使用“瘦客户机”或基于web的计算来执行敏感的加密操作将失去本协议可能提供的任何保护。
Recipient implementations should not reply automatically or routinely to received transcript transmissions. Such replies could provide valuable feedback to an attacker, especially if they can be elicited at will.
收件人实施不应自动或定期回复收到的抄本传输。这样的回复可以向攻击者提供有价值的反馈，特别是如果可以随意获取这些回复的话。
The EESST exchange format is compatible with and entails no alterations to existing email standards. Indeed, the syntactic similarity between the exchange format and standardized email message formats empowers users to apply widely deployed email tools to verify, interpret, or otherwise manipulate secondary school transcripts.
EESST交换格式与现有电子邮件标准兼容，且不需要对其进行任何更改。事实上，exchange格式和标准化电子邮件格式之间的语法相似性使用户能够应用广泛部署的电子邮件工具来验证、解释或以其他方式操纵中学成绩单。
In the hope of preventing any incompatibilities that could arise from future standards evolution or changes in common usage, this section describes the registration of two message header fields that are used in the EESST exchange format but currently lack any formal definition in existing standards. Consistent with registration procedures defined in RFC 3864 [RFC3864], the subsections below describe additions to the "Message Headers" registry maintained by the Internet Assigned Numbers Authority.
为了防止将来的标准演变或常见用法的变化可能导致的任何不兼容，本节描述了EESST交换格式中使用的两个消息头字段的注册，但现有标准中目前缺乏任何正式定义。与RFC 3864[RFC3864]中定义的注册程序一致，以下小节描述了对互联网分配号码管理局维护的“消息头”注册表的添加。
The "Eesst-Version" message header field is completely internal to the EESST transcript format, and, indeed, explicitly precluded from appearing within an enveloping email message (see Section 5). Registration has been completed in order to discourage its use in other contexts.
“Eesst版本”消息头字段完全在Eesst转录本格式内部，实际上，明确禁止出现在信封电子邮件中（见第5节）。已完成注册，以阻止在其他情况下使用。
Header field name: Eesst-Version
标题字段名称：Eesst版本
Applicable protocol: mail
适用协议：邮件
Status: provisional
现状：临时
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Specification document(s): RFC 7681
规范文件：RFC 7681
Related information: The value of this header field identifies the version of the EESST exchange format to which the represented school transcript conforms. This header may appear only within EESST school transcripts.
相关信息：此标题字段的值标识所代表的学校成绩单符合的EESST交换格式的版本。此标题只能出现在EESST学校成绩单中。
The EESST exchange format entails use of the "Organization" message header field to identify the originating institution for a student transcript. A header field of this name and semantics is already defined for use within network news articles (see [RFC5536]). Moreover, the "Organization" header field also frequently appears in electronic mail messages, although, perhaps surprisingly, it currently lacks any explicit, written definition in that context. This registration publicly documents ongoing use of this header field and may discourage incompatible uses in future.
EESST交换格式需要使用“组织”消息头字段来标识学生成绩单的原始机构。此名称和语义的标题字段已定义用于网络新闻文章（请参见[RFC5536]）。此外，“Organization”标题字段也经常出现在电子邮件中，尽管可能令人惊讶的是，它目前在该上下文中缺乏任何明确的书面定义。此注册公开记录此标题字段的当前使用情况，并可能阻止将来不兼容的使用。
Header field name: Organization
标题字段名称：组织
Applicable protocol: mail
适用协议：邮件
Status: informational
状态：信息性
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Author/Change controller: James R. Davin
info@eesst.org
http://www.eesst.org
Specification document(s): RFC 7681
规范文件：RFC 7681
Related information: The value of this header field identifies the organization or institution to which the originator of the relevant message belongs.
相关信息：此标题字段的值标识相关消息的发起人所属的组织或机构。
Note: this field is quite distinct from the mail address fields MTS.OrganizationName and MTS.OrganizationalUnitNames used in X.400 mail.
注意：此字段与X.400邮件中使用的邮件地址字段MTS.OrganizationName和MTS.organizationalUnitName截然不同。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[Fun12a] Funck, J., "XML Schema for the PESC Format for Academic Record Data Elements, Version 1.7.0", June 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/AcademicRecord_v1.7.0.xsd>.
[Fun12a]Funck，J.，“学术记录数据元素PESC格式的XML模式，版本1.7.0”，2012年6月<http://www.pesc.org/library/docs/standards/ 高%20学校%20成绩单/AcademicRecord_v1.7.0.xsd>。
[Fun12b] Funck, J., "XML Schema for the PESC Format for High School Transcripts, Version 1.3.0", June 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/ HighSchoolTranscript_v1.3.0.xsd>.
[Fun12b]Funck，J.，“高中成绩单PESC格式的XML模式，1.3.0版”，2012年6月<http://www.pesc.org/library/docs/standards/ 高%20学校%20成绩单/高中成绩单_v1.3.0.xsd>。
[GPH] Ashley, J., "The GNU Privacy Handbook", 1999, <https://www.gnupg.org/gph/en/manual.pdf>.
[GPH]Ashley，J.，《GNU隐私手册》，1999年<https://www.gnupg.org/gph/en/manual.pdf>.
[Jos07] Josefsson, J., "Inline OpenPGP Considered Harmful", April 2007, <http://josefsson.org/ inline-openpgp-considered-harmful.html>.
[Jos07]Josefsson，J.，“内联OpenPGP被认为有害”，2007年4月<http://josefsson.org/ 内联openpgp被认为有害。html>。
[Mar06] Marton, B., "XML Schema for the PESC Format for Core Main Data Elements, Version 1.2.0", February 2006, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/CoreMain_v1.2.0.xml>.
[Mar06]Marton，B.，“核心主要数据元素的PESC格式的XML模式，版本1.2.0”，2006年2月<http://www.pesc.org/library/docs/standards/ 高%20School%20Transcript/CoreMain_v1.2.0.xml>。
[PDF17] Adobe Systems, Inc., "Document Management - Portable Document Format - Part 1: PDF 1.7, First Edition", July 2008, <http://wwwimages.adobe.com/www.adobe.com/content/ dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf>.
[PDF17]Adobe Systems，Inc.“文档管理-可移植文档格式-第1部分：PDF 1.7，第一版”，2008年7月<http://wwwimages.adobe.com/www.adobe.com/content/ dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf>。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, October 1995, <http://www.rfc-editor.org/info/rfc1847>.
[RFC1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，DOI 10.17487/RFC1847，1995年10月<http://www.rfc-editor.org/info/rfc1847>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <http://www.rfc-editor.org/info/rfc1958>.
[RFC1958]Carpenter，B.，Ed.，“互联网的架构原则”，RFC 1958，DOI 10.17487/RFC19581996年6月<http://www.rfc-editor.org/info/rfc1958>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, <http://www.rfc-editor.org/info/rfc3156>.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全”，RFC 3156，DOI 10.17487/RFC3156，2001年8月<http://www.rfc-editor.org/info/rfc3156>.
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, DOI 10.17487/RFC3778, May 2004, <http://www.rfc-editor.org/info/rfc3778>.
[RFC3778]Taft，E.，Pravetz，J.，Zilles，S.，和L.Masinter，“应用程序/pdf媒体类型”，RFC 3778，DOI 10.17487/RFC3778，2004年5月<http://www.rfc-editor.org/info/rfc3778>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<http://www.rfc-editor.org/info/rfc3864>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, <http://www.rfc-editor.org/info/rfc4270>.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 4270，DOI 10.17487/RFC4270，2005年11月<http://www.rfc-editor.org/info/rfc4270>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 4880，DOI 10.17487/RFC4880，2007年11月<http://www.rfc-editor.org/info/rfc4880>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, DOI 10.17487/RFC5536, November 2009, <http://www.rfc-editor.org/info/rfc5536>.
[RFC5536]Murchison，K.，Ed.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC 5536，DOI 10.17487/RFC5536，2009年11月<http://www.rfc-editor.org/info/rfc5536>.
[Sal84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", ACM Transactions on Computer Systems 2(4), DOI 10.1145/357401.357402, November 1984, <http://dx.doi.org/10.1145/357401.357402>.
[Sal84]Saltzer，J.，Reed，D.，和D.Clark，“系统设计中的端到端参数”，计算机系统ACM交易2（4），DOI 10.1145/357401.357402，1984年11月<http://dx.doi.org/10.1145/357401.357402>.
[Ste12] Stewart, T., "Implementation Guide for the Postsecondary Electronic Standards Council XML Standard Format for the High School Transcript, Version 1.3.0", July 2012, <http://www.pesc.org/library/docs/standards/ High%20School%20Transcript/XML%20HS%20Transcript%20Impl%20 Guide%20Version%201.3.0%202012%2007%2026.pdf>.
[Ste12]Stewart，T.，“中学后电子标准委员会高中成绩单XML标准格式实施指南，1.3.0版”，2012年7月<http://www.pesc.org/library/docs/standards/ 高%20School%20Transcript/XML%20HS%20Transcript%20Impl%20指南%20Version%201.3.0%202012%2007%2026.pdf>。
[XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[XML11]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，Yergeau，F.，和J.Cowan，“可扩展标记语言（XML）1.1（第二版）”，W3C建议REC-XML11-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml11-20060816>.
[XSD] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSD]Biron，P.和A.Malhotra，“XML模式第2部分：数据类型第二版”，W3C建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Acknowledgments
致谢
Derek Atkins, Paul Hoffman, and Werner Koch provided independent reviews of this memo. Fred Baker, Dave Crocker, Keith Moore, and Chris Newman provided comments and questions about drafts of this document.
德里克·阿特金斯、保罗·霍夫曼和沃纳·科赫对这份备忘录进行了独立审查。Fred Baker、Dave Crocker、Keith Moore和Chris Newman提供了有关本文件草稿的评论和问题。
Author's Address
作者地址
James R. Davin
詹姆斯·R·大卫
Email: info@EESST.org
URI: http://EESST.org/
Email: info@EESST.org
URI: http://EESST.org/