分享
 
 
 

RFC2778 - A Model for Presence and Instant Messaging

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

Network Working Group M. Day

Request for Comments: 2778 Lotus

Category: Informational J. Rosenberg

dynamicsoft

H. Sugano

Fujitsu

February 2000

A Model for Presence and Instant Messaging

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This document defines an abstract model for a presence and instant

messaging system. It defines the various entities involved, defines

terminology, and outlines the services provided by the system. The

goal is to provide a common vocabulary for further work on

requirements for protocols and markup for presence and instant

messaging.

1. IntrodUCtion

A presence and instant messaging system allows users to subscribe to

each other and be notified of changes in state, and for users to send

each other short instant messages. To facilitate development of a

suite of protocols to provide this service, we believe that it is

valuable to first develop a model for the system. The model consists

of the various entities involved, descriptions of the basic functions

they provide, and most importantly, definition of a vocabulary which

can be used to facilitate discussion.

We note that the purpose of this model is to be descriptive and

universal: we want the model to map reasonably onto all of the

systems that are informally described as presence or instant

messaging systems. The model is not intended to be prescriptive or

achieve interoperability: an element that appears in the model will

not necessarily be an element of an interoperable protocol, and may

not even be a good idea.

In this document, each element of the model appears in upper case

(e.g., PRESENCE SERVICE). No term in lower case or mixed case is

intended to be a term of the model.

The first part of this document is intended as an overview of the

model. The overview includes diagrams, and terms are presented in an

order that is intended to help the reader understand the relationship

between elements. The second part of the document is the actual

definition of the model, with terms presented in alphabetical order

for ease of reference.

The overview is intended to be helpful but is not definitive; it may

contain inadvertent differences from the definitions in the model.

For any such difference, the definition(s) in the model are taken to

be correct, rather than the eXPlanation(s) in the overview.

2. Overview

The model is intended to provide a means for understanding,

comparing, and describing systems that support the services typically

referred to as presence and instant messaging. It consists of a

number of named entities that appear, in some form, in existing

systems. No actual implementation is likely to have every entity of

the model as a distinct part. Instead, there will almost always be

parts of the implementation that embody two or more entities of the

model. However, different implementations may combine entities in

different ways.

The model defines two services: a PRESENCE SERVICE and an INSTANT

MESSAGE SERVICE. The PRESENCE SERVICE serves to accept information,

store it, and distribute it. The information stored is

(unsurprisingly) PRESENCE INFORMATION. The INSTANT MESSAGE SERVICE

serves to accept and deliver INSTANT MESSAGES to INSTANT INBOXES.

2.1 PRESENCE SERVICE

The PRESENCE SERVICE has two distinct sets of "clients" (remember,

these may be combined in an implementation, but treated separately in

the model). One set of clients, called PRESENTITIES, provides

PRESENCE INFORMATION to be stored and distributed. The other set of

clients, called WATCHERS, receives PRESENCE INFORMATION from the

service.

+---------------------------+

PRESENCE SERVICE

+---------------------------+

^

v

+------------+ +------------+

PRESENTITY WATCHER

+------------+ +------------+

Fig. 1: Overview of Presence Service

There are two kinds of WATCHERS, called FETCHERS and SUBSCRIBERS. A

FETCHER simply requests the current value of some PRESENTITY's

PRESENCE INFORMATION from the PRESENCE SERVICE. In contrast, a

SUBSCRIBER requests notification from the PRESENCE SERVICE of

(future) changes in some PRESENTITY's PRESENCE INFORMATION. A

special kind of FETCHER is one that fetches information on a regular

basis. This is called a POLLER.

+----------------WATCHER---------------+

+----FETCHER---+ +--SUBSCRIBER--+

+--POLLER--+

+----------+

+--------------+ +--------------+

+--------------------------------------+

Fig. 2: Varieties of WATCHER

The PRESENCE SERVICE also has WATCHER INFORMATION about WATCHERS and

their activities in terms of fetching or subscribing to PRESENCE

INFORMATION. The PRESENCE SERVICE may also distribute WATCHER

INFORMATION to some WATCHERS, using the same mechanisms that are

available for distributing PRESENCE INFORMATION.

Changes to PRESENCE INFORMATION are distributed to SUBSCRIBERS via

NOTIFICATIONS. Figures 3a through 3c show the flow of information as

a piece of PRESENCE INFORMATION is changed from P1 to P2.

+---------------------------+

PRESENCE SERVICE

P1

+---------------------------+

+------------+ +------------+

P1->P2 P1

PRESENTITY SUBSCRIBER

+------------+ +------------+

