XEP0096Word文档下载推荐.docx
- 文档编号:18440935
- 上传时间:2022-12-16
- 格式:DOCX
- 页数:13
- 大小:22.92KB
XEP0096Word文档下载推荐.docx
《XEP0096Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《XEP0096Word文档下载推荐.docx(13页珍藏版)》请在冰豆网上搜索。
Wiki页:
//wiki.jabber.org/index.php/FileTransfer(XEP-0096)>
作者信息
ThomasMuldowney
Email:
temas@jabber.org
JabberID:
[xmpp:
temas@jabber.orgtemas@jabber.org]
MatthewMiller
linuxwolf@outer-
linuxwolf@outer-linuxwolf@outer-]
RyanEatmon
reatmon@jabber.org
reatmon@jabber.orgreatmon@jabber.org]
法律通告
版权
XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.
权限
特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可,被重新分发的修改工作,不得含有关于作者,标题,编号,或出版者的规格的误导性资料,并不得宣称修改工作是由本文的作者,作者所属的任何组织或项目,或XMPP标准基金会签注。
免责声明
注意:
本协议是提供的“原样”的基础,没有担保或任何形式的条件,明示或暗示,包括,但不限于任何担保或关于名称,非侵权性,适销性或适合作某一特定目的的条件.在任何情况XMPP标准基金会或作者不对此协议承担任何责任索赔,损害赔偿,或其他责任,无论是在一项行动的合同,侵权,或否则,所产生的,运出,或在他涉嫌与规格或执行,部署或以其它方式使用本协议.##
责任限制
在任何情况下以及没有任何法律规定时,不论是侵权行为(包括疏忽),合同或其它方面,除非根据适用法律的要求(如蓄意和有严重疏忽行为)或同意以书面形式,XMPP标准基金会或任何作者不对本协议承担所造成的损失,包括任何直接,间接,特殊,偶发,或相应的损害赔偿的任何字符利用所产生的或不能使用的规格(包括但不限于善意的损失,停止作业,电脑失灵或故障,或任何和所有其他商业损害或损失),即使XMPP标准基金会或作者已被告知此类损害的可能性。
知识产权的一致性
XMPP扩展协议完全遵守XSF的知识产权策略(可在<
//www.xmpp.org/extensions/ipr-policy.shtml>
找到副本或写信给XSF,P.O.Box1641,Denver,CO80201USA).
讨论地点
首选的讨论的地方是标准讨论邮件列表:
//mail.jabber.org/mailman/listinfo/standards>
.
勘误表发送到editor@xmpp.org
XMPP相关信息
XMPP是由XSF(XMPP标准化基金会)按互联网标准程序贡献的,和IETF的RFC2026兼容的规范,包括XMPP核心(RFC3920)和XMPPIM(RFC3921).在本文中定义的任何协议,都是在互联网标准程序之外开发的,是扩展XMPP,而不是改变、发展和修改XMPP本身。
一致性术语
本文中以下关键词的含义如RFC2119所述:
"
MUST"
"
SHALL"
REQUIRED"
;
MUSTNOT"
SHALLNOT"
SHOULD"
RECOMMENDED"
SHOULDNOT"
NOTRECOMMENDED"
MAY"
OPTIONAL"
目录
[隐藏]
∙1绪论
∙2要求
∙3协议
o3.1强制实现的技术
∙4例子
∙5IANA事项
∙6XMPP注册事项
o6.1流初始化情况
o6.2URI查询类型
▪6.2.1发送文件
▪6.2.2接收文件
∙7XMLSchema
∙8备注
∙9修订历史
绪论
在Jabber社区,传统的文件传输的方法是Out-of-BandData带外传输协议。
该协议有一些缺点:
1.它是不可靠的
2.当有一方在防火墙后面的话,该协议无效
3.对要交换的文件有元数据的限制。
本文档定义了一个流启动的流程用于解决带外传输的问题,并提供了一种健壮的、可靠的通过Jabber网络文件传输的算法。
要求
∙允许无缝文件传输,包括必要的回滚机制。
∙保证一方或者双方都在防火墙之后时,文件传输还能进行。
∙定义一个完整的文件传输的元数据,如下:
1.description
2.size
3.name
4.date
5.hash
∙可选的,支持文件传输的范围。
协议
文件传输情形属于http:
//jabber.org/protocol/si/profile/file-transfer命名空间。
该情形很简单:
由可能的描述可选择的传输范围的子元素组成的根元素组成。
根元素<
file>
有4个属性。
这些属性只有在流初始化的情况下使用:
∙size-发送文件的大小,按字节计算
∙name-发送者想要发送的文件名
∙date-文件的最后修改日期。
日期格式使用XMPPDateandTimeProfiles指定的格式。
∙hash-文件内容的MD5
文件大小和文件名属性必须(MUST)在传输情形中出现,其他属性可以(MAY)出现。
根元素还有2个可能的子元素:
<
desc>
和<
range>
,他们都是可选的(OPTIONAL)。
是发送者提供的对于文件描述,接收者可以更加明确被发送的是什么。
它不能(MUSTNOT)在结果中发送。
当提供了<
元素时,它不应该包含属性。
这表示发送者能按照范围发送。
当发送流初始化的结果中包含了<
元素时,是用以下属性:
∙offset-指定了位置,按字节计算,开始文件传输的起点。
如果没有指定,默认值为0。
∙length-指定了从偏移量开始的要接收的字节数。
默认值是从偏移量开始到文件末尾的字节数。
元素中的2个元素都是可选的(OPTIONAL)。
发送无属性的元素等同于没有<
元素。
当在流初始化的结果中没有<
元素时,发送者必须(MUST)从偏移量为0处发送完整的文件。
更通常的情况是,从偏移量位置开始根据指定长度通过字节流发送。
强制实现的技术
为了能够允许无缝实时进行文件传输以及适当的回滚机制,为了更好的处理这些情况,对于这些情况的具体实现必须(MUST)支持SOCKS5Bytestreams[4]和In-BandBytestreams[5]。
相关的命名空间也要包含于"
stream-method"
的可选值中,如下例子中所示:
此外,具体的实现也可以(MAY)支持其他机制。
例子
例子1.在流初始化中,简单的使用示例
iqtype='
set'
id='
offer1'
to='
receiver@jabber.org/resource'
>
sixmlns='
//jabber.org/protocol/si'
a0'
mime-type='
text/plain'
profile='
//jabber.org/protocol/si/profile/file-transfer'
filexmlns='
name='
test.txt'
size='
1022'
/>
featurexmlns='
//jabber.org/protocol/feature-neg'
xxmlns='
jabber:
x:
data'
type='
form'
fieldvar='
stream-method'
list-single'
option>
value>
//jabber.org/protocol/bytestreams<
/value>
/option>
//jabber.org/protocol/ibb<
/field>
/x>
/feature>
/si>
/iq>
例子2.在流初始化结果中,简单的使用示例
result'
sender@jabber.org/resource'
submit'
例子3.在流初始化中,完整的使用示例
hash='
552da749930852c69ae5d2141d3766b1'
date='
1969-07-21T02:
56:
15Z'
Thisisatest.Ifthiswerearealfile...<
/desc>
/file>
例子4.在流初始化结果中,完整的使用示例
从文件的起点处接收256个字节
例子5.
rangelength='
256'
从文件偏移量为128个字节处开始接收256个字节
例子6.
rangeoffset='
128'
length='
从文件偏移量为128个字节处开始接收剩下的文件
例子7.
以下的范围等同于没有发送范围请求,整个文件将被发送。
例子8.
range/>
IANA事项
本文不需要与InternetAssignedNumbersAuthority(IANA)[6]交互。
XMPP注册事项
流初始化情况
本文档描述的情形包含于由XMPPRegistrar维护的流初始化情形注册(参考<
//www.xmpp.org/registrar/si-profiles.html>
)。
注册请求如下:
profile>
name>
//jabber.org/protocol/si/profile/file-transfer<
/name>
doc>
XEP-0096<
/doc>
Aprofileforfiletransferbetweenanytwoentities.<
/profile>
URI查询类型
XMPP注册维护了XMPPURIs的查询和键-值对应的使用,并且被XMPPURIQueryComponents所验证(参考<
//www.xmpp.org/registrar/querytypes.html>
就如下描述的,文件传输的注册类型是"
sendfile"
和"
recvfile"
。
注意"
意味着另一个实体将发送一个文件给控制着IRI/URI的XMPP实体,"
意味着另一个实体将会从控制着IRI/URI的XMPP实体那里接收文件。
发送文件
为了允许另一个实体发送文件,IRI/URI就遵循如下:
例子9.发送文件:
IRI/URI
xmpp:
romeo@
具体的应用程序应该(SHOULD)提供一个界面,允许用户提供关于要发送的文件的信息(比如,为了选择一个文件,“浏览”用户计算机的文件系统)。
结果,应用程序应该(SHOULD)发送一个发布流初始化请求的信息给在IRI/URI封装的XMPP地址。
例子10.发送文件:
结果节点
messagefrom='
juliet@to='
romeo@'
sipubxmlns='
//jabber.org/protocol/si-pub'
publish-0123'
missive.txt'
1024'
2005-11-29T11:
21Z'
/sipub>
/message>
以下提交注册"
类型。
querytype>
sendfile<
proto>
/proto>
enablesinitiationofaninboundfiletransfertoXMPPentity<
/querytype>
接收文件
允许另一个实体接收文件,IRI/URI如下:
例子11.接收文件:
IRI/URI
该IRI/URI等同于以下XML节点:
例子12.接收文件:
等同的节点
juliet@
pub234'
reply.txt'
2048'
根据XEP-0137,应用程序应该(SHOULD)通过发送如下表单初始化文件传输:
例子13.接收文件:
iqfrom='
romeo@
startxmlns='
开始流的请求要发送给在XMPPIRI/URI中定义的实体的全JID。
因此,IRI/URI应该(SHOULD)包含全JID。
如果没有如此,接收者必须(MUST)通过出席信息或者服务发现来查找全JID。
如果接收者不能查找到发送者的全JID(比如,在最后一次出现时,通过发送订阅出席请求并从发送者的资源接收到出席信息),那么它应该(SHOULD)取消文件传输。
以下的提交注册了"
查询类型。
recvfile<
enablesinitiationofanoutboundfiletransferfromXMPPentity<
keys>
key>
mime-type<
theMIMEtypeofthefilebeingoffered<
/key>
name<
thenameofthefilebeingoffered<
sid<
thesessionIDassociatedwiththefilebeingoffered<
size<
thesizeinbytesofthefilebeingoffered<
/keys>
XMLSchema
?
xmlversion='
1.0'
encoding='
UTF-8'
xs:
schema
xmlns:
xs='
//www.w3.org/2001/XMLSchema'
targetNamespace='
xmlns='
elementFormDefault='
qualified'
annotation>
documentation>
Theprotocoldocumentedbythisschemaisdefinedin
XEP-0096:
http:
//www.xmpp.org/extensions/xep-0096.html
/xs:
elementname='
file'
complexType>
sequenceminOccurs='
0'
desc'
string'
elementref='
range'
sequence>
attributename='
date'
dateTime'
use='
optional'
hash'
name'
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XEP0096