GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5497

Network Working Group T. Clausen Request for Comments: 5497 LIX, Ecole Polytechnique Category: Standards Track C. Dearlove

                                                       BAE Systems ATC
                                                            March 2009
  Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)

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) 2009 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 in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Abstract

 This document describes a general and flexible TLV (type-length-value
 structure) for representing time-values, such as an interval or a
 duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/
 message format.  It defines two Message TLVs and two Address Block
 TLVs for representing validity and interval times for MANET routing
 protocols.

Clausen & Dearlove Standards Track [Page 1] RFC 5497 Time TLV March 2009

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Motivation and Rationale . . . . . . . . . . . . . . . . .  3
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6
 4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  6
 5.  Representing Time  . . . . . . . . . . . . . . . . . . . . . .  6
 6.  General Time TLV Structure . . . . . . . . . . . . . . . . . .  7
   6.1.  Single-Value Time TLVs . . . . . . . . . . . . . . . . . .  8
   6.2.  Multi-Value Time TLVs  . . . . . . . . . . . . . . . . . .  9
 7.  Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.1.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
   7.2.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
 8.  Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10
   8.1.  INTERVAL_TIME TLV  . . . . . . . . . . . . . . . . . . . . 10
   8.2.  VALIDITY_TIME TLV  . . . . . . . . . . . . . . . . . . . . 11
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.1.  Expert Review: Evaluation Guidelines . . . . . . . . . . . 11
   9.2.  Message TLV Types  . . . . . . . . . . . . . . . . . . . . 12
   9.3.  Address Block TLV Types  . . . . . . . . . . . . . . . . . 12
 10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
   11.2. Informative References . . . . . . . . . . . . . . . . . . 13
 Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 14

Clausen & Dearlove Standards Track [Page 2] RFC 5497 Time TLV March 2009

1. Introduction

 The generalized packet/message format [RFC5444] specifies a signaling
 format that MANET routing protocols can employ for exchanging
 protocol information.  This format presents the ability to express
 and associate attributes to packets, messages, or addresses, by way
 of a general TLV (type-length-value) mechanism.
 This document specifies a general Time TLV structure, which can be
 used by any MANET routing protocol that needs to express either
 single time-values or a set of time-values with each time-value
 associated with a range of hop counts, as provided by the Message
 Header of [RFC5444].  This allows a receiving node to determine a
 single time-value if either it knows its hop count from the
 originator node or the Time TLV specifies a single time-value.
 A time-value is, in this context, not an "absolute point in time",
 but rather an interval or a duration.  An instance of a Time TLV can,
 therefore, express an interval or a duration such as "10 seconds".
 This document also specifies two Message TLV Types, which use the TLV
 structure proposed.  These TLV Types are INTERVAL_TIME and
 VALIDITY_TIME, specifying, respectively, the maximum time before
 another message of the same type as this message from the same
 originator should be received, and the duration for which the
 information in this message is valid after receipt.  Note that, if
 both are present, then the latter will usually be greater than the
 former in order to allow for possible message loss.
 This document also specifies two Address Block TLV Types, which use
 the TLV structure proposed.  These TLV Types are INTERVAL_TIME and
 VALIDITY_TIME, defined equivalently to the two Message TLVs with the
 same names.

1.1. Motivation and Rationale

 The Time TLV structure, specified in this document, is intended to be
 used as a component in a MANET routing protocol, e.g., to indicate
 the expected spacing between successive transmissions of a given
 Message Type, by including a Time TLV in transmitted messages.
 Some MANET routing protocols may employ very short spacing for some
 messages and very long spacing for others, or may change the message
 transmission rate according to observed behavior.  For example, if a
 network is observed at some point in time to exhibit a highly dynamic
 topology, a very short (sub-second) message spacing could be
 appropriate, whereas if the network later is observed to stabilize,
 multi-hour message spacing may become appropriate.  Different MANET

