Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17

"Morteza Ansari (moransar)" <> Wed, 06 May 2015 16:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 880B81B2CBF for <>; Wed, 6 May 2015 09:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QSZsdd-paOca for <>; Wed, 6 May 2015 09:55:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 601241B2CB7 for <>; Wed, 6 May 2015 09:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11435; q=dns/txt; s=iport; t=1430931316; x=1432140916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VBpiYAMgrx832XNuhX7qg4W9HwWV2xIz1dLGTgANz74=; b=i3J6l5TpSYCzLVs5O7W74X3fw0u8mFNyn9s0g00O3JZsNRcKQOHq33+S bT5uBfdfqudh7u7I+6ydrIPbTLzkZvEistqtI9w93hf2qAiiBHF7odQQJ sRDVS7NZeFrqqq5WtEFbhORaTvULjl5vNC9FXFmxpNz5+9dnT0DkkHYXT s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,380,1427760000"; d="scan'208";a="147649306"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 May 2015 16:55:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t46GtDjm032455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 May 2015 16:55:13 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 6 May 2015 11:55:12 -0500
From: "Morteza Ansari (moransar)" <>
To: Phil Hunt <>, Elwyn Davies <>
Thread-Topic: Gen-art last call review of draft-ietf-scim-core-schema-17
Date: Wed, 06 May 2015 16:55:12 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Wed, 06 May 2015 10:17:03 -0700
Cc: Leif Johansson <>, General area reviewing team <>, "" <>
Subject: Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 May 2015 16:55:18 -0000

I believe the telechat review is scheduled for 14th. I think we should try
and publish an updated version of both docs with all the known/agreed upon
issues addressed by end of the week. Hopefully that would help the review
and make it clear what exactly is the state of the doc.


On 5/6/15, 9:42 AM, "Phil Hunt" <> wrote:

