Subject: [NGO] SMI and InetAddress modules for review

From: Andy Bierman <[email-masked]>
Date: Sat, 03 Mar 2007 07:16:36 -0800

Hi Martin,

I updated my SMI and InetAddress schemas based on your comments
on the mailing list (e.g., union not choice, type attr optional).
I think the IPv6 patterns are still wrong though.

I was hoping Dan would update his data types draft based on modules
that have rough consensus.  Let's see if these versions are closer.

thanks,
Andy

<xs:schema xmlns="http://netconfcentral.org/ietf/types"
 targetNamespace="http://netconfcentral.org/ietf/types"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.netconfcentral.org/xsd/ietf/smi.xsd"
 elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"
 version="0.5"
 xmlns:ncx="http://netconfcentral.org/ncx/1.0"
 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
 <xs:annotation>
  <xs:documentation> Converted from NCX module by ncxdump v0.2

    Module: smi
    Owner: ietf
    Application: types
    Version: 0.5
    Copyright (C) Andy Bierman (2006-2007).  All Rights Reserved.
    Contact Info: Translated by Andy Bierman.
       Send comments to [email-masked].

    Description:
      SMIv2 data types converted from the following sources: 

        * RFC 2578: Structure of Management Information Version 2 (SMIv2)
          
        * RFC 2579: Textual Conventions for SMIv2

        * RFC 2856: High Capacity Data Types

        * draft-romascanu-netconf-datatypes-01.txt

        * libsmi output from 'smidump -f xsd' command
          http://www.ibr.cs.tu-bs.de/projects/libsmi/ 

    Revision History:

      Revision: 0.5
      Update based on NGO mailing list comments:
             change BITS back to list, fix bugs.

      Revision: 0.4
      Change BITS from list to ustring

      Revision: 0.3
      Try to align to smidump and draft-romascanu.

      Revision: 0.2
      Refine OID and other tabular data types.

      Revision: 0.1
      Initial version.
