Last Call Review of draft-ietf-scim-core-schema-17

Request Review of draft-ietf-scim-core-schema
Requested rev. no specific revision (document currently at 22)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-05-12
Requested 2015-04-09
Authors Phil Hunt, Kelly Grizzle, Erik Wahlstroem, Chuck Mortimore
Draft last updated 2015-05-11
Completed reviews Genart Last Call review of -17 by Elwyn Davies (diff)
Genart Telechat review of -19 by Elwyn Davies (diff)
Secdir Last Call review of -17 by Brian Weis (diff)
Opsdir Last Call review of -17 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-scim-core-schema-17-opsdir-lc-wu-2015-05-11
Reviewed rev. 17 (document currently at 22)
Review result Has Nits
Review completed: 2015-05-11



I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational
 aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.


I think this draft is ready for publication. Here are a few editorial comments:



Section 1.1 “Requirements Notation and Conventions”


I am wondering how RFC2119 languages are applied to this document,

In Section 4.1.1, “RECOMMENDED” is applied to the attribute “userName” by adding

“RECOMMENDED” at the end of attribute “userName” description.

In section 7, “DEFAULT”is applied to subattibute “readwrite” by adding “DEFAULT”

at the end of “readwrite” sub-attribute description. “DEFAULT” seems not RFC2119 language.

Therefore RFC2119 language used to apply to some attribute seems not consistent with other

language(e.g., DEFAULT) applied to some other attributes. Or the language used at the end of

each attribute is not totally RFC2119 language.


Please distinct where RFC2119 language is used from where other language(e.g.,”DEFAULT” ) is

used in the draft.




Section 2.2 said:


2.2.  Attribute Data Types


   Attribute data types are derived from JSON [RFC7159] and unless

   otherwise specified have the following characteristics (see Section

   7 for attribute characteristic definitions):



Who has the following characteristics, attribute data types or attributes?

If it is the former,I am not sure all the attribute data types listed here have

the following characteristics(e.g., mutability, and returnability, uniqueness),

For example. Boolean and Integer, Decimal are not of type string.

Attribute data type “Reference” is not case insensitive.

Can you give an example to explain the attribute data types are modifiable?

Or attributes corresponding to attribute data type listed here are modifiable?

How to understand attribute data type are returned in response to queries?

Are you saying attribute corresponding to attribute data types listed here are

usually returned in response to queries?




Section 3.1 said:


For backwards compatibility reasons, some existing schema MAY list

common attributes as part of the schema.  The attribute

characteristics listed here SHALL take precedence.


Where the attribute characteristics are listed here? Section 7?

It looks what is listed here are a list of common attributes? What am I missing?

Also please clarify how to understand “take precedence of these attribute characteristics ”?




Section 3.2 said


In order to offer new types of resources, a

service provider defines the new resource type as specified in

Section 6and defines a schema representation (see Section 8.7).


Miss a blank space between “section 6” and “and” in this sentence.




Section 6 said:


   The following Singular Attributes are defined:



      The resource type's server unique id.  Often this is the same

      value as the "name" attribute.  OPTIONAL



      The resource type name.  When applicable service providers MUST

      specify the name specified in the core schema specification; e.g.,

      "User" or "Group".  This name is referenced by the

      "meta.resourceType" attribute in all resources.


It looks not all the attributes are suffixed with “RECOMMEND”,”REQUIRED”,”OPTIONAL”,”DEFAULT”.

So what is the default characteristics pertaining to the attribute if it is not suffixed with “RECOMMEND”,


If there is no default characteristics associated with the attribute,  For consistency, I think each attribute

should add a suffix like “DEFAULT”,”RECOMMENDED”,”REQUIRED”.




Section 7 said:


"Schema" resources have mutability of "readOnly"

   and are identified using the following schema URI:


Is SCIM Resources 





If they are the same thing, please use consistent terminology.




Section 7 also said:



      The unique URI of the schema.  When applicable service providers

      MUST specify the URI specified in the core schema specification;

      e.g., "urn:ietf:params:scim:schemas:core:2.0:User".  Unlike most

      other schemas, which use some sort of a GUID for the "id", the

      schema "id" is a URI so that it can be registered and is portable

      between different service providers and clients.


Does attribute “id” has the attribute characteristics described in section 2.2? i.e.,


   o  are OPTIONAL (is not required).


   o  are case insensitive ("caseExact" is "false"),


   o  are modifiable ("mutability" is "readWrite"),


   o  are returned in response to queries (returned by default),


   o  have no canonical values (e.g. type is "home" or "work"),


   o  are not unique ("uniqueness" is "none"), and,


   o  of type string (Section 2.2.1).




Section 8.6 said:



   The following is a non-normative example of the SCIM resource types

   in JSON format.


Section 7 said, A SCIM resource type can be “user” or “group”. I am wondering how represented

using JSON format in the example of section 8.6?

Using schema attribute


"schema": "urn:ietf:params:scim:schemas:core:2.0:User"


Or using combination of several attribute, e.g., “id”,”name”,etc.