Fig. 3a: NOTIFICATION (Step 1)

+---------------------------+

PRESENCE SERVICE

P1->P2

+---------------------------+

^

P2

+------------+ +------------+

P2 P1

PRESENTITY SUBSCRIBER

+------------+ +------------+

Fig. 3b: NOTIFICATION (Step 2)

+---------------------------+

PRESENCE SERVICE

P2

+---------------------------+

P2

v

+------------+ +------------+

P2 P1->P2

PRESENTITY SUBSCRIBER

+------------+ +------------+

Fig. 3c: NOTIFICATION (Step 3)

2.2 INSTANT MESSAGE SERVICE

The INSTANT MESSAGE SERVICE also has two distinct sets of "clients":

SENDERS and INSTANT INBOXES. A SENDER provides INSTANT MESSAGES to

the INSTANT MESSAGE SERVICE for delivery. Each INSTANT MESSAGE is

addressed to a particular INSTANT INBOX ADDRESS, and the INSTANT

MESSAGE SERVICE attempts to deliver the message to a corresponding

INSTANT INBOX.

+---------------------------+

INSTANT MESSAGE SERVICE

+---------------------------+

^

v

+------------+ +---------------+

SENDER INSTANT INBOX

+------------+ +---------------+

Fig. 4: Overview of Instant Message Service

2.3 Protocols

A PRESENCE PROTOCOL defines the interaction between PRESENCE SERVICE,

PRESENTITIES, and WATCHERS. PRESENCE INFORMATION is carried by the

PRESENCE PROTOCOL.

An INSTANT MESSAGE PROTOCOL defines the interaction between INSTANT

MESSAGE SERVICE, SENDERS, and INSTANT INBOXES. INSTANT MESSAGES are

carried by the INSTANT MESSAGE PROTOCOL.

In terms of this model, we believe that the IMPP working group is

planning to develop detailed requirements and specifications for the

structure and formats of the PRESENCE PROTOCOL, PRESENCE INFORMATION,

INSTANT MESSAGE PROTOCOL, and INSTANT MESSAGES.

2.4 Formats

The model defines the PRESENCE INFORMATION to consist of an arbitrary

number of elements, called PRESENCE TUPLES. Each such element

consists of a STATUS marker (which might convey information such as

online/offline/busy/away/do not disturb), an optional COMMUNICATION

ADDRESS, and optional OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS

includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of

COMMUNICATION MEANS, and the only one defined by this model, is

INSTANT MESSAGE SERVICE. One type of CONTACT ADDRESS, and the only

one defined by this model, is INSTANT INBOX ADDRESS. However, other

possibilities exist: a COMMUNICATION MEANS might indicate some form

of telephony, for example, with the corresponding CONTACT ADDRESS

containing a telephone number.

+------------------------------------+

PRESENCE INFORMATION

+------------------------------------+

+-------------------------------+

=> PRESENCE TUPLE

+-------------------------------+

+-------------------------+

=> STATUS

+-------------------------+

+-------------------------+

=> COMMUNICATION ADDRESS

+-------------------------+

+-----------------+

=> CONTACT MEANS

+-----------------+

+-----------------+

=> CONTACT ADDRESS

+-----------------+

+-------------------------+

=> OTHER MARKUP

+-------------------------+

+-------------------------------+

=> PRESENCE TUPLE

+-------------------------------+

+-------------------------+

=> STATUS

+-------------------------+

+-------------------------+

=> COMMUNICATION ADDRESS

+-------------------------+

+-----------------+

=> CONTACT MEANS

+-----------------+

+-----------------+

=> CONTACT ADDRESS

+-----------------+

+-------------------------+

=> OTHER MARKUP

+-------------------------+

+-------------------------------+

=> PRESENCE TUPLE

+-------------------------------+

...

Fig. 5: The structure of PRESENCE INFORMATION

STATUS is further defined by the model to have at least two states

that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT

MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will

not be accepted. OPEN and CLOSED may also be applicable to other

COMMUNICATION MEANS -- OPEN mapping to some state meaning "available"

or "open for business" while CLOSED means "unavailable" or "closed to

business." The model allows STATUS to include other values, which may

be interpretable by programs or only by persons. The model also

allows STATUS to consist of single or multiple values.

2.5 Presence and its effect on Instant Messages

An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT

INBOX ADDRESS is the information that can be included in PRESENCE

INFORMATION to define how an INSTANT MESSAGE should be delivered to

that INSTANT INBOX. As noted above, certain values of the STATUS

marker indicate whether INSTANT MESSAGES will be accepted at the

INSTANT INBOX. The model does not otherwise constrain the delivery