</xs:documentation>
 </xs:annotation>

 <xs:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd"/>

 <xs:simpleType name="INTEGER">
  <xs:annotation>
   <xs:documentation>INTEGER from RFC 2578, page 8 and sec. 7.1.1.
         An enumerated integer is simply the 'enum' data type</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:int"/>
 </xs:simpleType>

 <xs:simpleType name="OctetString">
  <xs:annotation>
   <xs:documentation>OCTET STRING from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:hexBinary">
   <xs:maxLength value="65535"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="ObjectIdentifier">
  <xs:annotation>
   <xs:documentation>OBJECT IDENTIFIER from RFC 2578, page 8.,
                   libsmi v0.4.5 output.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="[0-2](\.(0|([1-9]([0-9]*))))*"/>
   <xs:minLength value="2"/>
   <xs:maxLength value="128"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="Integer32">
  <xs:annotation>
   <xs:documentation>Integer32 from RFC 2578, sec. 7.1.1</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:int"/>
 </xs:simpleType>

 <xs:simpleType name="IpAddress">
  <xs:annotation>
   <xs:documentation>IpAddress from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:hexBinary">
   <xs:minLength value="8"/>
   <xs:maxLength value="8"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="Counter32">
  <xs:annotation>
   <xs:documentation>Counter32 from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt"/>
 </xs:simpleType>

 <xs:simpleType name="Gauge32">
  <xs:annotation>
   <xs:documentation>Gauge32 from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt"/>
 </xs:simpleType>

 <xs:simpleType name="Unsigned32">
  <xs:annotation>
   <xs:documentation>Unsigned32 from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt"/>
 </xs:simpleType>

 <xs:simpleType name="TimeTicks">
  <xs:annotation>
   <xs:documentation>TimeTicks from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt"/>
 </xs:simpleType>

 <xs:simpleType name="Opaque">
  <xs:annotation>
   <xs:documentation>Opaque from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:hexBinary"/>
 </xs:simpleType>

 <xs:simpleType name="Counter64">
  <xs:annotation>
   <xs:documentation>Counter64 from RFC 2578, page 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedLong"/>
 </xs:simpleType>

 <xs:simpleType name="Unsigned64">
  <xs:annotation>
   <xs:documentation>Unsigned64 TC (missing) from RFC 2856.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedLong"/>
 </xs:simpleType>

 <xs:simpleType name="CounterBasedGauge64">
  <xs:annotation>
   <xs:documentation>CounterBasedGauge64 TC from RFC 2856, pages 5 -6.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedLong"/>
 </xs:simpleType>

 <xs:simpleType name="ZeroBasedCounter64">
  <xs:annotation>
   <xs:documentation>ZeroBasedCounter64 TC from RFC 2856, page 6.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedLong"/>
 </xs:simpleType>

 <xs:simpleType name="BITS">
  <xs:annotation>
   <xs:documentation>BITS from RFC 2579, page 3.
         Bit definition in the hexBinary string are in network 
         byte order.</xs:documentation>
   <xs:appinfo>
    <ncx:no-duplicates/>
    <ncx:merge-type>ordered</ncx:merge-type>
   </xs:appinfo>
  </xs:annotation>
  <xs:list itemType="xs:NMTOKEN"/>
 </xs:simpleType>

 <xs:simpleType name="DisplayString">
  <xs:annotation>
   <xs:documentation>DisplayString TC from RFC 2579, page 3.,
                   smidump v0.4.5;

        Represents textual information taken from the NVT ASCII
        character set, as defined in pages 4, 10-11 of RFC 854.

        To summarize RFC 854, the NVT ASCII repertoire specifies:

          - the use of character codes 0-127 (decimal)

          - the graphics characters (32-126) are interpreted as
            US ASCII

          - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
            meanings specified in RFC 854

          - the other 25 codes have no standard interpretation

          - the sequence 'CR LF' means newline

          - the sequence 'CR NUL' means carriage-return

          - an 'LF' not preceded by a 'CR' means moving to the
            same column on the next line.

          - the sequence 'CR x' for any x other than LF or NUL is
            illegal.  (Note that this also means that a string may
            end with either 'CR LF' or 'CR NUL', but not with CR.)

        Any object defined using this syntax may not exceed 255
        characters in length.</xs:documentation>
   <xs:appinfo>
    <ncx:display-hint>255a</ncx:display-hint>
   </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="((((\p{IsBasicLatin})){0,255})){0,1}"/>
   <xs:maxLength value="255"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="PhysAddress">
  <xs:annotation>
   <xs:documentation>PhysAddress TC from RFC 2579, page 4.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(((([0-9A-Fa-f]{2}):)*([0-9A-Fa-f]{2}))){0,1}"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="MacAddress">
  <xs:annotation>
   <xs:documentation>IEE 802 MAC Address String. from smidump v0.4.5,

        Represents an 802 MAC address represented in the
        `canonical' order defined by IEEE 802.1a, i.e., as if it
        were transmitted least significant bit first, even though
        802.5 (in contrast to other 802.x protocols) requires MAC
        addresses to be transmitted most significant bit first.</xs:documentation>
   <xs:appinfo>
    <ncx:display-hint>1x:</ncx:display-hint>
   </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(((([0-9A-Fa-f]{2}):){5,5})([0-9A-Fa-f]{2}))"/>
   <xs:minLength value="17"/>
   <xs:maxLength value="17"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="TruthValue">
  <xs:annotation>
   <xs:documentation>TruthValue TC from RFC 2579, page 5.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="true"/>
   <xs:enumeration value="false"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="TestAndIncr">
  <xs:annotation>
   <xs:documentation>TestAndIncr TC from RFC 2579, page 5.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:maxInclusive value="2147483647"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:complexType name="AutonomousType">
  <xs:annotation>
   <xs:documentation>AutonomousType TC from RFC 2579, page 5.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="ObjectIdentifier"/>
  </xs:simpleContent>
 </xs:complexType>

 <xs:complexType name="InstancePointer">
  <xs:annotation>
   <xs:documentation>A pointer to either a specific instance of a MIB object or
         a conceptual row of a MIB table in the managed device.  In
         the latter case, by convention, it is the name of the
         particular instance of the first accessible columnar object
         in the conceptual row.

         The two uses of this textual convention are replaced by
         VariablePointer and RowPointer, respectively.</xs:documentation>
   <xs:appinfo>
    <ncx:deprecated/>
   </xs:appinfo>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="ObjectIdentifier"/>
  </xs:simpleContent>
 </xs:complexType>

 <xs:complexType name="VariablePointer">
  <xs:annotation>
   <xs:documentation>VariablePointer TC from RFC 2579, page 6. smidump v0.4.5,

         A pointer to a specific object instance.  For example,
         sysContact.0 or ifInOctets.3.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="ObjectIdentifier"/>
  </xs:simpleContent>
 </xs:complexType>

 <xs:complexType name="RowPointer">
  <xs:annotation>
   <xs:documentation>RowPointer TC from RFC 2579, page 6.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="ObjectIdentifier"/>
  </xs:simpleContent>
 </xs:complexType>

 <xs:simpleType name="RowStatus">
  <xs:annotation>
   <xs:documentation>RowStatus TC from RFC 2579, pages 6 - 17.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="active"/>
   <xs:enumeration value="notInService"/>
   <xs:enumeration value="notReady"/>
   <xs:enumeration value="createAndGo"/>
   <xs:enumeration value="createAndWait"/>
   <xs:enumeration value="destroy"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="TimeStamp">
  <xs:annotation>
   <xs:documentation>TimeStamp TC from RFC 2579, pages 17 - 18.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:maxInclusive value="2147483647"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="TimeInterval">
  <xs:annotation>
   <xs:documentation>TimeInterval TC from RFC 2579, page 18.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:maxInclusive value="2147483647"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="DateAndTime">
  <xs:annotation>
   <xs:documentation>DateAndTime TC from RFC 2579, pages 18 - 19.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:minLength value="8"/>
   <xs:maxLength value="28"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="StorageType">
  <xs:annotation>
   <xs:documentation>StorageType TC from RFC 2579, page 19.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="other"/>
   <xs:enumeration value="volatile"/>
   <xs:enumeration value="nonVolatile"/>
   <xs:enumeration value="permanent"/>
   <xs:enumeration value="readOnly"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:complexType name="TDomain">
  <xs:annotation>
   <xs:documentation>TDomain TC from RFC 2579, page 20.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="ObjectIdentifier"/>
  </xs:simpleContent>
 </xs:complexType>

 <xs:simpleType name="TAddress">
  <xs:annotation>
   <xs:documentation>TAddress TC from RFC 2579, page 20.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:hexBinary">
   <xs:minLength value="1"/>
   <xs:maxLength value="255"/>
  </xs:restriction>
 </xs:simpleType>

</xs:schema>

<xs:schema xmlns="http://netconfcentral.org/ietf/types"
 targetNamespace="http://netconfcentral.org/ietf/types"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.netconfcentral.org/xsd/ietf/inetAddress.xsd"
 elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"
 version="0.1"
 xmlns:ncx="http://netconfcentral.org/ncx/1.0"
 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
 <xs:annotation>
  <xs:documentation> Converted from NCX module by ncxdump v0.2

    Module: inetAddress
    Owner: ietf
    Application: types
    Version: 0.1
    Copyright (C) Andy Bierman (2005-2007).  All Rights Reserved.
    Contact Info: Translated by Andy Bierman.
       Send comments to &lt;[email-masked]&gt;.

    Description:
      InetAddress data types converted from the following sources: 

        * RFC 4001:  Textual Conventions for Transport Addresses

        * draft-romascanu-netconf-datatypes-01.txt
  
        * libsmi output from 'smidump -f xsd' command
          http://www.ibr.cs.tu-bs.de/projects/libsmi/   
      
     The InetAddress data types are literal translations for easier
     SNMP compatibility.  ASCII versions are also available.

    Revision History:

      Revision: 0.1
      Initial version.

      Revision: 0.2
      Update based on NETCONF mailing list discussion.
            Changed choice to a union and scope ID to an attribute
            so all address types can be part of the InetAddress union.
</xs:documentation>
 </xs:annotation>

 <xs:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd"/>

 <xs:simpleType name="InetAddressType">
  <xs:annotation>
   <xs:documentation>InetAddressType TC from RFC 4001, pages 6 - 7.
         Extended to support more IPv6 address types</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="unknown"/>
   <xs:enumeration value="ipv4"/>
   <xs:enumeration value="ipv6"/>
   <xs:enumeration value="ipv4z"/>
   <xs:enumeration value="ipv6z"/>
   <xs:enumeration value="ipv6m"/>
   <xs:enumeration value="ipv6s"/>
   <xs:enumeration value="dns"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetZoneIndex">
  <xs:annotation>
   <xs:documentation>InetAddress Zone Index from RFC 4001.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:minInclusive value="1"/>
   <xs:maxInclusive value="65535"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAddressUnknown">
  <xs:annotation>
   <xs:documentation>Entry for a generic type, not included here</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string"/>
 </xs:simpleType>

 <xs:simpleType name="InetAddressIPv4">
  <xs:annotation>
   <xs:documentation>InetAddressIPv4 TC from RFC 4001, pages 7 - 8.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(([0-1]?[0-9]?[0-9]|2?[0-5]?[0-5])\.){3}
                     ([0-1]?[0-9]?[0-9]|2?[0-5]?[0-5])"/>
   <xs:minLength value="7"/>
   <xs:maxLength value="15"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:complexType name="InetAddressIPv4z">
  <xs:annotation>
   <xs:documentation>InetAddressIPv4z TC from RFC 4001, pages 8 - 9.,
         draft-romascanu-netconf-datatypes-01.txt, page 5</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="InetAddressIPv4">
    <xs:attribute name="zoneIndex" type="InetZoneIndex" use="required"/>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>

 <xs:simpleType name="InetAddressIPv6">
  <xs:annotation>
   <xs:documentation>InetAddressIPv6 TC from RFC 4001, page 8.,
         draft-romascanu-netconf-datatypes-01.txt, page 6</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(([0-9a-fA-F]{1,4}:){6})
            (([0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})|
            ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAddressIPv6m">
  <xs:annotation>
   <xs:documentation>draft-romascanu-netconf-datatypes-01.txt, page 6</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(([0-9a-fA-F]{1,4}:){6})
              (([0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})|
              ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAddressIPv6s">
  <xs:annotation>
   <xs:documentation>draft-romascanu-netconf-datatypes-01.txt, page 6</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="(([0-9a-fA-F]{1,4}:)*|([0-9a-fA-F]{1,4}))*(::)
             (([0-9a-fA-F]{1,4}:)*|([0-9a-fA-F]{1,4}))*"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:complexType name="InetAddressIPv6z">
  <xs:annotation>
   <xs:documentation>InetAddressIPv6z TC from RFC 4001, page 9.
         draft-romascanu-netconf-datatypes-01.txt, page 6.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="InetAddressIPv6">
    <xs:attribute name="zoneIndex" type="InetZoneIndex" use="required"/>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>

 <xs:simpleType name="InetAddressDNS">
  <xs:annotation>
   <xs:documentation>InetAddressDNS TC from RFC 4001, pages 9 - 10.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:minLength value="1"/>
   <xs:maxLength value="255"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAddressPrefixLength">
  <xs:annotation>
   <xs:documentation>InetAddressDNS TC from RFC 4001, pages 9 - 10.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:maxInclusive value="2040"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetPortNumber">
  <xs:annotation>
   <xs:documentation>InetPortNumber TC from RFC 4001, pages 10 - 11.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt">
   <xs:maxInclusive value="65535"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAutonomousSystemNumber">
  <xs:annotation>
   <xs:documentation>InetAutonomousSystemNumber TC from RFC 4001, page 11.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:unsignedInt"/>
 </xs:simpleType>

 <xs:simpleType name="InetScopeType">
  <xs:annotation>
   <xs:documentation>InetScopeType TC from RFC 4001, pages 11 - 12.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="interfaceLocal"/>
   <xs:enumeration value="linkLocal"/>
   <xs:enumeration value="subnetLocal"/>
   <xs:enumeration value="adminLocal"/>
   <xs:enumeration value="siteLocal"/>
   <xs:enumeration value="organizationLocal"/>
   <xs:enumeration value="global"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetVersion">
  <xs:annotation>
   <xs:documentation>InetVersion TC from RFC 4001, pages 12 - 13.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:enumeration value="unknown"/>
   <xs:enumeration value="ipv4"/>
   <xs:enumeration value="ipv6"/>
  </xs:restriction>
 </xs:simpleType>

 <xs:simpleType name="InetAddressBT">
  <xs:union memberTypes="InetAddressIPv4 InetAddressIPv4z InetAddressIPv6 InetAddressIPv6m
InetAddressIPv6s InetAddressDNS InetAddressUnknown"/>
 </xs:simpleType>

 <xs:complexType name="InetAddress">
  <xs:annotation>
   <xs:documentation>InetAddress TC from RFC 4001, page 7. 

         The actual format of the string content is determined by
         the mandatory 'type' attribute as follows:
         
          unknown: InetAddressUnknown
          ipv4:    InetAddressIPv4
          ipv6:    InetAddressIPv6
          ipv4z:   InetAddressIPv4z 
          ipv6z:   InetAddressIPv6z
          ipv6m:   InetAddressIPv6m
          ipv6s:   InetAddressIPv6s
          dns:     InetAddressDNS

        The use of separate elements instead of a union or 
        substitution group approach allows for schema validation
        of the different address types, instead of just run-time
        validation.</xs:documentation>
  </xs:annotation>
  <xs:simpleContent>
   <xs:extension base="InetAddressBT">
    <xs:attribute name="type" type="InetAddressType"/>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>

</xs:schema>
_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Robert Moore <[email-masked]>
Date: Mon, 5 Mar 2007 08:43:06 -0500

>   <xs:maxLength value="128"/>

Andy,

The bounds 2 and 128 are talking about subidentifiers, not string 
characters.  So I think you need something along the lines of this (where 
the value 1398 = 1 + (127 * (1 + 10))):

 <xs:simpleType name="ObjectIdentifier">
  <xs:annotation>
   <xs:documentation>OBJECT IDENTIFIER from RFC 2578, page 8.,
                   libsmi v0.4.5 output.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:string">
   <xs:pattern value="[0-2](\.(0|([1-9]([0-9]*))))+"/>
   <xs:minLength value="3"/>
   <xs:maxLength value="1398"/>
  </xs:restriction>
 </xs:simpleType>

Whether schema validation against this maxLength is useful is another 
question entirely.

Regards,
Bob

Bob Moore
IBM Software Group Advanced Design & Technology
+1-919-254-4436
[email-masked]
_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Mar 2007 14:02:05 +0100

Hi Andy,

> I think the IPv6 patterns are still wrong though.

The pattern for IPv4 address is also wrong - it doesn't match addresses
where one of the parts is for example 249. The correct regexp should be
something like this (all on a single line):

((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|
2[0-4][0-9]|[01]?[0-9]?[0-9])

I would also prefer a different structuring of IPv6 addresses. There is
no reason for separating the full and shortened form of the IPv6
address. Both forms together can be matched by the conjunction of the
following two regexps:

([0-9a-fA-F]{0,4}:){0,7}[0-9a-fA-F]{0,4}

AND

(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::
(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?

On the other hand, the IPv4-mapped and IPv4-compatible IPv6 addresses
should be separate types as in some contexts they need not be allowed.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C