draft-ietf-scim-core-schema-04.txt   draft-ietf-scim-core-schema-05.txt 
Network Working Group K. Grizzle Network Working Group K. Grizzle
Internet-Draft SailPoint Internet-Draft SailPoint
Intended status: Standards Track P. Hunt, Ed. Intended status: Standards Track P. Hunt, Ed.
Expires: October 30, 2014 Oracle Expires: November 14, 2014 Oracle
E. Wahlstroem E. Wahlstroem
Technology Nexus Technology Nexus
C. Mortimore C. Mortimore
Salesforce Salesforce
April 28, 2014 May 13, 2014
System for Cross-Domain Identity Management: Core Schema System for Cross-Domain Identity Management: Core Schema
draft-ietf-scim-core-schema-04 draft-ietf-scim-core-schema-05
Abstract Abstract
The System for Cross-Domain Identity Management (SCIM) specification The System for Cross-Domain Identity Management (SCIM) specification
is designed to make managing user identity in cloud based is designed to make managing user identity in cloud based
applications and services easier. The specification suite builds applications and services easier. The specification suite builds
upon experience with existing schemas and deployments, placing upon experience with existing schemas and deployments, placing
specific emphasis on simplicity of development and integration, while specific emphasis on simplicity of development and integration, while
applying existing authentication, authorization, and privacy models. applying existing authentication, authorization, and privacy models.
Its intent is to reduce the cost and complexity of user management Its intent is to reduce the cost and complexity of user management
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 October 30, 2014. This Internet-Draft will expire on November 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Requirements Notation and Conventions . . . . . . . . . . . . 3 1. Requirements Notation and Conventions . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCIM Schema Structure . . . . . . . . . . . . . . . . . . . . 4 3. SCIM Schema Structure . . . . . . . . . . . . . . . . . . . . 5
3.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5 3.1. Attribute Data Types . . . . . . . . . . . . . . . . . . 5
3.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.4. Integer . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6 3.1.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.6. Binary . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 6 3.1.7. Reference . . . . . . . . . . . . . . . . . . . . . . 6
3.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.8. Complex . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7 3.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 10 skipping to change at page 3, line 10
11. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Schema Schema . . . . . . . . . . . . . . . . . . . . . . . . 19
12. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23 12. JSON Representation . . . . . . . . . . . . . . . . . . . . . 23
12.1. Minimal User Representation . . . . . . . . . . . . . . 23 12.1. Minimal User Representation . . . . . . . . . . . . . . 23
12.2. Full User Representation . . . . . . . . . . . . . . . . 24 12.2. Full User Representation . . . . . . . . . . . . . . . . 24
12.3. Enterprise User Extension Representation . . . . . . . . 26 12.3. Enterprise User Extension Representation . . . . . . . . 26
12.4. Group Representation . . . . . . . . . . . . . . . . . . 29 12.4. Group Representation . . . . . . . . . . . . . . . . . . 29
12.5. Service Provider Configuration Representation . . . . . 30 12.5. Service Provider Configuration Representation . . . . . 30
12.6. Resource Type Representation . . . . . . . . . . . . . . 31 12.6. Resource Type Representation . . . . . . . . . . . . . . 31
12.7. Schema Representation . . . . . . . . . . . . . . . . . 32 12.7. Schema Representation . . . . . . . . . . . . . . . . . 32
13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 13. Security Considerations . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . 54 14.1. Registering New SCIM Schemas . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . 55 14.1.1. Registration Procedure . . . . . . . . . . . . . . . 54
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 55 14.1.2. Schema Registration Template . . . . . . . . . . . . 55
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 56 14.2. Initial SCIM Schema Registry . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.1. Normative References . . . . . . . . . . . . . . . . . . 56
15.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 58
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Requirements Notation and Conventions 1. Requirements Notation and Conventions
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 [RFC2119] . document are to be interpreted as described in [RFC2119] .
Throughout this document, values are quoted to indicate that they are Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages, to be taken literally. When using these values in protocol messages,
the quotes MUST NOT be used as part of the value. the quotes MUST NOT be used as part of the value.
skipping to change at page 5, line 10 skipping to change at page 5, line 16
SCIM schema provides a minimal core schema for representing users and SCIM schema provides a minimal core schema for representing users and
groups (resources), encompassing common attributes found in many groups (resources), encompassing common attributes found in many
existing deployments and schemas. existing deployments and schemas.
A resource is a collection of attributes identified by one or more A resource is a collection of attributes identified by one or more
schemas. Minimally, an attribute consists of the attribute name and schemas. Minimally, an attribute consists of the attribute name and
at least one simple or complex value either of which may be multi- at least one simple or complex value either of which may be multi-
valued. SCIM schema defines the data type, plurality and other valued. SCIM schema defines the data type, plurality and other
distinguishing features of an attribute. Unless otherwise specified distinguishing features of an attribute. Unless otherwise specified
all attributes are modifiable by consumers. Attribute definitions all attributes are modifiable by consumers.
contain a property "mutability" that determines whether an attribute
is: "readOnly", "writeOnly", "immutable", or "readWrite"(the
default). Additionally, service providers MAY define other
properties such as returnability Resource's schema endpoint
(Section 5.2).
Attribute names SHOULD be camelCased. SCIM resources are represented Attribute names SHOULD be camelCased. SCIM resources are represented
in JSON [RFC7159] and MUST specify schema via the "schemas" attribute in JSON [RFC7159] and MUST specify schema via the "schemas" attribute
per Section 5.2. per Section 5.2.
Attribute names MUST conform to the following ABNF [RFC5234] rules: Attribute names MUST conform to the following ABNF [RFC5234] rules:
ATTRNAME = ALPHA *(nameChar) ATTRNAME = ALPHA *(nameChar)
nameChar = "-" / "_" / DIGIT / ALPHA nameChar = "-" / "_" / DIGIT / ALPHA
skipping to change at page 6, line 7 skipping to change at page 6, line 7
of type String (Section 3.1.1). of type String (Section 3.1.1).
The JSON format defines a limited set of data types, hence, where The JSON format defines a limited set of data types, hence, where
appropriate, alternate JSON representations derived from XML Schema appropriate, alternate JSON representations derived from XML Schema
[XML-Schema] are defined below. SCIM extensions SHOULD NOT introduce [XML-Schema] are defined below. SCIM extensions SHOULD NOT introduce
new data types. new data types.
3.1.1. String 3.1.1. String
A sequence of zero or more Unicode characters. The JSON format is A sequence of zero or more Unicode characters encoded using UTF-8 as
defined in Section 7 [RFC7159] . A "String" attribute MAY specify a per [RFC2277] and [RFC3629]. The JSON format is defined in Section 7
required data format. Additionally, when canonical values are [RFC7159] . A "String" attribute MAY specify a required data format.
specified service providers SHOULD conform to those values if Additionally, when canonical values are specified service providers
appropriate, but MAY provide alternate "String" values to represent SHOULD conform to those values if appropriate, but MAY provide
additional values. alternate "String" values to represent additional values.
3.1.2. Boolean 3.1.2. Boolean
The literal "true" or "false". The JSON format is defined in The literal "true" or "false". The JSON format is defined in
Section 3 [RFC7159] . Section 3 [RFC7159] .
3.1.3. Decimal 3.1.3. Decimal
A real number with at least one digit to the left and right of the A real number with at least one digit to the left and right of the
period. The JSON format is defined in Section 6 [RFC7159] . period. The JSON format is defined in Section 6 [RFC7159] .
3.1.4. Integer 3.1.4. Integer
A decimal number with no fractional digits. The JSON format is A decimal number with no fractional digits. The JSON format is
defined in Section 6 [RFC7159] with the additional constraint that defined in Section 6 [RFC7159] with the additional constraint that
the value MUST NOT contain fractionial or exponent parts. the value MUST NOT contain fractional or exponent parts.
3.1.5. DateTime 3.1.5. DateTime
A DateTime value (e.g. 2008-01-23T04:56:22Z). The attribute value A DateTime value (e.g. 2008-01-23T04:56:22Z). The attribute value
MUST be encoded as a valid xsd:dateTime as specified in Section 3.2.7 MUST be encoded as a valid xsd:dateTime as specified in Section 3.2.7
[XML-Schema] . [XML-Schema] .
Values represented in JSON MUST conform to the XML constraints above Values represented in JSON MUST conform to the XML constraints above
and are represented as a JSON String per Section 7 [RFC7159]. and are represented as a JSON String per Section 7 [RFC7159].
skipping to change at page 12, line 10 skipping to change at page 12, line 10
may be indicated by a user agent (which might be shared), or in a may be indicated by a user agent (which might be shared), or in a
non-user present interaction (such as in a delegated OAuth2 non-user present interaction (such as in a delegated OAuth2
[RFC6749] style interaction) where normal HTTP Accept-Language [RFC6749] style interaction) where normal HTTP Accept-Language
header negotiation cannot take place. header negotiation cannot take place.
locale Used to indicate the User's default location for purposes of locale Used to indicate the User's default location for purposes of
localizing items such as currency, date time format, numerical localizing items such as currency, date time format, numerical
representations, etc. A valid value is a language tag as defined representations, etc. A valid value is a language tag as defined
in [RFC5646]. Computer languages are explicitly excluded. in [RFC5646]. Computer languages are explicitly excluded.
A language tag is a sequence of one or more case-insensitive A language tag is a sequence of one or more case-insensitive sub-
subtags, each separated by a hyphen character ("-", %x2D). For tags, each separated by a hyphen character ("-", %x2D). For
backwards compatibility reasons, servers MAY accept tags separated backwards compatibility reasons, servers MAY accept tags separated
by an underscore character ("_", %5F). In most cases, a language by an underscore character ("_", %5F). In most cases, a language
tag consists of a primary language subtag that identifies a broad tag consists of a primary language sub-tag that identifies a broad
family of related languages (e.g., "en" = English) which is family of related languages (e.g., "en" = English) which is
optionally followed by a series of subtags that refine or narrow optionally followed by a series of sub-tags that refine or narrow
that language's range (e.g., "en-CA" = the variety of English as that language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a communicated in Canada). Whitespace is not allowed within a
language tag. Example tags include: language tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
timezone The User's time zone in IANA Time Zone database format timezone The User's time zone in IANA Time Zone database format
[RFC6557], also known as "Olson" timezone database [RFC6557], also known as "Olson" timezone database
skipping to change at page 20, line 6 skipping to change at page 20, line 6
multiValued Boolean value indicating the attribute's plurality. multiValued Boolean value indicating the attribute's plurality.
description The attribute's human readable description. When description The attribute's human readable description. When
applicable service providers MUST specify the description applicable service providers MUST specify the description
specified in the core schema specification. specified in the core schema specification.
required A Boolean value that specifies if the attribute is required A Boolean value that specifies if the attribute is
required. required.
caseExact A Boolean value that specifies if the String attribute caseExact A Boolean value that specifies if the String attribute
is case sensitive. is case sensitive. The server SHALL use case sensitivity when
evaluating filters. For attributes that are case exact, the
server SHALL preserve case for any value submitted. If the
attribute is case insensitive, the server MAY alter case for a
submitted value.
mutability A single keyword indicating what types of mutability A single keyword indicating what types of
modifications an attribute MAY accept as follows: modifications an attribute MAY accept as follows:
readOnly The attribute SHALL NOT be modified. readOnly The attribute SHALL NOT be modified.
readWrite The attribute MAY be updated and read at any time. readWrite The attribute MAY be updated and read at any time.
DEFAULT. DEFAULT.
immutable The attribute MAY be defined at resource creation immutable The attribute MAY be defined at resource creation
skipping to change at page 54, line 24 skipping to change at page 54, line 24
} }
]} ]}
13. Security Considerations 13. Security Considerations
The SCIM Core schema contains personally identifiable information as The SCIM Core schema contains personally identifiable information as
well as other sensitive data. Aside from prohibiting password values well as other sensitive data. Aside from prohibiting password values
in a SCIM response this specification does not provide any means or in a SCIM response this specification does not provide any means or
guarantee of confidentiality. guarantee of confidentiality.
14. References 14. IANA Considerations
14.1. Normative References 14.1. Registering New SCIM Schemas
This section defines the process for registering new SCIM schemas
with IANA. A schema URI is used as a value in the schemas attribute
(Section 5.2) for the purpose of distinguishing extensions used in a
SCIM resource.
14.1.1. Registration Procedure
The IETF has created a mailing list, scim@ietf.org, which can be used
for public discussion of SCIM schema proposals prior to registration.
Use of the mailing list is strongly encouraged. The IESG has
appointed a designated expert who will monitor the scim@ietf.org
mailing list and review registrations.
Registration of new schemas MUST be reviewed by the designated expert
and published in an RFC. A Standards Track RFC is REQUIRED for the
registration of new value data types that modify existing properties.
A Standards Track RFC is also REQUIRED for registration of SCIM
schema URIs that modify SCIM schema previously documented in a
Standards Track RFC.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to vcarddav@ietf.org
and iana@iana.org. Within two weeks, the designated expert is
expected to tell IANA and the submitter of the registration whether
the registration is approved, approved with minor changes, or
rejected with cause. When a registration is rejected with cause, it
can be re-submitted if the concerns listed in the cause are
addressed. Decisions made by the designated expert can be appealed
to the IESG Applications Area Director, then to the IESG. They
follow the normal appeals procedure for IESG decisions.
Once the registration procedure concludes successfully, IANA creates
or modifies the corresponding record in the SCIM schema registry.
The completed registration template is discarded.
An RFC specifying new schema URI MUST include the completed
registration templates, which MAY be expanded with additional
information. These completed templates are intended to go in the
body of the document, not in the IANA Considerations section. The
RFC SHOULD include any attributes defined.
14.1.2. Schema Registration Template
A SCIM schema URI is defined by completing the following template:
Schema URI: Schema URI: A unique URI for the SCIM schema extension.
Schema Name: A descriptive name of the schema extension (e.g.
Generic Device)
Intended or Associated Resource Type: A value defining the resource
type (e.g. "Device").
Purpose: A description of the purpose of the extension and/or its
intended use.
Single-value Attributes: A list and description of single-valued
attributes defined including complex attributes.
Multi-valued Attributes: A list and description of multi-valued
attributes defined including complex attributes.
14.2. Initial SCIM Schema Registry
The IANA has created and will maintain the following registries for
SCIM schema URIs with pointers to appropriate reference documents.
+---------------------------------------------+----------+----------+
| Schema URI | Name | Referenc |
| | | e |
+---------------------------------------------+----------+----------+
| urn:scim:schemas:core:2.0:User | User | See |
| | Resource | Section |
| | | 6 |
| urn:scim:schemas:extension:enterprise:2.0:E | Enterpri | See |
| nterpriseUser | se User | Section |
| | Extensio | 7 |
| | n | |
| urn:scim:schemas:core:2.0:Group | Group | See |
| | Resource | Section |
| | | 8 |
+---------------------------------------------+----------+----------+
SCIM Schema URIs for Data Resources
+-----------------------------------------+-------------+-----------+
| Schema URI | Name | Reference |
+-----------------------------------------+-------------+-----------+
| urn:scim:schemas:core:2.0:ServiceProvid | Service | See |
| erConfig | Provider Co | Section 9 |
| | nfiguration | |
| | Schema | |
| urn:scim:schemas:core:2.0:ResourceType | Resource | See |
| | Type Config | Section |
| | | 10 |
| urn:scim:schemas:core:2.0:Schema | Schema | See |
| | Definitions | Section |
| | Schema | 11 |
+-----------------------------------------+-------------+-----------+
SCIM Server Related Schema URIs
15. References
15.1. Normative References
[I-D.ietf-httpbis-p2-semantics] [I-D.ietf-httpbis-p2-semantics]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", draft-ietf- (HTTP/1.1): Semantics and Content", draft-ietf-
httpbis-p2-semantics-25 (work in progress), November 2013. httpbis-p2-semantics-25 (work in progress), November 2013.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, September 2006. BCP 47, RFC 4647, September 2006.
skipping to change at page 55, line 15 skipping to change at page 57, line 34
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
Time Zone Database", BCP 175, RFC 6557, February 2012. Time Zone Database", BCP 175, RFC 6557, February 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[XML-Schema] [XML-Schema]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", October 2004. Second Edition", October 2004.
14.2. Informative References 15.2. Informative References
[ISO3166] "ISO 3166:1988 (E/F) - Codes for the representation of [ISO3166] "ISO 3166:1988 (E/F) - Codes for the representation of
names of countries - The International Organization for names of countries - The International Organization for
Standardization, 3rd edition", 08 1988. Standardization, 3rd edition", 08 1988.
[ISO639-2] [ISO639-2]
ISO 639.2 Registration Authority, "ISO639-2: Codes for the ISO 639.2 Registration Authority, "ISO639-2: Codes for the
Representation of Names of Languages", July 2013. Representation of Names of Languages", July 2013.
[Olson-TZ] [Olson-TZ]
"Sources for Time Zone and Daylight Saving Time Data", . "Sources for Time Zone and Daylight Saving Time Data", .
[PortableContacts] [PortableContacts]
Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only", Smarr, J., "Portable Contacts 1.0 Draft C - Schema Only",
August 2008. August 2008.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June (LDAP): Directory Information Models", RFC 4512, June
2006. 2006.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The editors would like to acknowledge the contribution and work of The editors would like to acknowledge the contribution and work of
skipping to change at page 57, line 20 skipping to change at page 59, line 39
62 - Fix 'mutability' normative language 62 - Fix 'mutability' normative language
63 - Fix incorrect EnterpriseUser schema reference 63 - Fix incorrect EnterpriseUser schema reference
68 - Update JSON references from RFC4627 to RFC7159 68 - Update JSON references from RFC4627 to RFC7159
71 - Made corrections to language tags in compliance with BCP47 / 71 - Made corrections to language tags in compliance with BCP47 /
RFC5646 RFC5646
Draft 05 - PH - Revisions based on the following tickets
23 - Clarified that the server is not required to preserve case
for case insensitive strings
41 - Add IANA considerations
72 - Added text to indicate UTF-8 is default and mandatory
encoding format per BCP18
- Typo corrections and removed some redundant text
Authors' Addresses Authors' Addresses
Kelly Grizzle Kelly Grizzle
SailPoint SailPoint
Email: kelly.grizzle@sailpoint.com Email: kelly.grizzle@sailpoint.com
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
 End of changes. 19 change blocks. 
32 lines changed or deleted 160 lines changed or added

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