oidspecs: adjusting whitespace

1 files changed, 50 insertions, 50 deletions

diff --git a/doc/oidspecs/rfc/rfc4530.oidspec b/doc/oidspecs/rfc/rfc4530.oidspec
index 6e88524..a0da26d 100644
--- a/doc/oidspecs/rfc/rfc4530.oidspec
+++ b/doc/oidspecs/rfc/rfc4530.oidspec
@@ -5,14 +5,14 @@
    // RFC 4122                  A UUID URN Namespace                 July 2005
    //
    // 3.  Namespace Registration Template
-   // 
+   //
    //    Namespace ID:  UUID
    //    Registration Information:
    //       Registration date: 2003-10-01
-   // 
+   //
    //    Declared registrant of the namespace:
    //       JTC 1/SC6 (ASN.1 Rapporteur Group)
-   // 
+   //
    //    Declaration of syntactic structure:
    //       A UUID is an identifier that is unique across both space and time,
    //       with respect to the space of all UUIDs.  Since a UUID is a fixed
@@ -21,20 +21,20 @@
    //       used).  A UUID can be used for multiple purposes, from tagging
    //       objects with an extremely short lifetime, to reliably identifying
    //       very persistent objects across a network.
-   // 
+   //
    //       The internal representation of a UUID is a specific sequence of
    //       bits in memory, as described in Section 4.  To accurately
    //       represent a UUID as a URN, it is necessary to convert the bit
    //       sequence to a string representation.
-   // 
+   //
    //       Each field is treated as an integer and has its value printed as a
    //       zero-filled hexadecimal digit string with the most significant
    //       digit first.  The hexadecimal values "a" through "f" are output as
    //       lower case characters and are case insensitive on input.
-   // 
+   //
    //       The formal definition of the UUID string representation is
    //       provided by the following ABNF [7]:
-   // 
+   //
    //       UUID                   = time-low "-" time-mid "-"
    //                                time-high-and-version "-"
    //                                clock-seq-and-reserved
@@ -50,12 +50,12 @@
    //             "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
    //             "a" / "b" / "c" / "d" / "e" / "f" /
    //             "A" / "B" / "C" / "D" / "E" / "F"
-   // 
+   //
    //    The following is an example of the string representation of a UUID as
    //    a URN:
-   // 
+   //
    //    urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
-   // 
+   //
    //    Relevant ancillary documentation:
    //       [1][2]
    //    Identifier uniqueness considerations:
@@ -66,13 +66,13 @@
    //       application-provided text strings.  As a result, the UUIDs
    //       generated according to the mechanisms here will be unique from all
    //       other UUIDs that have been or will be assigned.
-   // 
+   //
    //    Identifier persistence considerations:
    //       UUIDs are inherently very difficult to resolve in a global sense.
    //       This, coupled with the fact that UUIDs are temporally unique
    //       within their spatial context, ensures that UUIDs will remain as
    //       persistent as possible.
-   // 
+   //
    //    Process of identifier assignment:
    //       Generating a UUID does not require that a registration authority
    //       be contacted.  One algorithm requires a unique value over space
@@ -83,10 +83,10 @@
    //       or privacy concerns make its use undesirable, Section 4.5
    //       specifies two alternatives.  Another approach is to use version 3
    //       or version 4 UUIDs as defined below.
-   // 
+   //
    //    Process for identifier resolution:
    //       Since UUIDs are not globally resolvable, this is not applicable.
-   // 
+   //
    //    Rules for Lexical Equivalence:
    //       Consider each field of the UUID to be an unsigned integer as shown
    //       in the table in section Section 4.1.2.  Then, to compare a pair of
@@ -94,54 +94,54 @@
    //       UUID in order of significance and according to their data type.
    //       Two UUIDs are equal if and only if all the corresponding fields
    //       are equal.
-   // 
+   //
    //       As an implementation note, equality comparison can be performed on
    //       many systems by doing the appropriate byte-order canonicalization,
    //       and then treating the two UUIDs as 128-bit unsigned integers.
-   // 
+   //
    //       UUIDs, as defined in this document, can also be ordered
    //       lexicographically.  For a pair of UUIDs, the first one follows the
    //       second if the most significant field in which the UUIDs differ is
    //       greater for the first UUID.  The second precedes the first if the
    //       most significant field in which the UUIDs differ is greater for
    //       the second UUID.
-   // 
+   //
    //    Conformance with URN Syntax:
    //       The string representation of a UUID is fully compatible with the
    //       URN syntax.  When converting from a bit-oriented, in-memory
    //       representation of a UUID into a URN, care must be taken to
    //       strictly adhere to the byte order issues mentioned in the string
    //       representation section.
-   // 
+   //
    //    Validation mechanism:
    //       Apart from determining whether the timestamp portion of the UUID
    //       is in the future and therefore not yet assignable, there is no
    //       mechanism for determining whether a UUID is 'valid'.
-   // 
+   //
    //    Scope:
    //       UUIDs are global in scope.
    //
    //
    // RFC 4530                     LDAP entryUUID                    June 2006
-   // 
+   //
    // 2.1.  UUID Syntax