>Thanks Elwyn for your thorough review. Much appreciated.
>Yes I agree with your comment re internationalization. I would think a
>best practice would be very helpful to move the industry.  I guess as a
>provisioning spec we are stuck having to deal with ossification since we
>have to map legacy anglo structures.
>I plan to update very soon pending ok from Kathleen and the group on some
>other issues. 
>> On May 6, 2015, at 09:18, Elwyn Davies <> wrote:
>> Hi, Phil.
>> Thanks for the response and the updated draft.
>> I'll bite my tongue and defer to past history and the WG consensus on
>>the internationalization issues.  IMO this area is something that needs
>>to be considered for other (new) specifications so that we don't remain
>>ossified and adhering to a US/UK English paradigm that doesn't really
>>fit other locales.  But, as I said, this draft goes ahead as is on that
>> There are some remaining minor comments on the updated draft inline
>>below.  If you don't get around to generating a new draft before the
>>telechat, I'll send these as my telechat review.
>> Regards,
>> Elwyn
>>> On 20/04/2015 19:30, Phil Hunt wrote:
>>> Elwyn,
>>> Thanks for your careful and thorough review.  I have included my
>>>comments below.
>>> Note, if I have not commented below, please assume I agree with your
>>>comment and will update the draft to include your feedback.
>>> Discussion inline below...
>>> Phil
>>>> On Apr 17, 2015, at 2:26 PM, Elwyn Davies <>
>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>> Gen-ART, please see the FAQ at
>>>> <>.
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive.
>>>> Document: draft-ietf-scim-core-schema-17.txt
>>>> Reviewer: Elwyn Davies
>>>> Review Date: 2015/04/09
>>>> IETF LC End Date: 2015/04/20
>>>> IESG Telechat date: (if known) -
>>>> Summary: Not ready.  The 'major' issue identified is really political
>>>>rather than strictly technical although the proposed syntax does limit
>>>>the applicability (or at least the easy applicability) of the scheme.
>>>>Making the schemas more aware of practice outside the basic English
>>>>speaking world should be an aim of IETF work, IMO.  The minor issues
>>>>are mostly  only just more than editorial nits - and there are quite a
>>>>few of these also.
>>>> Major issues:
>>>> ===========
>>>> s4.1.1, "name" attribute:  The definition of this attribute is
>>>>culturally insensitive.  The
>>>> collection of name sub-attribute terms are North
>>>>American/UK/Aussie/NZ English -speaking biased.  The authors might
>>>>wish to consider
>>> [PH] I am not sure I agree with your conclusion. SCIM is a
>>>provisioning protocol and not a rendering protocol. SCIM is concerned
>>>with conveying information between systems based on commonly used
>>>fields. Further for formatted name, there is no restriction on how the
>>>name may be structured. Essentially SCIM already follows the above
>>>reference. Note that we don¹t use a regional identifier in name, but
>>>rather have it as a separate attribute ³locale². This enables a UI to
>>>render the name in the appropriate regional method.
>>> The WG did have several international participants and no issues were
>>> I believe that what is being reflected is that while database
>>>structures and schemas tend to be ³western² oriented, there are well
>>>trodden industry practices to map those fields to render user facing
>>>material in the proper localized forms.
>>> In deference to your concern over the weekend, I re-raised the issue
>>>with Oracle developers and have been informed that there has been an
>>>internationalization review and the specification does not present any
>>>problems for us as international implementers.
>>>> To a lesser extent this also applies to the definition of the
>>>>addresses attribute in s4.1.2.  The issue of the representation of
>>>>postal addresses incorporated in I-Ds and RFCs in the xml2rfc schema
>>>>has been debated at length on the rfc-interest mailing list.  The new
>>>>(v3) vocabulary replaces the specific sub-attributes with an ordered
>>>>list of "postalLine" elements (see
>>>>Further, the use of country codes in RFCs has been dropped some time
>>>>ago.  It might be better to represent the address in a less specific
>>>>way and leave display up to user interfaces that can consider the
>>>>relevant locale.  My suggestion, FWIW, would be to have a country,
>>>>possibly a code field plus an ordered array of postalLines that can
>>>>contain any of the additional components and cater for any locale
>>>>specific format.
>>> [PH] The suggested workaround of following the format for XML2RFC
>>>using an array of ³postalLine² values causes more problems in the
>>>current SCIM model:
>>> 1.  SCIM does not support array references (e.g. postalLine/1,
>>>postalLine/2). In some cases, the order of elements may not be
>>>guaranteed by some impelementers (e.g. those building on top of LDAP)
>>> 2.  SCIM¹s objective is to provision. So the meaning associated with
>>>the field must be well known to map it to the receivers data system. A
>>>system line postalLine1, postalLine2 would require attribute parsing
>>>which is substantially more complex and unreliable given the wide
>>> 3.  In practice, international data is collected through a
>>>user-interface which then categorizes the input and maps them to the
>>>appropriate attributes.  If we introduce agnostic attribute naming in
>>>the protocol (postalAddress1, 2 etc) we actually lose knowledge of what
>>>the intended content is.  This means that it becomes impractical to say
>>>does postalAddress2 map to city, county, district, or mail stop of a
>>>target system.
>>> IOW. In the XML2RFC, we depend on human editors to validate and align
>>>the data. As a protocol we do not have this luxury.
>> As per my comment at the top, I withdraw these comments and defer to
>>the WG consensus.
>>>> ======================================================
>>>> Minor issues:
>>>> ===========
>>>> Reference to SCIM Protocol document:  At a bare minimum a normative
>>>>reference to the SCIM protocol document (currently
>>>>draft-ietf-scim-api-16) is needed in s1.2 where the protocol is
>>>>referred to in the first two definitions.  In my opinion, this
>>>>document would be improved by the addition of a brief overview of the
>>>>operation of the SCIM protocol and the implications for the design of
>>>>the schema.   For example, s2 talks about 'replacement of a resource':
>>>> Knowing in advance that one of the operations anticipated in the
>>>>protocol is replacement makes this clearer.
>> My feeling is still that a brief overview of the SCIM protocol would
>>help. Maybe something like inserted
>> befoee the last para of s1:
>>   The SCIM Protocol is an application-level protocol for provisioning
>>and managing identity data
>>   specified through the SCIM schemas.  The protocol supports creation,
>>modification, retrieval,
>>   and discovery of core identity resources such as Users and Groups,
>>using a subset of the HTML
>>   methods (GET for retrieval of resources, POST for creation, searching
>>and bulk modification, PUT for
>>   attribute replacement within resources, PATCH for partial update of
>>attributes, and DELETE for
>>   removing resources).
>>> No objection. There has been a practical problem that XML2RFC won¹t
>>>let you reference a draft version that does not exist. In practice
>>>we¹ve had to publish API 2 days after core-schema in order to allow the
>>>validation to succeed.  I will amend the document and leave notes for
>>>the RFC editor to co-publish the specs since they reference each other.
>> That will happen automatically - the documents form a RFC editor 'queue
>>cluster' because of the references.  This shouldn't be a big deal since
>>they are going through IESG at the same time.
>>>> s1.1, Use of OPTIONAL and REQUIRED:  These terms are overloaded in
>>>>this document.  The majority of uses are not specifying features of
>>>>the protocol as per RFC 2119 but indicating the necessity or otherwise
>>>>of the presence of particular attributes in resource types.  AFAICS
>>>>the only RFC 2119 usages are one place in  s2.2.7 for OPTIONAL  and
>>>>two adjacent places in s10.3.1 for REQUIRED .   To avoid the
>>>>overloading it would be easy to omit OPTIONAL and REQUIRED from the
>>>>RFC 2119 list, use the alternative RFC 2119 terminology (MAY in s2.2.7
>>>>and MUST in s10.3.1) and provide a separate note on the usage of
>>>>OPTIONAL and REQUIRED in s1.1.
>>> [PH] In the context of a schema document, the use of OPTIONAL and
>>>REQUIRED is equivalent to protocol normative language and was intended.
>>> Never-the-less, if you feel strongly, I can re-word to avoid RFC2119
>>>language entirely.
>> This is a difficult one.  When used as qualifiers for attributes they
>>have implications for both implementers and end users.
>> REQUIRED is not a big deal:  Implementers MUST implement it and users
>>MUST use it, so 2119 language is no problem.
>> OPTIONAL is a bit more difficult. Does an implementer have to implement
>>the OPTIONAL attribute?  If the OPTIONAL attribute is implemented in a
>>particular implementation, MUST the end user supply a value? And vice
>>>> s2.1, Syntax of attribute names:  I am confused by the constraints
>>>>suggested here.
>>>> (1)   "Attribute names SHOULD be camel-cased":  AFAICS this has no
>>>>impact on the specification or protocol.  My guess is that the
>>>>specification has adopted the convention normally used in JavaScript.
>>>>This is merely a representation of the convention used in SCIM schemas
>>>>and RFC 2119 language is inappropriate.  I suggest replacing this with
>>>> "This document uses the camel-casing convention for attribute names
>>>>(e.g., "camelCase").
>>>> (2) "nameChar   = "-" / "_" / DIGIT / ALPHA": Given the close
>>>>association with JavaScript, it seems inappropriate to allow hyphen
>>>>(-) as a character in attribute names as this is illegal in JavaScript.
>>>> (3) The definition should say whether attribute names are case