Clausen & Dearlove Standards Track [Page 3] RFC 5497 Time TLV March 2009

 routing protocols and different deployments of MANET routing
 protocols may have different granularity requirements and bounds on
 shortest and longest spacing between successive message
 transmissions.
 In addition, MANET routing protocol deployments typically use
 bandwidth-limited wireless network interfaces, and therefore prefer
 to trade off computational complexity for a saving in the number of
 bits transmitted.  This is practical in this case, because the
 intended usages of Time TLVs, including the specified examples of
 message interval time and information validity time, do not require
 high-precision values of time.
 The Time TLV structure, specified in this document, caters to these
 characteristics by:
 o  encoding time-values, such as an interval or a duration, in an
    8-bit field; while
 o  allowing these time-values to range from "very small" (e.g.,
    1/1024 second) to "very long" (e.g., 45 days); and
 o  allowing a MANET routing protocol, or a deployment, to
    parameterize this (e.g., to attain finer granularity at the
    expense of a lower upper bound) through a single parameter, C.
 The parameter C must be the same for all MANET routers in the same
 deployment.
 The TLV mechanism as specified in [RFC5444] allows associating a
 "value" to either a packet, a message, or to addresses.  The data
 structure for doing so -- the TLV -- is identical in each of the
 three cases; however, the TLV's position in a received packet allows
 determining if that TLV is a "Packet TLV" (it appears in the Packet
 Header, before any messages), a "Message TLV" (it appears in the TLV
 Block immediately following a Message Header), or an "Address Block
 TLV" (it appears in the TLV Block immediately following an Address
 Block).
 While TLVs may be structurally identical, that which they express may
 be different.  This is determined from the kind (packet, message, or
 Address Block) and type of the TLV.  For example, one TLV might
 associate a lifetime to an address, another a content sequence number
 to a message, and another a cryptographic signature to a packet.  For
 this reason, [RFC5444] specifies separate registries for Packet TLV
 Types, Message TLV Types, and Address Block TLV Types, and it does
 not specify any structure in the TLV Value field.

Clausen & Dearlove Standards Track [Page 4] RFC 5497 Time TLV March 2009

 The TLVs defined in this document express, essentially, that "this
 information will be refreshed within X seconds" and that "this
 information is valid for X seconds after being received", each
 allowing the "X seconds" to be specified as a function of the number
 of hops from the originator of the information.  This document
 specifies a general format allowing expressing and encoding this as
 the value field of a TLV.  This representation uses a compact (8-bit)
 representation of time, as message size is an issue in many MANETs,
 and the offered precision and range is appropriate for MANET routing
 protocols.
 A TLV of this format may be used for packets, messages, or addresses.
 For example, a proactive MANET routing protocol periodically
 reporting link-state information could include a TLV of this format
 as a Message TLV.  This may indicate a different periodicity in
 different scopes (possibly frequently up to a few hops, less
 frequently beyond that) because some messages may be sent with
 limited scope, as specified in [RFC5444].  A reactive MANET routing
 protocol could include a TLV of this format as an Address Block TLV
 for reporting the lifetime of routes to individual addresses.
 In addition to defining the general format as outlined above, this
 document requests IANA assignments for INTERVAL_TIME and
 VALIDITY_TIME TLVs.  These IANA assignments are requested in this
 document in order to avoid interdependencies between otherwise
 unrelated MANET protocols and in order to not exhaust the TLV Type
 spaces by having different protocols request types for essentially
 identical data structures.  Only Message TLVs and Address Block TLVs
 are requested, as these are those for which a need has been
 demonstrated.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].
 Additionally, this document uses terminology from [RFC5444], and
 introduces the following terminology:
 hop count  - the number of hops from the message originator to the
    message recipient.  This is defined to equal the <msg-hop-count>
    field in the <msg-header> element defined in [RFC5444], if
    present, after it is incremented on reception.  If the <msg-hop-
    count> field is not present, or in a Packet TLV, then hop count is
    defined to equal 255.

Clausen & Dearlove Standards Track [Page 5] RFC 5497 Time TLV March 2009

 time-value  - a time, measured in seconds.
 time-code  - an 8-bit field, representing a time-value.

3. Applicability Statement

 The TLV structure described in this document is applicable whenever a
 single time-value, or a time-value that varies with the number of
 hops from the originator of a message, is required in a protocol
 using the generalized MANET packet/message format [RFC5444].
 Examples of time-values that may be included in a protocol message
 are:
 o  The maximum time interval until the next message of the same type
    is to be generated by the message's originator node.
 o  The validity time of the information with which the time-value is
    associated.
 Either of these may vary with the hop count between the originating
 and receiving nodes, e.g., if messages of the same type are sent with
 different hop limits as defined in [RFC5444].
 Parts of this document have been generalized from material in the
 proactive MANET routing protocol OLSR (Optimized Link State Routing
 Protocol) [RFC3626].

4. Protocol Overview and Functioning

 This document does not specify a protocol nor does it mandate
 specific node or protocol behavior.  Rather, it outlines mechanisms
 for encoding time-values using the TLV mechanism of [RFC5444].