mechanism or format for instant messages. Reasonable people can

disagree about whether this omission is a strength or a weakness of

this model.

2.6 PRINCIPALS and their agents

This model includes other elements that are useful in characterizing

how the protocol and markup work. PRINCIPALS are the people, groups,

and/or software in the "real world" outside the system that use the

system as a means of coordination and communication. It is entirely

outside the model how the real world maps onto PRINCIPALS -- the

system of model entities knows only that two distinct PRINCIPALS are

distinct, and two identical PRINCIPALS are identical.

A PRINCIPAL interacts with the system via one of several user agents

(INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER

USER AGENT). As usual, the different kinds of user agents are split

apart in this model even though most implementations will combine at

least some of them. A user agent is purely coupling between a

PRINCIPAL and some core entity of the system (respectively, INSTANT

INBOX; SENDER; PRESENTITY; WATCHER).

+---------------------------+

PRESENCE SERVICE

+---------------------------+

^

PRESENCE PROTOCOL

v

+------------+ +------------+

PRESENTITY WATCHER

+------------+ +------------+

^ ^

o +--------------+ +-------------+ o

/\ --> PRESENCE UA WATCHER UA <-- / X +--------------+ +-------------+ X

(PRINCIPAL) (PRINCIPAL)

Fig. 6: A presence system

+---------------------------+

INSTANT MESSAGE SERVICE

+---------------------------+

^

IM INSTANT MESSAGE IM

PROTOCOL v

+------------+ +---------------+

SENDER INSTANT INBOX

+------------+ +---------------+

^ ^

o +-------------+ +------------------+ o

/\ --> SENDER UA INBOX UA <-- / X +-------------+ +------------------+ X

(PRINCIPAL) (PRINCIPAL)

Fig. 7: An instant messaging system

2.7 Examples

A simple example of applying the model is to describe a generic

"buddy list" application. These applications typically expose the

user's presence to others, and make it possible to see the presence

of others. So we could describe a buddy list as the combination of a

PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL,

using a single PRESENTITY and a single SUBSCRIBER.

We could then extend our example to instant messaging and describe a

generic "instant messenger" as essentially a buddy list with

additional capabilities for sending and receiving instant messages.

So an instant messenger would be the combination of a PRESENCE USER

AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER USER AGENT

for a single PRINCIPAL, using a single PRESENTITY, single SUBSCRIBER,

and single INSTANT INBOX, with the PRESENTITY's PRESENCE INFORMATION

including an INSTANT INBOX ADDRESS that leads to the INSTANT INBOX.

3. Model

Access RULES: constraints on how a PRESENCE SERVICE makes PRESENCE

INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE

INFORMATION, the applicable ACCESS RULES are manipulated by the

PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY.

Motivation: We need some way of talking about hiding presence

information from people.

CLOSED: a distinguished value of the STATUS marker. In the context of

INSTANT MESSAGES, this value means that the associated INSTANT

INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is

unable to accept an INSTANT MESSAGE. This value may have an

analogous meaning for other COMMUNICATION MEANS, but any such

meaning is not defined by this model. Contrast with OPEN.

COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT

ADDRESS.

COMMUNICATION MEANS: indicates a method whereby communication can

take place. INSTANT MESSAGE SERVICE is one example of a

COMMUNICATION MEANS.

CONTACT ADDRESS: a specific point of contact via some COMMUNICATION

MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS

is an INSTANT INBOX ADDRESS.

DELIVERY RULES: constraints on how an INSTANT MESSAGE SERVICE

delivers received INSTANT MESSAGES to INSTANT INBOXES. For each

INSTANT INBOX, the applicable DELIVERY RULES are manipulated by

the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT

INBOX.

Motivation: We need a way of talking about filtering instant

messages.

FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to for

the PRESENCE INFORMATION of one or more PRESENTITIES, but has not

asked for a SUBSCRIPTION to be created.

INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more

INSTANT INBOXES controlled by that PRINCIPAL.

Motivation: This is intended to isolate the core functionality of

an INSTANT INBOX from how it might appear to be manipulated by a

product. This manipulation includes fetching messages, deleting

messages, and setting DELIVERY RULES. We deliberately take no

position on whether the INBOX USER AGENT, INSTANT INBOX, and

INSTANT MESSAGE SERVICE are colocated or distributed across

machines.

INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by

the INSTANT INBOX's PRINCIPAL.

INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's

PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The

STATUS and INSTANT INBOX ADDRESS information are sufficient to

determine whether the PRINCIPAL appears ready to accept the

INSTANT MESSAGE.

