idnits 2.17.1 draft-pfeiffer-remoteaccess-00.txt: -(238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(339): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 29 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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.) -- The document date (January 2003) is 7770 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 46 looks like a reference -- Missing reference section? '3' on line 65 looks like a reference -- Missing reference section? '4' on line 287 looks like a reference -- Missing reference section? '5' on line 287 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 O. Pfeiffer 3 Internet Draft ESAcademy 4 Document: draft-pfeiffer-remoteaccess-00.txt P. Lukowicz 5 Expires: July 2003 ETH 6 Category: Best Current Practice January 2003 8 Remote Access to Embedded Devices 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The aim of this document is to standardize remote access options to 33 parameters of embedded devices with limited resources. Typically 34 such devices are based on 8-bit or 16-bit microcontrollers with 35 limited memory (64K or less) and a low operating frequency (20 MHz or 36 less). The protocol described in this document uses existing markup 37 formats to specify modifiable parameters of embedded devices and 38 existing protocols to transfer these parameters between clients and 39 servers. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [2]. 47 Table of Contents 49 1. Introduction...................................................2 50 1.1 Terminology and Abbreviations..............................3 51 2. Remote Access Parameter Description Format (RAPDF).............5 52 2.1 RAPDF Outline..............................................5 53 2.2 Storing the RAPDF..........................................6 54 3. Protocols and Formats Used.....................................7 55 4. General RAPDF Usage Example....................................7 56 Security Considerations...........................................8 57 References........................................................8 58 Appendix A � RAPDF Examples.......................................9 59 Author's Addresses...............................................12 61 1. Introduction 63 Remote access to embedded devices in our homes, factories, and 64 vehicles or to personal mobile electronic appliances becomes reality. 65 The RFC2324 [3] published on April 1st, 1998 was a humorous approach: 66 getting a coffee machine online and needing a Hyper Text Coffee Pot 67 Control Protocol (HTCPCP/1.0) seemed to be funny at that time. 69 Today RFC2324 does not sound as funny anymore - it is closer to 70 reality today than it was on its publishing date. There is a clear 71 drive in the industry to Internet-enable embedded device like climate 72 control units and appliances - and coffee machines. 74 There are attempts by several companies to Internet-enable their 75 products � with some companies inventing their own proprietary 76 protocols and methods on how to allow remote access via the Internet. 78 Unfortunately this approach is not user-friendly. Users have to get 79 acquainted with different methods and tools on how to access their 80 devices via email, web or other services � and none of them are 81 compatible with each other. 83 The goal of this document is to find a common ground for remote 84 access functionality � from the client viewpoint. No matter what 85 kind of embedded system is connected to the Internet the client 86 should be able to expect some standardized methods for the remote 87 access using common services like email, regular web browsers or 88 minimized web browsers for PDAs or mobile phones,. 90 This document does not invent any new Internet technologies - it just 91 RECOMMENDS how existing protocols and methods should be used to offer 92 users standardized methods for remote access. 94 For the scope of this document it does not matter how an embedded 95 device is connected to the Internet. Connection can be directly or 96 via a specialized gateway for embedded devices that might use a 97 simple serial link or other lower cost network or fieldbus to 98 exchange information with the embedded devices. However, this 99 document assumes that there is at least one Internet node that 100 manages one or more embedded device(s) and that offers the 101 standardized protocols and methods described in this document to 102 allow remote access to the embedded device(s). We distinguish 103 between three types of devices: 105 1) Remote Access Client (RAC): the system that attempts to access an 106 embedded device over the Internet. 107 2) Remote Access Server (RAS): the system that manages the internet 108 access to one or multiple embedded device and 109 3) Remote Access Device (RAD): the device that is to be accessed 110 through the Internet. 112 In some implementations, the RAS might be implemented directly with 113 one RAD. In others, one RAS will be able to handle multiple RADs. 115 1.1 Terminology and Abbreviations 117 RAD � Remote Access Device 118 The embedded device(s) that can be accessed via the Internet. 120 RAS � Remote Access Server 121 This is the access point for the Remote Access Client. The RAS 122 manages one or multiple Remote Access Devices and provides the 123 Internet connectivity. The RAS can be part of an embedded device or 124 part of a gateway connecting several Remote Access Devices to the 125 Internet. 127 RAC � Remote Access Client 128 A software or hardware client used to provide remote access to a 129 Remote Access Server. This can be a web browser, email client, PDA 130 or any other internet connected device. 132 RAPDF � Remote Access Parameter Description Format 133 A format that describes all Remote Access Devices and their 134 configurable parameters connected to a single Remote Access Server. 136 +------------+ 137 +------------+ ! RAS A ! 138 ! RAC ! <--> INTERNET <--> ! with RAPDF ! 139 +------------+ +------------+ 140 ! RAD 1 ! 141 +------------+ 143 FIGURE 1 � Remote Access to a RAS/RAD combination device 145 Figure 1 shows a Remote Access Device (RAD 1) that directly 146 implements a Remote Access Server (RAS A). The RAS A can directly 147 serve RAPDF information to a Remote Access Client (RAC). 149 +------------+ 150 +------------+ ! Web server ! 151 ! RAS B ! <--> INTERNET <--> ! with RAPDF ! 152 +------------+ ! info from ! 153 ! ! RAD 2-4 ! 154 E N ! +------------+ +------------+ 155 m e +---! RAD 2 ! 156 b t ! +------------! 157 e w ! 158 d o ! +------------+ 159 d r +---! RAD 3 ! 160 e k ! +------------! 161 d ! 162 ! +------------+ 163 +---! RAD 4 ! 164 +------------! 166 FIGURE 2 � Remote Access to devices on a local, embedded network 168 Figure 2 shows how one Remote Access Server (RAS B) can handle 169 multiple Remote Access Devices (RAD 2-4). The RADs can be connected 170 to the RAS via a local, low-cost serial network or fieldbus. 171 Depending on resources available to RAS and RAD, the RAS MAY retrieve 172 the RAPDF information from a web server instead from the RAD itself, 173 after the appropriate URL was reported to the RAS by each RAD. 175 2. Remote Access Parameter Description Format (RAPDF) 177 Every remote access devices has certain parameters/variables that we 178 want to be able to read or write through an Internet connection. 180 All accessible parameters (both, read and write) of a certain device 181 MUST be defined using the Remote Access Parameter Description Format 182 (RAPDF). 184 2.1 RAPDF Outline 186 RAPDF is based on HTML 4.0 [4] and obeys the following rules: 188 1.) The header section MUST include the META tag 190 192 2.) The body section MUST include AT LEAST ONE HTML FORM. The name 193 of the form and the action identifies exactly one RAD (Remote Access 194 Device). For example: 196
198 ... 199
201 Additionally, it is RECOMMENDED to use the