下载文档原格式
Network Working Group S.E. Hardcastle-Kille Requests for Comments 1275 University College London November 1991 Replication Requirements to provide an Internet Directory using X.500Status of this MemoThis memo provides information for the Internet community. Itdoes not specify an Internet standard. Distribution of this memo is unlimited.AbstractThis RFCconsiders certain deficiencies of the 1988 X.500standard, which need to be addressed before an effective openInternet Directory can be established using these protocols andservices [CCI88]. The only areas considered are primaryproblems, to which solutions must be found before a pilot can bedeployed. This RFCconcerns itself with deficiencies which canonly be addressed by use of additional protocol or procedures for distributed operation.1 Distributed Operation ExtensionsThe Internet Directory will operate DSAs over TCP/IP using RFC 1006 [RC87], and DSAs over the an ISO Network Service. Distributedoperation procedures should not require full connectivity.2 Knowledge ReplicationKnowledge information is critical to resolution of names, and performing searches. Knowledge information high up the tree needs to be widely available. Consider resolving a name below ‘‘Country=US’’. To do this, a DSA needs to have full knowledge at this point. Many DSAs need to be able to do this, in order to give reasonable response and availability. It would be an unacceptable bottleneck to force such resolution to a single or small number of DSAs. To replicatethis knowledge widely, a systematic approach to replication is needed.3 Data ReplicationSearches are often made at the root and country level, and this is a vital service (e.g., an approximate match of an organisation name). Data needs to be collected in such a way that this sort of searchingis reasonably efficient. The usual X.500 approach of subordinate references militates against this. At a node in the DIT, subordinate references to the entries below are held. These entries will be in many DSAs, each of which needs to be accessed in order to perform the single level search. It is suggested that replication of data is necessary to achieve this.The major requirement for this replication is high up the DIT, where information must be replicated between different implementations. At lower levels of the DIT, it is reasonable for DSAs to be of the same implementation and to use implementation specific techniques in order to achieve performance and availability.4 Alternate DSAsWhen a DSA Referral is returned, only the master DSA is indicated.This will lead to a single point of failure. It seems important to allow for additional references to slave copies, in order to get Hardcastle-Kille Page 1better availability. This needs to be solved in conjunction with the problem described in the previous section.5 Guidelines for use of ReplicationTo be effective, the replication specification needs to provide guidelines for deployment in the pilot, in order to meet the desired service criteria.6 Some scaling targetsMost techniques for replication have scaling limits. It is important that mechanisms used do not stress the limits of the mechanism. The order of magnitude envisioned in the pilot is 100 000 non-leaf entries and several million leaf entries.References[CCI88] The Directory --- overview of concepts, models and services,December 1988. CCITT X.500 Series Recommendations.[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Serviceson top of the TCP. Request for Comments 1006, NorthropCorporation Technology Center, May 1987.7 Security ConsiderationsSecurity considerations are not discussed in this memo.8 Author’s AddressSteve Hardcastle-KilleDepartment of Computer ScienceUniversity College LondonGower StreetWC1E 6BTEnglandHardcastle-Kille Page 2Phone: +44-71-380-7294EMail: S.Kille@Hardcastle-Kille Page 3。
Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。
The default code is NORMAL_CLEARING (if you do not specify one)The codes are documented in src/switch_channel.c and SIP Protocol MessagesIE stands for Information ElementQ.850 to SIP Code TableThe following table describes the mappings implemented by FreeSwitch (seemod_sofia.c:hangup_cause_to_sip). Unspecified causes codes (no value in the "SIP Equiv." column in the table) are translated to SIP "480 Temporarily Unavailable" by FreeSwitch.The table also contains non-standard codes above 127 (ISUP and ISDN only specify codes up to 127). These codes are used internally to FreeSwitch to indicate other states. (These codes do not map directly to SIP error codes either.) The complete list of SWITCH_CAUSE_ codes (switch_call_cause_t) is defined ininclude/switch_types.h.See ITU-T Q.850 standard for a formal definition of standard telephony disconnect cause codes for ISDN, and the mapping between Q.931 (DSSS1) and ISUP codes.See ITU Q.1912.5 for a formal definition of interoperability between ISUP and SIP, especially section 6.11 which specifies the "Reason" header and gives the mapping of the disconnect cause codes between ISUP and SIP.Another set of mappings are the Q.SIG / SIP mappings from RFC 4497 section 8.4.1. (Q.SIG is one of many extensions to Q.931 used for PBX-to-PBX signalling on private links.)In practice it appears that FreeSwitch implements neither Q.1912.5 nor RFC4497.No route to specified transit network (national use) [Q.850]This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network, which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause.3404NO_ROUTE_DESTINATION No route todestination[Q.850]This cause indicates that thecalled party cannot bereached because the networkthrough which the call hasbeen routed does not servethe destination desired. Thiscause is supported on anetwork dependent basis.6CHANNEL_UNACCEPTABLE channelunacceptable[Q.850]This cause indicates that thechannel most recentlyidentified is not acceptable tothe sending entity for use inthis call.7CALL_AWARDED_DELIVERED call awarded,being deliveredin anestablishedchannel[Q.850]This cause indicates that theuser has been awarded theincoming call, and that theincoming call is beingconnected to a channelalready established to thatuser for similar calls (e.g.packet-mode x.25 virtualcalls).16NORMAL_CLEARING normal callclearing[Q.850]This cause indicates that thecall is being cleared becauseone of the users involved inthe call has requested that thecall be cleared. Under normalsituations, the source of thiscause is not the network.17486USER_BUSY user busy[Q.850]This cause is used to indicate that the called party is unable to accept another call becausethe user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.18408NO_USER_RESPONSE no userresponding[Q.850]This cause is used when acalled party does not respondto a call establishmentmessage with either analerting or connect indicationwithin the prescribed periodof time allocated.19480NO_ANSWER no answer fromuser (useralerted)[Q.850]This cause is used when thecalled party has been alertedbut does not respond with aconnect indication within aprescribed period of time.Note - This cause is notnecessarily generated byQ.931 procedures but may begenerated by internal networktimers.20480SUBSCRIBER_ABSENT subscriberabsent [Q.850]This cause value is usedwhen a mobile station haslogged off, radio contact isnot obtained with a mobilestation or if a personaltelecommunication user istemporarily not addressableat any user-network interface.Sofia SIP will normally raiseUSER_NOT_REGISTEREDin such situations.21603CALL_REJECTED call rejected[Q.850]This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. The network may also generate this cause, indicating that the call was cleared due to asupplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.22410NUMBER_CHANGED numberchanged[Q.850]This cause is returned to acalling party when the calledparty number indicated by thecalling party is no longerassigned, The new calledparty number may optionallybe included in the diagnosticfield. If a network does notsupport this cause, cause no:1, unallocated (unassigned)number shall be used.23410REDIRECTION_TO_NEW_DESTINATION This cause is used by a general ISUP protocol mechanism that can be invoked by an exchange that decides that the call should be set-up to a different called number. Such an exchange can invoke a redirection mechanism, by use of this cause value, to request a preceding exchange involved in the call to route the call to the new number.25483EXCHANGE_ROUTING_ERROR This cause indicates that the destination indicated by the user cannot be reached, because an intermediate exchange has released the call due to reaching a limit in executing the hop counter procedure. This cause is generated by an intermediate node, which when decrementing the hop counter value, gives the result 0.27502DESTINATION_OUT_OF_ORDER destination outof order[Q.850]This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioningcorrectly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party;e.g. a physical layer or data link layer failure at the remote party, or user equipment off-line.28484INVALID_NUMBER_FORMAT invalid numberformat (addressincomplete)[Q.850]This cause indicates that thecalled party cannot bereached because the calledparty number is not in a validformat or is not complete.29501FACILITY_REJECTED facilitiesrejected[Q.850]This cause is returned when asupplementary servicerequested by the user cannotbe provide by the network.30RESPONSE_TO_STATUS_ENQUIRY response toSTATUSINQUIRY[Q.850]This cause is included in theSTATUS message when thereason for generating theSTATUS message was theprior receipt of a STATUSINQUIRY.31480NORMAL_UNSPECIFIED normal,unspecified[Q.850]This cause is used to report anormal event only when noother cause in the normalclass applies.34503NORMAL_CIRCUIT_CONGESTION nocircuit/channelavailable[Q.850]This cause indicates that thereis no appropriatecircuit/channel presentlyavailable to handle the call.38503NETWORK_OUT_OF_ORDER network out oforder [Q.850]This cause indicates that thenetwork is not functioningcorrectly and that thecondition is likely to last arelatively long period of timee.g. immediatelyre-attempting the call is notlikely to be successful.41503NORMAL_TEMPORARY_FAILURE temporaryfailure [Q.850]This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try anothercall attempt almost immediately.42503SWITCH_CONGESTION switchingequipmentcongestion[Q.850]This cause indicates that theswitching equipmentgenerating this cause isexperiencing a period of hightraffic.43ACCESS_INFO_DISCARDED accessinformationdiscarded[Q.850]This cause indicates that thenetwork could not deliveraccess information to theremote user as requested, i.e.user-to-user information, lowlayer compatibility, highlayer compatibility orsub-address as indicated inthe diagnostic. It is noted thatthe particular type of accessinformation discarded isoptionally included in thediagnostic.44503REQUESTED_CHAN_UNAVAIL requestedcircuit/channelnot available[Q.850]This cause is returned whenthe other side of the interfacecannot provide the circuit orchannel indicated by therequesting entity.45PRE_EMPTED47resourceunavailable,unspecified[Q.850]This cause is used to report aresource unavailable eventonly when no other cause inthe resource unavailable classapplies.50FACILITY_NOT_SUBSCRIBED requestedfacility notsubscribed[Q.850This cause indicates that theuser has requested asupplementary service, whichis available, but the user isnot authorized to use.52403OUTGOING_CALL_BARRED outgoing callsbarredThis cause indicates thatalthough the calling party is amember of the CUG for theoutgoing CUG call, outgoingcalls are not allowed for thismember of the CUG.54403INCOMING_CALL_BARRED incoming callsbarred This cause indicates that although the called party is a member of the CUG for theincoming CUG call, incoming calls are not allowed to this member of the CUG.57403BEARERCAPABILITY_NOTAUTH bearercapability notauthorized[Q.850]This cause indicates that theuser has requested a bearercapability that isimplemented by theequipment which generatedthis cause but the user is notauthorized to use.58503BEARERCAPABILITY_NOTAVAIL bearercapability notpresentlyavailable[Q.850]This cause indicates that theuser has requested a bearercapability which isimplemented by theequipment which generatedthis cause but which is notavailable at this time.63SERVICE_UNAVAILABLE service oroption notavailable,unspecified[Q.850]This cause is used to report aservice or option notavailable event only when noother cause in the service oroption not available classapplies.65488BEARERCAPABILITY_NOTIMPL bearercapability notimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support the bearercapability requested.66CHAN_NOT_IMPLEMENTED channel typenotimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support the channeltype requested69501FACILITY_NOT_IMPLEMENTED requestedfacility notimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support therequested supplementaryservices.79501SERVICE_NOT_IMPLEMENTED service oroption notimplemented,unspecified[Q.850]This cause is used to report aservice or option notimplemented event onlywhen no other cause in theservice or option notimplemented class applies.81INVALID_CALL_REFERENCE invalid callreference value This cause indicates that the equipment sending this causecall reference which is not currently in use on the user-network interface.88488INCOMPATIBLE_DESTINATION incompatibledestination[Q.850]This cause indicates that theequipment sending this causehas received a request toestablish a call which has lowlayer compatibility, highlayer compatibility or othercompatibility attributes (e.g.data rate) which cannot beaccommodated.95INVALID_MSG_UNSPECIFIED invalidmessage,unspecified[Q.850]This cause is used to reportan invalid message event onlywhen no other cause in theinvalid message class applies.96MANDATORY_IE_MISSING mandatoryinformationelement ismissing[Q.850]This cause indicates that theequipment sending this causehas received a message whichis missing an informationelement which must bepresent in the message beforethat message can beprocessed.97MESSAGE_TYPE_NONEXIST message typenon-existent ornotimplemented[Q.850]This cause indicates that theequipment sending this causehas received a message with amessage type it does notrecognize either because thisis a message not defined ofdefined but not implementedby the equipment sending thiscause.98WRONG_MESSAGE message notcompatiblewith call stateor messagetypenon-existent ornotimplemented.[Q.850]This cause indicates that theequipment sending this causehas received a message suchthat the procedures do notindicate that this is apermissible message toreceive while in the call state,or a STATUS message wasreceived indicating anincompatible call state.99IE_NONEXIST Informationelement /This cause indicates that the equipment sending this causenon-existent or not implemented [Q.850]includes information element(s)/parameter(s) not recognized because the informationelement(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the informationelement(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.100INVALID_IE_CONTENTS Invalidinformationelementcontents[Q.850]This cause indicates that theequipment sending this causehas received and informationelement which it hasimplemented; however, oneor more fields in the I.E. arecoded in such a way whichhas not been implemented bythe equipment sending thiscause.101WRONG_CALL_STATE message notcompatiblewith call state[Q.850]This cause indicates that amessage has been receivedwhich is incompatible withthe call state.102504RECOVERY_ON_TIMER_EXPIRE recovery ontimer expiry[Q.850]This cause indicates that aprocedure has been initiatedby the expiration of a timer inassociation with errorhandling procedures. This isoften associated with NATproblems. Ensure that "NATMapping Enable" is turned onin your ATA. If it is not NATrelated it can sometimes beprovider related, make sure toensure another outboundprovider does not solve theproblem.103MANDATORY_IE_LENGTH_ERROR parameter This cause indicates that thenon-existent or not implemented -passed on (national use) [Q.850]equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged.111PROTOCOL_ERROR protocol error,unspecified[Q.850]This cause is used to report aprotocol error event onlywhen no other cause in theprotocol error class applies.127INTERWORKING Interworking,unspecified[Q.850]This cause indicates that aninterworking call (usually acall to SW56 service) hasended.487487ORIGINATOR_CANCEL 500CRASH501SYSTEM_SHUTDOWN 502LOSE_RACE503MANAGER_REQUEST This cause is used when you send an api command to make it hangup. For example uuid_kill <uuid>600BLIND_TRANSFER601ATTENDED_TRANSFER 602ALLOTTED_TIMEOUT 603USER_CHALLENGE 604MEDIA_TIMEOUT605PICKED_OFF This cause means the call was picked up by intercepting it from another extension (i.e. dialing **ext_number from another extension).606USER_NOT_REGISTERED 607PROGRESS_TIMEOUTSIP to Q.850 Code TableThese mappings are taken from RFC 4497 section 8.4.4.See alsoredirect• respond• Hangup_CausesSee also 11。
学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议（Routing Information Protocol）rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强：Part1-消息编码和鉴别过程rfc1132中文版-802．2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议（IPCP）rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP（版本2）协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议（版本2）rfc1738中文版-统一资源定位器（URL）rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4（BGP-4）rfc1827中文版-IP封装安全载荷（ESP）rfc1883中文版-Internet协议，版本6（IPv6）说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议（）rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法（PPPoE）rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4（边界网关协议）的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换（传统NAT）rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围（RFC3037 LDP Applicability）rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS（多协议标签交换）环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言（NewsML）资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP：实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议（ICMP）rfc821中文版-RFC821 简单邮件传输协议（SMTP）rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项（RFC930——T elnet Terminal Type Option）rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。
rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。
RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。
在本文中，我们将介绍RFC相关的设置和使用。
1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。
RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。
RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。
2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。
这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。
通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。
阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。
3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。
它们提供了协议规范、算法实现、安全性和隐私等方面的建议。
网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。
此外，RFC文档还常用于进行互联网协议的实现、编程和配置。
4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。
任何人都可以参与到RFC的制定过程中。
要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。
通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。
5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。
这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。
遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。
总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。
rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。
RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。
在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。
本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。
二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。
它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。
三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。
2. 发送方主机将报文发送到网络中。
3.中间路由器收到报文后，将报文转发到下一跳路由器。
4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。
5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。
三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。
- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。
- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。
二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。
它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。
1.备忘 (3)2.版权申明 (3)3.摘要 (3)4.授权鉴别 (4)4.1.对HTTP/1.1规范的依赖 (4)4.2.访问鉴别框架 (4)5.基本鉴别方案 (6)6.摘要访问鉴别方案 (8)6.1.介绍 (8)6.1.1.目的 (8)6.1.2.操作概述 (8)6.1.3.摘要值的表示 (8)6.1.4.该方案的局限性 (8)6.2.摘要报头的规范 (9)6.2.1.WWW-Authenticate响应报头 (9)6.2.2.Authorization请求报头 (11)6.2.3.Authentication-info报头 (15)6.3.摘要操作 (17)6.4.安全协议讨论 (17)6.5.例子 (18)6.6.代理鉴别和代理授权 (18)7.安全考虑 (20)7.1.客户使用基本鉴别 (20)7.2.客户使用摘要鉴别 (20)7.3.受限的NONCE值使用 (21)7.4.基本鉴别与摘要鉴别的比较 (21)7.5.回放式攻击 (22)7.6.多方鉴别方案产生的缺点 (22)7.7.在线字典攻击 (23)7.8.中间人 (23)7.9.选择纯文本攻击 (23)7.10.预先计算的字典攻击 (24)7.11.批处理方式暴力攻击 (24)7.12.假冒服务器欺骗 (24)7.13.存储口令 (24)7.14.总结 (25)8.例子实现 (26)9.参考书目 (30)10.作者地址 (30)11.完整版权申明 (30)12.致谢 (30)1.备忘本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。
详情请参见官方文件（STD1）。
本文可任意分发。
2.版权申明Copyright (C) The Internet Society (1999). All Rights Reserved3.摘要“HTTP/1.0”中包括基本访问鉴别方案（Basic Access Authentication scheme）。
ENCRYPTION REFERENCE GUIDEPolycom® HDA50The following table presents product capabilities which are supported, but not necessarily required. Requirements will vary based on your environment.Provisioning Confidentiality Integrity Securely exchange configurationfile using HTTPSHTTPSSecure Real Time Protocol Confidentiality RTP/Media encryption for securedvoice communicationSRTPSIP over TLS Confidentiality SIP/Signaling encryption forsecured signalingTLS 1.2SIP Authentication Authentication Provides authentication of theproduct’s SIP user agentcredentials to the SIPProxy/RegistrarDigest (RFC 2617)Local Web Server Authentication HTTP Digest authentication forlocal/remote web server accessDigest (RFC)802.1X Supplicant AuthenticationConfidentialityIntegrity Allows product to authenticate toWIFI or a Layer 2 switch that isusing 802.1X for authenticationEAP-MD5 (RFC 3748)TLS 1.2, 1.1, 1.0July 2019 | 3725-86017-001APolycom, Inc. 1Copyright and TrademarkCopyright© 2019, Polycom, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc.6001 America Center DriveSan Jose, CA 95002USATrademarksPolycom®, the Polycom logo and the names and marks associated with Polycom products are trademarks and/or service marks of Polycom, Inc. and are registered and/or common law marks in the United States and various other countries.All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient's personal use, without the express written permission of Polycom.DisclaimerWhile Polycom uses reasonable efforts to include accurate and up-to-date information in this document, Polycom makes no warranties or representations as to its accuracy. Polycom assumes no liability or responsibility for any typographical or other errors or omissions in the content of this document.Limitation of LiabilityPolycom and/or its respective suppliers make no representations about the suitability of the information contained in this document for any purpose. Information is provided "as is" without warranty of any kind and is subject to change without notice. The entire risk arising out of its use remains with the recipient. In no event shall Polycom and/or its respective suppliers be liable for any direct, consequential, incidental, special, punitive or other damages whatsoever (including without limitation, damages for loss of business profits, business interruption, or loss of business information), even if Polycom has been advised of the possibility of such damages.End User License AgreementBY USING THIS PRODUCT, YOU ARE AGREEING TO THE TERMS OF THE END USER LICENSE AGREEMENT (EULA) AT: https:///indexes/licenses. IF YOU DO NOT AGREE TO THE TERMS OF THE EULA, DO NOT USE THE PRODUCT, AND YOU MAY RETURN IT IN THE ORIGINAL PACKAGING TO THE SELLER FROM WHOM YOU PURCHASED THE PRODUCT.Patent InformationThe accompanying product may be protected by one or more U.S. and foreign patents and/or pending patent applications held by Polycom, Inc.Open Source Software Used in this ProductThis product may contain open source software. You may receive the open source software from Polycom up to three (3) years after the distribution date of the applicable product or software at a charge not greater than the cost to Polycom of shipping or distributing the software to you. To receive software information, as well as the open source softwarecodeusedinthisproduct,**************************************************.Customer FeedbackWe are striving to improve our documentation quality and we appreciate your feedback. Email your opinions and comments to *********************************.Polycom SupportVisit Polycom Support for End User License Agreements, software downloads, product documents, product licenses, troubleshooting tips, service requests, and more.2 Polycom, Inc.。
IXIA网络测试仪使用说明(仅供内部使用)格林耐特技术有限公司GreenNet Technologies Co., Ltd.版权所有侵权必究All rights reservedIXIA网络测试仪操作规程目录1. IXIA网络测试仪操作规程 ..................................................................... (3)2. IXIA网络测试仪使用说明 ..................................................................... (4)2.1. IXIA测试仪简介 ..................................................................... .......................................................4 2.2. 测试原理 ..................................................................... . (4)2.3. 硬件安装和配置 ..................................................................... . (5)2.3.1. 检查包装...................................................................... .. (5)2.3.2. 硬件连接...................................................................... .. (5)2.3.3. 配置TCP/IP协议 ..................................................................... ...........................................6 2.4. 软件安装 ..................................................................... . (7)2.5. 测试操作 ..................................................................... . (8)2.5.1. 1.测试注意事项...................................................................... ..............................................83. IxExplorer使用说明 ..................................................................... . (9)4. ScriptMate使用说明 ..................................................................... .. (11)4.1. RFC2544测试 ..................................................................... . (13)4.2. RFC2285测试 ..................................................................... . (14)4.2.1. RFC2285测试配置参数一览表 ..................................................................... ...................14 4.3. Advanced Tcl Script Suite(ATSS) ................................................................. .. (17)版权所有侵权必究 All Rights Reserved. Page 2 of 17IXIA网络测试仪操作规程1. IXIA网络测试仪操作规程为加强IXIA测试仪的使用管理，保障设备运行安全，提高设备的完好率和使用率，特制定本规程。
Network Working Group H. Alvestrand Request for Comments: 2157 UNINETT Category: Standards Track January 1998 Mapping between X.400 and RFC-822/MIME Message BodiesStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (1998). All Rights Reserved.Table of Contents1 Introduction (2)1.1 Glossary (3)2 Basic rules for body part conversion (4)2.1 Generating the IPM Body from MIME (5)2.2 Generating the MIME Body from the IPMS.Body (6)2.3 Mapping the EMA FTBP parameters (7)2.3.1 Mapping GraphicStrings (7)2.3.2 Mapping specific parameters (7)2.3.3 Summary of FTBP elements generated (10)2.4 Information that is lost when mapping (11)3 Encapsulation of body parts (11)3.1 Encapsulation of MIME in X.400 (12)3.1.1 FTBP encapsulating body part (12)3.1.2 BP15 encapsulating body part (13)3.1.3 Encapsulation using IA5 (HARPOON) (15)3.1.4 Content passing using BP14 (16)3.2 Encapsulating X.400 Body Parts in MIME (16)3.3 Encapsulating FTBP body parts in MIME (17)4 User control over the gateway choice (18)4.1 Conversion from MIME to X.400 (18)4.2 Conversion from X.400 to MIME (20)5 The equivalence registry (21)5.1 What information one must give about a mapping (21)5.2 Equivalence summary for known X.400 and MIMETypes (22)5.3 MIME to X.400 Table (23)Alvestrand Standards Track [Page 1]5.4 X.400 to MIME Table (23)5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS (24)6 Defined Equivalences (26)6.1 IA5Text - text/plain (26)6.2 GeneralText - text/plain (ISO-8859) (27)6.3 BilaterallyDefined - application/octet-stream (29)6.4 FTBP EMA Unknown Attachment -application/octet-stream (29)6.5 MessageBodyPart - message/RFC822 (30)6.6 MessageBodyPart - multipart/* (31)6.7 Teletex - Text/Plain (Teletex) (32)7 Body parts where encapsulation is recommended (33)7.1 message/external-body (34)7.2 message/partial (35)7.3 multipart/signed (35)7.4 multipart/encrypted (36)8 Conformance requirements (37)9 Security Considerations (38)10 Author’s Address (38)11 Acknowledgements (38)References (38)APPENDIXES (41)Appendix A: Escape code normalization (41)Appendix B: OID Assignments (44)Appendix C: Registration information for theTeletex character set (46)Appendix D: IANA Registration form for newmappings (48)Full Copyright Statement (49)1. IntroductionThis document is a companion to [MIXER], which defines the principles and translation of headers for interworking between MIME-based RFC-822 mail and X.400 mail.This document defines how to map body parts of X.400 messages intoMIME entities and vice versa, including the handling of multipartmessages and forwarded messages.Alvestrand Standards Track [Page 2]1.1. GlossaryThe following terms are defined in this document:Body partPart of a message that has a unique type. This term comes fromX.400; the corresponding term in MIME (RFC 2046) is limited to use in parts of a multipart message; the term "body" may correspondbetter.Content-typeType information indicating what the content of a body partactually is. This term comes from MIME; the corresponding X.400term is "body part type".Mapping(noun): A description of how to transform an X.400 body part into a MIME body part, or how to transform a MIME body part into anX.400 body part.EquivalenceA set of two mappings that taken together provide a losslessconversion between an X.400 body part and a MIME body partEncapsulationThe process of wrapping something from one of the mail systems in such a way that it can be carried inside the other mail system.When encapsulating, it is not expected that the other mail system can make reasonable sense of the body part, but a gateway backinto the first system will always be able to convert the body part without loss back to its original format.HARPOON encapsulationThe encapsulating of a MIME body part by putting it inside an IA5 body with all headers and encoding intact. First described in RFC 1496 [HARPOON].TunnelingWhat happens when one gateway encapsulates a message and sends it to another gateway that decapsulates it. The hope is that thiswill cause minimal damage to the message in transit.DISCUSSIONAt many points in this document, the author has found it useful to include material that explains part of the reasoning behind thespecification. These sections all start with DISCUSSION: andcontinue to the next numbered section heading; they do not dictate any additional requirements on a gateway.Alvestrand Standards Track [Page 3]The words MUST, SHOULD and MAY, when capitalized, are used as defined in RFC 2119 [MUST].2. Basic rules for body part conversionThe basic approach for translating body parts is described in section 2.1 and 2.2.Chapter 3 gives details on "encapsulation", which allows you to becertain that no information is lost even when unknown types areencountered.Chapter 6 gives the core mappings for various body parts.The conformance requirements in chapter 8 describe what the minimumconformance for a MIXER gateway is with respect to body partconversion.DISCUSSION:At the moment both the MIME and the X.400 worlds seem to be in astable state of flux with regards to carrying around stuff that isnot text. In such a situation, there is little chance of defining a mapping between them that is the best for all people, all of thetime. For this reason, this specification allows a gatewayconsiderable latitude in deciding exactly what conversion to apply.The decision taken by the gateway may be based on various information sources:(1) If the gateway knows what body parts or contenttypes the recipient is able to handle, or hasregistered a particular set of preferences for auser, and knows how to convert the messagereasonably to those body parts, the gateway maychoose to convert body parts in the message tothose types only.(2) If the gateway gets indications (via specialheaders or heading-extensions defined for thepurpose) that the sender wanted a particularrepresentation on the "other side", and the gatewayis able to satisfy the request, it may do so. Sucha mechanism is defined in chapter 4 of thisdocument.Alvestrand Standards Track [Page 4](3) If the gateway gets a message that might beappropriate to send as one out of several types,but where the typing information does not tell youwhich one to use (like an X.400 BP14, FTAM "just afile", or MIME application/octet-stream), it mayapply heuristics like looking at content or lookingat filenames to figure out how to deal with themessage.(4) If the gateway knows that the next hop for themessage has limited capabilities (like X.400/84),it may choose to perform conversions appropriatefor that medium.(5) Where no mapping is known by the gateway, itmay choose to drop the body part, reject themessage, or encapsulate the body part asdescribed in chapter 3. The choice may beconfigurable, but a conformant MIXER gateway MUSTbe able to be configured for encapsulation.In many cases, a message that goes SMTP->X.400->SMTP will arrivewithout loss of information.In some cases, the reverse translation may not be possible, or twogateways may choose to apply different translations, based on thecriteria above, leading to an apparently inconsistent service.In addition, service will vary because some gateways will haveimplemented conversions not implemented by other gateways.This is believed to be unavoidable.2.1. Generating the IPM Body from MIMEWhen converting the body of a message from MIME to X.400, thefollowing steps are taken:If the header does not contain a 822.MIME-Version field, thengenerate an IPMS.Body with a single IPMS.BodyPart of typeIPMS.IA5TextBodyPart containing the body of the RFC 822 message with IPMS.IA5TextBodyPart.parameters.repertoire set to the default (IA5). If 822.MIME-Version is present, the body is analyzed as a MIMEmessage and the body is converted according to the mappingsconfigured and implemented in the gateway.Alvestrand Standards Track [Page 5]2.2. Generating the MIME Body from the IPMS.BodyWhen converting the body of a message from X.400 to MIME, thefollowing steps are taken:If there is more than one body part, and the first body part is IA5and starts with the string "RFC-822-Headers:" as the first line,then the remainder of this body part shall be appended to the RFC 822 header. This relies upon the theory that this body part has beengenerated according to Appendix B of MIXER. A gateway shall checkthe consistency and syntax of this body part, to ensure that theresulting message is conformant with RFC 822.If the remaining IPMS.Body consists of a single IPMS.Bodypart, there are three possibilities.(1) If it is of type IPMS.IA5Text, and the first lineis "MIME-Version: 1.0", it is assumed to be aHARPOON-encapsulated body part. The complete bodycontent is then appended to the headers; theseparating blank line is inside the message. If anRFC 822 syntax error is discovered inside themessage, it may be mapped directly as describedbelow instead.(2) If it is of type IPMS.IA5Text, then this is mappeddirectly and the default MIME encoding (7bit) isused, unless very long lines or non-ASCII orcontrol characters are found in the body part, inwhich case Quoted-Printable SHOULD be used.(3) All other types are mapped according to themappings configured and implemented in the gateway.If the IPMS.Body contains multiple IPMS.Bodypart fields, then a MIME message of content type multipart is generated. If all of the bodyparts are messages, then this is multipart/digest. Otherwise it ismultipart/mixed. The components of the multipart are generated inthe same order as in the IPMS.Body.Each component is mapped according to the mappings configured andimplemented in the gateway; any IA5 body parts are checked to see if they are HARPOON mappings, as described above.Alvestrand Standards Track [Page 6]2.3. Mapping the EMA FTBP parametersDISCUSSION:EMA has defined a profile for use of the File Transfer Body Part(FTBP). [MAWG]New mappings are expected to use this as the mechanism for carryingbody parts, and since it is important to have a consistent mappingfor the special FTBP parameters, these are defined here.The mapping of the body will depend on the content-type in MIME andon the application-reference in FTBP, and is not specified here.However, in many cases, we expect that the translation will involvesimply copying the octets from one format to the other; that is, "no conversion".2.3.1. Mapping GraphicStringsSome parameters of the EMA Profile are encoded as ASN.1GraphicStrings, which are troublesome because they can contain anyISO registered graphic character set. To map these to ASCII for use in mail headers, the gateway may either:(1) Use the RFC 2047 [MIME-HDR] encoding mechanism tocreate appropriate encoded-words for the headersinvolved. Note that in some cases, such as withinContent-Disposition filenames, the encoded-wordsmust be in quotes, which is not the normal usage ofencoded-words.(2) Apply the normalization procedure given in AppendixA to identify the ASCII characters of the string,and replace all non-ASCII characters with thequestion mark (?).Both procedures are valid for MIXER gateways; the simplifiedprocedure of ignoring escape sequences and bit-stripping the resultis NOT valid.2.3.2. Mapping specific parametersThe following parameters are mapped in both directions:Content-IDThe mapping of this element is complex.Alvestrand Standards Track [Page 7]The Content-ID is encoded as an IPM.MessageIdentifier and entered into the FTBP.FileTransferParameters.related-stored-file. file-identifier.cross-reference.message-reference.FTBP.FileTransferParameters.related-stored-file.relationship.descriptive-relationship is set to the string"Internet MIME Body Part".FTBP.FileTransferParameters.related-stored-file. file-identifier.cross-reference.application-crossreference is set to a null OCTET STRING.The reverse mapping is only performed if theFTBP.FileTransferParameters.related-stored-file.relationship.descriptive-relationship has the string value"Internet MIME Body Part".Content-DescriptionThe value of this field is mapped to and from the first string in er-visible-string.Content-DispositionThis field is defined in [CDISP]. It has multiple components; the handling of each component is given below.The "disposition" component is ignored on MIME -> X.400 mapping,and is always "attachment" on X.400 -> MIME mapping.C-D: filenameThe filename component of the C-D header is mapped to and fromFileTransferParameters.file-attributes.pathname.The EBNF.disposition-type is ignored when creating the FTBPpathname, and always set to "attachment" when creating theContent-Disposition header. For example:Content-Disposition: attachment; filename=dodo.docorContent-Disposition: attachment; filename=/etc/passwdAlvestrand Standards Track [Page 8]The filename will be carried as a single incomplete-pathnamestring. No special significance is assumed for the characters "/" and "\". Note that normal security precautions MUST be taken inusing a filename on a local file system; this should be obviousfrom the second example.This is done to be conformant with the EMA Profile.C-D: Creation-dateMapped to and from FileTransferParameters.file-attributes.date-and-time-of-creationFor this and all other date fields, the RFC-822 date format isused (822.date-time). Note that the parameter syntax of [CDISP]requires that all dates be quoted!C-D: Modification-dateMapped to and from FileTransferParameters.file-attributes.date-and-time-of-last-modificationC-D: Read-dateMapped to and from FileTransferParameters.file-attributes.date-and-time-of-last-read-accessC-D: SizeMapped to and from FileTransferParameters.file-attributes.object- size. If the value is "no-value-available", the component is NOT generated.Other RFC-822 headersMapped to extension in FTBP.FileTransferParameters.extensionsusing the rfc-822-field HEADING-EXTENSION from [MIXER].NOTE:The set of headers that are mapped will depend on the placement of the body part (single body part or multipart).When it is the only body of a message, headers starting with"content-" SHOULD be put into the FTAM extension, and all otherheaders should be put into the IPMS extension for the message.When it is a single bodypart of a multipart, ALL headers on thebody part are included, since there is nowhere else to put them.Note that only headers that start with "content-" have definedsemantics in this case.Alvestrand Standards Track [Page 9]EMA NOTEThe EMA profile, version 1.5, specifies that handling ofextensions is Optional for reception. This means that some non-MIXER gateways may not implement handling of this field, and some UAs may not have the possibility of showing the content of thisfield to the user.An alternative approach usinger-visible-string wassuggested to EMA, and the EMA MAWG recommended in its April 1996conference that the IETF MIXER group should rather choose thisapproach.2.3.3. Summary of FTBP elements generatedThis is a summary of the preceding section, and does not add newinformation.The following elements of the FTBP parameters are mapped or used (the rightmost column gives their status in the EMA profile; M=Mandatory, O=Optional, R=Recommended for Origination/Receipt): FileTransferParameters M/MRelated-Stored-File O/Ofile-identifiercross-referenceapplication-crossreference NULLmessage-reference Content-IDdescriptive-relationship Used as markercontents-type Must be unstructured-binary M/Menvironment M/Mapplication-reference Selects mapping M/Muser-visible-string Content-description R/Mfile-attributespathname C-D: Filename R/Mdate-and-time-of-creation C-D: Creation-Date O/Odate-and-time-of-last-modification C-D: Modification-Date R/Mdate-and-time-of-last-read-access C-D: Read-Date O/Oobject-size C-D: Size R/Mextensions Other headers O/OAll other elements of the FTBP parameters are discarded.Alvestrand Standards Track [Page 10]NOTE: There is ongoing work on defining a more completemapping between FTBP headers and a set of RFC-822 headers.A gateway MAY choose to support the larger set once it isavailable, but MUST support this limited set.2.4. Information that is lost when mappingMIME defines fields which add information to MIME contents. Two ofthese are "Content-ID", and "Content-Description", which have special rules here, but MIME allows new fields to be defined at any time.The possibilities are limited about what one can do with thisinformation:(1) When using encapsulation, the information can bepreserved(2) When using mapping to FTBP, the information can bepreserved in the FileTransferParameters.extensionsdefined for that purpose.(3) When mapping to a single-body message, theinformation can be preserved as P22 headerextensions(4) When mapping to other body part types, theinformation must be discarded.3. Encapsulation of body partsWhere no mapping is possible, the gateway may choose any of thefollowing alternatives:- Discard the body part, leaving a "marker" saying whathappened- Reject the message- "Encapsulate" the body part, by wrapping it in a bodypart defined for that purpose in the other mailsystemThe choice to be made should be configurable in the gateway, and may depend on both policy and knowledge of the recipient’s capabilities. Alvestrand Standards Track [Page 11]3.1. Encapsulation of MIME in X.400Four body parts are defined here to encapsulate MIME body parts inX.400.This externally-defined body part is backwards compatible with RFC1494. The FTBP body part is compatible with the EMA MAWG document[MAWG], version 1.5, but has some extensions, in particular the onefor extra headers.The imagined scenarios for each body part are:FTBP For use when sending to recipients that can handlegeneric FTBP, and for tunnelling MIME to a MIME UABP15 For use when tunnelling MIME to a MIME UA through anX.400(88) network, or to UAs that have been writtento RFC 1494IA5 For use when tunneling MIME to a MIME UA through anX.400 network, where some of the links may involveX.400(84).BP14 For use when the recipient may be an X.400(84) UAwith BP14 handling capability, and the loss ofinformation in headers is not regarded as important.but the gateway is free to use any method it finds appropriate in any situation.FTBP is expected to be the most useful body part in sending toX.400(92) systems, while the BP14 content passing is primarily useful for sending to X.400(84) systems.3.1.1. FTBP encapsulating body partThis body part utilizes the fundamental assumption in MIME that allmessage content can be legally and completely represented by a single octet stream, the "canonical format".The FTBP encapsulating body part is defined by the application-reference id-mime-ftbp-data; all headers are mapped to the FTBPheaders, including putting the "Content-type:" header inside the FTBP ExtensionsField.Translation from the MIME body part is done by:- Undoing the content-transfer-encodingAlvestrand Standards Track [Page 12]- Setting the "FileTransferData.FTdata.value.octet-aligned" to the resulting string of octets- Putting the appropriate parameters into the headers.Reversing the translation is done by:- Extracting the headers- Applying an appropriate content-transfer-encoding tothe body. If this is for some reason different fromthe content-transfer-encoding: header retrieved fromthe headers, the old one must be deleted.This mapping is lossless, and therefore counts as "no conversion".Note that this mapping does not work with multipart types; themultipart must first be mapped to a ForwardedIPMessage.3.1.2. BP15 encapsulating body partThis section defines an extended body part, based on body part 15,which may be used to hold any MIME content.mime-body-part EXTENDED-BODY-PART-TYPEPARAMETERS MimeParametersIDENTIFIED BY id-mime-bp-parametersDATA OCTET STRING::= id-mime-bp-dataMimeParameters ::=SEQUENCE {content-type IA5String,content-parameters SEQUENCE OFSEQUENCE {parameter IA5String parameter-value IA5String }other-header-fields RFC822FieldList}The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime-bp-data aredefined in Appendix B. A MIME content is mapped onto this body part. The MIME headers of the body part are mapped as follows:RFC822FieldList is defined in Appendix L of [MIXER].Alvestrand Standards Track [Page 13]Content-Type:The "type/subtype" string is mapped toMimeParameters.content-type.For each "parameter=value" string create aMimeParameters.content-parameters element. TheMimeParameters.content-Parameters.parameter field isset to the parameter and the MimeParameters.content-parameters.parameter-value field is set to the value.Quoting is preserved in the parameter-value.OtherTake all other headers and createMimeParameters.other-header-fields.The MIME-version, content-type and content-transfer-encoding fields are NOT copied.NOTE:The set of headers that are mapped will depend on theplacement of the body part (single body part ormultipart).When it is the only body of a message, headersstarting with "content-" SHOULD be put into theother-header-fields, and all other headers should beput into the IPMS extension for the message.When it is a single bodypart of a multipart, ALLheaders on the body part are included, since there isnowhere else to put them. Note that only headers thatstart with "content-" have defined semantics in thiscase.The body is mapped as follows:Convert the MIME body part into its canonical form, as specified inAppendix H of MIME [MIME]. This canonical form is used to generatethe mime-body-part.data octet string.The Parameter mapping may be used independently of the body partmapping (e.g., in order to use a different encoding for a mapped MIME body part).This body part contains all of the MIME information, and so can bemapped back to MIME without loss of information.The OID id-mime-bp-data is added to the Encoded Information Types of the envelope.Alvestrand Standards Track [Page 14]This body part is completely compatible with RFC 1494.When converting back to a MIME body part, the gateway is responsiblefor:(1) Selecting an appropriate content-transfer-encoding,and deleting any content-transfer-encoding headerfrom the other-header-fields(2) Adding quotes to any parameters that need them (butnot adding quotes to parameters that are alreadyquoted)(3) Removing any content-type field that is left in theRFC822FieldList of the message that is redundant orconflicting with the one from the mime-body-part(4) Make sure that on multipart messages, the boundarystring actually used is reflected in the boundary-parameter of the content-type header, and does notoccur within the body of the message.3.1.3. Encapsulation using IA5 (HARPOON)This approach is the one taken in RFC 1496 - HARPOON - for tunnelingany MIME body part through X.400/84 networks. It has proven ratherunhelpful for bringing information to X.400 users, but preserves allthe information of a MIME body part.The following IA5Text body part is made:- Content = IA5String- First bytes of content: (the description is in USASCII, with C escape sequences used to representcontrol characters):MIME-version: <version>\r\nContent-type: <the proper MIME content type>\r\nContent-transfer-encoding: <7bit, quoted-printable or base64>\r\n <Possibly other Content headings here, terminated by\r\n>\r\n<Here follows the bytes of the content, encodedin the proper encoding>All implementations MUST place the MIME-version: header first in thebody part. Headers that are placed by [MIXER] into other parts of the message MUST NOT be placed in the MIME body part.Alvestrand Standards Track [Page 15]This encapsulation may also be applied to subtypes of multipart,creating a single IA5 body part that contains a single multipart/*,which in turn may contain multiple MIME body parts.3.1.4. Content passing using BP14This is described in this section because it is at the sameconceptual level as encapsulation. It is a lossy transformation; itis impossible to reconstruct the MIME type information from it.Nevertheless, there is a demand for such functionality.This "encapsulation" simply strips off all headers, undoes thecontent-transfer-encoding, and creates a BilaterallyDefined body part (BP14) from the resulting octet stream.No reverse translation is defined; when a BP14 arrives at a MIXERgateway, it will be turned into an application/octet-stream according to chap. 6.33.2. Encapsulating X.400 Body Parts in MIMEThis section specifies a generic mechanism to map X.400 body parts to a MIME content. This allows for the body part to be tunneled through MIME. It may also be used directly by an appropriately configuredMIME UA.This content-type is defined to carry any X.400 extended body part.The mapping of all standard X.400 body parts is defined in thisdocument. The content-type field is "application/x400-bp". Theparameter is defined by the EBNF:mime-parameter = "bp-type=" ( object-identifier / 1*DIGIT=If the body is a basic body part, the bp-type parameter is set to the number of the body part’s context-specific tag, that is, the tag ofthe IPMS.Body.BodyPart component.If the body is an Extended Body Part, the EBNF.object-dentifier isset to the OBJECT IDENTIFIER from IPMS.body.externally-defined.data.direct-reference.For example, a basic VideotexBodyPart will haveContent-type=application/x400-bp; bp-type=6whilst a Extended Videotex body part will haveAlvestrand Standards Track [Page 16]Content-type=application/x400-bp; bp-type=2.6.1.4.5The body contains the raw ASN.1 IPM body octet stream, that is, theBER encoding of the IPM.Body.BodyPart, including the initial tagoctet. The content may use a content-transfer-encoding of eitherbase64 or quoted-printable when carried in 7-bit MIME. It isrecommended to use the one which gives the more compact encoding ofthe data. If this cannot be determined, Base64 is recommended. Noattempt is made to turn the parameters of Extended Body Parts intoMIME parameters, as this cannot be done in a general manner.For extended body parts, the3.3. Encapsulating FTBP body parts in MIMEThe File Transfer Body Part is believed to be important in the future as "the" means of carrying well-identified data in X.400 networks.They also share the property (at lest when limited to the EMA MAWGfunctional profile) of having a well-defined data part that is always representable as a sequence of bytes.This conversion will have to fail, and the x400-bp encapsulation used instead, if:- FileTransferData has more than one element- Contents-type is not unstructured-binary- Parameters that are not mappable, but important, arepresent (like Compression, which EMA doesn’trecommend).Otherwise, it can be encapsulated in MIME by:- Creating the "content-type" value by forming thestring "application/x-ftbp." and appending thenumbers of the OID found inFileTransferParameters.environment.application-reference.registered-identifier- Mapping all other parameters according to thestandard FTBP parameter mapping- Applying an appropriate content-transfer-encoding tothe data contained in FileTransferData.value.encodingAlvestrand Standards Track [Page 17]。
