Subject: [scim] Benoit Claise's No Objection on draft-ietf-scim-core-schema-20: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 14 May 2015 01:47:50 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-scim-core-schema-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Here is Qin's OPS DIR review:

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

1.       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.

2.       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?

3.       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 ”?

4.       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.

5.       Section 6 said:

“

   The following Singular Attributes are defined:

   id

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

      value as the "name" attribute.  OPTIONAL

   name

      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”,

”REQUIRED”,”OPTIONAL”,”DEFAULT”?

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

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

6.       Section 7 said:

“

"Schema" resources have mutability of "readOnly"

   and are identified using the following schema URI:

”

Is SCIM Resources “shema”resource?

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

7.       Section 7 also said:

“

   id

      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).

”

8.       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.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 18 May 2015 14:43:48 -0700

Comments inline.

Phil

@independentid
www.independentid.com
[email-masked]

> On May 14, 2015, at 1:47 AM, Benoit Claise <[email-masked]> wrote:
> 

Since we make heavy use of OPTIONAL and REQUIRED, I have added these keywords to the requirements notations and conventions section.
> usually returned in response to queries?

I’m not sure you were commenting on draft 20. Attribute characteristics were broken out from data types to make it clear that characteristics refer to attribute qualities (e.g., mutability, returnability, etc) and are distinct from data types.

> Also please clarify how to understand “take precedence of these attribute

New text:
   For backwards compatibility reasons, some existing schema definitions MAY list
   common attributes as part of the schema.  The attribute
   characteristics (see Section 2.2) listed here SHALL take precedence
   over older definitiions that may be included in existing schemas.

What we are saying is that having common attributes in actual schemas are not needed because they can’t change and are present in every object.  However for backwards compatibility reasons, it is acceptable to still include them.

In other words we don’t want a User schema to define an attribute differently than Group does.

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

I’m not sure of the disconnect here. I have added some text that *might* help.
> Does attribute “id” has the attribute characteristics described in

I have made some clarifications that set defaults and added REQUIRED and OPTIONAL where missing.

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

I think you are referring to Section 6. It mentions that name can be for example “User”, “Group”.  Nothing here precludes other names.

A resource type is most often referred by “name”.  “id” was added for consistency reasons and is usually the same value as “name” as stated.

> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 May 2015 14:23:53 +0200

Thank you Phil.
We should be good now.

Regards, Benoit
> .