rfc1738.txt

很多RFC的中文文档

0D(US-ASCII 字符CR)外的所有八位字节。
Gopher客户通过向Gopher服务器发送Gopher选择器字符串来指定要获得的项。
<gopher-path>中没有保留字符。
需要注意的是：有些Gopher<selector>字符串是以<gophertype>字符的一个拷贝来开头，
在这种情况下，这个字符将会连续出现两次。Gopher选择器可能是空字符串；Gopher客
户端就是这样来查询Gopher服务器的高层目录的。
3．4．2为Gopher搜索引擎指定URL
如果URL被提交到Gopher搜索引擎进行查询，那么选择器后将紧跟一个已编码的tab
（%09）和一个搜索字符串。Gopher客户为了向Gopher搜索服务器提交一个搜索必须向
Gopher服务器发送<selector>字符串（编码后），一个tab字符，和一个搜索字符串。
3．4．3Gopher+项的URL语法
Gopher+项的URL有一个已编码的tab字符（%09）和一个Gopher+字符串。注意尽管
<search>元素可以是空字符串，但在这种情况下必须提供%09<search>字符串。
<gopher+_string>被用来表示取得Gopher+项所需要的信息。Gopher+项可以拥有交替视
图，任意的属性系，也可以有与它们相关联的电子表格。
客户为了获得与Gopher+URL相关联的数据，必须连接到服务器并且发送Gopher选择器，
这个选择器的后面紧跟一个tab字符和搜索字符串（可以为空）然后是一个tab字符和
Gopher+命令。
3．4．4 缺省的Gopher+数据表示
当一个Gopher服务器向客户返回目录列表时，Gopher+项后面跟着一个“+”（表示
Gopher+项）或者一个“?”（表示具有与它们相关联的+ASK形式的Gopher+项）。Gopher+
字符串只有一个字符“+”的Gopher URL采用项的缺省的视图（数据表示），而Gopher+
字符串只有一个字符“?”的Gopher URL则采用具有相关联的Gopher电子表格的项。
3．4．5 具有电子表格的Gopher+项
具有与之相关联的+ASK的Gopher+项（也就是跟着一个“?”的Gopher+项）要求客户端
取得该项的+ASK属性来获得表格定义，然后让用户填写这个表格并将用户应答和获得项
的选择器字符串一起返回。Gopher+客户端知道如何完成这些工作，但需要依赖于Gopher+
项描述中的“？”标签来知道什么时候处理这种情况。Gopher+项中的“?”被用来与Gopher+
协议中这种符号的用法相兼容。
3．4．6 Gopher+项属性集
为了表示项的Gopher+属性，Gopher URL的Gopher+字符串由“!”或者“$”组成。“!”
涉及Gopher+项的所有属性。“$”则涉及Gopher目录中所有项的所有项属性。
3．4．7涉及特定的Gopher+属性
为了表示特殊的属性，URL的gopher+_string是“!<attribute_name>”或者
“$<attribute_name>”。例如，gopher+_string的值为“!+ABSTRACT” 表示属性包含
一个项的抽象。
为了表示几个属性，gopher+_string可以由几个属性名组成，并且用已编码的空格分隔
开。例如，“!+ABSTRACT%20+SMELL”代表一个项的+ABSTRACT和+SMELL属性。

3．4．8 Gopher+交替视图的URL语法
Gopher+允许项有优化的交替数据表示(交替视图)。Gopher+客户端发送适当的视图和语
言标志（出现在项的+VIEW属性里）来获得Gopher+的交替视图。为了引用一个特定的
Gopher+交替视图试图，URL的Gopher+字符串的形式必须如下所示：
+<视图名称>%20<语言名称>
例如，Gopher+字符串"+application/postscript%20Es_ES"引用了一个Gopher+项的交
替视图的西班牙语附注。
3．4．9 Gopher+电子表格的URL语法
一个引用了填充有特定数据的Gopher+电子表格（一个ASK块）所参考的项的URL的
Gopher+字符串是通过对客户送给服务器的gopher+字符串进行编码得到的。这个gopher+
字符串的形式如下所示：
+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A
Gopher客户端为了获得这个项，它发送如下信息给Gopher服务器：
       <a_gopher_selector><tab>+<tab>1<cr><lf>
       +-1<cr><lf>
       <ask_item1_value><cr><lf>
       <ask_item2_value><cr><lf>
       .<cr><lf>
3．5 MAILTO
mailto URL方案是用来指明一个个体或者服务的因特网邮件地址的。它只代表因特网邮
件地址，而不表示任何其它的附加信息。
Mailto URL的形式如下所示：
mailto:<rfc822-addr-spec>
这里的<rfc822-addr-spec>是地址说明（的编码），这在RFC822[6]中进行了详细的说明。
在mailto URL中没有保留字。

注意百分符号（"%"）在RFC822中用得比较普遍，它必须被编码。