5. Representing Time

 This document specifies a TLV structure in which time-values are each
 represented in an 8-bit time-code, one or more of which may be used
 in a TLV's <value> field.  Of these 8 bits, the least significant 3
 bits represent the mantissa (a), and the most significant 5 bits
 represent the exponent (b), so that:
 o  time-value := (1 + a/8) * 2^b * C
 o  time-code := 8 * b + a

Clausen & Dearlove Standards Track [Page 6] RFC 5497 Time TLV March 2009

 All nodes in the MANET MUST use the same value of the constant C,
 which will be specified in seconds, hence so will be all time-values.
 C MUST be greater than 0 seconds.  Note that ascending values of the
 time-code represent ascending time-values; time-values may thus be
 compared by comparison of time-codes.
 An algorithm for computing the time-code representing the smallest
 representable time-value not less than the time-value t is:
 1.  find the largest integer b such that t/C >= 2^b;
 2.  set a := 8 * (t / (C * 2^b) - 1), rounded up to the nearest
     integer;
 3.  if a = 8, then set b := b + 1 and set a := 0;
 4.  if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value
     can be represented by the time-code 8 * b + a, otherwise it
     cannot.
 The minimum time-value that can be represented in this manner is C.
 The maximum time-value that can be represented in this manner is 15 *
 2^28 * C, or about 4.0 * 10^9 * C.  If, for example, C = 1/1024
 second, then this is about 45 days.
 A protocol using this time representation MUST define the value of C.
 A protocol using this specification MAY specify that the all-bits
 zero time-value (0) represents a time-value of zero and/or that the
 all-bits one time-value (255) represents an indefinitely large time-
 value.

6. General Time TLV Structure

 The following data structure allows the representation of a single
 time-value, or of a default time-value plus pairs of (time-values,
 hop counts) for when hop-count-dependent time-values are required.
 The time-values are represented as time-codes as defined in
 Section 5.  This <time-data> data structure is specified, using the
 regular expression syntax of [RFC5444], by:
     <time-data> = (<time-code><hop-count>)*<time-code>
 where:
 <time-code>  is an 8-bit unsigned integer field containing a time-
    code as defined in Section 5.

Clausen & Dearlove Standards Track [Page 7] RFC 5497 Time TLV March 2009

 <hop-count>  is an 8-bit unsigned integer field specifying a hop
    count from the message originator.
 A <time-data> structure thus consists of an odd number of octets;
 with a repetition factor of n for the (time, hop count) pairs in the
 regular expression syntax, it contains 2n+1 octets.  On reception, n
 is determined from the length.
 A <time-data> field may be thus represented by:
     <t_1><d_1><t_2><d_2> ... <t_i><d_i> ...  <t_n><d_n><t_default>
 <d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence,
 with <d_n> < 255.  Then, at the receiving node's hop count from the
 originator node, the time-value indicated is that represented by the
 time-code:
 o  <t_1>, if n > 0 and hop count <= <d_1>;
 o  <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such
    that 1 <= i < n;
 o  <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>.
 If included in a message without a <msg-hop-count> field in its
 Message Header, or in a Packet TLV, then the form of this data
 structure with a single time-code in <time-data> (i.e., n = 0) SHOULD
 be used.

6.1. Single-Value Time TLVs

 The purpose of a single value Time TLV is to allow a single time-
 value to be determined by a node receiving an entity containing the
 Time TLV, based on its hop count from the entity's originator.  The
 Time TLV may contain information that allows that time-value to be a
 function of the hop count; thus, different receiving nodes may
 determine different time-values.
 A single-value Time TLV may be a Packet TLV, a Message TLV, or an
 Address Block TLV.
 A Time TLV that has the tismultivalue flag cleared ('0') in its <tlv-
 flags> field, as defined in [RFC5444], contains a single <time-data>,
 as defined above, in its <value> field.  For such a Time TLV:
 o  The <length> field in the TLV MUST contain the value 2n+1, with n
    being the number of (time-value, hop count) pairs in the Time TLV.

Clausen & Dearlove Standards Track [Page 8] RFC 5497 Time TLV March 2009

 o  The number of (time-value, hop count) pairs MUST be identified by
    inspecting the <length> field in the TLV.  The number of such
    pairs, n, is:
  • n := (<length> - 1) / 2
    This MUST be an integer value.