Motivation: The definition is pretty loose about exactly how any

of this works, even leaving open the possibility of reusing parts

of the email infrastructure for instant messaging.

INSTANT MESSAGE: an identifiable unit of data, of small size, to be

sent to an INSTANT INBOX.

Motivation: We do not define "small" but we seek in this

definition to avoid the possibility of transporting an arbitrary-

length stream labelled as an "instant message."

INSTANT MESSAGE PROTOCOL: The messages that can be exchanged between

a SENDER USER AGENT and an INSTANT MESSAGE SERVICE, or between an

INSTANT MESSAGE SERVICE and an INSTANT INBOX.

INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES.

-- May require authentication of SENDER USER AGENTS and/or INSTANT

INBOXES.

-- May have different authentication requirements for different

INSTANT INBOXES, and may also have different authentication

requirements for different INSTANT INBOXES controlled by a

single PRINCIPAL.

-- May have an internal structure involving multiple SERVERS

and/or PROXIES. There may be complex patterns of redirection

and/or proxying while retaining logical connectivity to a

single INSTANT MESSAGE SERVICE. Note that an INSTANT MESSAGE

SERVICE does not require having a distinct SERVER -- the

service may be implemented as direct communication between

SENDER and INSTANT INBOX.

-- May have an internal structure involving other INSTANT MESSAGE

SERVICES, which may be independently accessible in their own

right as well as being reachable through the initial INSTANT

MESSAGE SERVICE.

NOTIFICATION: a message sent from the PRESENCE SERVICE to a

SUBSCRIBER when there is a change in the PRESENCE INFORMATION

of some PRESENTITY of interest, as recorded in one or more

SUBSCRIPTIONS.

Motivation: We deliberately take no position on what part of

the changed information is included in a NOTIFICATION.

OPEN: a distinguished value of the STATUS marker. In the context of

INSTANT MESSAGES, this value means that the associated INSTANT

INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is

ready to accept an INSTANT MESSAGE. This value may have an

analogous meaning for other COMMUNICATION MEANS, but any such

meaning is not defined by this model. Contrast with CLOSED.

OTHER PRESENCE MARKUP: any additional information included in the

PRESENCE INFORMATION of a PRESENTITY. The model does not define

this further.

POLLER: a FETCHER that requests PRESENCE INFORMATION on a regular

basis.

PRESENCE INFORMATION: consists of one or more PRESENCE TUPLES.

PRESENCE PROTOCOL: The messages that can be exchanged between a

PRESENTITY and a PRESENCE SERVICE, or a WATCHER and a PRESENCE

SERVICE.

PRESENCE SERVICE: accepts, stores, and distributes PRESENCE

INFORMATION.

-- May require authentication of PRESENTITIES, and/or WATCHERS.

-- May have different authentication requirements for different

PRESENTITIES.

-- May have different authentication requirements for different

WATCHERS, and may also have different authentication

requirements for different PRESENTITIES being watched by a

single WATCHER.

-- May have an internal structure involving multiple SERVERS

and/or PROXIES. There may be complex patterns of redirection

and/or proxying while retaining logical connectivity to a

single PRESENCE SERVICE. Note that a PRESENCE SERVICE does not

require having a distinct SERVER -- the service may be

implemented as direct communication among PRESENTITY and

WATCHERS.

-- May have an internal structure involving other PRESENCE

SERVICES, which may be independently accessible in their own

right as well as being reachable through the initial PRESENCE

SERVICE.

PRESENCE TUPLE: consists of a STATUS, an optional COMMUNICATION

ADDRESS, and optional OTHER PRESENCE MARKUP.

PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more

PRESENTITIES.

Motivation: This is essentially a "model/view" distinction: the

PRESENTITY is the model of the presence being exposed, and is

independent of its manifestation in any user interface. In

addition, we deliberately take no position on how the PRESENCE

USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or

distributed across machines.

PRESENTITY (presence entity): provides PRESENCE INFORMATION to a

PRESENCE SERVICE.

Motivation: We don't like to coin new Words, but "presentity"

seemed worthwhile so as to have an unambiguous term for the entity

of interest to a presence service. Note that the presentity is not

(usually) located in the presence service: the presence service

only has a recent version of the presentity's presence

information. The presentity initiates changes in the presence

information to be distributed by the presence service.

PRINCIPAL: human, program, or collection of humans and/or programs

that chooses to appear to the PRESENCE SERVICE as a single actor,

distinct from all other PRINCIPALS.

Motivation: We need a clear notion of the actors outside the

system. "Principal" seems as good a term as any.

