栏目搜索
 
 
 
 
你的位置:首页 > 协议大全 > RFC4102 - Registration of the text/red MIME Sub-Type >
 

RFC4102 - Registration of the text/red MIME Sub-Type

发布者:[本站编辑] | 来源:[]

RFC4102 - Registration of the text/red MIME Sub-Type_电脑维修资料库

network working group p. jonesrequest for comments: 4102 cisco systems, inc.category: standards track june 2005registration of the text/red mime sub-typestatus of this memothis document specifies an internet standards track protocol for theinternet 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 (2005).abstractthis document defines the text/red mime sub-type. red is short forredundant. the actual rtp packetization for this mime type isspecified in rfc 2198.1. introductiontext is an important component of any multimedia communicationsystem. like audio, the transport of text can benefit from the useof redundancy in order to improve reliability and end-userexperience.rfc 2198 <1> defines an rtp <2> payload format for redundant audiodata. the format defined in that document is quite suitable forproviding redundancy for text, as well as audio.rfc 4103 <8> specifies one usage of rfc 2198 and the text/red mimetype for the transport of redundant text data.this memo provides the mime sub-type registration information fortext/red. while this document focuses on the use of this mime sub-type in sdp <5>, the application of this mime sub-type is notrestricted to sdp.2. conventions used in this documentthe key words must, must not, required, shall, shall not,should, should not, recommended, may, and optional in thisdocument are to be interpreted as described in rfc 2119 <3>.3. iana considerationsone new mime sub-type has been registered by the iana, as describedbelow:mime media type name: textmime subtype name: redrequired parameters:rate: the rtp clock rate of the payload carried within the rtppacket. typically, this rate is 1000, but other rates may bespecified. this parameter must be set equal to the clock rate ofthe text payload format carried as the primary encoding.pt: a comma-separated ordered list of rtp payload typesenumerating the primary, secondary, etc., in accordance with rfc2198. because comma is a special character, the list must be aquoted-string (enclosed in double quotes). for static payloadtypes, each list element is simply the type number. for dynamicpayload types, each list element is a mapping of the dynamicpayload type number to an embedded mime content-type specificationfor the payload format corresponding to the dynamic payload type.the format of the mapping is:dynamic-payload-type = content-typeif the content-type string includes a comma, then the content-type string must be a quoted-string. if the content-type stringdoes not include a comma, it may still be quoted. because it ispart of the list, which must itself be a quoted-string, thequotation marks must be quoted with backslash quoting as specifiedin rfc 2045 <4>. if the content-type string itself contains aquoted-string, then the requirement for backslash quoting isrecursively applied.optional parameters: ptime, maxptime (these attributes are originallydefined in rfc 2327 <5> and rfc 3267 <6>, respectively)restrictions on usage:this type is defined only for transfer via rtp.it shall not be defined for a storage format.encoding considerations:see restrictions on usage above; this section is included perthe requirements in rfc 3555 <7>.security considerations: refer to section 5 of rfc 4102.interoperability considerations: nonepublished specification: rfc 2198applications which use this media type:text streaming and conferencing tools.additional information: noneperson & email address to contact for further information:paul e. jonese-mail: paulej@packetizer.comintended usage: commonauthor:paul e. jonespaulej@packetizer.comchange controller:avt working group delegated from the iesg4. mapping to sdp parametersthe information carried in the mime media type specification has aspecific mapping to fields in the session description protocol (sdp)<5>, which is commonly used to describe rtp sessions. when sdp isused to specify sessions employing the rfc 2198 in a text session,the mapping is as follows:- the mime type (text) goes in sdp m= as the media name.- the value of the parameter rate goes in sdp a=rtpmap.- the mime subtype (red) goes in sdp a=rtpmap as the encodingname.- the parameters ptime and maxptime go in the sdp a=ptime anda=maxptime attributes, respectively.- the pt parameter is mapped to an a=fmtp attribute by eliminatingthe parameter name (pt) and changing the commas to slashes. forexample, 'pt=101,102' maps to 'a=fmtp:99 101/102', where = '99'is the payload type of the redundancy frames. note that thesingle quote marks (') used in this example are not present in theactual message encoding, but are present here only forreadability. the level of redundancy is shown by the number ofelements in the payload type list.any dynamic payload type in the list must be represented by itspayload type number and not by its content-type. the mapping ofpayload types to the content-type is done using the normal sdpprocedures with a=rtpmap.an example of sdp is:m=text 11000 rtp/avp 98 100a=rtpmap:98 t140/1000a=rtpmap:100 red/1000a=fmtp:100 98/98for each redundancy payload type defined, the ordering of the primaryand redundancy encoding(s) is fixed. if more than one combination ofprimary and redundancy encoding(s) is desired, multiple redundancypayload types needs to be defined.5. security considerationsthe security considerations listed in rfc 2198 apply. further, itshould be understood that text data, perhaps even more so than audiodata, is susceptible to unwanted modification that may lead toundesired results. to prevent modification of the primary,secondary, or header information, payload integrity protection overat least the complete rtp packet is recommended, for example usingsrtp <9>.6. normative references<1> perkins, c., kouvelas, i., hodson, o., hardman, v., handley, m.,bolot, j., vega-garcia, a., and s. fosse-parisis, rtp payloadfor redundant audio data, rfc 2198, september 1997.<2> schulzrinne, h., casner, s., frederick, r., and v. jacobson,rtp: a transport protocol for real-time applications, std 64,rfc 3550, july 2003.<3> bradner, s., key words for use in rfcs to indicate requirementlevels, bcp 14, rfc 2119, march 1997.<4> freed, n. and n. borenstein, multipurpose internet mailextensions (mime) part one: format of internet message bodies,rfc 2045, november 1996.<5> handley, m., jackson, v., sdp: session description protocol,rfc 2327, april 1998.<6> sjoberg, j., westerlund, m., lakaniemi, a., and q. xie, real-time transport protocol (rtp) payload format and file storageformat for the adaptive multi-rate (amr) and adaptive multi-ratewideband (amr-wb) audio codecs, rfc 3267, june 2002.<7> casner, s. and p. hoschka, mime type registration of rtp payloadformats, rfc 3555, july 2003.7. informative references<8> hellstrom, g. and p. jones, rtp payload for text conversation,rfc 4103, june 2005.<9> baugher, m., mcgrew, d., naslund, m., carrara, e., and k.norrman, the secure real-time transport protocol (srtp), rfc3711, march 2004.author's addresspaul e. jonescisco systems, inc.7025 kit creek rd.research triangle park, nc 27709, usaphone: +1 919 392 6948email: paulej@packetizer.comfull copyright statementcopyright (c) the internet society (2005).this document is subject to the rights, licenses and restrictionscontained in bcp 78, and except as set forth therein, the authorsretain all their rights.this document and the information contained herein are provided on anas is basis and the contributor, the organization he/she representsor is sponsored by (if any), the internet society and the internetengineering task force disclaim all warranties, express or implied,including but not limited to any warranty that the use of theinformation herein will not infringe any rights or any impliedwarranties of merchantability or fitness for a particular purpose.intellectual propertythe ietf takes no position regarding the validity or scope of anyintellectual property rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. informationon the procedures with respect to rights in rfc documents can befound in bcp 78 and bcp 79.copies of ipr disclosures made to the ietf secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the ietf on-line ipr repository athttp://www.ietf.org/ipr.the ietf invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. please address the information to the ietf at ietf-ipr@ietf.org.acknowledgementfunding for the rfc editor function is currently provided by theinternet society.</t

 
 
  推荐文章
 
     暂无
 
 
  随机资讯
 
     暂无