Network Working Group R. Herriot
Request for Comments: 3391 December 2002
Category: Informational
Network Working Group R. Herriot
Request for Comments: 3391 December 2002
Category: Informational
The MIME Application/Vnd.pwg-multiplexed Content-Type
MIME应用程序/Vnd.pwg-multiplexed内容类型
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
IESG Note
IESG注释
The IESG believes use of this media type is only appropriate in situations where the producer is fully aware of the capabilities and limitations of the consumer. In particular, this mechanism is very dependent on the producer knowing when the consumer will need a particular component of a multipart object. But consumers potentially work in many different ways and different consumers may need different things at different times. This mechanism provides no means for a producer to determine the needs of a particular consumer and how they are to be accommodated.
IESG认为，只有在制作人充分了解消费者的能力和限制的情况下，才适合使用这种媒体类型。特别是，这种机制非常依赖于生产者知道消费者何时需要多部分对象的特定组件。但消费者可能以许多不同的方式工作，不同的消费者在不同的时间可能需要不同的东西。这种机制无法让生产者确定特定消费者的需求以及如何满足这些需求。
Alternative mechanisms, such as a protocol based on BEEP which is capable of bidirectional communication between the producer and consumer, should be considered when the capabilities of the consumer are not known by the producer.
当生产者不知道消费者的能力时，应考虑替代机制，例如基于BEEP的协议，该协议能够在生产者和消费者之间进行双向通信。
Abstract
摘要
The Application/Vnd.pwg-multiplexed content-type, like the Multipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. An Application/Vnd.pwg-multiplexed entity contains a sequence of chunks. Each chunk contains a MIME message or a part of a MIME message. Each MIME message represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets. With an Application/Vnd.pwg-multiplexed entity, a message and its reference in some other message can be made quite close by chunking the message containing the reference. For example, if a long message contains
Application/Vnd.pwg-multiplexed内容类型与Multipart/Related内容类型一样，提供了一种表示由多个组件组成的对象的机制。Application/Vnd.pwg-multiplexed实体包含一系列块。每个区块包含一条MIME消息或MIME消息的一部分。每个MIME消息表示复合对象的一个组件，就像多部分/相关实体的主体部分表示组件一样。对于多部分/相关实体，主体部分及其在其他主体部分中的引用可能由许多八位字节分隔。对于Application/Vnd.pwg-multiplexed实体，通过对包含引用的消息进行分块，可以使消息及其在其他消息中的引用非常接近。例如，如果长消息包含
references to images and the producer does not know of the need for each image until it generates the reference, then Application/Vnd.pwg-multiplexed allows the consumer to process the reference to the image and the image before it consumes the entire long message. This ability is important in printing and scanning applications. This document defines the Application/Vnd.pwg-multiplexed content-type. It also provides examples of its use.
对图像的引用，生产者在生成引用之前不知道对每个图像的需要，然后Application/Vnd.pwg-multiplexed允许消费者在消费整个长消息之前处理对图像和图像的引用。这种能力在打印和扫描应用中非常重要。本文档定义了Application/Vnd.pwg-multiplexed内容类型。它还提供了它的使用示例。
Table of Contents
目录
1. Introduction....................................................2
2. Terminology.....................................................7
3. Details.........................................................9
3.1 Syntax of Application/Vnd.pwg-multiplexed Contents...........10
3.2 Parameters for Application/Vnd.pwg-multiplexed...............12
3.2.1 The "type" Parameter.......................................12
3.2.2 Syntax.....................................................12
4. Handling Application/Vnd.pwg-multiplexed Entities..............12
5. Examples.......................................................13
5.1 Example With Multipart/Related...............................14
5.2 Examples with Application/Vnd.pwg-multiplexed................15
5.2.1 Example Where Each Chunk Has a Complete Message............15
5.2.2 Example of Chunking the Root Message.......................17
5.2.3 Example of Chunking the Several Messages...................18
5.2.4 Example of Chunks with Empty Payloads......................20
6. Security Considerations........................................22
7. Registration Information for Application/Vnd.pwg-multiplexed...22
8. Acknowledgments................................................23
9. References.....................................................23
10. Author's Address..............................................24
11. Full Copyright Statement......................................25
1. Introduction....................................................2
2. Terminology.....................................................7
3. Details.........................................................9
3.1 Syntax of Application/Vnd.pwg-multiplexed Contents...........10
3.2 Parameters for Application/Vnd.pwg-multiplexed...............12
3.2.1 The "type" Parameter.......................................12
3.2.2 Syntax.....................................................12
4. Handling Application/Vnd.pwg-multiplexed Entities..............12
5. Examples.......................................................13
5.1 Example With Multipart/Related...............................14
5.2 Examples with Application/Vnd.pwg-multiplexed................15
5.2.1 Example Where Each Chunk Has a Complete Message............15
5.2.2 Example of Chunking the Root Message.......................17
5.2.3 Example of Chunking the Several Messages...................18
5.2.4 Example of Chunks with Empty Payloads......................20
6. Security Considerations........................................22
7. Registration Information for Application/Vnd.pwg-multiplexed...22
8. Acknowledgments................................................23
9. References.....................................................23
10. Author's Address..............................................24
11. Full Copyright Statement......................................25
The simple MIME content-types, such as "text/plain" provide a mechanism for representing a simple object, such as a text document. The Multipart/Related [RFC2387] content-type provides a mechanism for representing a compound object, such as a text document with two gif images.
简单的MIME内容类型（如“text/plain”）提供了一种表示简单对象（如文本文档）的机制。多部分/相关[RFC2387]内容类型提供了一种表示复合对象的机制，例如具有两个gif图像的文本文档。
A compound object consists of multiple components. One such component is the root component, which contains references to other components of the compound object. These components may, in turn, contain references to other components of the compound object. For example, a compound object could consist of a root html text component and two gif image components -- each referenced by the root component.
复合对象由多个组件组成。其中一个组件是根组件，它包含对复合对象的其他组件的引用。这些组件又可能包含对复合对象的其他组件的引用。例如，一个复合对象可以由一个根html文本组件和两个gif图像组件组成——每个组件都由根组件引用。
A compound object and a component are both abstractions. For transmission over the wire or writing to storage, each needs a representation. A "Multipart/Related entity" is one possible representation of a compound object, and a "body part" is one possible representation of a component.
复合对象和组件都是抽象。对于通过导线传输或写入存储器，每个都需要一个表示。“多部分/相关实体”是复合对象的一种可能表示形式，“身体部位”是组件的一种可能表示形式。
However, the Multipart/Related content-type is not a good solution for applications that require each component to be close to its corresponding reference in the root component. This document defines a new MIME content-type Application/Vnd.pwg-multiplexed that provides a better solution for some applications. The Application/Vnd.pwg-multiplexed content-type, like the Multipart/Related content-type, provides a common mechanism for representing a compound object. A Multipart/Related entity consists of a sequence of body parts separated by boundary strings. Each body part represents a component of the compound object. An Application/Vnd.pwg-multiplexed entity consists of a sequence of chunks, each of whose length is specified in the chunk header. Each chunk contains a message or a part of a message. Each message represents a component of the compound object. Chunks from different messages can be interleaved. HTTP is the typical transport for an Application/Vnd.pwg-multiplexed entity over the wire. An Application/Vnd.pwg-multiplexed entity could be stored in a Microsoft HTML (message/rfc822) file whose suffix is .mht.
但是，对于要求每个组件接近其在根组件中的对应引用的应用程序，多部分/相关内容类型不是一个好的解决方案。本文档定义了一个新的MIME内容类型Application/Vnd.pwg-multiplexed，它为某些应用程序提供了更好的解决方案。Application/Vnd.pwg-multiplexed内容类型与Multipart/Related内容类型一样，提供了一种表示复合对象的通用机制。多部分/相关实体由一系列由边界字符串分隔的身体部位组成。每个身体部位表示复合对象的一个组件。Application/Vnd.pwg-multiplexed实体由一系列块组成，每个块的长度在块头中指定。每个区块包含一条消息或消息的一部分。每条消息表示复合对象的一个组件。来自不同消息的块可以交错。HTTP是应用程序/Vnd.pwg多路复用实体的典型传输。Application/Vnd.pwg-multiplexed实体可以存储在后缀为.mht的Microsoft HTML（message/rfc822）文件中。
The following paragraphs contain three examples of applications. For each application, there is a discussion of its solution with the Application/Vnd.pwg-multiplexed content-type, the Multipart/Related content-type and BEEP [RFC3080].
以下段落包含三个应用示例。对于每个应用程序，都会讨论其解决方案，包括application/Vnd.pwg-multiplexed content type、Multipart/Related content type和BEEP[RFC3080]。
Example 1: a printing application. A Producer creates a print stream that consists of a very long series of page descriptions, each of which references one or more images. The root component is the long series of page descriptions. An image may be referenced from multiple pages descriptions, and there is a mechanism to indicate when there are no additional references to an image (i.e., the image is out of scope). The Producer does not know what images to include with a page until it generates that page. The Consumer is presumed to have enough storage to hold all in-scope images and enough of the root component to process at least one page. The Producer doesn't need any knowledge of the Consumer's storage capabilities in order to create an entity that the Consumer can successfully process. However, the Producer needs to be prudent about the number of images that are in-scope at any time. Of course, a malicious Producer may try to exceed the storage capabilities of the Consumer, and the Consumer must guard against such entities (see section 6). Here are ways to represent this compound object.
示例1：一个打印应用程序。生产者创建一个打印流，该打印流由一系列非常长的页面描述组成，每个页面描述引用一个或多个图像。根组件是一长串的页面描述。可以从多个页面描述中引用图像，并且存在一种机制来指示何时没有对图像的附加引用（即，图像超出范围）。在生成页面之前，制作人不知道页面要包含哪些图像。假定使用者有足够的存储空间来保存所有范围内的映像，并且有足够的根组件来处理至少一个页面。生产者不需要了解消费者的存储能力，就可以创建消费者可以成功处理的实体。但是，制作人需要对任何时候范围内的图像数量保持谨慎。当然，恶意生产者可能会试图超过消费者的存储能力，消费者必须防范此类实体（见第6节）。以下是表示此复合对象的方法。
With the Application/Vnd.pwg-multiplexed content-type, each image is a message and the root component is a message. The Producer breaks the root component message into chunks with each image message occurring shortly before its first reference. When the Consumer encounters a reference, it can assume that it has already received the referenced image in an earlier chunk.
对于Application/Vnd.pwg-multiplexed内容类型，每个图像都是一条消息，根组件是一条消息。生产者将根组件消息分成块，每个图像消息在第一次引用前不久出现。当消费者遇到引用时，它可以假设它已经在先前的块中收到了引用的图像。
With the Multipart/Related content-type, each image must either precede or follow the root component.
对于多部分/相关内容类型，每个图像必须位于根组件之前或之后。
If images follow the root component, the Consumer must read all remaining pages of the root component before it can print the first page that references such images. The Consumer must wait to print such a page until it has received the entire root component, and the Consumer may not have the space to hold the remaining pages.
如果图像跟随根组件，则使用者必须读取根组件的所有剩余页面，然后才能打印引用此类图像的第一页。使用者必须等待打印这样的页面，直到它收到整个根组件，并且使用者可能没有空间容纳其余页面。
If images precede the root component, the Producer must determine and send all such images before it sends the root component. The Consumer must, in the best case, wait some additional time before it receives the first page of the root component. In the worse case, the Consumer may not have enough storage for all the images.
如果映像位于根组件之前，则生产者必须在发送根组件之前确定并发送所有此类映像。在最好的情况下，使用者必须在收到根组件的第一页之前再等待一段时间。在更糟糕的情况下，消费者可能没有足够的存储空间存储所有图像。
The Multipart/Related solution is not a good solution because of the wait time and because, in some cases, the Consumer may not have sufficient storage for all of the images.
多部分/相关解决方案不是一个好的解决方案，因为等待时间较长，并且在某些情况下，消费者可能没有足够的存储空间来存储所有图像。
With BEEP, the images and root component can be sent in separate channels. The Producer can push each image when it encounters the first reference or the Consumer can request it when it encounters the first reference. The over-the-wire stream of octets is similar to an Application/Vnd.pwg-multiplexed entity. However, there is a substantial difference in behavior for a printing application. With the Application/Vnd.pwg-multiplexed content-type, the Producer puts each image message before its first reference so that when the Consumer encounters a reference, the image is guaranteed to be present on the printer. With BEEP, if the Consumer pulls the image, the Consumer has to wait while the image comes over the network. If the Producer pushes the image, BEEP may put the image message after its first reference and the Consumer may still have to wait for the image. A high-speed printer should not have to risk waiting for images; otherwise it cannot run at full speed.
使用BEEP，图像和根组件可以在单独的通道中发送。生产者可以在遇到第一个引用时推送每个图像，消费者也可以在遇到第一个引用时请求。八位字节的有线传输流类似于Application/Vnd.pwg-multiplexed实体。但是，打印应用程序的行为有很大的不同。对于Application/Vnd.pwg-multiplexed content type，生产者将每个图像消息放在其第一个引用之前，以便当消费者遇到引用时，确保图像出现在打印机上。使用BEEP时，如果消费者提取图像，消费者必须等待图像通过网络传输。如果制作人推送图像，BEEP可能会将图像消息放在其第一次参考之后，消费者可能仍需要等待图像。高速打印机不应冒险等待图像；否则它不能全速运行。
Example 2: a scanning (fax-like) application. The Producer is a scanner, which scans pages and sends them along with a vnd.pwg-xhtml-print+xml root component that contains references to each page
示例2：扫描（类似传真）应用程序。生产者是一个扫描器，它扫描页面并将其与包含每个页面引用的vnd.pwg xhtml print+xml根组件一起发送
image. Each page is referenced exactly once in the root-component. The Consumer is a printer that consumes vnd.pwg-xhtml-print+xml entities and their attachments. That is, the Consumer is not limited to print jobs that come from scanners. A Producer and Consumer are each presumed to have enough storage to hold a few page images and most if not all of the root component. The Producer doesn't need any additional knowledge of the Consumer's storage capabilities in order to create an entity that the Consumer can successfully process. Of course, a malicious Producer may try to exceed the storage capabilities of the Consumer and the Consumer must guard against such entities (see section 6). Here are ways to represent this compound object.
形象每个页面在根组件中只引用一次。使用者是使用vnd.pwg xhtml print+xml实体及其附件的打印机。也就是说，消费者不仅限于来自扫描仪的打印作业。生产者和消费者都被假定有足够的存储空间来容纳几个页面图像和大部分（如果不是全部的话）根组件。生产者不需要了解消费者的存储能力，就可以创建消费者可以成功处理的实体。当然，恶意生产者可能试图超过消费者的存储能力，消费者必须防范此类实体（见第6节）。以下是表示此复合对象的方法。
With the Application/Vnd.pwg-multiplexed content-type, each page image is a message and the root component is a message. The Producer breaks the root component message into chunks with each image message just before or just after its reference.
对于Application/Vnd.pwg-multiplexed content类型，每个页面图像都是一条消息，根组件是一条消息。生产者将根组件消息分成块，每个图像消息在其引用之前或之后。
With the Multipart/Related content-type, the images cannot precede the root component because the Consumer might not have enough space to store them until the root component arrived. In this case, the printer could fail to print the job correctly and the Producer might not know. Therefore the images must follow the root component, and the Producer must scan all pages before it can send the first page. At the very least, this solution delays the printing of the pages until all have been scanned. In the worst case, the Producer does not have sufficient memory to buffer the images, and the job fails.
对于多部分/相关内容类型，图像不能位于根组件之前，因为在根组件到达之前，使用者可能没有足够的空间来存储它们。在这种情况下，打印机可能无法正确打印作业，生产商可能不知道。因此，图像必须跟随根组件，生产者必须扫描所有页面，然后才能发送第一页。至少，此解决方案会延迟打印页面，直到扫描完所有页面。在最坏的情况下，生产者没有足够的内存来缓冲图像，作业失败。
With BEEP, the issues are the same as in the previous example, except that speed is not as important in this case. So BEEP is a viable alternative for this example.
对于BEEP，问题与上一个示例中的问题相同，只是在这种情况下速度没有那么重要。因此，对于这个例子来说，BEEP是一个可行的选择。
Example 3: a printing application. A Producer creates a print stream that consists of a series of pages, each of which references zero or more images. Each image is referenced exactly once. The Producer does not know what images to include with a page until it generates that page, and the Producer doesn't know the layout details; the Consumer handles layout. The Producer has enough storage to send the root component and all images. However, it may not have enough storage to hold the entire root component or all octets of any of the images. The Consumer is presumed to have enough storage to render the root component and to render each image. It may not have enough storage to hold the entire root component or all octets of any of the images. The Producer doesn't determine the Consumer's storage capabilities. Rather it arranges the components so that the Consumer is mostly likely to succeed. Of course, a malicious Producer may try
示例3：一个打印应用程序。生产者创建由一系列页面组成的打印流，每个页面引用零个或多个图像。每个图像只引用一次。在生成页面之前，制作人不知道页面要包含哪些图像，而且制作人也不知道布局细节；使用者处理布局。生产者有足够的存储空间来发送根组件和所有映像。但是，它可能没有足够的存储空间来保存任何图像的整个根组件或所有八位字节。假定使用者有足够的存储空间来渲染根组件和渲染每个图像。它可能没有足够的存储空间来保存任何映像的整个根组件或所有八位字节。生产者不确定消费者的存储能力。相反，它安排组件，使消费者最有可能成功。当然，恶意制作人可能会尝试
to exceed the storage capabilities of the Consumer, and the Consumer must guard against such entities (see section 6). Here are ways to represent this compound object.
要超过使用者的存储能力，使用者必须防范此类实体（见第6节）。以下是表示此复合对象的方法。
With the Application/Vnd.pwg-multiplexed content-type, each image is a message and the root component is a message. The Producer breaks the root component message into chunks with each image message just after its reference. The references appear first so that the Consumer knows the location of each image before it processes the image. This strategy minimizes storage needs for Producer and Consumer and provides a good strategy in case of failure. Here are the cases to consider.
对于Application/Vnd.pwg-multiplexed内容类型，每个图像都是一条消息，根组件是一条消息。生产者将根组件消息分成块，每个图像消息都在引用之后。参考首先出现，以便消费者在处理图像之前知道每个图像的位置。此策略最大限度地减少了生产者和消费者的存储需求，并在出现故障时提供了一个良好的策略。下面是要考虑的情况。
a) When the document consists of vertically aligned blocks where each block contains either lines of text or a single image, the sequence of chunks is the same as the sequence of printable blocks, thus minimizing Consumer buffering needs.
a) 当文档由垂直对齐的块组成，其中每个块包含文本行或单个图像时，块的顺序与可打印块的顺序相同，从而最大限度地减少消费者的缓冲需求。
b) When a block can contain N side-by-side images, the Consumer must buffer N-1 images unless the Producer interleaves the images. If the Producer doesn't interleave the images, and the Consumer runs out of storage before it has received N-1, images, it can print what it has and print the remaining images below; not what the Producer intended, but better than nothing. If the Producer interleaves images, and the Consumer runs out of storage before it has received the bands of N images, the Consumer would print portions of images interleaved with portions of other images. So, a Producer should not interleave images.
b) 当一个块可以包含N个并排图像时，使用者必须缓冲N-1个图像，除非生产者交错图像。如果生产商没有交错图像，消费者在收到N-1个图像之前就用完了存储空间，那么它可以打印它拥有的图像，并打印下面剩余的图像；不是制作人想要的，但总比没有好。如果生产者交错图像，并且消费者在接收到N个图像的频带之前耗尽存储，消费者将打印与其他图像部分交错的图像部分。因此，制作人不应交错图像。
c) When a block contains text and image side-by-side (i.e., run-around text), there are additional buffering requirements. When the Consumer processes the text that follows the reference, it will place some of it next to the image (run-around text) and will place the remaining text after the image. The Producer doesn't know where the run-around ends, and thus doesn't know where to end the text chunk and start the image chunk. If the Producer ends the text too soon, then the Consumer either has to process the entire image (if it has enough storage) in order to get the remaining run-around text, or it ends the run-around text prematurely. If the Producer ends the text too late, then the Consumer may have to store too much text and possibly put the image later than the Producer requested. Because text data requires significantly less storage than image data, a good strategy for Producer is to err on the side of sending too much rather than too little text before the image data.
c) 当块包含并排的文本和图像（即，环绕文本）时，会有额外的缓冲要求。当使用者处理引用后面的文本时，它会将部分文本放在图像旁边（环绕文本），并将剩余文本放在图像后面。制作人不知道循环在哪里结束，因此也不知道在哪里结束文本块和开始图像块。如果生产者过早结束文本，消费者要么必须处理整个图像（如果它有足够的存储空间）以获取剩余的循环文本，要么过早结束循环文本。如果制作人结束文本的时间太晚，那么消费者可能不得不存储太多的文本，并且可能会比制作人要求的时间晚放置图像。因为文本数据比图像数据需要更少的存储空间，所以生产者的一个好策略是在图像数据之前发送过多而不是过少的文本。
d) When a block contains text and multiple side-by-side images, the problem becomes a combination of items b) and c) above.
d) 当一个块包含文本和多个并排图像时，问题会变成上面b）和c）项的组合。
The Application/Vnd.pwg-multiplexed content-type can be made to work in this example, but a Consumer must have failure strategies and the result may not be quite what the producer intended. With the Multipart/Related content-type, the images cannot precede the root component because the Consumer might not have enough space to store them until the root component arrived. Also, the images cannot follow the root component because the Consumer might not have enough storage for the root component before the first image arrives. So the Multipart/Related content-type is not an acceptable solution for this example.
在本例中，可以使Application/Vnd.pwg-multiplexed content type起作用，但消费者必须具有故障策略，并且结果可能与生产者的意图不完全一致。对于多部分/相关内容类型，图像不能位于根组件之前，因为在根组件到达之前，使用者可能没有足够的空间来存储它们。此外，映像不能跟随根组件，因为在第一个映像到达之前，使用者可能没有足够的存储空间来存储根组件。因此，对于本例，多部分/相关内容类型不是可接受的解决方案。
With BEEP, the Producer can send the root component on channel 1 and the Consumer can request images on even numbered channels when it encounters a reference. This solution allows more flexibility than the Application/Vnd.pwg-multiplexed content-type. If there are side-by-side images and/or run-around text, the Consumer can request bands of each image or run-around text over separate channels.
使用BEEP，生产者可以在通道1上发送根组件，消费者可以在遇到引用时请求偶数通道上的图像。此解决方案比Application/Vnd.pwg-multiplexed内容类型具有更大的灵活性。如果存在并排图像和/或环绕文字，消费者可以通过单独的频道请求每个图像或环绕文字的波段。
In all of these examples, the Application/Vnd.pwg-multiplexed content-type provides a much better solution than Multipart/Related. However, it is evenly matched with BEEP. For applications where speed is important and ordering of the chunks is important in order to avoid printing delays, the Application/Vnd.pwg-multiplexed content-type is best. For applications, where the Consumer needs more control over the ordering of received octets, BEEP is best.
在所有这些示例中，Application/Vnd.pwg-multiplexed内容类型提供了比Multipart/Related更好的解决方案。但是，它与BEEP的匹配度是相等的。对于速度很重要且块排序很重要以避免打印延迟的应用程序，Application/Vnd.pwg-multiplexed content type是最好的。对于消费者需要更多地控制接收到的八位字节顺序的应用，BEEP是最好的选择。
This document uses some of the MIME terms that are defined in [RFC2045]. The following are the terms used in this document:
本文档使用了[RFC2045]中定义的一些MIME术语。以下是本文件中使用的术语：
Entity: the headers and the content. In this document, the term "entity" describes all the octets that represent a compound object.
实体：标题和内容。在本文档中，术语“实体”描述了表示复合对象的所有八位字节。
Message: an entity as in [RFC2045]. In this document, the term "message" describes all octets that represent one component of a compound object. That is, it has MIME headers and content.
消息：如[RFC2045]中所示的实体。在本文档中，术语“消息”描述了表示复合对象一个组件的所有八位字节。也就是说，它有MIME头和内容。
Body Part: an entity inside a multipart. That is, a body part is the headers and content (i.e., octets) between the multipart boundary strings not including the CRLF at the beginning and end. This document never uses "entity" to mean "body part".
主体部分：多部分中的实体。也就是说，主体部分是多部分边界字符串之间的标题和内容（即八位字节），不包括开头和结尾的CRLF。本文件从不使用“实体”来表示“身体部位”。
Headers: the initial lines of an entity, message or body part. An empty line (i.e., two adjacent CRLFs) terminates the headers. Sometimes the term "MIME header" is used instead of just "header".
标题：实体、消息或正文部分的起始行。空行（即两个相邻的CRLF）终止报头。有时使用术语“MIME头”，而不仅仅是“头”。
Content: the part of an entity, message or body part that follows the headers (i.e., follows the two adjacent CRLFs). The content of a body part ends at the octet preceding the CRLF before the multipart boundary string. The content of a message ends at the octets specified by the length field in the Chunk Header.
内容：实体、消息或正文部分中位于标题后面的部分（即，位于两个相邻的CRLF后面）。主体部分的内容在多部分边界字符串之前的CRLF之前的八位字节结束。消息的内容在块头中的长度字段指定的八位字节处结束。
This document uses the following additional terms.
本文件使用以下附加条款。
Chunk: a chunk of data, consisting of a chunk header, a chunk payload and a CRLF.
Chunk：数据块，由块头、块有效负载和CRLF组成。
Chunk Header: the first line of a chunk. The line consists of the "CHK" keyword, the message number, the length and the continuation indicator, each separated by a single space character (ASCII 32). A CRLF terminates the line. Each message in an Application/Vnd.pwg-multiplexed entity has a message number that normally differs from the message numbers of all other messages in the Application/Vnd.pwg-multiplexed entity. The message number 0 is reserved for final Chunk Header in the Application/Vnd.pwg-multiplexed entity.
块头：块的第一行。该行由“CHK”关键字、消息编号、长度和延续指示符组成，每一行由单个空格字符（ASCII 32）分隔。CRLF终止该行。Application/Vnd.pwg-multiplexed实体中的每条消息都有一个消息编号，该编号通常不同于Application/Vnd.pwg-multiplexed实体中所有其他消息的消息编号。消息编号0保留给Application/Vnd.pwg-multiplexed实体中的最终块头。
Chunk Payload: the octets between the Chunk Header and the Chunk Header of the next chunk. The length field in the header's length field specifies the number of octets in the Chunk Payload. The Chunk Payload is either a complete message or a part of a message. The continuation field in the header specifies whether the chunk is the last chunk of the message.
区块有效负载：区块头和下一个区块的区块头之间的八位字节。标头长度字段中的长度字段指定块有效负载中的八位字节数。区块有效负载是完整消息或消息的一部分。标头中的continuation字段指定该区块是否为消息的最后一个区块。
CRLF: the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break. A CRLF terminates each chunk in order to provide visual separation from the next chunk header.
CRLF：对应于两个US-ASCII字符CR（十进制值13）和LF（十进制值10）的八位字节序列，按此顺序加在一起表示换行。CRLF终止每个区块，以提供与下一个区块头的可视分离。
Consumer: the software that receives and processes a MIME entity, e.g., software in a printer or software that reads a file.
使用者：接收和处理MIME实体的软件，例如打印机中的软件或读取文件的软件。
Producer: the software that creates and sends a MIME entity, e.g., software in a scanner or software that writes a file.
生产者：创建和发送MIME实体的软件，例如扫描仪中的软件或写入文件的软件。
The Application/Vnd.pwg-multiplexed content-type, like Multipart/Related, is intended to represent a compound object consisting of several inter-related components. This document does not specify the representation of these relationships, but [RFC2557] contains examples of Multipart/Related entities that use the Content-ID and Content-Location headers to identify body parts and URLs (including the "cid" URL) to reference body parts. It is expected that Application/Vnd.pwg-multiplexed entities would use the patterns described in [RFC2557].
Application/Vnd.pwg-multiplexed内容类型与Multipart/Related类似，旨在表示由多个相互关联的组件组成的复合对象。本文档未指定这些关系的表示，但[RFC2557]包含多部分/相关实体的示例，这些实体使用内容ID和内容位置头来标识身体部位和参考身体部位的URL（包括“cid”URL）。预计Application/Vnd.pwg多路复用实体将使用[RFC2557]中描述的模式。
For an Application/Vnd.pwg-multiplexed entity, there is one parameter for the Content-Type header. It is a "type" parameter, and it is like the "type" parameter for the Multipart/Related content-type. The value of the "type" parameter must be the content-type of the root message and it effectively specifies the type of the compound object.
对于Application/Vnd.pwg-multiplexed实体，Content-Type头有一个参数。它是一个“类型”参数，与多部分/相关内容类型的“类型”参数类似。“type”参数的值必须是根消息的内容类型，并且它有效地指定了复合对象的类型。
An Application/Vnd.pwg-multiplexed entity contains a sequence of chunks. Each chunk consists of a chunk header, a chunk payload and a CRLF.
Application/Vnd.pwg-multiplexed实体包含一系列块。每个区块由区块头、区块有效负载和CRLF组成。
- The chunk header consists of a "CHK" keyword followed by the message number, the chunk payload length, whether the chunk is the last chunk of a message and, finally, a CRLF. The length field removes the need for boundary strings that Multipart uses. (See section 3.1 for the syntax of a chunk header).
- 区块头由一个“CHK”关键字组成，后跟消息编号、区块有效负载长度、区块是否是消息的最后一个区块以及最后一个CRLF。“长度”字段不再需要多部分使用的边界字符串。（有关块头的语法，请参见第3.1节）。
- The chunk payload is a sequence of octets that is either a complete message or a part of a message.
- 区块有效负载是一个八位字节序列，它要么是完整的消息，要么是消息的一部分。
- The CRLF provides visual separation from the following chunk.
- CRLF提供了与以下区块的可视分离。
Each message represents a component of the compound object, and a message is intended to have exactly the same representation, octet for octet, as a body part of a Multipart/Related entity that represents the same component. When a message is split across multiple chunks, the chunks need not be contiguous.
每个消息都表示复合对象的一个组件，消息的表示方式完全相同，八位字节对应八位字节，作为表示相同组件的多部分/相关实体的主体部分。当消息被拆分为多个块时，这些块不必是连续的。
The contents of an Application/Vnd.pwg-multiplexed entity have the following properties:
Application/Vnd.pwg-multiplexed实体的内容具有以下属性：
1) The first chunk contains a complete or partial message that (in either case) represents the root component of the compound object.
1) 第一个区块包含一条完整或部分消息（在任何情况下）表示复合对象的根组件。
2) Additional chunks contain messages or partial messages that represent some component of the compound object.
2) 其他块包含表示复合对象某些组件的消息或部分消息。
3) The final chunk's header contains a message number of 0, a length of 0 and a last-chunk-of-message mark (i.e., the chunk header line is "CHK 0 0 LAST"). The final chunk contains no chunk payload.
3) 最后一个区块的标头包含消息编号0、长度0和消息标记的最后一个区块（即区块标头行为“CHK 0 last”）。最后一个区块不包含区块负载。
4) A message can be broken into multiple parts and each break can occur anywhere within the message. Each part of the message is zero or more bytes in length and each part of the message is the contents of its own chunk. The order of the chunks within the Application/Vnd.pwg-multiplexed entity must be the same as the order of the parts within the message.
4) 一条消息可以分为多个部分，每个部分都可以发生在消息中的任何位置。消息的每个部分的长度为零个或多个字节，消息的每个部分都是其自身区块的内容。Application/Vnd.pwg-multiplexed实体中块的顺序必须与消息中部分的顺序相同。
5) A message represents a component of a compound object, and it is intended that it have exactly the same representation, octet for octet, as a body part of a Multipart/Related entity that represents the same component. In particular, the message may contain a Content-Type header to specify the content-type of the message content. Also, the message may contain a Content-ID header and/or Content-Location header to identify a message that is referenced from within another message. If a message contains no Content-Type header, then the message has an implicit content-type of "text/plain; charset=us-ascii", cf. [RFC2045].
5) 消息表示复合对象的一个组件，其目的是使其具有完全相同的表示形式（octet for octet），作为表示相同组件的多部分/相关实体的主体部分。具体地，消息可以包含内容类型报头，以指定消息内容的内容类型。此外，消息可以包含内容ID报头和/或内容位置报头，以标识从另一消息中引用的消息。如果消息不包含内容类型标头，则消息具有“text/plain；charset=us ascii”的隐式内容类型，参见[RFC2045]。
See section 4 for a discussion displaying an Application/Vnd.pwg-multiplexed entity.
有关显示应用程序/Vnd.pwg-multiplexed实体的讨论，请参见第4节。
The ABNF [RFC2234] for the contents of an Application/Vnd.pwg-multiplexed entity is:
应用程序/Vnd.pwg复用实体内容的ABNF[RFC2234]为：
contents = *chunk finalChunk
chunk = header payload CRLF
header = "CHK" SP messageNumber SP length SP isMore CRLF
messageNumber = 1..2147483647
length = 0..2147483647
isMore = "MORE" / "LAST"
payload = *OCTET
finalChunk = finalHeader CRLF
finalHeader = "CHK" SP "0" SP "0" SP "LAST" CRLF
contents = *chunk finalChunk
chunk = header payload CRLF
header = "CHK" SP messageNumber SP length SP isMore CRLF
messageNumber = 1..2147483647
length = 0..2147483647
isMore = "MORE" / "LAST"
payload = *OCTET
finalChunk = finalHeader CRLF
finalHeader = "CHK" SP "0" SP "0" SP "LAST" CRLF
The messageNumber field specifies the message that the chunk is associated with. See the end of this section for more details.
messageNumber字段指定区块关联的消息。有关更多详细信息，请参见本节末尾。
The length field specifies the number of octets in the chunk payload (represented in ABNF as "payload"). The first octet of the chunk payload is the one immediately following the LF (i.e., final octet) of the chunk header. The last octet of the chunk payload is the one immediately preceding the two octets CRLF that end the chunk.
长度字段指定块有效负载中的八位字节数（在ABNF中表示为“有效负载”）。区块有效载荷的第一个八位组是紧接区块头的LF（即，最后一个八位组）之后的八位组。区块有效载荷的最后一个八位字节是结束区块的两个八位字节CRLF之前的一个八位字节。
The isMore field has a value of "LAST" for the last chunk of a message and "MORE" for all other chunks of a message.
isMore字段的值为“LAST”，表示消息的最后一个区块，而“MORE”表示消息的所有其他区块。
Normally each message in an Application/Vnd.pwg-multiplexed entity has a unique message number, and a message consists of the concatenation of all the octets from the one or more chunks with the same message number. The isMore field of the chunk header of the last chunk of each message must have a value of "LAST" and the isMore field of the chunk header of all other chunks must have a value of "MORE".
通常，Application/Vnd.pwg-multiplexed实体中的每条消息都有一个唯一的消息编号，并且一条消息由来自具有相同消息编号的一个或多个块的所有八位字节串联而成。每条消息的最后一个区块的区块头的isMore字段必须具有值“last”，而所有其他区块的区块头的isMore字段必须具有值“MORE”。
Two or more messages may have the same message number, though such reuse of message numbers is not recommended. The chunks with the same message number represent a sequence of one or more messages where the isMore field of the chunk header of the last chunk of each message has a value of "LAST". All chunks whose isMore field of the chunk header has the value of "MORE" belong to the same message as the next chunk (in sequence) whose isMore field of the chunk header has the value of "LAST". In other words, if two messages have the same message number, the last chunk of the first message must occur before the first chunk of the second message.
两个或多个消息可能具有相同的消息编号，但不建议重复使用消息编号。具有相同消息编号的区块表示一个或多个消息的序列，其中每个消息的最后一个区块的区块头的isMore字段的值为“last”。区块头的isMore字段值为“MORE”的所有区块与下一个区块（按顺序）属于同一条消息，该区块头的isMore字段值为“LAST”。换句话说，如果两条消息具有相同的消息编号，则第一条消息的最后一块必须出现在第二条消息的第一块之前。
The behavior of the Consumer is undefined if the final Chunk (i.e., the Chunk whose chunk header is "CHK 0 0 LAST") occurs before the last chunk of every message occurs.
如果最后一个区块（即区块头为“CHK 0 0 LAST”的区块）出现在每条消息的最后一个区块出现之前，则消费者的行为未定义。
Two adjacent chunks usually have different message numbers. However, they may have the same message number. If two adjacent chunks have the same message number, the two chunks could be combined into a single chunk, but they need not be combined.
两个相邻的区块通常具有不同的消息编号。但是，它们可能具有相同的消息编号。如果两个相邻的区块具有相同的消息编号，那么这两个区块可以组合成一个区块，但不需要组合。
The number of octets in a chunk payload may be zero, and an Application/Vnd.pwg-multiplexed entity may contain any number of chunks with zero octets of chunk payload. For example, the last chunk of each message may contain zero octets for programming convenience. As another example, suppose that a particular compound object format requires that referenced messages occur before the root message. This document requires that the first chunk of an Application/Vnd.pwg-multiplexed entity contain the root message or a
区块有效载荷中的八位字节数可以是零，并且应用程序/Vnd.pwg多路复用实体可以包含任何数量的区块，其中区块有效载荷的八位字节数为零。例如，为了便于编程，每条消息的最后一块可能包含零个八位字节。作为另一个示例，假设特定的复合对象格式要求引用的消息出现在根消息之前。本文档要求Application/Vnd.pwg-multiplexed实体的第一个块包含根消息或
part of it. So, the first chunk contains a chunk payload of zero octets with the first octet of the root message in the second chunk. That is, all of the message headers of the root message are in the second chunk. As an extreme but unlikely example, it would be possible to have a message broken into ten chunks with zero octet chunk payloads in all chunks except for chunks 4 and 7.
一部分。因此，第一个区块包含零个八位字节的区块负载，根消息的第一个八位字节位于第二个区块中。也就是说，根消息的所有消息头都在第二个块中。作为一个极端但不太可能的例子，有可能将一条消息分成十个块，除了块4和块7之外，所有块中的八位组块有效负载都为零。
This section defines additional parameters for Application/Vnd.pwg-multiplexed.
本节定义了Application/Vnd.pwg-multiplexed的附加参数。
The type parameter must be specified. Its value is the content-type of the "root" message. It permits a Consumer to determine the content-type without reference to the enclosed message. If the value of the type parameter differs from the content-type of the root message, the Consumer's behavior is undefined.
必须指定类型参数。它的值是“根”消息的内容类型。它允许消费者在不参考随附消息的情况下确定内容类型。如果type参数的值与根消息的内容类型不同，则消费者的行为未定义。
The syntax for "parameter" is:
“参数”的语法为：
parameter := "type" "=" type "/" subtype ; cf. [RFC2045]
parameter := "type" "=" type "/" subtype ; cf. [RFC2045]
The application that handles the Application/Vnd.pwg-multiplexed entity has the responsibility for displaying the entity. However, Application/Vnd.pwg-multiplexed messages may contain Content-Disposition headers that provide suggestions for the display and storage of a message, and in some cases the application may pay attention to such headers.
处理application/Vnd.pwg-multiplexed实体的应用程序负责显示该实体。然而，Application/Vnd.pwg-multiplexed消息可能包含为消息的显示和存储提供建议的内容处置头，并且在某些情况下，应用程序可能会注意这些头。
As a reminder, Content-Disposition headers [RFC1806] allow the sender to suggest presentation styles for MIME messages. There are two presentation styles, 'inline' and 'attachment'. Content-Disposition headers have a parameter for specifying a suggested file name for storage.
作为提醒，内容处置头[RFC1806]允许发送者建议MIME消息的呈现样式。有两种演示样式，“内联”和“附件”。内容处置标头有一个参数，用于指定建议的存储文件名。
There are three cases to consider for handling Application/Vnd.pwg-multiplexed entities:
处理应用/VND.PWG复用实体需要考虑三种情况：
a) The Consumer recognizes Application/Vnd.pwg-multiplexed and the content-type of the root. The Consumer determines the presentation style for the compound object; it handles the display of the components of the compound object in the context
a) 使用者识别应用程序/Vnd.pwg-multiplexed和根目录的内容类型。使用者确定复合对象的表示样式；它处理上下文中复合对象组件的显示
of the compound object. In this case, the Content-Disposition header information is redundant or even misleading, and the Consumer shall ignore them for purposes of display. The Consumer may use the suggested file name if the entity is stored.
复合对象的属性。在这种情况下，内容处置标题信息是冗余的，甚至是误导性的，消费者应忽略它们以便于显示。如果存储了实体，消费者可以使用建议的文件名。
b) The Consumer recognizes Application/Vnd.pwg-multiplexed, but not the content-type of the root. The Consumer will give the user the choice of suppressing the entire Application/Vnd.pwg-multiplexed entity or treating the Application/Vnd.pwg-multiplexed entity as a Multipart/Mixed entity where each message is a body part of the Multipart/Mixed entity. In this case (where the entity is not suppressed), the Consumer may find the Content-Disposition information useful for displaying each body part of the resulting Multipart/Mixed entity. If a body part has no Content-Disposition header, the Consumer should display the body part as an attachment.
b) 使用者识别Application/Vnd.pwg-multiplexed，但不识别根目录的内容类型。使用者将向用户提供以下选择：抑制整个应用程序/Vnd.pwg-多路复用实体，或将应用程序/Vnd.pwg-多路复用实体视为多部分/混合实体，其中每条消息都是多部分/混合实体的主体部分。在这种情况下（实体未被抑制），消费者可能会发现内容配置信息对于显示结果多部分/混合实体的每个身体部位有用。如果正文部分没有内容处置标题，使用者应将正文部分显示为附件。
c) The Consumer does not recognize Application/Vnd.pwg-multiplexed. The Consumer treats the Application/Vnd.pwg-multiplexed entity as opaque and can do nothing with it.
c) 使用者无法识别应用程序/Vnd.pwg-multiplexed。使用者将Application/Vnd.pwg-multiplexed实体视为不透明的，对其无能为力。
This section contains five examples. Each example is a different representation of the same compound object. The compound object has four components: an XHTML text component and three image components. The images are encoded in binary. The string "<<binary data>>" and "<<part of binary data>>" in each example represents all or part of the binary data of each image. Two of the images are potentially side by side and the third image is displayed later in the document. All of the images are identified by Content-Id and two of the images are also identified by a Content-Location. One of the images references the Content-Location.
本节包含五个示例。每个示例都是同一复合对象的不同表示形式。复合对象有四个组件：一个XHTML文本组件和三个图像组件。这些图像是用二进制编码的。每个示例中的字符串“<<二进制数据>>”和“<<<部分二进制数据>>”表示每个图像的全部或部分二进制数据。其中两个图像可能并排显示，第三个图像稍后显示在文档中。所有图像由内容Id标识，其中两个图像也由内容位置标识。其中一个图像引用了内容位置。
The first example shows a Multipart/Related representation of the compound object in order to provide a representation that the reader is familiar with. The remaining examples show Application/Vnd.pwg-multiplexed representations of the same compound object. In the second example, each chunk contains a whole message. In the third example, the XHTML message is split across 3 chunks, and these chunks are interleaved among the three image messages. In the fourth example, the XHTML message is split across 4 chunks, and the two side-by-side images are each split across two chunks. The XHTML chunks are interleaved among the image chunks. In the fifth example, there are chunks with empty payloads and adjacent chunks with the same message number.
第一个示例显示复合对象的多部分/相关表示，以便提供读者熟悉的表示。其余示例显示了同一复合对象的Application/Vnd.pwg多路复用表示。在第二个示例中，每个区块都包含一条完整的消息。在第三个示例中，XHTML消息被分割成3个块，这些块在三个图像消息之间交错。在第四个示例中，XHTML消息被分割成4个块，两个并排的图像分别被分割成两个块。XHTML块在图像块之间交错。在第五个示例中，存在具有空有效负载的块和具有相同消息编号的相邻块。
The last example may seem to address useless cases, but sometimes it is easier to write software if these cases are allowed. For example, when a buffer fills, it may be easiest to write a chunk and not worry if the previous chunk had the same message number. Likewise, it may be easiest to end a message with an empty chunk. Finally, the Application/Vnd.pwg-multiplexed content-type requires that the first chunk be part of the root message. Sometimes, it is more convenient for the Producer if the root message starts after the occurrence of some attachments. Since a chunk can be empty, the first chunk of the root message can be empty, i.e., it doesn't even contain any headers. Then the first chunk contains a part of the root message, but the Producer doesn't generate any octets for that chunk.
最后一个示例似乎解决了一些无用的情况，但如果允许这些情况，有时编写软件会更容易。例如，当一个缓冲区被填满时，写一个区块可能是最容易的，并且不必担心前一个区块是否具有相同的消息编号。同样，以空块结束消息可能是最容易的。最后，Application/Vnd.pwg-multiplexed内容类型要求第一个区块是根消息的一部分。有时，如果根消息在某些附件出现之后启动，则生产者会更方便。因为区块可以是空的，所以根消息的第一个区块可以是空的，也就是说，它甚至不包含任何头。然后，第一个区块包含根消息的一部分，但生产者不会为该区块生成任何八位字节。
Each body part of the Multipart/Related entity and each message of the Application/Vnd.pwg-multiplexed entity contain a content-disposition, which the Consumer uses according to the rules in section 4. Note the location of the content-disposition headers in the examples.
多部分/相关实体的每个主体部分和Application/Vnd.pwg-multiplexed实体的每个消息都包含一个内容配置，消费者根据第4节中的规则使用该内容配置。注意示例中内容处置头的位置。
In this example, the compound object is represented as a Multipart/Related entity so that the reader can compare it with the Application/Vnd.pwg-multiplexed entities.
在本例中，复合对象表示为多部分/相关实体，以便读者可以将其与Application/Vnd.pwg-multiplexed实体进行比较。
Content-Type: multipart/related; boundary="boundary-example";
type="text/xhtml+xml"
Content-Type: multipart/related; boundary="boundary-example";
type="text/xhtml+xml"
--boundary-example
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
--boundary-example
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
--boundary-example
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<p>some final text
</p>
</body>
</html>
--boundary-example
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example--
<<binary data>>
--boundary-example--
The four examples in this section show Application/Vnd.pwg-multiplexed representations of the same compound object. Note that each CRLF is represented by a visual line break.
本节中的四个示例显示了同一复合对象的Application/Vnd.pwg多路复用表示。请注意，每个CRLF由可视换行符表示。
In this example, the compound object is represented as an Application/Vnd.pwg-multiplexed entity. Each chunk contains an entire message, i.e., none of the messages are split across multiple chunks. Each message in this example is identical to the corresponding body part in the preceding Multipart/Relate example.
在本例中，复合对象表示为Application/Vnd.pwg-multiplexed实体。每个区块都包含一条完整的消息，也就是说，没有一条消息被分割成多个区块。本例中的每条消息与前面多部分/关联示例中的相应正文部分相同。
Content-Type: application/vnd.pwg-multiplexed;
type="application/vnd.pwg-xhtml-print+xml"
Content-Type: application/vnd.pwg-multiplexed;
type="application/vnd.pwg-xhtml-print+xml"
CHK 1 550 LAST
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
CHK 1 550 LAST
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 0 0 LAST
<<binary data>>
CHK 0 0 LAST
In this example, the compound object is represented as an Application/Vnd.pwg-multiplexed entity. The message containing the XHTML component is split into 3 pieces so that the reference to an image is as close as possible to the beginning of the chunk. The chunk containing the referenced image message occurs just before the chunk with the reference. This minimizes the distance between reference and referenced message.
在本例中，复合对象表示为Application/Vnd.pwg-multiplexed实体。包含XHTML组件的消息被分成3部分，以便对图像的引用尽可能靠近块的开头。包含引用的图像消息的区块正好出现在具有引用的区块之前。这将最小化引用和引用消息之间的距离。
Note that there are other possible arrangements (see the third example in section 5.2.3). For example, a sender could split the XHTML message so that the reference to an image is as close as possible to the end of the chunk. Then the chunk containing the referenced image message should occur just after the chunk with the reference. The sender could mix this strategy with the one used in this example.
注意，还有其他可能的安排（见第5.2.3节中的第三个示例）。例如，发送方可以拆分XHTML消息，以便对图像的引用尽可能靠近块的末尾。然后，包含引用的图像消息的块应该正好出现在具有引用的块之后。发送方可以将此策略与本示例中使用的策略混合使用。
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
CHK 1 267 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
CHK 1 267 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 166 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<<binary data>>
CHK 1 166 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 80 LAST
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
<<binary data>>
CHK 1 80 LAST
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
CHK 0 0最后
In this example, the compound object is represented as an Application/Vnd.pwg-multiplexed entity. The message containing the XHTML component is split into 4 pieces so that the reference to an image is as close as possible to either the beginning or the end of the chunk. The references to the first and second images closely follow the referenced images. The reference to the third image closely precedes the referenced image. This minimizes the distance between reference and referenced message. In addition, the first two image messages are split into two chunks each.
在本例中，复合对象表示为Application/Vnd.pwg-multiplexed实体。包含XHTML组件的消息被分成4个部分，以便对图像的引用尽可能接近块的开头或结尾。对第一和第二图像的引用紧跟在所引用的图像之后。对第三个图像的引用紧跟在被引用图像之前。这将最小化引用和引用消息之间的距离。此外，前两个图像消息被分为两个块。
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
CHK 1 303 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
CHK 1 303 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
<<part of binary data>>
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 2 6162 LAST
<<part of binary data>>
CHK 3 6201 LAST
<<part of binary data>>
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 2 6162 LAST
<<part of binary data>>
CHK 3 6201 LAST
<<part of binary data>>
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 41 LAST
</p>
<p>some final text
</p>
</body>
</html>
<<binary data>>
CHK 1 41 LAST
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
CHK 0 0最后
This example is identical to the previous one, except that some chunks have a chunk payload of zero octets. The root message starts with a chunk whose payload is empty and every message ends with a chunk whose payload is empty. This example also shows two adjacent chunks that are from the same message. These two chunks could be coalesced into a single chunk, but they might be kept separate for programming convenience.
此示例与前一个示例相同，只是有些块的块负载为零个八位字节。根消息以有效负载为空的区块开始，每条消息以有效负载为空的区块结束。此示例还显示了来自同一消息的两个相邻块。这两个块可以合并成一个块，但为了编程方便，它们可以分开。
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
CHK 1 0 MORE
CHK 10更多
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 1 303 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<<part of binary data>>
CHK 1 303 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 6162 MORE
<<part of binary data>>
CHK 3 6201 MORE
<<part of binary data>>
CHK 2 0 LAST
CHK 2 6162 MORE
<<part of binary data>>
CHK 3 6201 MORE
<<part of binary data>>
CHK 2 0 LAST
CHK 3 0 LAST
CHK 30最后
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 4 7603 MORE
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
CHK 4 7603 MORE
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 4 0 LAST
<<binary data>>
CHK 4 0 LAST
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 1 41 MORE
</p>
<p>some final text
</p>
</body>
</html>
CHK 1 41 MORE
</p>
<p>some final text
</p>
</body>
</html>
CHK 1 0 LAST
CHK 10最后
CHK 0 0 LAST
CHK 0 0最后
There are security considerations that pertain to each message of an Application/Vnd.pwg-multiplexed entity. Those security considerations are described by the document that defines the content-type of the message. They are not addressed in this document.
存在与应用程序/Vnd.pwg多路复用实体的每条消息相关的安全注意事项。这些安全注意事项由定义消息内容类型的文档描述。本文件未提及这些问题。
There are also security considerations that pertain to the Application/Vnd.pwg-multiplexed entity as a whole. A Producer that is buggy or malicious may send an Application/Vnd.pwg-multiplexed entity that could cause a Consumer to request more storage than it has, even if it has a large amount of storage. A Consumer must be able to deal gracefully with the following scenarios and combinations of them:
还有一些安全注意事项与Application/Vnd.pwg-multiplexed实体作为一个整体有关。有缺陷或恶意的生产者可能发送应用程序/Vnd.pwg多路复用实体，该实体可能导致消费者请求比其拥有的更多的存储，即使其拥有大量存储。消费者必须能够优雅地处理以下场景及其组合：
- The chunks of one or more messages are separated by a very large number of octets. In the extreme case some or all of the messages don't terminate, i.e., they don't contain a closing chunk. - A very large number of messages are started and interleaved before their final chunk occurs. - A message contains one or more references to other messages that never occur or don't occur for a large number of octets. - A very large number of referenced messages occur before the Consumer knows that it can discard them.
- 一个或多个消息的块由大量的八位字节分隔。在极端情况下，部分或全部消息不会终止，即它们不包含结束块。-在最后一个区块出现之前，启动并交错了大量消息。-一条消息包含对其他消息的一个或多个引用，这些消息在大量八位字节中从未出现或未出现。-大量被引用的消息出现在消费者知道可以丢弃它们之前。
The following form is copied from RFC 1590, Appendix A.
以下表格复制自RFC 1590附录A。
To: iana@iana.org
致：iana@iana.org
Subject: Registration of new Media Type application/Vnd.pwg-multiplexed Media Type name: Application Media subtype name: Vendor Tree - vnd.pwg-multiplexed Required parameters: Type, a media type/subtype. Optional parameters: No optional parameters Encoding considerations: Each message of an Application/Vnd.pwg-multiplexed entity can be encoded in any manner allowed by the Content-Type of the message. However, using the reasoning of Multipart, the Application/Vnd.pwg-multiplexed entity cannot be encoded. Otherwise, a message would be
主题：注册新媒体类型应用程序/Vnd.pwg-复用媒体类型名称：应用媒体子类型名称：供应商树-Vnd.pwg-复用所需参数：类型，媒体类型/子类型。可选参数：无可选参数编码注意事项：应用程序/Vnd.pwg-multiplexed实体的每条消息都可以按照消息内容类型允许的任何方式进行编码。但是，使用Multipart推理，无法对Application/Vnd.pwg-multiplexed实体进行编码。否则，将显示一条消息
encoded twice, once at the message level and once at the Application/Vnd.pwg-multiplexed level. Security considerations: See section 6 (Security Considerations) of RFC 3391. Published specification: RFC 3391. Person & email address to contact for further information:
编码两次，一次在消息级别，一次在应用程序/Vnd.pwg多路复用级别。安全注意事项：见RFC 3391第6节（安全注意事项）。已发布规范：RFC3391。联系人和电子邮件地址，以获取更多信息：
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
美国加利福尼亚州帕洛阿尔托科罗拉多大道706号罗伯特·赫里奥特94303电话：1-650-327-4466传真：1-650-327-4466电子邮件：bob@herriot.com
The author gratefully acknowledges the contributions of: Ugo Corda, Dave Crocker, Melinda Sue Grant, Graham Klyne, Carl-Uno Manros, Larry Masinter, Ira McDonald, Chris Newman, Henrik Frystyk Nielsen and Dale R. Worley. In particular, Chris Newman provided invaluable help.
作者衷心感谢乌戈·科尔达、戴夫·克罗克、梅琳达·休·格兰特、格雷厄姆·克莱恩、卡尔·乌诺·曼罗斯、拉里·马斯滕、艾拉·麦克唐纳、克里斯·纽曼、亨里克·弗莱斯特克·尼尔森和戴尔·沃利的贡献。特别是，克里斯·纽曼提供了宝贵的帮助。
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[RFC1806]Troost，R.和S.Dorner，“在互联网消息中传达呈现信息：内容处置标题”，RFC 1806，1995年6月。
[RFC1873] Levinson, E. and J. Clark, "Message/External-Body Content-ID Access Type", RFC 1873, December 1995. Levinson, E., "Message/External-Body Content-ID Access Type", Work in Progress.
[RFC1873]Levinson，E.和J.Clark，“消息/外部主体内容ID访问类型”，RFC 1873，1995年12月。Levinson，E.，“消息/外部主体内容ID访问类型”，正在进行的工作。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.Overell，“用于句法规范的增强BNF:ABNF”，RFC 2234，1997年11月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]Levinson，E.“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML", RFC 2557, March 1999.
[RFC2557]Palme，J.，“聚合文档的MIME封装，如HTML（MHTML），RFC2557，1999年3月。
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，编辑，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA
罗伯特·赫里奥特美国加利福尼亚州帕洛阿尔托市科罗拉多大道706号，邮编94303
Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
电话：1-650-327-4466传真：1-650-327-4466电子邮件：bob@herriot.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。