6.2. Multi-Value Time TLVs

 The purpose of a multi-value Time TLV is to associate a set of <time-
 data> structures to an identically sized set of addresses, as
 described in [RFC5444].  For each of these <time-data> structures, a
 single time-value can be determined by a node receiving an entity
 containing the Time TLV, based on its hop count from the entity's
 originator.  The Time TLV may contain information that allows that
 time-value to be a function of the hop count, and thus different
 receiving nodes may determine different time-values.
 Multi-value Time TLVs MUST be Address Block TLVs.  A multi-value Time
 TLV MUST NOT be a Packet TLV or Message TLV.
 A Time TLV that has the tismultivalue flag set ('1') in its <tlv-
 flags> field, as defined in [RFC5444], contains a sequence of <time-
 data> structures, as defined above, in its <value> field.  For such a
 Time TLV:
 o  The <length> field in the TLV MUST contain the value m * (2n+1),
    with n being the number of (time-value, hop count) pairs in the
    Time TLV, and m being number-values as defined in [RFC5444].
 o  The number of <time-data> structures included in the <value> field
    is equal to number-values as defined in [RFC5444].
 o  The number of (time-value, hop count) pairs in each <time-data>
    structure MUST be the same, and MUST be identified by inspecting
    the <length> field in the TLV and using number-values as defined
    in [RFC5444].  The number of such pairs in each <time-data>
    structure, n, is:
  • n := ((<length> / number-values) - 1) / 2
    This MUST be an integer value.  The lists of hop count values MAY
    be different.

Clausen & Dearlove Standards Track [Page 9] RFC 5497 Time TLV March 2009

7. Message TLVs

 Two Message TLVs are defined, for signaling message interval
 (INTERVAL_TIME) and message validity time (VALIDITY_TIME).

7.1. INTERVAL_TIME TLV

 An INTERVAL_TIME TLV is a Message TLV that defines the maximum time
 before another message of the same type as this message from the same
 originator should be received.  This interval time MAY be specified
 to depend on the hop count from the originator.  (This is appropriate
 if messages are sent with different hop limits so that receiving
 nodes at greater hop counts have an increased interval time.)
 A message MUST NOT include more than one INTERVAL_TIME TLV.
 An INTERVAL_TIME TLV is an example of a Time TLV specified as in
 Section 5.

7.2. VALIDITY_TIME TLV

 A VALIDITY_TIME TLV is a Message TLV that defines the validity time
 of the information carried in the message in which the TLV is
 contained.  After this time, the receiving node MUST consider the
 message content to no longer be valid (unless repeated in a later
 message).  The validity time of a message MAY be specified to depend
 on the hop count from its originator.  (This is appropriate if
 messages are sent with different hop limits so that receiving nodes
 at greater hop counts receive information less frequently and must
 treat is as valid for longer.)
 A message MUST NOT include more than one VALIDITY_TIME TLV.
 A VALIDITY_TIME TLV is an example of a Time TLV specified as in
 Section 5.

8. Address Block TLVs

 Two Address Block TLVs are defined, for signaling address
 advertisement interval (INTERVAL_TIME) and address validity time
 (VALIDITY_TIME).

8.1. INTERVAL_TIME TLV

 An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum
 time before this address from the same originator should be received
 again.  This interval time MAY be specified to depend on the hop
 count from the originator.  (This is appropriate if addresses are

Clausen & Dearlove Standards Track [Page 10] RFC 5497 Time TLV March 2009

 contained in messages sent with different hop limits so that
 receiving nodes at greater hop counts have an increased interval
 time.)
 A protocol using this TLV and the same named Message TLV MUST specify
 how to interpret the case when both are present (typically, that the
 former overrides the latter for those addresses that are covered by
 the former).
 An INTERVAL_TIME TLV is an example of a Time TLV specified as in
 Section 5.

8.2. VALIDITY_TIME TLV

 A VALIDITY_TIME TLV is an Address Block TLV that defines the validity
 time of the addresses to which the TLV is associated.  After this
 time, the receiving node MUST consider the addresses to no longer be
 valid (unless these are repeated in a later message).  The validity
 time of an address MAY be specified to depend on the hop count from
 its originator.  (This is appropriate if addresses are contained in
 messages sent with different hop limits so that receiving nodes at
 greater hop counts receive information less frequently and must treat
 is as valid for longer.)
 A protocol using this TLV and the same named Message TLV MUST specify
 how to interpret the case when both are present (typically, that the
 former overrides the latter for those addresses that are covered by
 the former).
 A VALIDITY_TIME TLV is an example of a Time TLV specified as in
 Section 5.

