Network Working Group D. New Internet-Draft Invisible Worlds, Inc. Expires: August 30, 2001 March 2001 The WCIP Profile draft-new-webi-wcip-beep-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes a BEEP profile that provides an invalidation channel for transporting object volumes in the Web Cache Invalidation Protocol. New Expires August 30, 2001 [Page 1] Internet-Draft WCIP Profile March 2001 Table of Contents 1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Subscription . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.7 Environment . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 5 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1 BEEP Profile Registration . . . . . . . . . . . . . . . . . . 6 6.2 Registration: The System (Well-Known) TCP port number for the WCIP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 New Expires August 30, 2001 [Page 2] Internet-Draft WCIP Profile March 2001 1. Rationale The Web Cache Invalidation Protocol allows proxy caches to be proactively informed of changes in the cached materials, allowing them to serve only timely and consistant information without the need to fetch the material from the original source for each request. The WCIP does not define a specific method for transporting the messages that implement the protocol. Instead, WCIP is willing to use any transport mechanism that meets its needs, said needs being enumerated in the WCIP specification. This document describes a BEEP profile that meets the needs of WCIP and can thus be used to transport WCIP messages. 2. Requirements The requirements for a WCIP transport channel are specified in Section 3.3 of [1]. This profile satisfies the requirements in the following ways: 2.1 Naming The URI naming a WCIP channel SHALL be of the form "wcip://" domain-name ":" port "/" channel-name "?proto=beep" For example, "wcip://example.com:10288/news/world/europe?proto=beep" Privacy and authentication requirements are addressed in the Security section below. Such requirements do not impact the URI used to specify the channel. 2.2 Subscription Each WCIP channel will be carried over a separate BEEP channel. The WCIP channel name is passed over the BEEP channel after BEEP channel establishment. Closure of the BEEP channel (via closing the specific BEEP channel, the BEEP session, or loss of underlying transport connection) will be communicated to the application. 2.3 Framing Each WCIP channel message is carried in a single BEEP message, using MSG or RPY appropriately, as described below. 2.4 Delivery BEEP is a point-to-point protocol when mapped over TCP, as described in [3]. Hence, delivery will be as prompt as delivery of TCP data. New Expires August 30, 2001 [Page 3] Internet-Draft WCIP Profile March 2001 2.5 Security The normal BEEP mechanisms for authentication and encryption (SASL and TLS) are used. The channel URI does not specify the security mechanisms (if any) to use over a WCIP connection. To determine whether encryption must be used on an invalidation channel, the cache examines the greetings sent by the invalidation server. The channel URI is sent from the content server to the cache to identify which invalidation server to use. When the cache connects to the invalidation server named by that channel URI, it MUST examine the greeting from the invalidation server. If the initial greeting includes the TLS profile but not the WCIP profile, then the cache starts the TLS profile and expects the WCIP profile in the post-negotiation greeting. If a SASL identity is required before WCIP can be started, this MUST be configured into the cache via an out-of-band mechanism. 2.6 Scalability Channel relay (as described in Section 4.1 of [1]) shall be used. Since BEEP is peer-to-peer, such an architecture presents no problems. 2.7 Environment BEEP is mapped to TCP, so there is no problem with wide-area networks. For penetrating firewalls, the TUNNEL profile [4] can be used, or a specific port may be allocated to breach the firewall. 3. Message Syntax The contents of the messages exchanged by this profile are defined in [1]. Generally, each BEEP message or reply will carry a single WCIP message. The content-type of each BEEP message carrying a WCIP element MUST be application/xml. The content-type of each BEEP message carrying an element MUST be application/beep+xml. New Expires August 30, 2001 [Page 4] Internet-Draft WCIP Profile March 2001 4. Message Semantics In this profile, the initiator is always the cache, while the listener is always the invalidation server. Once a BEEP channel is started with this profile, the listener expects a "ObjectVolume" element from the initiator, along with the and declarations, as described in [1]. Due to the nature of the profile, the initial element MUST NOT be passed as piggyback data on the "start" element. Any "ObjectVolume" element sent by the initiator is sent in a MSG message. The listener replies with an "ObjectVolume" element returned in a RPY message. If the listener sends an unsolicited message, it will send an "ObjectVolume" element in a MSG, and the initiator MUST reply with an "ok" element in a RPY. If errors are detected in the syntax or semantics of the objects exchanged, the BEEP channel over which the erroneous object was sent is closed cleanly. Each BEEP channel MUST be associated with a single WCIP channel. The first "ObjectVolume" sent on a BEEP channel will determine which WCIP channel is associated with that BEEP channel. If multiple WCIP channels are required over the same session, multiple BEEP channels can be opened. 5. Provisioning The [2] defines authentication mechanisms and privacy mechanisms. If privacy is required by a listener, it MUST NOT advertise this profile in its greeting before adequate privacy has been negotiated via TLS. If authentication is required, a listener MUST NOT open a WCIP channel before adequate authorization has been granted. New Expires August 30, 2001 [Page 5] Internet-Draft WCIP Profile March 2001 6. IANA Considerations 6.1 BEEP Profile Registration The IANA adds the following to its registry of BEEP profiles, upon approval of this document by the IESG: Profile identification: http://xml.resource.org/profiles/WCIP Message exchanged during channel creation: None. Messages starting one-to-one exchanges: "ObjectVolume" Messages in positive replies: "ok", "ObjectVolume" Messages in negative replies: None. Messages in one-to-many exchanges: None. Message syntax: See Section 3 and [1]. Message semantics: See Section 4 and [1]. Contact information: See the Author's Address appendix of this document. 6.2 Registration: The System (Well-Known) TCP port number for the WCIP Profile A single well-known port is allocated to the WCIP profile. Protocol Number: TCP Message Formats, Types, Opcodes, and Sequences: See Section 3. Functions: See Section 4. Use of Broadcast/Multicast: none Proposed Name: WCIP Profile Short name: WCIP-beep Contact Information: See the "Authors' Addresses" section of this memo 7. Security Considerations The WCIP profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 8 of [2] for a discussion of this. New Expires August 30, 2001 [Page 6] Internet-Draft WCIP Profile March 2001 References [1] Li, D., Cao, P. and M. Dahlin, "WCIP: Web Cache Invalidation Protocol", draft-danli-wrec-wcip-01 (work in progress), March 2001. [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [4] New, D., "The TUNNEL Profile", draft-ietf-idwg-beep-tunnel-01 (work in progress), February 2001. Author's Address Darren New Invisible Worlds, Inc. 131 Stony Circle, Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: dnew@invisible.net URI: http://invisible.net/ Appendix A. Acknowledgements None yet, but I'm sure there will be. New Expires August 30, 2001 [Page 7] Internet-Draft WCIP Profile March 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. New Expires August 30, 2001 [Page 8]