RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (4)

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 5365
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Gary Palmer
Date Reported: 2018-05-22
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30

Section 7.2.1.1 says:

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The specification states that the suffix should be "xml" for an uncompressed file, and "xml.gz" for a compressed file. The example filename is missing the "xml" component of the suffix

Errata ID: 5371
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Cris van Pelt
Date Reported: 2018-05-28
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30

Section 7.2.1.1 says:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression.

It should say:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression (described in [RFC1952]).

Notes:

The term "GZIP compression" is not defined in the text. To clarify, maintain compatibility with future (potentially incompatible) gzip versions, and to bring the document in line with other RFCs (e.g. 3712, 6713, 6968), a reference to RFC 1952 ("GZIP file format specification version 4.3") should be added.

This is assuming RFC 1952 was the author's intent.

Errata ID: 5440
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: John Levine
Date Reported: 2018-07-25
Verifier Name: Adrian Farrel
Date Verified: 2018-07-26

Section 7.1, B.2.1, B.2.3, B.2.4 says:

==7.1==
In particular, the "v=DMARC1" tag is

comes back containing a tag of "v=DMARC1",

containing at least "v=DMARC1"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1")

==B.2.3==

with the value "=DMARC1".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1"

     example.com._report._dmarc   IN   TXT    "v=DMARC1"

==B.2.4==

        o  The version of DMARC being used is "DMARC1" ("v=DMARC1")

It should say:

==7.1==
In particular, the "v=DMARC1;" tag is

comes back containing a tag of "v=DMARC1;",

containing at least "v=DMARC1;"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1;")

==B.2.3==

with the value "v=DMARC1;".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1;"

     example.com._report._dmarc   IN   TXT    "v=DMARC1;"

==B.2.4==

   o  The version of DMARC being used is "DMARC1" ("v=DMARC1;")

Notes:

The ABNF of dmarc-record in section 6.4 says that there has to be a semicolon after v=DMARC1, but several of the examples for the _report._dmarc record are missing the semicolon.

Errata ID: 6439
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Norton
Date Reported: 2021-02-23
Verifier Name: Adrian Farrel
Date Verified: 2021-02-24

Section 7.1 says:

For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the host extracted from the
latter ("red.example.net") does not match "blue.example.com", so this
procedure is enacted.

It should say:

For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the Organizational Domain of the
host extracted from the latter ("example.net") does not match the
Organizational Domain "example.com", so this procedure is enacted.

Notes:

Section 7.1 (third paragraph) is clear that it is the Organizational Domains which are to be compared in order to make a determination on the need to perform validation steps. The example incorrectly makes this determination by comparing the hostnames instead of the Organizational Domains.

Status: Reported (9)

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Note: This RFC has been updated by RFC 8553, RFC 8616

Source of RFC: INDEPENDENT

Errata ID: 5220
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01

Section A.6. says:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

It should say:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   Certain TLDs could be classified as a Organizational Domains. The 
   benefits to those organizations do not yet justify the necessary 
   modifications to this document. An few organizations may 
   prefer the simplified reporting and DNS configuration of a 
   TLD Organizational Domain. This would require modifications to 
   this document and DMARC receivers for a capability that may not even
   be desired by those organizations that strictly control a TLD.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

Notes:

RFC7489 does not address Organizational Top Level Domains. There are advantages and disadvantages to using a strictly controlled TLD as an Organizational Domain.

Advantages:
Simplified reporting for nonexistent domains
Simplified external reporting to another email address with the same TLD
Reduced need for multiple wildcard TXT records

Disadvantages:
Decreased flexibility for subdomains
A "_dmarc.tld" record is not be a dotless domain, but may not be recommended
Significant changes to current DMARC processing systems
New requirement to manage which TLDs are eligible to be Organizational Domains
Organizations with a strictly controlled TLD may not desire this change

Errata ID: 5221
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01

Section Appendix C. says:

       <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                   ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>