9. IANA Considerations

 This specification defines two Message TLV Types, which have been
 allocated from the "Assigned Message TLV Types" repository of
 [RFC5444] as specified in Table 1, and two Address Block TLV Types,
 which have been allocated from the "Assigned Address Block TLV Types"
 repository of [RFC5444] as specified in Table 2.
 IANA has assigned the same numerical value to the Message TLV Type
 and Address Block TLV Type with the same name.

9.1. Expert Review: Evaluation Guidelines

 For the registries for TLV Type Extensions where an Expert Review is
 required, the designated expert SHOULD take the same general
 recommendations into consideration as are specified by [RFC5444].

Clausen & Dearlove Standards Track [Page 11] RFC 5497 Time TLV March 2009

9.2. Message TLV Types

 +---------------+------+-----------+--------------------------------+
 |      Name     | Type |    Type   | Description                    |
 |               |      | Extension |                                |
 +---------------+------+-----------+--------------------------------+
 | INTERVAL_TIME |   0  |     0     | The maximum time before        |
 |               |      |           | another message of the same    |
 |               |      |           | type as this message from the  |
 |               |      |           | same originator should be      |
 |               |      |           | received                       |
 |   Unassigned  |   0  |   1-223   | Expert Review                  |
 |               |      |  224-255  | Experimental Use               |
 | VALIDITY_TIME |   1  |     0     | The time from receipt of the   |
 |               |      |           | message during which the       |
 |               |      |           | information contained in the   |
 |               |      |           | message is to be considered    |
 |               |      |           | valid                          |
 |   Unassigned  |   1  |   1-223   | Expert Review                  |
 |               |      |  224-255  | Experimental Use               |
 +---------------+------+-----------+--------------------------------+
                                Table 1

9.3. Address Block TLV Types

 +---------------+------+-----------+--------------------------------+
 |      Name     | Type |    Type   | Description                    |
 |               |      | extension |                                |
 +---------------+------+-----------+--------------------------------+
 | INTERVAL_TIME |   0  |     0     | The maximum time before        |
 |               |      |           | another message of the same    |
 |               |      |           | type as this message from the  |
 |               |      |           | same originator and containing |
 |               |      |           | this address should be         |
 |               |      |           | received                       |
 |   Unassigned  |   0  |   1-223   | Expert Review                  |
 |               |      |  224-255  | Experimental Use               |
 | VALIDITY_TIME |   1  |     0     | The time from receipt of the   |
 |               |      |           | address during which the       |
 |               |      |           | information regarding this     |
 |               |      |           | address is to be considered    |
 |               |      |           | valid                          |
 |   Unassigned  |   0  |   1-223   | Expert Review                  |
 |               |      |  224-255  | Experimental Use               |
 +---------------+------+-----------+--------------------------------+
                                Table 2

Clausen & Dearlove Standards Track [Page 12] RFC 5497 Time TLV March 2009

10. Security Considerations

 This document specifies how to add data structures (TLVs) that
 provide timing information to packets and messages specified using
 [RFC5444].  In particular, information validity durations and
 reporting intervals may be added.
 The general security threats that apply are those general to
 [RFC5444] and described therein, problems of integrity and
 confidentiality.  With regard to the former, modification of a Time
 TLV can cause information to have an invalid validity time, or
 expected interval time.  This may cause incorrect protocol
 performance.  Modification or addition of timed information can add
 to a protocol's workload (especially if a short validity time is
 specified) and storage requirements (especially if a long validity
 time is specified).
 To counter these threats, the security suggestions in [RFC5444], for
 the use of authentication and encryption, are appropriate.

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
            "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
            Format", RFC 5444, February 2009.

11.2. Informative References

 [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
            Routing Protocol", RFC 3626, October 2003.

Clausen & Dearlove Standards Track [Page 13] RFC 5497 Time TLV March 2009

Appendix A. Acknowledgements

 The authors would like to thank Brian Adamson and Justin Dean (both
 NRL) and Ian Chakeres (Motorola) for their contributions, and Alan
 Cullen (BAE Systems) and Jari Arkko (Ericsson, Finland) for their
 careful reviews of this specification.

Authors' Addresses

 Thomas Heide Clausen
 LIX, Ecole Polytechnique, France
 Phone: +33 6 6058 9349
 EMail: T.Clausen@computer.org
 URI:   http://www.ThomasClausen.org/
 Christopher Dearlove
 BAE Systems Advanced Technology Centre
 Phone: +44 1245 242194
 EMail: chris.dearlove@baesystems.com
 URI:   http://www.baesystems.com/

Clausen & Dearlove Standards Track [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5497.txt · Last modified: 2009/03/13 19:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki