DOCSLIB.ORG

EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; and ORBITZ, LLC Petitioners

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; and ORBITZ, LLC Petitioners UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; AND ORBITZ, LLC Petitioners v. INTERNATIONAL BUSINESS MACHINES CORP. Patent Owner ____________ Case No. Unassigned Patent 6,374,359 ____________ PETITION FOR INTER PARTES REVIEW OF CLAIMS 1-16 OF U.S. PATENT NO. 6,374,359 Petition for IPR of U.S. Patent 6,374,359 TABLE OF CONTENTS I. INTRODUCTION ......................................................................................... 1 Summary of Unpatentability Grounds .................................................. 1 II. MANDATORY NOTICES, STANDING, AND FEES .............................. 1 Mandatory Notices ................................................................................ 1 Certification of Grounds for Standing ................................................... 3 Fees ........................................................................................................ 3 III. OVERVIEW OF THE ’359 Patent .............................................................. 3 Subject Matter of the ’359 Patent .......................................................... 3 Claims of the ’359 Patent ...................................................................... 5 Prosecution History of the ’359 Patent ................................................. 6 Ordinary Skill in the Art ........................................................................ 8 IV. SUMMARY OF PRIOR ART ...................................................................... 9 Reiche .................................................................................................... 9 Spinning the Web by Yuval Fisher ......................................................16 Stubbs ..................................................................................................19 Goodman .............................................................................................24 LDAP Draft and RFCs ........................................................................25 V. CLAIM CONSTRUCTION ........................................................................ 28 VI. THE CHALLENGED CLAIMS ARE UNPATENTABLE ..................... 35 Ground 1 ..............................................................................................35 Ground 2 ..............................................................................................45 Ground 3 ..............................................................................................58 Ground 4 ..............................................................................................64 Ground 5 ..............................................................................................72 i Petition for IPR of U.S. Patent 6,374,359 Ground 6 ..............................................................................................75 VII. CONCLUSION ............................................................................................ 77 ii Petition for IPR of U.S. Patent 6,374,359 LIST OF EXHIBITS1 1001 U.S. Patent No. 6,374,359 to Shrader et al. (“the ’359 Patent”) 1002 Expert Declaration of B. Keith Moore 1003 CV of B. Keith Moore 1004 File History of U.S. Patent No. 6,374,359 to Shrader et al. 1005 U.S. Patent No. 6,092,196 to Reiche (“Reiche”) 1006 Yuval Fisher, Spinning the Web (1996) (“Fisher”) 1007 Nesta Stubbs, One-time authentication for multiple Web servers?, post to the comp.infosystems.www.servers.misc group on July 3, 1996 (“Stubbs”) 1008 D. Kristol et al., “HTTP State Management Mechanism,” Internet RFC 2109 (Feb. 1997) (“RFC 2109”) 1009 R. Fielding et al., “Hypertext Transfer Protocol - HTTP/1.1,” Internet RFC 2068 (Jan. 1997) (“RFC 2068”) 1010 Danny Goodman, JavaScript Handbook, 1996 (“Goodman”) 1011 T. Howes et al., “The C LDAP Application Program Interface”, IETF Working Draft (Jul. 29, 1997) (“LDAP Draft”) 1012 Expert Declaration of James L. Mullins, Ph.D 1013 CV of James L. Mullins 1014 Memorandum in Support of Motion for Summary Judgment of Defendant Groupon, Inc., International Business Machines Corp. v. Groupon Inc., 1:16-cv-122, Dkt. 241, March 13, 2018 1 Citations in the Petition to Exhibits are made to native page numbering on the exhibits wherever possible. iii Petition for IPR of U.S. Patent 6,374,359 1015 Collected posts to the comp.infosystems.www.servers.misc group in thread with One-time authentication for multiple Web servers? 1016 Exhibit 1 to Mullins Declaration 1017 Exhibit 2 to Mullins Declaration 1018 RESERVED 1019 RESERVED 1020 S. Bradner, “The Internet Standards Process -- Revision 3,” Internet RFC 2026 (Oct. 1996) (“RFC 2026”) 1021 M. Horton, “Standard for Interchange of USENET Message,” Internet RFC 1036 (Dec. 1987) (“RFC 1036”) 1022 B. Reid, “USENET Readership Summary Report for July 1995,” (Aug. 6, 1995), available at https://groups.google.com/forum/#!original/news.lists/bt_reRadXYo/- 9tq-mbefFYJ 1023 B. Reid, “USENET Readership Report for July 1995,” (Aug. 6, 1995). available at https://groups.google.com/forum/#!original/news.lists/zCfHkoXchIg/ N41pFcwrUTQJ 1024 J. Linn, “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures,” Internet RFC 989 (Feb. 1987) (“RFC 989”) 1025 N. Borenstein, N .Freed. “MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies,”. Internet RFC 1341 (June 1992) (“RFC 1341”) 1026 T. Berners-Lee et al., “Uniform Resource Locators,” Internet RFC 1738 (Dec. 1994) (“RFC 1738”) 1027 T. Berners-Lee, D. Connolly, “Hypertext Markup Language – 2.0,” iv Petition for IPR of U.S. Patent 6,374,359 Internet RFC 1866 (Nov. 1995) (“RFC 1866”) 1028 “An Exploration of Dynamic Documents,” captured June 14, 1997, available at https://web.archive.org/web/19970614044340/http://home.netscape.co m/assist/net_sites/pushpull.html 1029 “Common Gateway Interface,” captured Dec. 10, 1998, available at https://web.archive.org/web/19971210170704/http://hoohoo.ncsa.uiuc. edu/cgi/intro.html 1030 M. Horton, R. Adams, “Standard for Interchange of USENET Messages,” Internet RFC 1036 (Dec. 1987) (“RFC 1036”) 1031 J.S. Quarterman, The Matrix: Computer Networks and Conferencing Systems Worldwide, 1990 (“Quarterman”) 1032 “Google Acquires Usenet Discussion Service and Significant Assets from Deja.com,” captured Feb. 16, 2001, available at https://web.archive.org/web/20010216202357/http://www.google.com /press/pressrel/pressrelease48.html 1033 “Google Acquires Deja’s Usenet Archive: Google Releases Beta Service in Transition,” captured Feb. 17, 2001, available at https://web.archive.org/web/20010217005302/http://groups.google.co m:80/ 1034 Google Groups Beta, captured May 12, 2001, available at https://web.archive.org/web/20010512173704/http://groups.google.co m:80/ 1035 “Full Usenet Archive Now Available,” Google Groups Beta, Captured May 7, 2012, available at https://web.archive.org/web/20010507171811/http://groups.google.co m/googlegroups/archive_announce.html 1036 “Google Groups Archive Information,” Dec. 21, 2001, available at https://groups.google.com/forum/message/raw?msg=news.admin.misc /1GuWaOCDgMc/x7PnQ5BQ7G0J. v Petition for IPR of U.S. Patent 6,374,359 1037 “20 Year Usenet Archive Now Available,” captured on Dec. 12, 2001, available at https://web.archive.org/web/20011212191924/http://www.google.com /googlegroups/archive_announce_20.html 1038 IETF Mail Archive, RFC 2068 publication, Jan. 2, 1997, available at https://mailarchive.ietf.org/arch/search/?q=subject%3A%28RFC+206 8%29 1039 E. Raymond, This is the Jargon File, Version 2.9.6, Aug. 16, 1991, available at http://jargon-file.org/archive/jargon-2.9.6.dos.txt 1040 V. Khera, Using Set-cookie and Location in the same header?, post to the comp.infosystems.www.authoring.cgi group on June 13, 1996 1041 M. Budash, HTTP Header Syntax, post to the comp.infosystems.www.authoring.cgi group on July 30, 1997 1042 D. Crichton, Setting a cookie and redirecting in the same perl script, post to the comp.infosystems.www.authoring.cgi group on Feb. 3, 1998 1043 C. Saia, Make clients forget passwords, post to the comp.infosystems.www.servers.unix group on Dec. 26, 1997 vi Petition for IPR of U.S. Patent 6,374,359 I. INTRODUCTION Petitioners request inter partes review (“IPR”) under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42.100 et seq. of Claims 1-16 (“the Challenged Claims”) of U.S. Patent No. 6,374,359 (“the ’359 Patent”). Petitioners assert the Challenged Claims are unpatentable and request review and cancellation of the Challenged Claims under 35 U.S.C. § 103. Summary of Unpatentability Grounds Ground Summary 1 Claims 1, 5, and 6 are obvious in view of Reiche and Fisher 2 Claims 2, 3 and 4 are obvious in view of Reiche, Fisher, and Stubbs 3 Claims 7, 8, and 9 are obvious in view of Reiche, Fisher, and the LDAP Draft 4 Claim 10 is obvious in view of Reiche, Fisher, and Goodman 5 Claims 11, 12, and 13 are obvious in view of Reiche, Fisher, Goodman, and Stubbs 6 Claims 14, 15, and 16 are obvious in view of Reiche, Fisher, Goodman, and the LDAP Draft II. MANDATORY NOTICES, STANDING, AND FEES Mandatory Notices Real Party in Interest: The real parties in interest are the Petitioners (Expedia, Inc.; Homeaway.com, Inc.; Hotels.com L.P.; Hotwire, Inc.; and Orbitz, LLC) and Expedia Group, Inc.; Hotels.com GP, LLC; HRN 99 Holdings; Travelscape LLC.; HomeAway Holdings, Inc., Orbitz Worldwide, Inc.; Orbitz Worldwide, LLC; and Orbitz, Inc. 1 Petition
Load more