-   // 
+   //
    //    A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
    //    bit) value that identifies an object.  The ASN.1 [X.680] type UUID is
    //    defined to represent UUIDs as follows:
-   // 
+   //
    //        UUID ::= OCTET STRING (SIZE(16))
    //              -- constrained to an UUID [RFC4122]
-   //        
+   //
    //    In LDAP, UUID values are encoded using the [ASCII] character string
    //    representation described in [RFC4122].  For example,
    //    "597ae2f6-16a6-1027-98f4-d28b5365dc14".
-   // 
+   //
    //    The following is an LDAP syntax description suitable for publication
    //    in subschema subentries.
-   // 
+   //
    //        ( 1.3.6.1.1.16.1 DESC 'UUID' )
-   // 
+   //
    .oid           =  "1.3.6.1.1.16.1",
    .name          =  "UUID",
    .desc          =  "UUID",
@@ -187,19 +187,19 @@
 {
    //
    // RFC 4530                     LDAP entryUUID                    June 2006
-   // 
+   //
    // 2.2.  'uuidMatch' Matching Rule
-   // 
+   //
    //    The 'uuidMatch' matching rule compares an asserted UUID with a stored
    //    UUID for equality.  Its semantics are the same as the
    //    'octetStringMatch' [X.520][RFC4517] matching rule.  The rule differs
    //    from 'octetStringMatch' in that the assertion value is encoded using
    //    the UUID string representation instead of the normal OCTET STRING
    //    string representation.
-   // 
+   //
    //    The following is an LDAP matching rule description suitable for
    //    publication in subschema subentries.
-   // 
+   //
    //        ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
    //            SYNTAX 1.3.6.1.1.16.1 )
    //
@@ -225,57 +225,57 @@
 {
    //
    // RFC 4530                     LDAP entryUUID                    June 2006
-   // 
+   //
    // 2.3.  'uuidOrderingMatch' Matching Rule
-   // 
+   //
    //    The 'uuidOrderingMatch' matching rule compares an asserted UUID with
    //    a stored UUID for ordering.  Its semantics are the same as the
    //    'octetStringOrderingMatch' [X.520][RFC4517] matching rule.  The rule
    //    differs from 'octetStringOrderingMatch' in that the assertion value
    //    is encoded using the UUID string representation instead of the normal
    //    OCTET STRING string representation.
-   // 
+   //
    //   The following is an LDAP matching rule description suitable for
    //    publication in subschema subentries.
-   // 
+   //
    //        ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
    //            SYNTAX 1.3.6.1.1.16.1 )
-   //      
+   //
    //    Note that not all UUID variants have a defined ordering; and even
    //    where it does, servers are not obligated to assign UUIDs in any
    //    particular order.  This matching rule is provided for completeness.
    //
    .oid           =  "1.3.6.1.1.16.3",
-   .name          =  "uuidOrderingMatch",                                           
+   .name          =  "uuidOrderingMatch",
    .desc          =  "'uuidOrderingMatch' Matching Rule",
-   .flags         =  0,                                 
+   .flags         =  0,
    .type          =  LDAPSCHEMA_MATCHINGRULE,
    .def           =  "( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' SYNTAX 1.3.6.1.1.16.1 )",
    .spec          =  "RFC 4530: LDAP entryUUID",
-   .spec_type     =  LDAPSCHEMA_SPEC_RFC,                                   
+   .spec_type     =  LDAPSCHEMA_SPEC_RFC,
    .spec_name     =  "4530",
    .spec_section  =  "2.3",
-   .spec_source   =  NULL,                                                  
-   .spec_vendor   =  "IETF",                                                
-   .spec_text     =  NULL,                                                  
-   .notes         =  NULL,                                                  
+   .spec_source   =  NULL,
+   .spec_vendor   =  "IETF",
+   .spec_text     =  NULL,
+   .notes         =  NULL,
    .examples      =  NULL,
-};  
+};
 
 
 
 {
    //
    // RFC 4530                     LDAP entryUUID                    June 2006
-   // 
+   //
    // 2.4.  'entryUUID' Attribute
-   // 
+   //
    //    The 'entryUUID' operational attribute provides the Universally Unique
-   //    Identifier (UUID) assigned to the entry. 
-   // 
+   //    Identifier (UUID) assigned to the entry.
+   //
    //    The following is an LDAP attribute type description suitable for
    //    publication in subschema subentries.
-   // 
+   //
    //        ( 1.3.6.1.1.16.4 NAME 'entryUUID'
    //            DESC 'UUID of the entry'
    //            EQUALITY uuidMatch
@@ -284,11 +284,11 @@
    //            SINGLE-VALUE
    //            NO-USER-MODIFICATION
    //            USAGE directoryOperation )
-   //      
+   //
    //    Servers SHALL generate and assign a new UUID to each entry upon its
    //    addition to the directory and provide that UUID as the value of the
    //    'entryUUID' operational attribute.  An entry's UUID is immutable.
-   // 
+   //
    //    UUID are to be generated in accordance with Section 4 of [RFC4122].
    //    In particular, servers MUST ensure that each generated UUID is unique
    //    in space and time.