Considerations of software generated message on XMPP
draft-sato-xmpp-software-message-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Hirotaka Sato , Nobuo Ogashiwa | ||
| Last updated | 2010-03-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In RFC2779 [RFC2779] and RFC2778 [RFC2778], XMPP [RFC3920] client is defined as "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. Considering this description, it does not matter whether the user of end node is human or software. However, current specification of XMPP is expected that there will be a human in front of the client. So, there is no consideration for looping the message between softwares and processing message that human will not be able to react. Recently system and software are replying in return of human. Moreover, by making client act like a human, new network service can be made. There are many of these called "bots" already, but there is a possibility which can aggregate or control remote resources.By clarifying models of usage and problem, this document aims to use XMPP in software-to-software and human-to-software models not only human-to-human model.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)