不像许多URL，mailto方案不代表可直接访问的数据对象；也没有迹象表面它代表一个
对象。它的使用方法不同于MIME中的报文/外部实体类型。
3．6 NEWS（新闻）
新闻URL方案被用来查阅新闻组或者USENET新闻上的独立文章，这一点在RFC1036中详
细说明了。

新闻URL的形式是下面两个之一：
news:<newsgroup-name>
news:<message-id>
<newsgroup-name>是一个用句点分隔的层次名称，例如：
“comp.infosystems.www.misc”。<message-id>与RFC1036中的2.1.5节中的
Message-ID一样，只是后者没有用“<”和“>”括起来；它的形式如下
<unique>@<full_domain_name>。消息标志符通过代表“在（at）”的“@”字符和新闻组
名称相区分。除此之外，在新闻URL组件中没有其它的保留字符。

如果<newsgroup-name>是“*”（例如：<URL:news:*>），那么它表示“所有可用的新闻组”。

新闻URL是不同寻常的，因为它们自身不包含足够的信息来定位一个单一资源，但是它
们的位置是任意的。

3．7 NNTP（Network News Transfer Protocol,网络新闻传
输协议）

网络新闻传输协议URL方案是引用新闻文章的另一个方法，这个方案在用来从NNTP服务
器指定新闻文章时是非常有用的（RFC977）。

网络新闻传输协议URL的形式如下：
nntp://<host>:<port>/<newsgroup-name>/<article-number>

这里的<host>和<port>在3.1节进行了阐述。如果省略:<port>，那么端口缺省为119。

<newsgroup-name>是组名，<article-number>是新闻组中文章的数字编号。

注意nntp:URL指定了文章资源的一个唯一的位置，大多数因特网上的NNTP服务器目前
进行的配置只允许本地客户端访问，因此nntp URL并不代表全球可访问的资源。这样URL
的news:形式成为标志新闻文章的首选方法。
3．8 TELNET
远程登录URL方案被用来指明交互式服务，这种服务可以通过Telnet协议来进行访问。

telnet URL的形式如下：
telnet://<user>:<password>@<host>:<port>/

向3.1节所讲的那样，最后面的“/”字符可以被省略。如果:<port>被省略，那么端口
缺省为23。:<password>也可以被省略，<user>:<password>部分也可以整个被省略。

这个URL并不指定一个数据对象，而是指定一个交互式的服务。远程交互式服务在允许
远程登录的方法上差别很大。实际上，提供的<user>和<password>仅供参考：正在访问
一个telnet URL的客户端仅仅建议所暗示的用户名和密码的用户。

3．9 WAIS（Wide Area Information Servers,广域信息服
务系统）
WAIS URL 方案用来指示WAIS数据库，搜索或者WAIS数据库中可用的单个文档。WAIS
在[7]中进行了描述。RFC1625[17]对WAIS协议进行了阐述。虽然WAIS协议是基于
Z39.50-1988的，但 WAIS URL方案并不是特意用来和任意的Z39.50服务一起使用的。

WAIS URL有如下几个形式：

 wais://<host>:<port>/<database>
     wais://<host>:<port>/<database>?<search>
     wais://<host>:<port>/<database>/<wtype>/<wpath>

这里的<host>和<port>在3.1节阐述过了。如果省略了:<port>，那么端口缺省为210。
第一种形式指定了一个可以用来搜索的WAIS服务器。第二种形式表明了一个特定的搜索。
<database>是被查询的WAIS数据库名。

第三种形式表明了WAIS数据中的一个要获取的特定文档。在这种形式中<wtype>是对象
类型的WAIS表示。许多WAIS实现需要一个在取得信息之间就能够认识对象“类型”的
客户端，这个类型和搜索响应中的内部对象标志符一起返回。<wtype>包含在URL中，这
是为了让客户端能理解URL的足够信息来取得文档。

WAIS URL的<wpath>由WAIS文档标志组成，这个文档标志使用了2.2节所叙述的方法进
行编码。WAIS 文档标志在处理时应该是不透明的；它仅可以被发布它的服务器分解。

3．10 FILES(文件)
文件URL方案被用来指定那些特定主机上的可访问的文件。这个方案和其它大多数方案
不一样，因为它并不表示一个在因特网上普遍可访问的资源。

文件URL的形式如下：
file://<host>/<path>
这里的<host>是系统域名的全称，在这个系统中<path>是可访问的，它是形如
<directory>/<directory>/.../<name>的层次目录。

例如，一个VMS文件：
DISK$USER:[MY.NOTES]NOTE123456.TXT
的形式如下：
<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

有一种特殊情况，就是<host>可以是字符串“localhost”或者空字符串；它被解释为解
释这个URL的主机。

文件URL方案是与众不同的，因为它不指定一个因特网协议或者访问这些文件的方法；
这样它在主机间网络协议上的效用是有限的。

3．11 PROSPERO

Prospero URL方案是用来指定那些可以通过Prospero目录服务访问的资源。Prospero
协议在其它地方介绍了[14]。
Prospero URL的形式如下：
prospero://<host>:<port>/<hsoname>;<field>=<value>
这里<host>和<port>和3.1节介绍的一样。如果省略了:<port>，那么端口缺省为1525。
这里不需要用户名和密码。