Recommended publications
  • 2765 Sun Microsystems Category: Standards Track February 2000
    Network Working Group E. Nordmark Request for Comments: 2765 Sun Microsystems Category: Standards Track February 2000 Stateless IP/ICMP Translation Algorithm (SIIT) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. Acknowledgements This document is a product of the NGTRANS working group. Some text has been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for Section 1. Keith Moore provided a careful review of the document. Nordmark Standards Track [Page 1] RFC 2765 SIIT February 2000 Table of Contents 1. Introduction and Motivation.............................. 2 1.1. Applicability and Limitations......................
    [Show full text]
  • 3068 Microsoft Category: Standards Track June 2001 an Anycast
    Network Working Group C. Huitema Request for Comments: 3068 Microsoft Category: Standards Track June 2001 An Anycast Prefix for 6to4 Relay Routers Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." 1 Introduction According to [RFC3056], there are two deployment options for a 6to4 routing domain, depending on whether or not the domain is using an IPv6 exterior routing protocol. If a routing protocol is used, then the 6to4 routers acquire routes to all existing IPv6 networks through the combination of EGP and IGP. If no IPv6 exterior routing protocol is used, the 6to4 routers using a given relay router each have a default IPv6 route pointing to the relay router. This second case is typically used by small networks; for these networks, finding and configuring the default route is in practice a significant hurdle. In addition, even when the managers of these networks find an available route, this route often points to a router on the other side of the Internet, leading to very poor performance.
    [Show full text]
  • Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
    Internet Engineering Task Force (IETF) R. Fielding, Editor Request for Comments: 7230 Adobe Obsoletes: 2145, 2616 J. Reschke, Editor Updates: 2817, 2818 greenbytes Category: Standards Track June 2014 ISSN: 2070-1721 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Abstract The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 57411. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc72302. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info3) 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.
    [Show full text]
  • IPJ-V3N1-Rev11.Fm
    March 2000 Volume 3, Number 1 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals In This Issue Work on a new version of the Internet Protocol, known as IPv6, has been under way for several years in the IETF. There is still some debate From the Editor .......................1 about when and how IPv6 will be deployed. Proponents of IPv6 argue that the demand for new IP addresses will continue to rise to a point where we will simply run out of available IPv4 addresses and that we Routing IPv6 over IPv4............2 should, therefore, start deploying IPv6 today. Opponents argue that such a protocol transition will be too costly and painful for most organiza- IP Security..............................11 tions. They also argue that careful address management and the use of Network Address Translation (NAT) will allow continued use of the IPv4 address space for a very long time. Regardless of the timeframe, a QoS—Fact or Fiction? ...........27 major factor in the deployment of IPv6 is an appropriate transition strat- egy that allows existing IPv4 systems to communicate with new IPv6 Book Review..........................35 systems. A transition mechanism, known as “6to4,” is described in our first article by Brian Carpenter, Keith Moore, and Bob Fink. Call for Papers .......................38 In previous editions of this journal, we have looked at various security technologies for use in the Internet. Security mechanisms have been added at every layer of the protocol stack, and IP itself is no exception. Fragments ..............................39 IP Security, commonly known as “IPSec,” is being deployed in many public and private networks.
    [Show full text]
  • Use of HTTP State Management RFC 2964
    Network Working Group K. Moore Request for Comments: 2964 University of Tennessee BCP: 44 N. Freed Category: Best Current Practice Innosoft October 2000 Use of HTTP State Management Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. IESG Note The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. Abstract The mechanisms described in "HTTP State Management Mechanism" (RFC- 2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. 1. Introduction The HTTP State Management mechanism is both useful and controversial. It is useful because numerous applications of HTTP benefit from the ability to save state between HTTP transactions, without encoding such state in URLs. It is controversial because the mechanism has been used to accomplish things for which it was not designed and is not well-suited.
    [Show full text]
  • HTTP Cookies: Standards, Privacy, and Politics
    HTTP Cookies: Standards, Privacy, and Politics DAVID M. KRISTOL Bell Labs, Lucent Technologies How did we get from a world where cookies were something you ate and where “nontechies” were unaware of “Netscape cookies” to a world where cookies are a hot-button privacy issue for many computer users? This article describes how HTTP “cookies” work and how Netscape’s original specification evolved into an IETF Proposed Standard. I also offer a personal perspective on how what began as a straightforward technical specification turned into a political flashpoint when it tried to address nontechnical issues such as privacy. Categories and Subject Descriptors: C.2.2 [Computer-Communication Networks]: Network Protocols—Applications; K.2 [History of Computing]: Systems General Terms: Standardization, Security, Design Additional Key Words and Phrases: Cookies, HTTP, privacy, state management, World Wide Web 1. INTRODUCTION The topic of HTTP “cookies” has become at least slightly familiar to many In- ternet users. Articles in the popular press now regularly mention cookies in conjunction with privacy concerns. However, cookies were in use for over two years before they achieved notoriety,and some of that notoriety emerged around the same time as the appearance of the first formal standard for cookies, which had previously been informally described on Netscape Communications Corpo- ration’s Web site. The cookie standardization process began in April 1995 with a discussion on [www-talk]. In December of that year, the IETF undertook to write a cookie standard. After a series of Internet-Drafts got published in connec- tion with extensive public discussion on [http-wg] (and after noticeable de- lays due to IETF process), RFC 2109 [Kristol and Montulli 1997], HTTP State Management Mechanism, was published in February 1997 as an IETF Pro- posed Standard.
    [Show full text]
  • Kapanfangrechts
    KapAnfangRechts Literaturverzeichnis 1. Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, Stephen Williams und Edward A. Fox. Caching Proxies: Limitations and Potentials. In Proceedings of the Fourth International World Wide Web Conference, S. 119–133, Boston, Massachu- setts, Dezember 1995. 2. Adobe Systems Inc. Postscript Language Reference Manual. Addison-Wesley, Reading, Massachusetts, 2. Auflage, Dezember 1990. 3. Adobe Systems Inc. Postscript Language Reference Manual. Addison-Wesley, Reading, Massachusetts, 3. Auflage, Januar 1999. 4. Nabeel AI-Shamma, Robert Ayers, Richard Cohn, Jon Ferraiolo, Martin Newell, Roger K. de Bry, Kevin McCluskey und Jerry Evans. Precision Graphics Markup Language (PGML). World Wide Web Consortium, Note NOTE-PGML-19980410, April 1998. 5. Paul Albitz und Cricket Liu. DNS and BIND. O'Reilly & Associates, Inc., Sebastopol, California, Januar 1992. 6. Aldus Corporation. TIFF – Revision 6.0. Seattle, Washington, Juni 1992. 7. Harald Tveit Alvestrand. Tags for the Identification of Languages. Internet proposed standard RFC 1766, März 1995. 8. American National Standards Institute. Coded Character Set – 7-Bit American National Standard Code for Information Interchange. ANSI X3.4, 1992. 9. American National Standards Institute. Information Retrieval (Z39.50): Applica- tion Service Definition and Protocol Specification. ANSI/NISO Z39.501995, Juli 1995. 10. Mark Andrews. Negative Caching of DNS Queries (DNS NCACHE). Internet proposed standard RFC 2308, März 1998. 11. Farhad Anklesaria, Mark McCahill, Paul Lindner, David Johnson, Daniel Torrey und Bob Alberti. The Internet Gopher Protocol. Internet informational RFC 1436, März 1993. 12. Apple Computer, Inc., Cupertino, California. The TrueType Reference Manual, Oktober 1996. 13. Helen Ashman und Paul Thistlewaite, Herausgeber. Proceedings of the Seventh International World Wide Web Conference, Brisbane, Australia, April 1998.
    [Show full text]
  • 2956 Surfnet Expertisecentrum Bv Category: Informational October 2000
    Network Working Group M. Kaat Request for Comments: 2956 SURFnet ExpertiseCentrum bv Category: Informational October 2000 Overview of 1999 IAB Network Layer Workshop 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 is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. Table of Contents 1. Introduction . 2 2. Conclusions and Observations . 3 2.1 Transparency. 3 2.2 NAT, Application Level Gateways & Firewalls . 4 2.3 Identification and Addressing . 4 2.4 Observations on Address Space . 5 2.5 Routing Issues. 5 2.6 Observations on Mobility. 6 2.7 DNS Issues. 7 2.8 NAT and RSIP. 7 2.9 NAT, RSIP and IPv6. 8 2.10 Observations on IPv6. 9 3. Recommendations. 10 3.1 Recommendations on Namespace . 10 3.2 Recommendations on RSIP. 10 3.3 Recommendations on IPv6. 10 3.4 Recommendations on IPsec . 11 Kaat Informational [Page 1] RFC 2956 1999 IAB Network Layer Workshop October 2000 3.5 Recommendations on DNS .
    [Show full text]
  • 2765 Sun Microsystems Category: Standards Track February 2000
    Network Working Group E. Nordmark Request for Comments: 2765 Sun Microsystems Category: Standards Track February 2000 Stateless IP/ICMP Translation Algorithm (SIIT) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. Acknowledgements This document is a product of the NGTRANS working group. Some text has been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for Section 1. Keith Moore provided a careful review of the document. Nordmark Standards Track [Page 1] RFC 2765 SIIT February 2000 Table of Contents 1. Introduction and Motivation.............................. 2 1.1. Applicability and Limitations......................
    [Show full text]
  • 3834 University of Tennessee Category: Standards Track August 2004
    Network Working Group K. Moore Request for Comments: 3834 University of Tennessee Category: Standards Track August 2004 Recommendations for Automatic Responses to Electronic Mail Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. 1. Introduction Many programs which automatically respond to email are currently in use. Although these programs vary widely in their function, several problems with this class of programs have been observed, including: significant numbers of useless or unwanted response and responses sent to inappropriate addresses, and occasional incidences of mail loops or "sorcerer's apprentice" mode.
    [Show full text]
  • Arxiv:Cs/0105018V1 [Cs.SE] 9 May 2001
    · 1 Contents 1 Introduction 3 2 What are Cookies? Why are they Useful? 4 2.1 An Introduction to Hypertext Transfer Protocol (HTTP) . ..... 4 2.2 HowDoCookiesWork? ......................... 5 2.3 Proxies................................... 6 2.4 WhyCookies?............................... 6 2.5 HowAreCookiesUsed? ......................... 7 3 The IETF Standards Process 8 4 RFCs2109and2965:ABriefHistory 9 4.1 IntheBeginning... ........................... 9 4.2 RFC 2109: December, 1995to February,1997 . 10 4.3 RFC2965: February,1997toOctober,2000 . 12 4.3.1 Fixing the Incompatibility . 12 4.3.2 Unverifiable Transactions and Certified Cookies . ... 12 4.3.3 DeadlockandResolution . 12 5 Privacy/Politics 13 5.1 FederalTradeCommission. 13 5.2 W3CandP3P .............................. 14 5.3 IndustrySelf-Regulation . 14 5.4 Third-PartyCookies . .. .. .. .. .. .. .. .. .. .. .. 14 5.5 DoUsersCare?.............................. 15 6 Lessons Learned 16 6.1 WritingStandardsIsHard. 16 6.2 ZombieTopics .............................. 16 6.3 ReconcilingIncompatibleGoals . 17 6.3.1 Domain-matchingRules . 17 6.3.2 Compatibility and Deployment . 17 arXiv:cs/0105018v1 [cs.SE] 9 May 2001 6.4 SpeakNow,orForeverHoldYourPeace . 17 6.5 How Wide is the World Wide Web? . 18 6.6 Technical Decisions May Have Social Consequences . ..... 18 6.7 HowtoDoitBetter ........................... 19 6.7.1 Involvethestakeholders . 19 6.7.2 Separatepolicyandmechanism . 19 6.7.3 Avoidlily-gilding. 20 7 Conclusions 20 7.1 TimingMatters.............................. 20 7.2 OntheBrightSide... .......................... 21 7.3 Summary ................................. 22 7.4 WhyDidIStickWithIt? ........................ 22 2 · David M. Kristol 8 Acknowledgements 22 Appendix 24 A History of RFC 2109, HTTP State Management Mechanism 24 A.1 TheStateSub-GroupForms. 24 A.2 TechnicalDetails: Netscape’sCookies . ... 25 A.2.1 Server to Client: Set-Cookie .................. 25 A.2.2 Client to Server: Cookie ....................
    [Show full text]
  • Jay P. Kesan* & R
    ARTICLE DECONSTRUCTING CODE JAY P. KESAN* & RAJIV C. SHAH** I. INTRODUCTION ............................................................................. 279 II. THE CASE STUDIES: THE DEVELOPMENT OF CODE WITHIN INSTITUTIONS ...................................................... 289 A. WORLD WIDE WEB .......................................................... 290 1. LIBWWW............................................................................ 290 2. NCSA MOSAIC ................................................................. 292 B. COOKIES ............................................................................ 297 1. NETSCAPE’S COOKIES....................................................... 297 2. THE IETF’S STANDARD FOR COOKIES............................ 301 C. PLATFORM FOR INTERNET CONTENT SELECTION ......... 305 D. APACHE ............................................................................. 311 III. LEGISLATIVE BODIES: SOCIETAL INSTITUTIONS THAT DEVELOP CODE.................................................................. 314 A. UNIVERSITIES .................................................................... 315 B. FIRMS................................................................................. 318 C. CONSORTIA ....................................................................... 320 D. OPEN SOURCE MOVEMENT.............................................. 325 IV. CAMPAIGN CONTRIBUTIONS AND SPECIAL INTERESTS: INFLUENCES THAT SHAPE THE DEVELOPMENT OF CODE ......... 328 A. UNIVERSITIES ...................................................................
    [Show full text]