rfc2779.txt

中、英文RFC文档大全打包下载完全版 .

   notifications occur.

       Discussion: This is omitted from the requirements, as traffic
       analysis, even of encrypted traffic, can convey this information
       in some situations.

   A3. That she only receives notifications of things she's subscribed
   to.

       Discussion:  Stands as a requirement. [Requirement 5.3.2]

   A4. Notifications come from the apparent sender, B.

       Discussion: Stands in principle, although the verification should
       be  optional for A. [Requirement 5.3.3]

   A5. A can tell the difference between a message generated by the
   user, and a message legitimately generated by the agent on behalf of
   the user.

       Discussion: This could be quite difficult to enforce and could
       unduly restrict usage scenarios; this is omitted from the
       requirements.



Day, et al.                  Informational                     [Page 20]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   A6. That information given by agents on behalf of users can also be
   expected to be truthful, complete, and legitimately offered; the user
   permitted the agent to publish these notifications.

       Discussion: This is difficult to enforce and is omitted from the
       requirements.

   A7. A can prove that a notification from B was delivered in a timely
   fashion and can prove exactly how long the message took to be
   delivered.

       Discussion: This is difficult to enforce and is omitted from the
       requirements.  For example, such proof may entail global time
       synchronization mechanisms (since any system clocks have
       associated unreliability), which is outside the scope of this
       effort.

   A8. A can prove that B was indeed the sender of a given message.

       Discussion: This is a duplication of expectation A4 above and is
       reflected in the corresponding requirement 5.3.3.

8.2. INSTANT MESSAGEs

   8.2.1. Named Instant Messaging

   When a user Alice sends an instant message M to another user Bob:

   Alice expects that she:

   A1. will receive notification of non-delivery

       Discussion: Stands as a requirement. [Requirement 5.4.1]

   Alice expects that Bob:

   B1. will receive the message

       Discussion: covered by A1 and is reflected in the corresponding
       requirement 5.4.1.

   B2. will receive the message quickly

       Discussion: Stands as a requirement, although this is also
       covered elsewhere (in the non-security requirements), so this is
       omitted from the security requirements.





Day, et al.                  Informational                     [Page 21]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   B3. will receive the message only once

       Discussion: Stands as a requirement. [Requirement 5.4.2]

   B4. will be able to verify that Alice sent the message

       Discussion:  Stands as a requirement. [Requirement 5.4.3]

   B5. will not know whether there were BCCs

       Discussion: Emulating e-mail conventions and social protocols is
       not a core goal of this effort, and therefore references to
       standard mail fields are omitted from the requirements.

   B6. will be able to reply to the message

       Discussion: Stands in principle; the recipient should be able to
       reply via an instant message. [Requirement 5.4.4]

   B7. will know if he was a bcc recipient

       Discussion: Omitted, as noted above.

   B8. will not be able to determine any information about A (such as
   her location or IP address) without A's knowledge and consent.

       Discussion: "Any information about A" is too general; the
       requirement should focus on IP address.  Further, "without A's
       knowledge and consent" may be overkill. [Requirement 5.4.5]

   Alice expects that no other user Charlie will be able to:

   C1. see the content of M

       Discussion: Stands in principle, although this should not be
       mandated for all IM communication. [Requirement 5.4.6]

   C2. tamper with M

       Discussion: Stands, with the same caveat as above.
       [Requirement 5.4.7]

   C3. know that M was sent

       Discussion: It is impossible to prevent traffic analysis, and
       this is therefore omitted from the requirements.





Day, et al.                  Informational                     [Page 22]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   When a user Bob receives an instant message M from another user
   Alice:

   Bob expects that Bob:

   D1. will be able to read M

       Discussion: Stands as a requirement. [Requirement 5.4.8]

   D2. will be able to verify M's authenticity (both Temporal and the
   sender's identity)

       Discussion: As noted earlier, it is not reasonable to directly
       require temporal checks.  The protocol should, however, allow
       signing messages using existing standards for signing.
       [Requirement 5.4.9]

   D3. will be able to verify M's integrity

       Discussion:  Stands as a requirement. [Requirement 5.4.10]

   D4. will be able to prevent A from sending him future messages

       Discussion: Stands as a requirement. [Requirement 5.4.11]

   Bob expects that Alice:

   E1. intended to send the message to Bob

       Discussion: This is covered by the corresponding requirement
       5.4.6 for C1 above.

   E2. informed Bob of all CCs.

       Discussion: As noted earlier, references to cc:'s are omitted
       from the requirements.

   8.2.2. Anonymous Instant Messaging

       Discussion: Anonymous instant messaging, as in "hiding the
       identity of the sender", is not deemed to be a core requirement
       of the protocol and references to it are therefore omitted from
       the requirements. Implementations may provide facilities for
       anonymous messaging if they wish, in ways that are consistent
       with the other requirements.

   When a user Alice sends an anonymous instant message to another user
   Bob:



Day, et al.                  Informational                     [Page 23]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   Alice expects that Bob:

   B1. will receive the message

   B2. will receive the message quickly

   B3. will receive the message only once

   AB4.1. cannot know Alice sent it

   AB4.2. will know that the IM is anonymous, and not from a specific
   named user

   AB4.3   may not allow anonymous IMs

   B5. will not know whether there were BCCs

   B6. will be able to reply to the message

   Alice expects that she:

   C1. will receive notification of non-delivery

   AC2. will receive an error if the IM was refused

   Bob expects that he:

   D1. will be able to read M

   D2. will be able to verify M's authenticity (both temporal and the
   sender's identity)

   D3. will be able to verify M's integrity

   AD4. will know if an IM was sent anonymously

   AD5. will be able to automatically discard anonymous IM if desired

   AD6. will be able to control whether an error is sent to Alice if M
   is discarded.

   8.2.3. Administrator Expectations

   Charlie, Alice's network administrator expects:

   C1. that C will be able to send A instant messages at any time.

   C2. that A will receive any message he sends while A is online.



Day, et al.                  Informational                     [Page 24]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


   C3. that A will not be able to refuse delivery of any instant
   messages sent by C.

       Discussion for C1-C3: It is not clear this needs to be specially
       handled at the protocol level; Administrators may accomplish the
       above objectives through other means.  For example, an
       administrator may send a message to a user through the normal
       mechanisms.  This is therefore omitted from the requirements.











































Day, et al.                  Informational                     [Page 25]

RFC 2779          Instant Messaging/Presence Protocol      February 2000


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 RFC Editor function is currently provided by the
   Internet Society.



















Day, et al.                  Informational                     [Page 26]