--- /dev/null
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+<title>TEP Structure and Keywords</title>
+<meta name="author" content="Philip Levis" />
+<style type="text/css">
+
+/*
+:Author: David Goodger
+:Contact: goodger@users.sourceforge.net
+:date: $Date$
+:version: $Revision$
+:copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the HTML output of Docutils.
+*/
+body {
+ font-family: Times;
+ font-size: 16px;
+}
+
+.first {
+ margin-top: 0 ! important }
+
+.last {
+ margin-bottom: 0 ! important }
+
+.hidden {
+ display: none }
+
+a.toc-backref {
+ text-decoration: none ;
+ color: black }
+
+blockquote.epigraph {
+ margin: 2em 5em ; }
+
+dd {
+ margin-bottom: 0.5em }
+
+/* Uncomment (& remove this text!) to get bold-faced definition list terms
+dt {
+ font-weight: bold }
+*/
+
+div.abstract {
+ margin: 2em 5em }
+
+div.abstract p.topic-title {
+ font-weight: bold ;
+ text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning, div.admonition {
+ margin: 2em ;
+ border: medium outset ;
+ padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+ color: red ;
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title,
+div.admonition p.admonition-title {
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.dedication {
+ margin: 2em 5em ;
+ text-align: center ;
+ font-style: italic }
+
+div.dedication p.topic-title {
+ font-weight: bold ;
+ font-style: normal }
+
+div.figure {
+ margin-left: 2em }
+
+div.footer, div.header {
+ font-size: smaller }
+
+div.line-block {
+ display: block ;
+ margin-top: 1em ;
+ margin-bottom: 1em }
+
+div.line-block div.line-block {
+ margin-top: 0 ;
+ margin-bottom: 0 ;
+ margin-left: 1.5em }
+
+div.sidebar {
+ margin-left: 1em ;
+ border: medium outset ;
+ padding: 0em 1em ;
+ background-color: #ffffee ;
+ width: 40% ;
+ float: right ;
+ clear: right }
+
+div.sidebar p.rubric {
+ font-family: sans-serif ;
+ font-size: medium }
+
+div.system-messages {
+ margin: 5em }
+
+div.system-messages h1 {
+ color: red }
+
+div.system-message {
+ border: medium outset ;
+ padding: 1em }
+
+div.system-message p.system-message-title {
+ color: red ;
+ font-weight: bold }
+
+div.topic {
+ margin: 2em }
+
+h1 {
+ font-family: Arial, sans-serif;
+ font-size: 20px;
+}
+
+h1.title {
+ text-align: center;
+ font-size: 32px;
+}
+
+h2 {
+ font-size: 16px;
+ font-family: Arial, sans-serif;
+}
+
+h2.subtitle {
+ text-align: center }
+
+h3 {
+ font-size: 12px;
+ font-family: Arial, sans-serif;
+}
+
+hr {
+ width: 75% }
+
+ol.simple, ul.simple {
+ margin-bottom: 1em }
+
+ol.arabic {
+ list-style: decimal }
+
+ol.loweralpha {
+ list-style: lower-alpha }
+
+ol.upperalpha {
+ list-style: upper-alpha }
+
+ol.lowerroman {
+ list-style: lower-roman }
+
+ol.upperroman {
+ list-style: upper-roman }
+
+p.attribution {
+ text-align: right ;
+ margin-left: 50% }
+
+p.caption {
+ font-style: italic }
+
+p.credits {
+ font-style: italic ;
+ font-size: smaller }
+
+p.label {
+ white-space: nowrap }
+
+p.rubric {
+ font-weight: bold ;
+ font-size: larger ;
+ color: maroon ;
+ text-align: center }
+
+p.sidebar-title {
+ font-family: sans-serif ;
+ font-weight: bold ;
+ font-size: larger }
+
+p.sidebar-subtitle {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+p.topic-title {
+ font-weight: bold }
+
+pre.address {
+ margin-bottom: 0 ;
+ margin-top: 0 ;
+ font-family: serif ;
+ font-size: 100% }
+
+pre.line-block {
+ font-family: serif ;
+ font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+ margin-left: 2em ;
+ margin-right: 2em ;
+ background-color: #eeeeee;
+ border-color: #000000;
+ border-width: thin;
+ font-size: 14px
+}
+
+span.classifier {
+ font-family: sans-serif ;
+ font-style: oblique }
+
+span.classifier-delimiter {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+span.interpreted {
+ font-family: sans-serif }
+
+span.option {
+ white-space: nowrap }
+
+span.option-argument {
+ font-style: italic }
+
+span.pre {
+ white-space: pre }
+
+span.problematic {
+ color: red }
+
+table {
+ margin-top: 0.5em ;
+ margin-bottom: 0.5em }
+
+table.citation {
+ border-left: solid thin gray ;
+ padding-left: 0.5ex }
+
+table.docinfo {
+ margin: 2em 4em;
+}
+
+table.footnote {
+ border-left: solid thin black ;
+ padding-left: 0.5ex }
+
+td, th {
+ padding-left: 0.5em ;
+ padding-right: 0.5em ;
+ vertical-align: top }
+
+th.docinfo-name, th.field-name {
+ font-weight: bold ;
+ text-align: left ;
+ white-space: nowrap;
+ }
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+ font-size: 100% }
+
+tt {}
+
+ul.auto-toc {
+ list-style-type: none }
+
+</style>
+</head>
+<body>
+<div class="document" id="tep-structure-and-keywords">
+<h1 class="title">TEP Structure and Keywords</h1>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">1</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Best Current Practice</td>
+</tr>
+<tr><th class="docinfo-name">Status:</th>
+<td>Draft</td></tr>
+<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
+</tr>
+<tr><th class="docinfo-name">Author:</th>
+<td>Philip Levis</td></tr>
+<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">18-Oct-2004</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-06-13</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
+</tr>
+</tbody>
+</table>
+<div class="note">
+<p class="first admonition-title">Note</p>
+<p class="last">This document specifies a Best Current Practices for the
+TinyOS Community, and requests discussion and suggestions for
+improvements. Distribution of this memo is unlimited.</p>
+</div>
+<div class="section">
+<h1><a id="abstract" name="abstract">Abstract</a></h1>
+<p>This memo describes the structure all TinyOS Extension Proposal (TEP)
+documents follow, and defines the meaning of several key words in
+those documents.</p>
+</div>
+<div class="section">
+<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
+<p>In order to simplify management, reading, and tracking development,
+all TinyOS Extension Proposals (TEPs) MUST have a particular
+structure. Additionally, to simplify development and improve
+implementation interoperability, all TEPs MUST observe the meaning of
+several key words that specify levels of compliance. This document
+describes and follows both.</p>
+</div>
+<div class="section">
+<h1><a id="keywords" name="keywords">2. Keywords</a></h1>
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in TEP 1.</p>
+<p>Note that the force of these words is modified by the requirement
+level of the document in which they are used.</p>
+<div class="section">
+<h2><a id="must" name="must">2.1 MUST</a></h2>
+<p>MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the
+definition is an absolute requirement of the specification.</p>
+</div>
+<div class="section">
+<h2><a id="must-not" name="must-not">2.2 MUST NOT</a></h2>
+<p>MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the
+definition is an absolute prohibition of the specification.</p>
+</div>
+<div class="section">
+<h2><a id="should" name="should">2.3 SHOULD</a></h2>
+<p>SHOULD: This word, or the adjective "RECOMMENDED", mean that there
+may exist valid reasons in particular circumstances to ignore a
+particular item, but the full implications must be understood and
+carefully weighed before choosing a different course.</p>
+</div>
+<div class="section">
+<h2><a id="should-not" name="should-not">2.4 SHOULD NOT</a></h2>
+<p>SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that
+there may exist valid reasons in particular circumstances when the
+particular behavior is acceptable or even useful, but the full
+implications should be understood and the case carefully weighed
+before implementing any behavior described with this label.</p>
+</div>
+<div class="section">
+<h2><a id="may" name="may">2.5 MAY</a></h2>
+<p>MAY: This word, or the adjective "OPTIONAL", mean that an item is
+truly optional. One implementer may choose to include the item
+because a particular application requires it or because the
+implementer feels that it enhances the system while another
+implementer may omit the same item. An implementation which does not
+include a particular option MUST be prepared to interoperate with
+another implementation which does include the option, though perhaps
+with reduced functionality. In the same vein an implementation which
+does include a particular option MUST be prepared to interoperate with
+another implementation which does not include the option (except, of
+course, for the feature the option provides.)</p>
+</div>
+<div class="section">
+<h2><a id="guidance-in-the-use-of-these-imperatives" name="guidance-in-the-use-of-these-imperatives">2.6 Guidance in the use of these Imperatives</a></h2>
+<p>Imperatives of the type defined in this memo must be used with care
+and sparingly. In particular, they MUST only be used where it is
+actually required for interoperation or to limit behavior which has
+potential for causing harm (e.g., limiting retransmissions) For
+example, they must not be used to try to impose a particular method
+on implementors where the method is not required for
+interoperability.</p>
+</div>
+</div>
+<div class="section">
+<h1><a id="tep-structure" name="tep-structure">3. TEP Structure</a></h1>
+<p>TEPs have two major parts, a header and a body. The header states
+document metadata, for management and status. The body contains the
+content of the proposal.</p>
+<p>All TEPs MUST follow the TEP docutils template, and conform to
+reStructuredText standards <a class="footnote-reference" href="#id2" id="id1" name="id1">[1]</a>, to enable translation from
+reStructuredText to HTML and Latex.</p>
+<div class="section">
+<h2><a id="tep-header" name="tep-header">3.1 TEP Header</a></h2>
+<p>The TEP header has several fields which MUST be included, as well as
+others which MAY be included. The first six header fields MUST be
+included in all TEPs, in the order stated here.</p>
+<p>The first field is "TEP," and specifies the TEP number of the
+document. A TEP's number is unique.. This document is TEP 1. The
+TEP type (discussed below)
+determines how a number is assigned to it. Generally, when a document
+is ready to be a TEP, it is assigned the smallest available number.
+BCP TEPs start at 1 and all other TEPs (Documentary, Experimental,
+and Informational) start at 101.</p>
+<p>The second field states the name of the working group that produced
+the document. This document was produced by the Core Working Group.</p>
+<p>The third field is "Type," and specifies the type of TEP the document
+is. There are four types of TEP: Best Current Practice (BCP),
+Documentary, Informational, and Experimental. This document is Best
+Current Practice.</p>
+<p>Best Current Practice is the closest thing TEPs have to a standard: it
+represents conclusions from significant experience and work by its
+authors. Developers desiring to add code (or TEPs) to TinyOS SHOULD
+follow all current BCPs.</p>
+<p>Documentary TEPs describe a system or protocol that exists; a
+documentary TEP MUST reference an implementation that a reader can
+easily obtain. Documentary TEPs simplify interoperability when
+needed, and document TinyOS service implementations.</p>
+<p>Informational TEPs provide information that is of interest to the
+community. Informational TEPs include data gathered on radio behavior,
+hardware characteristics, other aspects of TinyOS software/hardware,
+organizational and logistic information,
+or experiences which could help the community achieve its goals.</p>
+<p>Experimental TEPs describe a completely experimental approach to a
+problem, which are outside the TinyOS core and will not necessarily
+become part of it. Unlike Documentary TEPs, Experimental TEPs may
+describe systems that do not have a reference implementation.</p>
+<p>The fourth field is "Status," which specifies the status of the TEP.
+A TEP status can either be "Draft," which means it is a work in
+progress, "Final," which means it is complete and will not change, or
+"Obsolete," which means it should no longer be considered. If a TEP is
+"Obsolete" because it has been replaced by another TEP, then the new
+TEP number should follow "Obsolete," such as "Obsolete by TEP 1231."</p>
+<p>If a TEP is Best Current Practices or Documentary, then it MUST
+include an additional field, "TinyOS-Version:," which states what
+version(s) of TinyOS the document pertains to. This document pertains
+to all versions of TinyOS, until made obsolete by a future TEP. This
+field MUST appear after the Status field and before the Author field.</p>
+<p>The final required field is Author, which states the names of the
+authors of the document. Full contact information should not be listed
+here (see Section 3.2).</p>
+<p>If a TEP is a Draft, then four additional fields MUST be included:
+Draft-Created, Draft-Modified, Draft-Version, and Draft-Discuss.
+Draft-Created states the date the document was created, Draft-Modified
+states when it was last modified. Draft-Version specifies the version
+of the draft, which MUST increase every time a modification is
+made. Draft-Discuss specifies the email address of a mailing list
+where the draft is being discussed. Final and Obsolete TEPs MUST NOT
+have these fields, which are for Drafts only.</p>
+</div>
+<div class="section">
+<h2><a id="tep-body" name="tep-body">3.2 TEP Body</a></h2>
+<p>The first element of the TEP body MUST be the title of the document. A
+TEP SHOULD follow the title with an Abstract, which gives a brief
+overview of the content of the TEP. Longer TEPs MAY, after the
+Abstract, have a Table of Contents. After the Abstract and Table of
+Contents there SHOULD be an Introduction, stating the problem the TEP
+seeks to solve and providing needed background information.</p>
+<p>If a TEP is Documentary, it MUST have a section entitled
+"Implementation," which instructs the reader how to obtain the
+implementation documented.</p>
+<p>If a TEP is Best Current Practices, it MUST have a section entitled
+"Reference," which points the reader to one or more reference uses of
+the practices.</p>
+<p>The last section of a TEP (but before citations, if there are any),
+entitled "Author's Address" or "Author's Addresses" MUST contain
+detailed author contact information.</p>
+</div>
+</div>
+<div class="section">
+<h1><a id="reference" name="reference">4. Reference</a></h1>
+<p>The reference use of this document is TEP 1 (itself).</p>
+</div>
+<div class="section">
+<h1><a id="acknowledgments" name="acknowledgments">5. Acknowledgments</a></h1>
+<p>The definitions of the compliance terms are a direct copy of
+definitions taken from IETF RFC 2119.</p>
+</div>
+<div class="section">
+<h1><a id="author-s-address" name="author-s-address">6. Author's Address</a></h1>
+<div class="line-block">
+<div class="line">Philip Levis</div>
+<div class="line">467 Soda Hall</div>
+<div class="line">UC Berkeley</div>
+<div class="line">Berkeley, CA 94720</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 510 290 5283</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:pal@cs.berkeley.edu">pal@cs.berkeley.edu</a></div>
+</div>
+</div>
+<div class="section">
+<h1><a id="citations" name="citations">7. Citations</a></h1>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id2">[1]</a></td><td>reStructuredText Markup Specification. <<a class="reference" href="http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html">http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html</a>></td></tr>
+</tbody>
+</table>
+</div>
+</div>
+</body>
+</html>
projects / tinyos-2.x.git / blobdiff