Re: [Gen-art] review of draft-ietf-scim-api-16.txt

Jari Arkko <jari.arkko@piuha.net> Wed, 13 May 2015 10:02 UTC

Return-Path: <jari.arkko@piuha.net>
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 1B1971B2A08 for <gen-art@ietfa.amsl.com>; Wed, 13 May 2015 03:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 yyMVlXRqbO4f for <gen-art@ietfa.amsl.com>; Wed, 13 May 2015 03:02:27 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA91B29F0 for <gen-art@ietf.org>; Wed, 13 May 2015 03:02:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 82A722CC61; Wed, 13 May 2015 13:02:26 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3pZ3JJILHrg; Wed, 13 May 2015 13:02:25 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 819DA2CC5A; Wed, 13 May 2015 13:02:24 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_3A74B94E-57CD-498E-AF39-EAED5C03C572"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <DB52A206-D749-421A-AAAA-E9E78183EF87@yahoo.com>
Date: Wed, 13 May 2015 12:02:22 +0200
Message-Id: <34C8F57D-B613-43A9-B87B-F54EE236932F@piuha.net>
References: <201504221506.t3MF67xd089983@givry.fdupont.fr> <DB52A206-D749-421A-AAAA-E9E78183EF87@yahoo.com>
To: Phil Hunt <phil.hunt@yahoo.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/AKZmzhwmq1r3ItuY2Apf2EbOkgA>
Cc: gen-art@ietf.org, draft-ietf-scim-api.all@tools.ietf.org
Subject: Re: [Gen-art] review of draft-ietf-scim-api-16.txt
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, 13 May 2015 10:02:30 -0000

Francis: thanks for the review. Phil: thanks for the update.

Jari

On 24 Apr 2015, at 22:57, Phil Hunt <phil.hunt@yahoo.com> wrote:

> Francis,
> 
> Thanks again for the detailed review. 
> 
> Comments inline. If no comments, the changes have been made to the draft posted moments ago.
> 
> I believe this should address all of your comments.
> 
> Best regards,
> 
> Phil
> 
> phil.hunt@yahoo.com
> 
>> On Apr 22, 2015, at 8:06 AM, Francis Dupont <Francis.Dupont@fdupont.fr> 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-api-16.txt
>> Reviewer: Francis Dupont
>> Review Date: 20150418
>> IETF LC End Date: 20150420
>> IESG Telechat date: unknown
>> 
>> Summary: Ready with nits
>> 
>> Major issues: None
>> 
>> Minor issues: None
>> 
>> Nits/editorial comments: many!
>> - Abstract page 1: a standardized services:
>> either 'a standardized service' or 'standardized services'
>> 
>> - Abstract page 1: add at least a comma in:
>>  a common user
>>  schema and extension model and a service protocol
>>                            ^ e.g., here
>> 
>> - ToC page 2:
>>  3.4.1.  Retrieving a known Resource
>>                       ^ Known
>> 
>> - about keywords: IMHO it is far better, less ambigous and BTW
>> compliant to avoid lower case keywords.
>> 
>> - 1.1 page 4: some examples of (not very ambigous) lower case "may"s.
>> 
>> - 3.2 page 6: ask the RFC Editor to check the page break is not
>> as badly placed as in my paper copy (PATCH alone at last line).
>> 
>> - 3.2 page 7 table 1 and a lot of other places: e.g. -> e.g.,
>> 
>> - 3.5.2 page 30: long uri cut issue (there is no perfect solution:
>> either cut it into two lines, or insert a line break. But you
>> should be consistent in this choice).
> Tried to make more consistent.  Note: I prioritized trying to maintain alignment with some “id” shortening using “…". When line is still too long, I fail back to putting the value on the beginning of the next line.
> 
> I’ve tried to achieve a balance here, but am open to making further changes to meet IETF “style” where needed.
>> 
>> - 3.5.2 page 31: misplaced comma?
>>   a patch operation that sets a value's
>>  "primary" attribute to "true", SHALL cause the server to
>>                               ^
>> 
> The section was a bit awkward. Rephrased.
> 
>> - 3.5.2 page 31: no closing parenthesis:
>>   resource (subject to
>>            ^
>> 
>> - 3.5.2.2 page 35: missing required SP:
>>   "path":"members[value eq\"2819c223...919d-413861904646\”]"
> 
> The example appears to be valid. There is no SP between members and [
>>                           ^
>> 
>> - 3.5.2.3 page 38: selction -> selection
>> 
>> - 3.6 page 42: from my long list a debatable lower case "should not":
>>  the previously deleted resource should not fail
>> 
>> - 3.9 page 60: why an upper case "OR" in:
>>  "attributes" OR
>>  “excludedAtributes"
> 
> Corrected multiple cases.
>> 
>> - 3.10 page 61: "A" in plurals?
>>  A Complex
>>  attributes' Sub-Attributes are referenced
>> 
>> - 5 page 70: bad wording:
>>  To increase the likelihood that the input and comparison of unicode
>>  usernames and passwords will work in ways that make sense for typical
>>  users throughout the world there are special string preparation and
>>  comparison methods (PRECIS) that MUST be followed for usernames and
>>  passwords.
> 
> The text comes directly from the introduction of SASLPREPBIS.
> 
>> - 7.2 page 73: spurious comma:
>>  As mentioned in ,Section
>>                  ^
>> 
>> - 7.4 page 74: i.e. -> i.e., (the only one I found :-)
>> 
>> - 9.2 page 78: strange ', .'s (missing parameter in a macro?)
>>  [OpenSearch]
>>             Clinton, D., "OpenSearch Protocol 1.1, Draft 5", .
>> 
>>  [Order-Operations]
>>             Wikipedia, "Order of Operations: Programming Languages", .
>> 
>> Regards
>> 
>> Francis.Dupont@fdupont.fr
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art