<hsoname>是Prospero协议中特定主机的对象名称，它需要被编码。这个名称是不透明
的，它是由Prospero服务器解释。分号“;”是保留字符，它不能不经过引用就出现在
<hsoname>中.

Prospero URL是通过联系特定主机和端口上的Prospero目录服务器来解释的，然后用来
决定访问资源的合适的方法，这些资源自身可能被表示成不同的URL。外部的Prospero
链接被表示成采用底层访问方法的URL，而不是表示成Prospero URL。

注意斜线“/”可以不经过引用就出现在<hsoname>中，应用程序假定它不代表任何意义。
尽管斜线在服务器上可以用来表示层次结构，但是这些结构并不被承认。注意许多
<hsoname>是由斜线开头，在这种情况下，主机或者端口之后将紧跟一个双斜线：前面是
URL语法的斜线，后面是<hsoname>的开始斜线。（举例来说：
<URL:prospero://host.dom//pros/name>表示<hsoname>为“/pros/name”）。

另外，与Prospero链接相关联的任意的字段和值都可以成为URL中<hsoname>之后的一
个部分。在这种情况下，每个“字段/值”组合对都用一个“;”（分号）相互以及与URL
的其它部分分隔开。字段名称和它的值用一个“＝”（等号）分隔开。如果出现这种情况，
这些域将用来标志URL的目标。例如，OBJECT-VERSION域可以被用来标志对象的特定版
本。

4． 新方案的注册
可以通过定义一个到相应URL语法的映射和使用一个新的前缀来引入一个新的方案。URL
试验方案可以通过团体间的共同协议来使用。用字符“x-”开头的方案名称是保留给试验
方案用的。

国际数字分配权威（IANA，Internet Assigned Numbers Authority）将管理URL方案的
注册。任何提交的新URL方案都必须包含一个访问该方案中资源的法则的定义还必须包
含描述这个方案的语法。

URL方案必须具有可论证的实用性和可操作性。提供这样一个示范的方法就是借助一个为
使用已有协议的客户端提供新方案中的对象的网关。如果新方案不能够定位一个数据对象
资源，那么这个新领域中的名称的属性必须要进行清晰的定义。

新方案应该在适当的地方努力遵从与已有方案相同的语法规则。对于可以用URL访问的
协议的地方也是同样的。客户端软件被规定配置成使用特定网关定位符来通过新的命名方
案间接访问。

下面的方案已经多次被提议，但这个文档没有定义它自己的语法。它建议IANA保留它们
的方案名以备将来定义：
afs   Andrew 文件系统全局文件名（Andrew File System global file         names）。
   mid   		电子邮件报文标志（Message identifiers for electronic mail）.
   cid    		MIME主体部分的内容标志符（ Content identifiers for MIME body 
parts）.
   nfs   	 	网络文件系统（NFS）文件名（Network File System file names）.
   tn3270	 	交互式3270竞争会话(Interactive 3270 emulation sessions).
   mailserver   访问邮件服务器上的有效数据（Access to data available from mail 
servers）.
   z39.50       访问ANSI Z39.50服务(Access to ANSI Z39.50 services).

5．特定URL方案的BNF（巴柯斯范式）
这是统一资源定位器语法的类BNF描述，它使用了RFC822中的约定，除了用“|”表示
选择，用方括号[]将可选或者重复的元素括起来之外。简单地说就是文字用引号""引起
来，可选元素放在方括号[]内，元素可以用<n>*来开头表明有n个或者更多个此元素；n
缺省为0。

;URL的一般形式如下：
genericurl     = scheme ":" schemepart

;特定的预定义方案在这里进行定义；新方案可以在IANA那儿注册
url            = httpurl | ftpurl | newsurl |
                 nntpurl | telneturl | gopherurl |
                 waisurl | mailtourl | fileurl |
                 prosperourl | otherurl
;新方案遵从一般语法
otherurl       = genericurl
;方案都是小写的；解释程序应该忽略大小写
scheme         = 1*[ lowalpha | digit | "+" | "-" | "." ]
schemepart     = *xchar | ip-schemepart
;基于协议的ip的URL方案部分：
ip-schemepart  = "//" login [ "/" urlpath ]

login          = [ user [ ":" password ] "@" ] hostport
hostport       = host [ ":" port ]
host           = hostname | hostnumber
hostname       = *[ domainlabel "." ] toplabel
domainlabel    = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel       = alpha | alpha *[ alphadigit | "-" ] alphadigit
alphadigit     = alpha | digit
hostnumber     = digits "." digits "." digits "." digits
port           = digits
user           = *[ uchar | ";" | "?" | "&" | "=" ]
password       = *[ uchar | ";" | "?" | "&" | "=" ]
urlpath        = *xchar    ;建立在3.1节的协议基础上
;预定义方案：
;FTP(文件传输协议，请参考RFC959)
ftpurl         = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]