分享
 
 
 

RFC2017 - Definition of the URL MIME External-Body Access-Type

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group N. Freed

Request for Comments: 2017 Innosoft International

Category: Standards Track K. Moore

University of Tennessee

A. Cargille, WG Chair

October 1996

Definition of the URL

MIME External-Body Access-Type

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

1. Abstract

This memo defines a new access-type for message/external-body MIME

parts for Uniform Resource Locators (URLs). URLs provide schemes to

access external objects via a growing number of protocols, including

HTTP, Gopher, and TELNET. An initial set of URL schemes are defined

in RFC1738.

2. IntrodUCtion

The Multipurpose Internet Message Extensions (MIME) define a facility

whereby an object can contain a reference or pointer to some form of

data rather than the actual data itself. This facility is embodied in

the message/external-body media type defined in RFC1521. Use of

this facility is growing as a means of conserving bandwidth when

large objects are sent to large mailing lists.

Each message/external-body reference must specify a mechanism whereby

the actual data can be retrieved. These mechanisms are called access

types, and RFC1521 defines an initial set of access types: "FTP",

"ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER".

Uniform Resource Locators, or URLs, also provide a means by which

remote data can be retrieved automatically. Each URL string begins

with a scheme specification, which in turn specifies how the

remaining string is to be used in conjunction with some protocol to

retrieve the data. However, URL schemes exist for protocol operations

that have no corresponding MIME message/external-body access type.

Registering an access type for URLs therefore provides

message/external-body with access to the retrieval mechanisms of URLs

that are not currently available as access types. It also provides

access to any future mechanisms for which URL schemes are developed.

This access type is only intended for use with URLs that actually

retreive something. Other URL mechansisms, e.g. mailto, may not be

used in this context.

3. Definition of the URL Access-Type

The URL access-type is defined as follows:

(1) The name of the access-type is URL.

(2) A new message/external-body content-type parameter is

used to actually store the URL string. The name of the

parameter is also "URL", and this parameter is

mandatory for this access-type. The syntax and use of

this parameter is specified in the next section.

(3) The phantom body area of the message/external-body is

not used and should be left blank.

For example, the following message illustrates how the URL access-

type is used:

Content-type: message/external-body; access-type=URL;

URL="http://www.foo.com/file"

Content-type: text/Html

Content-Transfer-Encoding: binary

THIS IS NOT REALLY THE BODY!

3.1. Syntax and Use of the URL parameter

Using the ANBF notations and definitions of RFC822 and RFC1521, the

syntax of the URL parameter Is as follows:

URL-parameter := <"> URL-Word *(*LWSP-char URL-word) <">

URL-word := token

; Must not exceed 40 characters in length

The syntax of an actual URL string is given in RFC1738. URL strings

can be of any length and can contain arbitrary character content.

This presents problems when URLs are embedded in MIME body part

headers that are wrapped according to RFC822 rules. For this reason

they are transformed into a URL-parameter for inclusion in a

message/external-body content-type specification as follows:

(1) A check is made to make sure that all occurrences of

SPACE, CTLs, double quotes, backslashes, and 8-bit

characters in the URL string are already encoded using

the URL encoding scheme specified in RFC1738. Any

unencoded occurrences of these characters must be

encoded. Note that the result of this operation is

nothing more than a different representation of the

original URL.

(2) The resulting URL string is broken up into substrings

of 40 characters or less.

(3) Each substring is placed in a URL-parameter string as a

URL-word, separated by one or more spaces. Note that

the enclosing quotes are always required since all URLs

contain one or more colons, and colons are tspecial

characters [RFC1521].

Extraction of the URL string from the URL-parameter is even simpler:

The enclosing quotes and any linear whitespace are removed and the

remaining material is the URL string.

The following example shows how a long URL is handled:

Content-type: message/external-body; access-type=URL;

URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/

8/9/10/11/12/13/14/15/16/17/18/20/21/

file.html"

Content-type: text/html

Content-Transfer-Encoding: binary

THIS IS NOT REALLY THE BODY!

Some URLs may provide access to multiple versions of the same object

in different formats. The HTTP URL mechanism has this capability, for

example. However, applications may not eXPect to receive something

whose type doesn't agree with that expressed in the

message/external-body, and may in fact have already made irrevocable

choices based on this information.

Due to these considerations, the following restriction is imposed:

When URLs are used in the context of an access-type only those

versions of an object whose content-type agrees with that specified

by the inner message/external-body header can be retrieved and used.

4. Security Considerations

The security considerations of using URLs in the context of a MIME

access-type are no different from the concerns that arise from their

use in other contexts. The specific security considerations

associated with each type of URL are discussed in the URL's defining

document.

Note that the Content-MD5 field can be used in conjunction with any

message/external-body access-type to provide an integrity check. This

insures that the referenced object really is what the message

originator intended it to be. This is not a signature service and

should not be confused with one, but nevetheless is quite useful in

many situations.

5. Acknowledgements

The authors are grateful for the feedback and review provided by John

Beck and John Klensin.

6. References

[RFC-822]

Crocker, D., "Standard for the Format of ARPA Internet

Text Messages", STD 11, RFC822, UDEL, August 1982.

[RFC-1521]

Borenstein, N. and N. Freed, "MIME (Multipurpose

Internet Mail Extensions): Mechanisms for Specifying and

Describing the Format of Internet Message Bodies", RFC

1521, Bellcore, Innosoft, September, 1993.

[RFC-1590]

Postel, J., "Media Type Registration Procedure", RFC

1590, USC/Information Sciences Institute, March 1994.

[RFC-1738]

Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform

Resource Locators (URL)", December 1994.

7. Authors' Addresses

Ned Freed

Innosoft International, Inc.

1050 East Garvey Avenue South

West Covina, CA 91790

USA

Phone: +1 818 919 3600

Fax: +1 818 919 3614

EMail: ned@innosoft.com

Keith Moore

Computer Science Dept.

University of Tennessee

107 Ayres Hall

Knoxville, TN 37996-1301

USA

EMail: moore@cs.utk.edu

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有