It should say:

       <xs:pattern value="^((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])$|
                   ^(([0-9A-Fa-f]{1,4}:){7}[A-Fa-f0-9]{1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,6})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,5})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,5}(:[0-9A-Fa-f]{1,4}){1,2})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,6}(:[0-9A-Fa-f]{1,4}){1,1})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,7}|:):)$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,7})$|
                   ^(((([0-9A-Fa-f]{1,4}:){6})
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^((([0-9A-Fa-f]{1,4}:){5}[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^(([0-9A-Fa-f]{1,4}:){5}:[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,3}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,2}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,1}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,5}|:):
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,5}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$"/>

Notes:

The document does not address compressed IPv6 addresses, and the IPv6 regular expression pattern does provided in the proposed XML validation does not match compressed IPv6 addresses.

I recommend using a more comprehensive regular expression, adding another note to the appendix that the IPv6 pattern is only included for brevity, or modifying the document to require fully expanded IPv6 addresses.

Credit for the IPv6 regular expression above goes to Vernon Mauery (http://vernon.mauery.com/content/projects/linux/ipv6_regex).

Errata ID: 5229
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Steven Hilton
Date Reported: 2018-01-07

Section Appendix C says:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

It should say:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/
                   minOccurs="0"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/
                   minOccurs="0"/>
     </xs:all>
   </xs:complexType>

Notes:

Per section 6.3, "adkim", "aspf", "sp", "pct", and "fo" are optional. All but "sp" have a default value, which is inconsistently applied in Appendix C.

If the Subdomain Policy (sp) is required in aggregate reports, I recommend clarification on how to provide this information for domains that do not publish this information.
For example:
- If a subdomain policy is published on a subdomain of an organizational domain, return an 'ignored' subdomain policy in the aggregate report
- If a subdomain policy is NOT published on an organizational domain, recommend returning the effective subdomain policy in the aggregate report, which is the domain policy per section 6.3
- Recommend addition of the "fo" tag only if the "ruf" tag is published.

Errata ID: 5495
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Scott Kitterman
Date Reported: 2018-09-08

Section 6.6.3 step 1 says:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

It should say:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the _dmarc subdomain of the one found in
       the RFC5322.From domain in the message.  A possibly empty set
       of records is returned.

Notes:

Section 6.1. DMARC Policy Record states that DMARC records are 'stored as DNS TXT records in subdomains named "_dmarc"'. The policy discovery procedure needs to match. As I read it, it currently doesn't.

Errata ID: 5773
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Freddie Leeman
Date Reported: 2019-07-03

Section Appendix C says:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

It should say:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options. -->
       <xs:element name="fo" type="xs:string" />
     </xs:all>
   </xs:complexType>

Notes:

The name "PolicyPublishedType" suggests that the elements within it represent the domain's published policy. But the comment from element "fo" describes itself as "Failure reporting options IN EFFECT".

A lot of organizations do not send failure (forensic) reports and do not publish the "fo" element in their aggregate reports (Google, Yahoo!, Zoho) . This is reasonable since the description says "in effect". But the field also has a (default) MinOccurs of 1 because MinOccurs is not defined. So by omitting the element, the reports from these organizations are in violation of the guidelines.

Should an aggregate report have a mandatory "fo" element, even if the organization doesn't do failure (forensic) reporting? If so, than the comment "<!-- Failure reporting options in effect. -->" should be "<!-- Failure reporting options. -->". And if not, than the minOccurs="0" should be added to the "fo" element to allow it to be optional.

Even if DMARC policy options are OPTIONAL and not specified, the messages are processed by the receiver with the default values. This is also the case for adkim and aspf, which also have a minOccurs of 0.

So i would suggest the following:

The PolicyPublishedType describe the policy that is applied tot the messages in the reports. Elements that are not defined by the domain's DMARC policy should be filled with the default values, as they would also be processed that way. So when adkim is not configured in the policy, the report should state value "r" as this is the default value. Same applies to aspf ("r"), sp (same as "p"), pct (100) and fo (0). Even if an organization doesn't send out failure reports it MUST mention the "fo" value from the domain's policy, or, when not specified, the default value of 0.

Errata ID: 6729
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Scott Kitterman
Date Reported: 2021-11-01

Section 3.2 says:

   3.  Search the public suffix list for the name that matches the
       largest number of labels found in the subject DNS domain.  Let
       that number be "x".

It should say:

   3.  Search the ICANN DOMAINS section of the public suffix list for
       the name that matches the largest number of labels found in the
       subject DNS domain.  Let that number be "x".

Notes:

The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result.

Errata ID: 7099
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").

Errata ID: 7100
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").

Errata ID: 7865
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Fränz Friederes
Date Reported: 2024-03-23

Appendix C says:

<!-- Credit to Roger L. Costello for IPv4 regex
    http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
          018018.html -->
<!-- Credit to java2s.com for IPv6 regex
    http://www.java2s.com/Code/XML/XML-Schema/
          IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
  <xs:restriction base="xs:string">
    <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
  </xs:restriction>
</xs:simpleType>

It should say:

<!-- Credit to Roger L. Costello for IPv4 regex
    http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
          018050.html -->
<!-- Credit to java2s.com for IPv6 regex
    http://www.java2s.com/Code/XML/XML-Schema/
          IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
  <xs:restriction base="xs:string">
    <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}
                (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
  </xs:restriction>
</xs:simpleType>

Notes:

The IPv4 regex contains a period "." that should be corrected to an escaped period "\." As stated in the follow up message of the one referenced in the IPv4 regex credit: "I just realized that there is a bug [...] The period (.) is a special character meaning 'any character'. To indicate that we want a period and not 'any character' the period must be escaped with a backslash, i.e., \." Following the XML schema provided in the original Appendix C, strings like "1a1a1a1" and "1111111" are considered valid IPv4 addresses, although they are not usable.

Report New Errata



Advanced Search