PROXY: a SERVER that communicates PRESENCE INFORMATION, INSTANT

MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER.

Sometimes a PROXY acts on behalf of a PRESENTITY, WATCHER, or

INSTANT INBOX.

SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT

MESSAGE SERVICE.

SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more

SENDERS.

SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE

SERVICE.

SPAM: unwanted INSTANT MESSAGES.

SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.

STALKING: using PRESENCE INFORMATION to infer the whereabouts of a

PRINCIPAL, especially for malicious or illegal purposes.

STATUS: a distinguished part of the PRESENCE INFORMATION of a

PRESENTITY. STATUS has at least the mutually-exclusive values OPEN

and CLOSED, which have meaning for the acceptance of INSTANT

MESSAGES, and may have meaning for other COMMUNICATION MEANS.

There may be other values of STATUS that do not imply anything

about INSTANT MESSAGE acceptance. These other values of STATUS may

be combined with OPEN and CLOSED or they may be mutually-exclusive

with those values.

Some implementations may combine STATUS with other entities. For

example, an implementation might make an INSTANT INBOX ADDRESS

visible only when the INSTANT INBOX can accept an INSTANT MESSAGE.

Then, the existence of an INSTANT INBOX ADDRESS implies OPEN,

while its absence implies CLOSED.

SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to

notify it immediately of changes in the PRESENCE INFORMATION of

one or more PRESENTITIES.

SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a

SUBSCRIBER's request to be notified of changes in the PRESENCE

INFORMATION of one or more PRESENTITIES.

VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes WATCHER

INFORMATION available to WATCHERS. For each WATCHER's WATCHER

INFORMATION, the applicable VISIBILITY RULES are manipulated by

the WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER.

Motivation: We need a way of talking about hiding watcher

information from people.

WATCHER: requests PRESENCE INFORMATION about a PRESENTITY, or WATCHER

INFORMATION about a WATCHER, from the PRESENCE SERVICE. Special

types of WATCHER are FETCHER, POLLER, and SUBSCRIBER.

WATCHER INFORMATION: information about WATCHERS that have received

PRESENCE INFORMATION about a particular PRESENTITY within a

particular recent span of time. WATCHER INFORMATION is maintained

by the PRESENCE SERVICE, which may choose to present it in the

same form as PRESENCE INFORMATION; that is, the service may choose

to make WATCHERS look like a special form of PRESENTITY.

Motivation: If a PRESENTITY wants to know who knows about it, it

is not enough to examine only information about SUBSCRIPTIONS. A

WATCHER might repeatedly fetch information without ever

subscribing. Alternately, a WATCHER might repeatedly subscribe,

then cancel the SUBSCRIPTION. Such WATCHERS should be visible to

the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION,

but will not be appropriately visible if the WATCHER INFORMATION

includes only SUBSCRIPTIONS.

WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or more

WATCHERS controlled by that PRINCIPAL.

Motivation: As with PRESENCE USER AGENT and PRESENTITY, the

distinction here is intended to isolate the core functionality of

a WATCHER from how it might appear to be manipulated by a product.

As previously, we deliberately take no position on whether the

WATCHER USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or

distributed across machines.

4. Security Considerations

This document provides a model and vocabulary for systems with

certain intrinsic security issues. In particular, presence and

instant messaging systems must deal with "the three S's": STALKING,

SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER

INFORMATION are intended to deal with STALKING. The several kinds of

authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE

SERVICE are intended to deal with SPOOFING. DELIVERY RULES are

intended to deal with SPAM.

5. Conclusion

This document has provided a model for a presence and instant

messaging system. The purpose of the model is to provide a common

vocabulary for the further work of defining and implementing

interoperable presence and instant messaging protocols.

6. Acknowledgements

This document has been improved by comments from Jesse Vincent and

Colin Benson, by the participants in the Cambridge, MA meeting on

June 11, 1999, and by Roy Salisbury, who contributed the original

version of Figure 5. The authors gratefully acknowledge their

assistance.

7. Authors' Addresses

Mark Day

SightPath, Inc.

135 Beaver Street

Waltham, MA 02452

USA

EMail: mday@alum.mit.edu

(Formerly Mark_Day@lotus.com)

Jonathan Rosenberg

dynamicsoft

200 Executive Drive

Suite 120

West Orange, NJ 07046

Email: jdrosen@dynamicsoft.com

Hiroyasu Sugano

Fujitsu Laboratories Ltd.

64 Nishiwaki, Ohkubo-cho

Akashi 674-8555

Japan

EMail: suga@flab.fujitsu.co.jp

8. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
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- 王朝網路 版權所有