Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17
"Morteza Ansari (moransar)" <moransar@cisco.com> Wed, 06 May 2015 16:55 UTC
Return-Path: <moransar@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880B81B2CBF for <gen-art@ietfa.amsl.com>; Wed, 6 May 2015 09:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSZsdd-paOca for <gen-art@ietfa.amsl.com>; Wed, 6 May 2015 09:55:15 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601241B2CB7 for <gen-art@ietf.org>; Wed, 6 May 2015 09:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0C/BAC5RkpV/4cNJK1TCYMMU1wFtwuNbmYJgVaGBQKBJjgUAQEBAQEBAYEKhCEBAQRuCxACAQgUBC4yExICBAENBRUKh3gDEg20eJBGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4o3gQKCTYFcBAYBAR0zB4QtBYU8CoVeNYZMhBSCRoIvgU+BJD2DGYgRgW5WgxaDUyOBZSIcgVJvAYECAQcXBhyBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,380,1427760000"; d="scan'208";a="147649306"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 May 2015 16:55:15 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-2.cisco.com (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 xmb-rcd-x08.cisco.com ([169.254.8.175]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 6 May 2015 11:55:12 -0500
From: "Morteza Ansari (moransar)" <moransar@cisco.com>
To: Phil Hunt <phil.hunt@yahoo.com>, Elwyn Davies <elwynd@dial.pipex.com>
Thread-Topic: Gen-art last call review of draft-ietf-scim-core-schema-17
Thread-Index: AQHQeVVZz3zQSJTNDUKR35k19EfzWp1WkUMAgBkAeACAAAaTAP//jlSA
Date: Wed, 06 May 2015 16:55:12 +0000
Message-ID: <D16F944E.12428B%moransar@cisco.com>
References: <55317A7E.7050707@dial.pipex.com> <60A4B3BE-C5E6-44E2-A515-2D2DA5EE9E53@yahoo.com> <554A3ED6.1090106@dial.pipex.com> <1AFD0D41-54FC-4ADA-BA3C-72A2EE70F2A4@yahoo.com>
In-Reply-To: <1AFD0D41-54FC-4ADA-BA3C-72A2EE70F2A4@yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [10.155.84.129]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6A789BFAC9A5F24EA235169F52E132EC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/3djS0iGkN_13nNdeyQIlx7XLfxk>
X-Mailman-Approved-At: Wed, 06 May 2015 10:17:03 -0700
Cc: Leif Johansson <leifj@mnt.se>, General area reviewing team <gen-art@ietf.org>, "draft-ietf-scim-core-schema.all@tools.ietf.org" <draft-ietf-scim-core-schema.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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. Cheers, Morteza On 5/6/15, 9:42 AM, "Phil Hunt" <phil.hunt@yahoo.com> 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. > >Thanks! > >Phil > >> On May 6, 2015, at 09:18, Elwyn Davies <elwynd@dial.pipex.com> 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 >>front. >> >> 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 >>> >>> phil.hunt@yahoo.com >>> >>>> On Apr 17, 2015, at 2:26 PM, Elwyn Davies <elwynd@dial.pipex.com> >>>>wrote: >>>> >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> 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 >>>>http://www.w3.org/International/questions/qa-personal-names. >>> [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 >>>raised. >>> >>> 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 >>>>https://tools.ietf.org/html/draft-hoffman-xml2rfc-16#section-2.39). >>>>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 >>>variance. >>> 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 >>versa. >>>> 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 >>>>sensitive
- [Gen-art] Gen-art last call review of draft-ietf-… Elwyn Davies
- Re: [Gen-art] Gen-art last call review of draft-i… Leif Johansson
- Re: [Gen-art] Gen-art last call review of draft-i… Phil Hunt
- Re: [Gen-art] Gen-art last call review of draft-i… Leif Johansson
- Re: [Gen-art] Gen-art last call review of draft-i… Kelly Grizzle
- Re: [Gen-art] Gen-art last call review of draft-i… Erik Wahlström neXus
- Re: [Gen-art] Gen-art last call review of draft-i… Elwyn Davies
- Re: [Gen-art] Gen-art last call review of draft-i… Phil Hunt
- Re: [Gen-art] Gen-art last call review of draft-i… Morteza Ansari (moransar)
- Re: [Gen-art] Gen-art last call review of draft-i… Elwyn Davies
- Re: [Gen-art] Gen-art last call review of draft-i… Phil Hunt
- Re: [Gen-art] Gen-art last call review of draft-i… Elwyn Davies
- Re: [Gen-art] Gen-art last call review of draft-i… Phil Hunt