< draft-ietf-eppext-tmch-smd-03.txt   draft-ietf-eppext-tmch-smd-04.txt >
Internet Engineering Task Force G. Lozano Internet Engineering Task Force G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Standards Track September 28, 2015 Intended status: Standards Track January 04, 2016
Expires: March 31, 2016 Expires: July 7, 2016
Mark and Signed Mark Objects Mapping Mark and Signed Mark Objects Mapping
draft-ietf-eppext-tmch-smd-03 draft-ietf-eppext-tmch-smd-04
Abstract Abstract
This document describes the format of a mark and a digitally signed This document describes the format of a mark and a digitally signed
mark used by trademark holders for registering domain names during mark used by trademark holders for registering domain names during
the sunrise phase of generic Top Level Domains (gTLDs). the sunrise phase of generic Top Level Domains (gTLDs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2016. This Internet-Draft will expire on July 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Description . . . . . . . . . . . . . . . . . . . . . 3 2. Object Description . . . . . . . . . . . . . . . . . . . . . 3
2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 3 2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 4
2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 12 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 13
2.5. Appendix A. base64 encoded signedMark . . . . . . . . . . 12 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 13
3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 15 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 17 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 21
4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 24 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 22
4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 24 4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 22
4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 25 4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 22
4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 25 4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 23
4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 25 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Change History . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document describes the format of a mark and a digitally signed Domain Name Registries (DNRs) may operate in special modes for
mark, used to construct a Signed Mark Data (SMD) file, required by certain periods of time enabling trademark holders to protect their
the Internet Corporation for Assigned Names and Numbers (ICANN) rights during the introduction of a Top Level Domain (TLD).
Trademark Clearinghouse, Rights Protection Mechanism (RPM)
Requirements defined in [ICANN-TMCH]. This document provides a One of those special modes of operation is the Sunrise Period. The
framework that can be referenced by application protocols like the Sunrise Period allows trademark holders an advance opportunity to
Extensible Provisioning Protocol (EPP), defined in [RFC5730]. register domain names corresponding to their trademarks before names
are generally available to the public.
This specification was defined as part of the development of the
ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global
repository for trademark data used by DNRs, registrars and trademark
holders during the registration process of domain names.
This document describes a mapping of the common elements found in
trademark data (Mark). A digitally signed Mark (Signed Mark) format
is defined in order to support digital signatures on the Mark object.
Finally a mapping for encoding the Signed Mark is defined.
This specification is intended to be used in the gTLD space, but
nothing precudle the use of this format by other entities.
The detailed requirements regarding the public key infrastructure,
authorized validators, and other architectural details must be
defined based on the local policy of the entities using this
specification. In the case of gTLDs, the detailed architectural
requirements regarding the use of this specification are defined in
the Rights Protection Mechanism Requirements document ([ICANN-TMCH]).
The objects specified in this document can be referenced by
application protocols like the Extensible Provisioning Protocol
(EPP), defined in [RFC5730].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
XML is case sensitive. Unless stated otherwise, XML specifications XML (EXtensible Markup Language) is case sensitive. Unless stated
and examples provided in this document MUST be interpreted in the otherwise, XML specifications and examples provided in this document
character case presented in order to develop a conforming MUST be interpreted in the character case presented in order to
implementation. develop a conforming implementation.
"signedMark-1.0" is used as an abbreviation for "signedMark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix
"smd" is used, but implementations MUST NOT depend on it and instead "smd" is used, but implementations MUST NOT depend on it and instead
employ a proper namespace-aware XML parser and serializer to employ a proper namespace-aware XML parser and serializer to
interpret and output the XML documents. interpret and output the XML documents.
"mark-1.0" is used as an abbreviation for "mark-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark"
is used, but implementations MUST NOT depend on it and instead employ is used, but implementations MUST NOT depend on it and instead employ
a proper namespace-aware XML parser and serializer to interpret and a proper namespace-aware XML parser and serializer to interpret and
output the XML documents. output the XML documents.
2. Object Description 2. Object Description
This section defines the objects associated with marks and signed This section defines the Mark and Signed Mark objects. Empty complex
marks. Empty complex element types and abstract elements are defined element types and abstract elements are defined to support additional
to support additional mark and signed mark definition using XSD Mark and Signed Mark definition using XML schema substitution groups.
substitution groups. Support for replacement through the XSD Support for replacement through the XML schema substitution groups is
substitution groups is included in the descriptions of the objects. included in the description of the objects.
This section defines some elements as OPTIONAL, the elements not
defined as OPTIONAL are REQUIRED to be included in the appropriate
objects.
The following elements are defined as telephone numbers:
<mark:voice>, <mark:fax> and <smd:voice>. The representation of
telephone numbers in this specification is derived from structures
defined in [ITU.E164.2005]. Telephone numbers described in this
mapping are character strings that MUST begin with a plus sign ("+",
ASCII value 0x002B), followed by a country code defined in
[ITU.E164.2005], followed by a dot (".", ASCII value 0x002E),
followed by a sequence of digits representing the telephone number.
An optional "x" attribute is provided to note telephone extension
information.
The following elements are defined as email addresses: <mark:email>
and <smd:email>. Email address syntax is defined in [RFC5322].
2.1. Holder and Contacts objects 2.1. Holder and Contacts objects
Marks are linked to Holder objects and optionally linked to Contacts Marks are linked to Holder objects and optionally linked to Contact
objects. This section defines the <mark:holder> and <mark:contact> objects. This section defines the <mark:holder> and <mark:contact>
objects. objects.
o The child elements of <mark:holder> include: o The child elements of <mark:holder> include:
* An OPTIONAL <mark:name> element that contains the name of the * A <mark:name> element that contains the name of the holder. At
holder. A <mark:name> MUST be specified in case <mark:org> is least one of <mark:name> and <mark:org> MUST be specified, and
not specified. <mark:name> is OPTIONAL if <mark:org> is specified.
* An OPTIONAL <mark:org> element that contains the name of the * A <mark:org> element that contains the name of the organization
organization holder of the mark. A <mark:org> MUST be holder of the mark. At least one of <mark:name> and <mark:org>
specified in case <mark:name> is not specified. MUST be specified, and <mark:org> is OPTIONAL if <mark:name> is
specified.
* A <mark:addr> element that contains the address information of * A <mark:addr> element that contains the address information of
the holder of a mark. A <mark:addr> contains the following the holder of a mark. A <mark:addr> contains the following
child elements: child elements:
+ One, two or three OPTIONAL <mark:street> elements that + One, two or three OPTIONAL <mark:street> elements that
contains the organization's street address. contains the organization's street address.
+ A <mark:city> element that contains the organization's city. + A <mark:city> element that contains the organization's city.
skipping to change at page 5, line 24 skipping to change at page 6, line 21
abstract element to define a concrete definition of a mark. The abstract element to define a concrete definition of a mark. The
<mark:abstractMark> element can be replaced by other mark definitions <mark:abstractMark> element can be replaced by other mark definitions
using the XML schema substitution groups feature. using the XML schema substitution groups feature.
The child elements of the <mark:mark> element include: The child elements of the <mark:mark> element include:
One or more <mark:trademark>, <mark:treatyOrStatute> and <mark:court> One or more <mark:trademark>, <mark:treatyOrStatute> and <mark:court>
elements that contains the detailed information of marks. elements that contains the detailed information of marks.
o A <mark:trademark> element that contains the following child o A <mark:trademark> element that contains the following child
elements. elements:
* A <mark:id> element that contains an identifier of the mark. * A <mark:id> element that contains an identifier of the mark.
The identifier MUST be globally unique in relation to the The identifier MUST be globally unique in relation to the
repository of marks. A <mark:id> value is a concatenation of repository of marks. A <mark:id> value is a concatenation of
the local identifier, followed by a hyphen ("-", ASCII value the local identifier, followed by a hyphen ("-", ASCII value
0x002D), followed by the issuer identifier. 0x002D), followed by the issuer identifier.
* A <mark:markName> element that contains the mark text string. * A <mark:markName> element that contains the mark text string.
* One or more <mark:holder> elements that contains the * One or more <mark:holder> elements that contains the
skipping to change at page 6, line 29 skipping to change at page 7, line 25
* A <mark:regNum> element that contains the trademark * A <mark:regNum> element that contains the trademark
registration number registered in the trademark office. registration number registered in the trademark office.
* A <mark:regDate> element that contains the date the trademark * A <mark:regDate> element that contains the date the trademark
was registered. was registered.
* An OPTIONAL <mark:exDate> element that contains the expiration * An OPTIONAL <mark:exDate> element that contains the expiration
date of the trademark. date of the trademark.
o A <mark:treatyOrStatute> element that contains the following child o A <mark:treatyOrStatute> element that contains the following child
elements. elements:
* A <mark:id> element that contains an identifier of the mark. * A <mark:id> element that contains an identifier of the mark.
The identifier MUST be globally unique in relation to the The identifier MUST be globally unique in relation to the
repository of marks. A <mark:id> value is a concatenation of repository of marks. A <mark:id> value is a concatenation of
the local identifier, followed by a hyphen ("-", ASCII value the local identifier, followed by a hyphen ("-", ASCII value
0x002D), followed by the issuer identifier. 0x002D), followed by the issuer identifier.
* A <mark:markName> element that contains the mark text string. * A <mark:markName> element that contains the mark text string.
* One or more <mark:holder> elements that contains the * One or more <mark:holder> elements that contains the
skipping to change at page 7, line 37 skipping to change at page 8, line 33
* A <mark:proDate> element that contains the date of protection * A <mark:proDate> element that contains the date of protection
of the mark. of the mark.
* A <mark:title> element that contains the title of the treaty or * A <mark:title> element that contains the title of the treaty or
statute. statute.
* A <mark:execDate> element that contains the execution date of * A <mark:execDate> element that contains the execution date of
the treaty or statute. the treaty or statute.
o A <mark:court> element that contains the following child elements. o A <mark:court> element that contains the following child elements:
* A <mark:id> element that contains an identifier of the mark. * A <mark:id> element that contains an identifier of the mark.
The identifier MUST be globally unique in relation to the The identifier MUST be globally unique in relation to the
repository of marks. A <mark:id> value is a concatenation of repository of marks. A <mark:id> value is a concatenation of
the local identifier, followed by a hyphen ("-", ASCII value the local identifier, followed by a hyphen ("-", ASCII value
0x002D), followed by the issuer identifier. 0x002D), followed by the issuer identifier.
* A <mark:markName> element that contains the mark text string. * A <mark:markName> element that contains the mark text string.
* One or more <mark:holder> elements that contains the * One or more <mark:holder> elements that contains the
skipping to change at page 8, line 41 skipping to change at page 9, line 36
<mark:region> is specified a default-deny approach MUST be <mark:region> is specified a default-deny approach MUST be
assumed regarding the regions of a country. assumed regarding the regions of a country.
* A <mark:courtName> element that contains the name of the court. * A <mark:courtName> element that contains the name of the court.
2.3. Signed Mark 2.3. Signed Mark
The <smd:signedMark> is the fragment of XML that is digitally signed The <smd:signedMark> is the fragment of XML that is digitally signed
using XML Signature [XMLDSIG]. The <smd:signedMark> includes a using XML Signature [XMLDSIG]. The <smd:signedMark> includes a
required "id" attribute of type XSD ID for use with an IDREF URI from required "id" attribute of type XSD ID for use with an IDREF URI from
the Signature element. The certificate of the issuer MAY be issued the Signature element.
by a Certificate Authority (CA) that can be chained with the issuer's
certificate by the validating client.
A <smd:signedMark> element substitutes for the A <smd:signedMark> element substitutes for the
<smd:abstractSignedMark> abstract element to define a concrete <smd:abstractSignedMark> abstract element to define a concrete
definition of a signed mark. The <smd:abstractSignedMark> element definition of a signed mark. The <smd:abstractSignedMark> element
can be replaced by other signed mark definitions using the XML schema can be replaced by other signed mark definitions using the XML schema
substitution groups feature. substitution groups feature.
The child elements of the <smd:signedMark> element include: The child elements of the <smd:signedMark> element include:
o The <smd:id> value is a concatenation of the local identifier, o The <smd:id> value is a concatenation of the local identifier,
skipping to change at page 9, line 19 skipping to change at page 10, line 11
o A <smd:issuerInfo> element that contains the information of the o A <smd:issuerInfo> element that contains the information of the
issuer of the mark registration. A "issuerID" attribute is used issuer of the mark registration. A "issuerID" attribute is used
to specify the issuer identifier. The child elements include: to specify the issuer identifier. The child elements include:
* A <smd:org> element that contains the organization name of the * A <smd:org> element that contains the organization name of the
issuer. issuer.
* A <smd:email> element that contains the issuer customer support * A <smd:email> element that contains the issuer customer support
email address. email address.
* An OPTIONAL <smd:url> element that contains the HTTP URL of the * An OPTIONAL <smd:url> element that contains the HTTP or HTTPS
issuer's site. URL of the issuer's site.
* An OPTIONAL <smd:voice> element that contains the issuer's * An OPTIONAL <smd:voice> element that contains the issuer's
voice telephone number. voice telephone number.
o A <smd:notBefore> element that contains the creation date and time o A <smd:notBefore> element that contains the creation date and time
of the signed mark. of the signed mark.
o A <smd:notAfter> element that contains the expiration date and o A <smd:notAfter> element that contains the expiration date and
time of the signed mark. time of the signed mark.
skipping to change at page 9, line 48 skipping to change at page 10, line 40
The following is an example <smd:signedMark> using the XML Signature The following is an example <smd:signedMark> using the XML Signature
[XMLDSIG] to sign all of the elements of <smd:signedMark> element. [XMLDSIG] to sign all of the elements of <smd:signedMark> element.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<smd:signedMark xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0" <smd:signedMark xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"
id="smd1"> id="smd1">
<smd:id>0000001751376056503931-65535</smd:id> <smd:id>0000001751376056503931-65535</smd:id>
<smd:issuerInfo issuerID="65535"> <smd:issuerInfo issuerID="65535">
<smd:org>ICANN TMCH TESTING TMV</smd:org> <smd:org>ICANN TMCH TESTING TMV</smd:org>
<smd:email>notavailable@example.com</smd:email> <smd:email>notavailable@example.com</smd:email>
<smd:url>http://www.example.com</smd:url> <smd:url>https://www.example.com</smd:url>
<smd:voice>+32.000000</smd:voice> <smd:voice>+32.000000</smd:voice>
</smd:issuerInfo> </smd:issuerInfo>
<smd:notBefore>2013-08-09T13:55:03.931Z</smd:notBefore> <smd:notBefore>2013-08-09T13:55:03.931Z</smd:notBefore>
<smd:notAfter>2017-07-23T22:00:00.000Z</smd:notAfter> <smd:notAfter>2017-07-23T22:00:00.000Z</smd:notAfter>
<mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"> <mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
<mark:trademark> <mark:trademark>
<mark:id>00052013734689731373468973-65535</mark:id> <mark:id>00052013734689731373468973-65535</mark:id>
<mark:markName>Test &amp; Validate</mark:markName> <mark:markName>Test &amp; Validate</mark:markName>
<mark:holder entitlement="owner"> <mark:holder entitlement="owner">
<mark:org>Ag corporation</mark:org> <mark:org>Ag corporation</mark:org>
skipping to change at page 12, line 16 skipping to change at page 13, line 8
</Signature> </Signature>
</smd:signedMark> </smd:signedMark>
NOTE: The example shown above includes white-spaces for indentation NOTE: The example shown above includes white-spaces for indentation
purposes. It is RECOMMENDED that SMDs do not include white-spaces purposes. It is RECOMMENDED that SMDs do not include white-spaces
between the XML elements, in order to mitigate risks of invalidating between the XML elements, in order to mitigate risks of invalidating
the digital signature when transferring of SMDs between applications the digital signature when transferring of SMDs between applications
takes place. takes place.
NOTE: Exclusive XML canonicalization as defined in [XMLC14N] SHOULD NOTE: Exclusive XML canonicalization as defined in [XMLC14N] SHOULD
be used when generating the SMD. SHA256 as suggested by [RFC6194] be used when generating the SMD.
and RSA-SHA256 SHOULD be used for digesting and signing respectively.
The size of the RSA key SHOULD be at least 2048 bits. NOTE: The digital signature algorithm used SHOULD be RSA-SHA256
[RFC4051]. The size of the RSA key SHOULD be at least 2048 bits. A
valid reason for choosing something else would be if RSA-SHA256 would
be deemed to not provide sufficient security.
2.4. Encoded Signed Mark 2.4. Encoded Signed Mark
The <smd:encodedSignedMark> element contains an encoded form of the The <smd:encodedSignedMark> element contains an encoded form of the
digitally signed <smd:signedMark> element, described in Section 2.3, digitally signed <smd:signedMark> element, described in Section 2.3,
with the encoding defined by the "encoding" attribute with the with the encoding defined by the "encoding" attribute with the
default "encoding" value of "base64". The "base64" encoded text of default "encoding" value of "base64" [RFC4648].
the <smd:encodedSignedMark> element MUST conform to [RFC2045]. A
full example of a <smd:encodedSignedMark> element is presented in
Appendix A.
2.5. Appendix A. base64 encoded signedMark
The following is an example of a <smd:encodedSignedMark> element that The following is an example of a <smd:encodedSignedMark> element that
uses the default "base64" for encoding a <smd:signedMark> element. uses the default "base64" for encoding a <smd:signedMark> element.
<smd:encodedSignedMark <smd:encodedSignedMark
xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"> xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ
rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW
Q9Il84Yzk0ZjRmMS1jZTlmLTRjOTAtOTUzMS01MzE1ZDIzY2EzYmQiPgogIDxzbWQ6aWQ+M ... (base64 data elided for brevity) ...
DAwMDAwMTc1MTM3NjA1NjUwMzkzMS02NTUzNTwvc21kOmlkPgogIDxzbWQ6aXNzdWVySW5m
byBpc3N1ZXJJRD0iNjU1MzUiPgogICAgPHNtZDpvcmc+SUNBTk4gVE1DSCBURVNUSU5HIFR
NVjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+bm90YXZhaWxhYmxlQGV4YW1wbGUuY29tPC
9zbWQ6ZW1haWw+CiAgICA8c21kOnVybD5odHRwOi8vd3d3LmV4YW1wbGUuY29tPC9zbWQ6d
XJsPgogICAgPHNtZDp2b2ljZT4rMzIuMDAwMDAwPC9zbWQ6dm9pY2U+CiAgPC9zbWQ6aXNz
dWVySW5mbz4KICA8c21kOm5vdEJlZm9yZT4yMDEzLTA4LTA5VDEzOjU1OjAzLjkzMVo8L3N
tZDpub3RCZWZvcmU+CiAgPHNtZDpub3RBZnRlcj4yMDE3LTA3LTIzVDIyOjAwOjAwLjAwMF
o8L3NtZDpub3RBZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhc
mFtczp4bWw6bnM6bWFyay0xLjAiPgogICAgPG1hcms6dHJhZGVtYXJrPgogICAgICA8bWFy
azppZD4wMDA1MjAxMzczNDY4OTczMTM3MzQ2ODk3My02NTUzNTwvbWFyazppZD4KICAgICA
gPG1hcms6bWFya05hbWU+VGVzdCAmYW1wOyBWYWxpZGF0ZTwvbWFyazptYXJrTmFtZT4KIC
AgICAgPG1hcms6aG9sZGVyIGVudGl0bGVtZW50PSJvd25lciI+CiAgICAgICAgPG1hcms6b
3JnPkFnIGNvcnBvcmF0aW9uPC9tYXJrOm9yZz4KICAgICAgICA8bWFyazphZGRyPgogICAg
ICAgICAgPG1hcms6c3RyZWV0PjEzMDUgQnJpZ2h0IEF2ZW51ZTwvbWFyazpzdHJlZXQ+CiA
gICAgICAgICA8bWFyazpjaXR5PkFyY2FkaWE8L21hcms6Y2l0eT4KICAgICAgICAgIDxtYX
JrOnNwPkNBPC9tYXJrOnNwPgogICAgICAgICAgPG1hcms6cGM+OTAwMjg8L21hcms6cGM+C
iAgICAgICAgICA8bWFyazpjYz5VUzwvbWFyazpjYz4KICAgICAgICA8L21hcms6YWRkcj4K
ICAgICAgPC9tYXJrOmhvbGRlcj4KICAgICAgPG1hcms6Y29udGFjdCB0eXBlPSJhZ2VudCI
+CiAgICAgICAgPG1hcms6bmFtZT5Ub255IEhvbGxhbmQ8L21hcms6bmFtZT4KICAgICAgIC
A8bWFyazpvcmc+QWcgY29ycG9yYXRpb248L21hcms6b3JnPgogICAgICAgIDxtYXJrOmFkZ
HI+CiAgICAgICAgICA8bWFyazpzdHJlZXQ+MTMwNSBCcmlnaHQgQXZlbnVlPC9tYXJrOnN0
cmVldD4KICAgICAgICAgIDxtYXJrOmNpdHk+QXJjYWRpYTwvbWFyazpjaXR5PgogICAgICA
gICAgPG1hcms6c3A+Q0E8L21hcms6c3A+CiAgICAgICAgICA8bWFyazpwYz45MDAyODwvbW
FyazpwYz4KICAgICAgICAgIDxtYXJrOmNjPlVTPC9tYXJrOmNjPgogICAgICAgIDwvbWFya
zphZGRyPgogICAgICAgIDxtYXJrOnZvaWNlPisxLjIwMjU1NjIzMDI8L21hcms6dm9pY2U+
CiAgICAgICAgPG1hcms6ZmF4PisxLjIwMjU1NjIzMDE8L21hcms6ZmF4PgogICAgICAgIDx
tYXJrOmVtYWlsPmluZm9AYWdjb3Jwb3JhdGlvbi5jb208L21hcms6ZW1haWw+CiAgICAgID
wvbWFyazpjb250YWN0PgogICAgICA8bWFyazpqdXJpc2RpY3Rpb24+VVM8L21hcms6anVya
XNkaWN0aW9uPgogICAgICA8bWFyazpjbGFzcz4xNTwvbWFyazpjbGFzcz4KICAgICAgPG1h
cms6bGFiZWw+dGVzdGFuZHZhbGlkYXRlPC9tYXJrOmxhYmVsPgogICAgICA8bWFyazpsYWJ
lbD50ZXN0LS0tdmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3
RhbmQtdmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtZXQtd
mFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtdmFsaWRhdGU8
L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtLXZhbGlkYXRlPC9tYXJrOmx
hYmVsPgogICAgICA8bWFyazpsYWJlbD50ZXN0LWV0dmFsaWRhdGU8L21hcms6bGFiZWw+Ci
AgICAgIDxtYXJrOmxhYmVsPnRlc3RldHZhbGlkYXRlPC9tYXJrOmxhYmVsPgogICAgICA8b
WFyazpsYWJlbD50ZXN0dmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVs
PnRlc3RldC12YWxpZGF0ZTwvbWFyazpsYWJlbD4KICAgICAgPG1hcms6Z29vZHNBbmRTZXJ
2aWNlcz5ndWl0YXI8L21hcms6Z29vZHNBbmRTZXJ2aWNlcz4KICAgICAgPG1hcms6cmVnTn
VtPjEyMzQ8L21hcms6cmVnTnVtPgogICAgICA8bWFyazpyZWdEYXRlPjIwMTItMTItMzFUM
jM6MDA6MDAuMDAwWjwvbWFyazpyZWdEYXRlPgogICAgPC9tYXJrOnRyYWRlbWFyaz4KICA8
L21hcms6bWFyaz4KPGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmc
vMjAwMC8wOS94bWxkc2lnIyIgSWQ9Il81ODg5YzM5Zi1jMzM3LTQ0NzctOTU1Ni05NTNiZT
A5Y2NkMTgiPjxkczpTaWduZWRJbmZvPjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ
29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PGRz
OlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQ
veG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiLz48ZHM6UmVmZXJlbmNlIFVSST0iI184Yzk0Zj
RmMS1jZTlmLTRjOTAtOTUzMS01MzE1ZDIzY2EzYmQiPjxkczpUcmFuc2Zvcm1zPjxkczpUc
mFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj
ZW52ZWxvcGVkLXNpZ25hdHVyZSIvPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8
vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48L2RzOlRyYW5zZm9ybXM+PG
RzOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQve
G1sZW5jI3NoYTI1NiIvPjxkczpEaWdlc3RWYWx1ZT5IdUdKYlZCWkVaVGlFelB2d0NObVFs
NmFMZEExWHo1QzAzdnhDWFBIZW1BPTwvZHM6RGlnZXN0VmFsdWU+PC9kczpSZWZlcmVuY2U
+PGRzOlJlZmVyZW5jZSBVUkk9IiNfMWRlNTg5OGMtNmY3Ny00ZDViLTlkZDgtMzE4MWM5MT
E3Yzk3Ij48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL
3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxk
czpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3h
tbGVuYyNzaGEyNTYiLz48ZHM6RGlnZXN0VmFsdWU+NHBiU0M2M2xObVBxelc3TDBNRDBxZ0
5GNHc5SUE3YXQ3OWxEVE5VZjBndz08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlP
jwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWUgSWQ9Il9hODAwZmIwNS02NjRh
LTQ2OTItYjM5MS04OTM4NTlhNTM0OGQiPlc5VHAxQ09HeEk4dlZQNkZONEdpYlhtc3RRM1Z
0bmpSZVN3VVdicFZCTEtmenZ1L1c1OGNoOUdxdnRQTm9HZTdXOXVvQUt0U1J0MUkKMzdPeD
IwQmVQb2xGdWZmekVVR3NGMHBETkRoWmNiRUdEMlVWRTBpYnhIRkVDUU13d0ppK1NVb2ora
3JIWmRXM0FybmNaZ0RkMkhXZgpudVJZSmVucnpCS2k2RG1YVlVRYlhXRFVkbGxzcjlDSmtB
THYrd0s2V2RweE9Na0NTc2E0WUU2bEVNTjVXNGhzUXFlZ2N6ZGkwdUZ0CnZxQ2JLVnM3RTJ
3c0VIZC94aUxzbldZNEUxNWdLNnI0UW9tWHJqdFI0ZkFyZ1lMTnRLK09NRCt6UktNeGNuNV
F2QzJVeHlzNUV6RHcKNmhlenYrdXBxTldkRjRYL2lCNW1JY25DMzAraVBpY3lDb2JHUlE9P
TwvZHM6U2lnbmF0dXJlVmFsdWU+PGRzOktleUluZm8gSWQ9Il8xZGU1ODk4Yy02Zjc3LTRk
NWItOWRkOC0zMTgxYzkxMTdjOTciPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXR
lPk1JSUZMekNDQkJlZ0F3SUJBZ0lnTHJBYmV2b2FlNTJ5M2Y2QzJ0QjBTbjNwN1hKbTBUMD
JGb2d4S0NmTmhYb3dEUVlKS29aSWh2Y04KQVFFTEJRQXdmREVMTUFrR0ExVUVCaE1DVlZNe
FBEQTZCZ05WQkFvVE0wbHVkR1Z5Ym1WMElFTnZjbkJ2Y21GMGFXOXVJR1p2Y2lCQgpjM05w
WjI1bFpDQk9ZVzFsY3lCaGJtUWdUblZ0WW1WeWN6RXZNQzBHQTFVRUF4TW1TVU5CVGs0Z1Z
ISmhaR1Z0WVhKcklFTnNaV0Z5CmFXNW5hRzkxYzJVZ1VHbHNiM1FnUTBFd0hoY05NVE13Tm
pJMk1EQXdNREF3V2hjTk1UZ3dOakkxTWpNMU9UVTVXakNCanpFTE1Ba0cKQTFVRUJoTUNRa
1V4SURBZUJnTlZCQWdURjBKeWRYTnpaV3h6TFVOaGNHbDBZV3dnVW1WbmFXOXVNUkV3RHdZ
RFZRUUhFd2hDY25WegpjMlZzY3pFUk1BOEdBMVVFQ2hNSVJHVnNiMmwwZEdVeE9EQTJCZ05
WQkFNVEwwbERRVTVPSUZSTlEwZ2dRWFYwYUc5eWFYcGxaQ0JVCmNtRmtaVzFoY21zZ1VHbH
NiM1FnVm1Gc2FXUmhkRzl5TUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ
2dLQ0FRRUEKeGxwM0twWUhYM1d5QXNGaFNrM0x3V2ZuR2x4blVERnFGWkEzVW91TVlqL1hp
Z2JNa05lRVhJamxrUk9LVDRPUEdmUngvTEF5UmxRUQpqQ012NHFoYmtjWDFwN2FyNjNmbHE
0U1pOVmNsMTVsN2gwdVQ1OEZ6U2ZubHowdTVya0hmSkltRDQzK21hUC84Z3YzNkZSMjdqVz
hSCjl3WTRoaytXczRJQjBpRlNkOFNYdjFLcjh3L0ptTVFTRGtpdUcrUmZJaXVid1EvZnk3R
WtqNVFXaFBadyttTXhOS25IVUx5M3hZejIKTHdWZmZ0andVdWVhY3ZxTlJDa01YbENsT0FE
cWZUOG9TWm9lRFhlaEh2bFBzTENlbUdCb1RLdXJza0lTNjlGMHlQRUg1Z3plMEgrZgo4RlJ
Pc0lvS1NzVlEzNEI0Uy9qb0U2N25wc0pQVGRLc05QSlR5UUlEQVFBQm80SUJoekNDQVlNd0
RBWURWUjBUQVFIL0JBSXdBREFkCkJnTlZIUTRFRmdRVW9GcFk3NnA1eW9ORFJHdFFwelZ1U
jgxVVdRMHdnY1lHQTFVZEl3U0J2akNCdTRBVXc2MCtwdFlSQUVXQVhEcFgKU29wdDNERU5u
bkdoZ1lDa2ZqQjhNUXN3Q1FZRFZRUUdFd0pWVXpFOE1Eb0dBMVVFQ2hNelNXNTBaWEp1Wlh
RZ1EyOXljRzl5WVhScApiMjRnWm05eUlFRnpjMmxuYm1Wa0lFNWhiV1Z6SUdGdVpDQk9kVz
FpWlhKek1TOHdMUVlEVlFRREV5WkpRMEZPVGlCVWNtRmtaVzFoCmNtc2dRMnhsWVhKcGJtZ
G9iM1Z6WlNCUWFXeHZkQ0JEUVlJZ0xyQWJldm9hZTUyeTNmNkMydEIwU24zcDdYSm0wVDAy
Rm9neEtDZk4KaFhrd0RnWURWUjBQQVFIL0JBUURBZ2VBTURRR0ExVWRId1F0TUNzd0thQW5
vQ1dHSTJoMGRIQTZMeTlqY213dWFXTmhibTR1YjNKbgpMM1J0WTJoZmNHbHNiM1F1WTNKc0
1FVUdBMVVkSUFRK01Ed3dPZ1lES2dNRU1ETXdNUVlJS3dZQkJRVUhBZ0VXSldoMGRIQTZMe
TkzCmQzY3VhV05oYm00dWIzSm5MM0JwYkc5MFgzSmxjRzl6YVhSdmNua3dEUVlKS29aSWh2
Y05BUUVMQlFBRGdnRUJBSWVEWVlKcjYwVzMKeTlRcyszelJWSTlrZWtLb201dmtIT2FsQjN
3SGFaSWFBRllwSTk4dFkwYVZOOWFHT04wdjZXUUYrbnZ6MUtSWlFiQXowMUJYdGFSSgo0bV
BrYXJoaHVMbjlOa0J4cDhIUjVxY2MrS0g3Z3Y2ci9jMGlHM2JDTkorUVNyN1FmKzVNbE1vN
npMNVVkZFUvVDJqaWJNWENqL2YyCjFRdzN4OVFnb3lYTEZKOW96YUxnUTlSTWtMbE9temtD
QWlYTjVBYjQzYUo5ZjdOMmdFMk5uUmpOS21tQzlBQlEwVFJ3RUtWTGhWbDEKVUdxQ0hKM0F
sQlhXSVhONXNqUFFjRC8rbkhlRVhNeFl2bEF5cXhYb0QzTVd0UVZqN2oyb3FsYWtPQk1nRz
grcTJxWWxtQnRzNEZOaQp3NzQ4SWw1ODZIS0JScXhIdFpkUktXMlZxYVE9PC9kczpYNTA5Q
2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L2RzOktleUluZm8+PC9kczpTaWduYXR1cmU+
PC9zbWQ6c2lnbmVkTWFyaz4= PC9zbWQ6c2lnbmVkTWFyaz4=
</smd:encodedSignedMark> </smd:encodedSignedMark>
3. Formal Syntax 3. Formal Syntax
Two schemas are presented here. The first schema is the schema for Two schemas are presented here. The first schema is the schema for
the signed mark. The second schema is the schema for the mark. the signed mark. The second schema is the schema for the mark.
The formal syntax presented here is a complete schema representation The formal syntax presented here is a complete schema representation
of the object mapping suitable for automated validation of EPP XML of the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI are used to note the beginning and ending of the schema for URI
registration purposes. registration purposes.
3.1. Signed Mark Schema 3.1. Signed Mark Schema
Copyright (c) 2012 IETF Trust and the persons identified as authors Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions modification, is permitted pursuant to, and subject to the license
are met: terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
o Redistributions of source code must retain the above copyright Documents (http://trustee.ietf.org/license-info).
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema <schema
targetNamespace="urn:ietf:params:xml:ns:signedMark-1.0" targetNamespace="urn:ietf:params:xml:ns:signedMark-1.0"
xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0" xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"
xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Schema for representing a Signed Trademark. Schema for representing a Signed Trademark.
</documentation> </documentation>
</annotation> </annotation>
<import namespace="urn:ietf:params:xml:ns:mark-1.0" <import namespace="urn:ietf:params:xml:ns:mark-1.0" />
schemaLocation="mark-1.0.xsd" /> <import namespace="http://www.w3.org/2000/09/xmldsig#" />
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
<!-- <!--
Abstract signed mark for replacement via substitution. Abstract signed mark for replacement via substitution.
--> -->
<element name="abstractSignedMark" type="smd:abstractSignedMarkType" <element name="abstractSignedMark" type="smd:abstractSignedMarkType"
abstract="true"/> abstract="true"/>
<!-- <!--
Empty type for use in extending for a signed mark Empty type for use in extending for a signed mark
--> -->
skipping to change at page 17, line 31 skipping to change at page 15, line 34
<extension base="token"> <extension base="token">
<attribute name="encoding" type="token" default="base64"/> <attribute name="encoding" type="token" default="base64"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
</schema> </schema>
END END
3.2. Mark Schema 3.2. Mark Schema
Copyright (c) 2012 IETF Trust and the persons identified as authors Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions modification, is permitted pursuant to, and subject to the license
are met: terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
o Redistributions of source code must retain the above copyright Documents (http://trustee.ietf.org/license-info).
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema <schema
targetNamespace="urn:ietf:params:xml:ns:mark-1.0" targetNamespace="urn:ietf:params:xml:ns:mark-1.0"
xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Schema for representing a Trademark, also referred to Schema for representing a Trademark, also referred to
as Mark. as Mark.
</documentation> </documentation>
</annotation> </annotation>
<!-- <!--
Abstract mark for replacement via substitution. Abstract mark for replacement via substitution.
--> -->
skipping to change at page 26, line 22 skipping to change at page 23, line 43
Licensing: Proprietary Licensing: Proprietary
Contact: fobispo@uniregistry.link Contact: fobispo@uniregistry.link
5. Acknowledgements 5. Acknowledgements
Special thanks to Chris Wright for creating the first prototype of a Special thanks to Chris Wright for creating the first prototype of a
SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and
SMD definitions in their EPP draft launch extension on which this SMD definitions in their EPP draft launch extension on which this
draft is based. Portions of the security section were shamefully draft is based. Portions of the security section were shamefully
copied from RFC5105. Special suggestions that have been incorporated copied from RFC5105. The author would like to acknowledge the
into this document were provided by Scott Hollenbeck. following individuals for their contributions to this document: Scott
Hollenbeck and Jan Jansen.
6. Change History
[[RFC Editor: Please remove this section.]]
Version draft-ietf-eppext-tmch-smd-02 to version draft-ietf-eppext-
tmch-smd-03
RFC6194 and RFC6982 moved to informative references section.
Version draft-ietf-eppext-tmch-smd-01 to version draft-ietf-eppext-
tmch-smd-02
Security considerations section was updated.
IANA considerations section was updated.
Normative reference added for the ICANN Trademark Clearinghouse
definition document.
Editorial changes.
Version draft-ietf-eppext-tmch-smd-00 to version draft-ietf-eppext-
tmch-smd-01
Implementation Status section added.
Added type to the enconding element.
Version draft-lozano-tmch-smd-03 to version draft-ietf-eppext-tmch-
smd-00
Internet-Draft resubmitted.
Version 02 to version 03
<smd:signedMark> example is now aligned with ICANN test SMDs.
<smd:encodedSignedMark> example is replaced with a public ICANN
test SMD.
Several recommendations where added.
Version 01 to version 02
Change apID and regNum of trademark validated mark to token.
Change refNum of treatyOrStatute validated mark to token.
Change refNum of court validated mark to token.
Version 00 to version 01
Add missing email element to holderType.
Change ruling from an attribute to an element.
Version preview-01 to version 00
signedMarkType now ref mark:abstractMark.
Security section completed.
Version preview-00 to preview-01
Full example of an encodedSignedMark added.
signedMark example now fully validates with XSD.
Fixed labelType to allow two-character labels.
Missing mark:protectionType added in the XSD.
Issuer email is now required.
7. IANA Considerations 6. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Two URI conforming to a registry mechanism described in [RFC3688]. Two URI
assignments have been registered by the IANA. assignments have been registered by the IANA.
Registration request for the signed mark namespace: Registration request for the signed mark namespace:
URI: urn:ietf:params:xml:ns:signedMark-1.0 URI: urn:ietf:params:xml:ns:signedMark-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG
document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the signed mark schema: Registration request for the signed mark schema:
URI: urn:ietf:params:xml:schema:signedMark-1.0 URI: urn:ietf:params:xml:schema:signedMark-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG
document.
XML: See the "Formal Syntax" section of this document. XML: See the "Formal Syntax" section of this document.
Registration request for the mark namespace: Registration request for the mark namespace:
URI: urn:ietf:params:xml:ns:mark-1.0 URI: urn:ietf:params:xml:ns:mark-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG
document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the mark schema: Registration request for the mark schema:
URI: urn:ietf:params:xml:schema:mark-1.0 URI: urn:ietf:params:xml:schema:mark-1.0
Registrant Contact: See the "Author's Address" section of this Registrant Contact: IESG
document.
XML: See the "Formal Syntax" section of this document. XML: See the "Formal Syntax" section of this document.
8. Security Considerations 7. Security Considerations
The security of a SMD file depends on the security of the underlying The security of a Signed Mark object depends on the security of the
XML DSIG algorithms. As such, all the security considerations from underlying XML DSIG algorithms. As such, all the security
[XMLDSIG] apply here as well. SMD files generated for the ICANN new considerations from [XMLDSIG] apply here as well.
gTLD program use the algorithms for digesting and signing recommended
in this document.
The SMD file is not encrypted. If local policy dictates that the In the case of the ICANN Trademark Clearinghouse (TMCH), Signed Mark
information contained within the SMD file should be confidential, objects use the algorithms for digesting and signing recommended in
then this has to be handled through a different mechanism. this document.
SMD files are used primarily for sunrise domain name registrations in Signed Marks are used primarily for sunrise domain name registrations
gTLDs, but other third-parties might be using SMD files. A party in gTLDs, but other third-parties might be using them. A party using
using a SMD file should verify that the SMD file is valid based on Signed Marks should verify that the digital signature is valid based
local policy. In the case of gTLDs, the RPM Requirements on local policy. In the case of gTLDs, the RPM Requirements document
[ICANN-TMCH] defines such policy. [ICANN-TMCH] defines such policy.
9. References 8. References
9.1. Normative References 8.1. Normative References
[ICANN-TMCH] [ICANN-TMCH]
ICANN, "ICANN Trademark Clearinghouse, Rights Protection ICANN, "ICANN Trademark Clearinghouse, Rights Protection
Mechanism Requirements", 2013, Mechanism Requirements", 2013,
<http://newgtlds.icann.org/en/about/trademark- <http://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-30sep13-en.pdf>. clearinghouse/rpm-requirements-30sep13-en.pdf>.
[ISO3166-2] [ISO3166-2]
ISO, "International Standard for country codes and codes ISO, "International Standard for country codes and codes
for their subdivisions", 2006, for their subdivisions", 2006,
<http://www.iso.org/iso/home/standards/country_codes.htm>. <http://www.iso.org/iso/home/standards/country_codes.htm>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [ITU.E164.2005]
Extensions (MIME) Part One: Format of Internet Message International Telecommunication Union, "The international
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, public telecommunication numbering plan", 2010,
<http://www.rfc-editor.org/info/rfc2045>. <https://www.itu.int/rec/T-REC-E.164-201011-I/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform
Resource Identifiers (URIs)", RFC 4051,
DOI 10.17487/RFC4051, April 2005,
<http://www.rfc-editor.org/info/rfc4051>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<http://www.rfc-editor.org/info/rfc5730>. <http://www.rfc-editor.org/info/rfc5730>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[WIPO-NICE-CLASSES] [WIPO-NICE-CLASSES]
skipping to change at page 30, line 29 skipping to change at page 26, line 25
WIPO, "Recommended standard on two-letter codes for the WIPO, "Recommended standard on two-letter codes for the
representation of states, other entities and representation of states, other entities and
intergovernmental organizations", March 2007, intergovernmental organizations", March 2007,
<http://www.wipo.int/standards/en/pdf/03-03-01.pdf>. <http://www.wipo.int/standards/en/pdf/03-03-01.pdf>.
[XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization [XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization
Version 1.0", 2002, Version 1.0", 2002,
<http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>. <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.
[XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing [XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing
(Second Edition)", 2008, (Second Edition)", 2013,
<http://www.w3.org/TR/2008/REC-xmldsig-core-20080610>. <http://www.w3.org/TR/xmldsig-core1>.
9.2. Informative References
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 8.2. Informative References
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
Author's Address Author's Address
Gustavo Lozano Gustavo Lozano
ICANN ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles 90292 Los Angeles 90292
US US
Phone: +1.3103015800 Phone: +1.3103015800
Email: gustavo.lozano@icann.org Email: gustavo.lozano@icann.org
 End of changes. 44 change blocks. 
348 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/