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

[Phil Hunt <[e-mail]>]

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

[e-mail]

> On Apr 22, 2015, at 8:06 AM, Francis Dupont <[e-mail]> 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
> 
> [e-mail]