[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/html tep1.html, 1.1, 1.2
Phil Levis
scipio at users.sourceforge.net
Wed Dec 15 14:49:35 PST 2004
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/html
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24118/html
Modified Files:
tep1.html
Log Message:
Makefile for teps. Stylesheet is clearly the wrong way to do it in the long
term (disconnected clients will get a bad format), but I haven't
thought through the best way to do it yet.
Index: tep1.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/html/tep1.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep1.html 21 Oct 2004 00:06:12 -0000 1.1
--- tep1.html 15 Dec 2004 22:49:33 -0000 1.2
***************
*** 7,11 ****
<title>TEP structure and key words</title>
<meta name="author" content="Philip Levis" />
! <link rel="stylesheet" href="stylesheets/tep2.css" type="text/css" />
</head>
<body>
--- 7,11 ----
<title>TEP structure and key words</title>
<meta name="author" content="Philip Levis" />
! <link rel="stylesheet" href="http://www.cs.berkeley.edu/~pal/public/tep.css" type="text/css" />
</head>
<body>
***************
*** 29,35 ****
<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">$Revision$</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">$Date$</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-1.2WG List <tinyos at barnowl.org></td>
--- 29,35 ----
<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.2</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2004-12-10</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS-1.2WG List <tinyos at barnowl.org></td>
***************
*** 39,66 ****
<div class="document" id="tep-structure-and-key-words">
<div class="note">
! <p class="admonition-title first">Note</p>
! This document specifies a Best Current Practices for the
TinyOS Community, and requests discussion and suggestions for
! improvements. Distribution of this memo is unlimited.</div>
<div class="section" id="abstract">
<h1><a name="abstract">Abstract</a></h1>
! <p>This memo describes the structure all TinyOS Extension Proposal
! documents follow, and defines the meaning of several key words.</p>
</div>
<div class="section" id="introduction">
<h1><a 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" id="keywords">
<h1><a 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>
--- 39,67 ----
<div class="document" id="tep-structure-and-key-words">
<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" id="abstract">
<h1><a 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" id="introduction">
<h1><a 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" id="keywords">
<h1><a 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>
***************
*** 93,106 ****
<h2><a 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" id="guidance-in-the-use-of-these-imperatives">
--- 94,107 ----
<h2><a 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" id="guidance-in-the-use-of-these-imperatives">
***************
*** 109,113 ****
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 retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
--- 110,114 ----
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
***************
*** 128,197 ****
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.
! This document is TEP 1.</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.
! Compliance with Documentary TEPs is entirely OPTIONAL; they
! exist is to simplify interoprability when it is needed, and to 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,
or experiences which would help the community it its goals. It is
! RECOMMENDED that TEPs be aware of and consider Informational TEPs
! of relevance to its particular topic.</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.
! Experimental TEPs may describe systems that do not have a reference
! implementation (as Documentary ones do).</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" id="tep-body">
<h2><a 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 a reference use of the practices.</p>
! <p>The last section of a TEP (but before references, if there are any),
! entitled "Author's Address" or "Author's Addresses" MUST contain detailed
! author contact information.</p>
</div>
</div>
--- 129,199 ----
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. This document is TEP 1.</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. Compliance with Documentary TEPs is entirely OPTIONAL;
! they exist is to simplify interoperability when it is needed, and to
! 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,
or experiences which would help the community it its goals. It is
! RECOMMENDED that TEPs be aware of and consider Informational TEPs of
! relevance to its particular topic.</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. Experimental TEPs may describe systems that do not
! have a reference implementation (as Documentary ones do).</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" id="tep-body">
<h2><a 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>
***************
*** 202,207 ****
<div class="section" id="acknowledgments">
<h1><a 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" id="author-s-address">
--- 204,209 ----
<div class="section" id="acknowledgments">
<h1><a 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" id="author-s-address">
***************
*** 220,224 ****
<div class="section" id="citations">
<h1><a name="citations">7. Citations</a></h1>
! <table class="citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
--- 222,226 ----
<div class="section" id="citations">
<h1><a name="citations">7. Citations</a></h1>
! <table class="docutils citation" frame="void" id="rst" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
***************
*** 228,237 ****
</div>
</div>
- <hr class="footer" />
- <div class="footer">
- <a class="reference" href="tep1.txt">View document source</a>.
- Generated on: 2004-10-21 00:17 UTC.
- Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
- </div>
</body>
</html>
--- 230,233 ----
More information about the Tinyos-beta-commits
mailing list