idnits 2.17.1 draft-day-envy-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 178 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Calsyn,Mohr]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'Calsyn' -- Possible downref: Normative reference to a draft: ref. 'Day' -- Possible downref: Normative reference to a draft: ref. 'Dusseault' -- Possible downref: Normative reference to a draft: ref. 'Mohr' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mark Day 2 Expires: September 13, 1998 Lotus Development Corporation 4 ''HTTP Envy'' and Presence Information Protocols 6 draft-day-envy-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 2. Abstract 29 There are a variety of proposals [Calsyn, Mohr] for building a 30 presence information protocol as a variant or version of HTTP. This 31 document summarizes why I believe that is not a good idea. 33 3. Introduction 35 HTTP is a remarkably ubiquitous protocol. It is not hard to find 36 people who believe approximately one of the following: 38 "HTTP is everywhere. It could not be so pervasive without being 39 good. Therefore it is good, and I should imitate it with my protocol." 41 "HTTP is everywhere. Therefore, if I base my protocol on HTTP, my 42 protocol will also be everywhere." 44 In the rest of this document, I consider the reality of building a 45 presence information protocol, and compare these realities to the HTTP 46 fantasies. Other documents [Dusseault, Day] provide perspective on 47 what a presence information protocol must be. 49 4. Crossing Firewalls Made Easy 51 In most organizations HTTP traffic crosses firewalls fairly easily. 52 It is easy to claim (for instance) that a new super-duper protocol 53 will use port 80 and thereby get all of HTTP's firewall-crossing 54 virtues. There are typically two holes in this story. 56 The first hole is that these protocols typically don't get all the 57 details right so that the protocol data tunnels through HTTP, with 58 intermediates unaware that another protocol is being carried. 59 Instead, there's a hand wave or two in the general direction of 60 modifying or upgrading the deployed proxies and firewalls (a much 61 harder problem than is usually acknowledged). 63 The second hole in the story is that firewall managers don't like HTTP 64 tunnelling. It makes it difficult to block or control non-HTTP 65 traffic without also slowing down the legitimate (real) HTTP traffic. 67 In the specific context of a presence information protocol, the 68 HTTP/firewall fantasy has an additional hole: there is no "reverse 69 path" in HTTP from the server to the client, and no particular reason 70 to expect all of the proxies and firewalls involved in a particular 71 client-to-server HTTP request to allow a distinct server-to-client 72 request, even if both client and server agree on the value of such a 73 request. 75 5. Reuse of well-understood technology 77 Even if a presence information protocol can't actually be HTTP (and 78 thereby cross tall firewalls in a single bound), perhaps it should be 79 like HTTP so that people can understand it readily and reuse their 80 existing code for clients, proxies, and servers. 82 But this is revealed to be fantasy when we start looking at detailed 83 proposals. The trouble is that HTTP itself is a reasonably 84 well-understood protocol only when confined to GET requests. As soon 85 as POST and PUT enter the mix, confusion usually follows. The IETF 86 WebDAV working group is building an interoperable and workable 87 semantics for creating and updating information on the Web: that is, 88 WebDAV is an effort (as yet unfinished!) to fix the fact that PUT and 89 POST are broken. 91 When a proposed protocol based on HTTP introduces new methods or 92 headers, those methods must be related to the existing HTTP methods, 93 headers, and ways of using them. It is not obvious that the use of 94 HTTP saves any effort for reader, writer, or implementor when these 95 issues are taken into account. 97 There is a relatively powerful and reusable piece of technology used 98 in HTTP that is relevant to presence information and instant 99 messaging: MIME. However, a presence information protocol can pick up 100 MIME without dragging HTTP along with it. 102 7. Almost the Right Protocol 104 We might think that HTTP is enough like a presence information 105 protocol, except for the "minor" addition of notifications and instant 106 messaging, that we might as well leverage the existing facilities for 107 retrieving state about people. This is not a bad theory, but properly 108 applied it starts with LDAP instead of HTTP. That is, if we believe that 109 the goal is to find information about people and resources, including 110 contact and rendezvous information, the more natural starting point is 111 a directory service. In this view, the role of a presence information 112 protocol is to serve as an extension to the existing naming & locating 113 services of a directory service, either by extending the directory 114 protocol itself or by operating alongside it. 116 8. Let's Use URLs 118 Finally, we might think that URLs represent a particularly good way to 119 represent people. A URL is not necessarily worse than other 120 representations for a low-level location mechanism, hidden from 121 users. But URLs are lousy for representing names for two reasons. 123 First, URLs are restricted to a weak subset of Latin-1. It is 124 unconscionable that a system intended for global use should build in 125 needless restrictions on accurately writing personal names. 127 Second, the definition of URLs recognizes the reality and value of 128 aliases, but makes those facilities available primarily for the host 129 name. Simply by using URLs as defined, We can recognize that two URLs 130 are "the same" if the host parts are aliases for the same machine. But 131 without defining additional mechanism, we cannot recognize that two 132 URLs are "the same" if the remainders are aliases for the same person! 133 And if we have to define that piece of machinery, it doesn't seem that 134 we are getting much value from the use of URLs. 136 9. Conclusion 138 At least some of the arguments for HTTP as a basis for a presence 139 information protocol -- ease of crossing firewalls, reuse of existing 140 technology, use of similar protocol, and the applicability of URLs -- 141 seem unconvincing. Perhaps there are other, better arguments for the 142 use of HTTP. In the absence of such arguments, HTTP seems like a 143 rather poor choice technically. Its popularity as a basis for 144 presence information protocols seems more driven by fantasies of 145 HTTP-like ubiquity than by rational thought. 147 10. References 149 [Calsyn] Martin Calsyn and Lisa Dusseault. "RVP: A Presence 150 Notification Protocol." Internet-Draft draft-calsyn-rvp-01.txt. 152 [Day] Mark Day. "Requirements for Presence and Instant Messaging." 153 Internet-Draft draft-day-rpim-00.txt. 155 [Dusseault] Lisa Dusseault. "Presence Information Protocol 156 Requirements." Internet-Draft draft-dusseault-pipr-00.txt 158 [Mohr] Gordon Mohr. "Widely Hosted Object Data Protocol 159 (WhoDP)". Internet-Draft draft-mohr-whodp-00.txt. 161 10. Author's Address 163 Mark Day 164 Lotus Development Corporation 165 55 Cambridge Parkway 166 Cambridge, MA 02142 167 USA 169 Mark_Day@lotus.com