Subject: [scim] Stephen Farrell's No Objection on draft-ietf-scim-api-18: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 13 May 2015 09:03:21 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-scim-api-18: 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-api/

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

Feel free to ignore any of these that overlap with earlier
comments, I've not been following all discussion on this one.

- section 2 says that bearer tokens based on no authenticaton
may be used (as the exception to the "SHOULD NOT be used").
Why is that ok? Maybe s/SHOULD NOT/MUST NOT/ here would be
better and justified?

- 3.1: seems odd to define schema but then say it's entirely
fine to ignore all of that - or am I reading this wrong?

- p9, figures and tables should have captions and be numbered
and this looks like a table of HTTP methods (not
"operations") that has neither.

- general: I came across a bunch of places where some forward
reference would help (e.g. 3.3 assumes I get what readOnly
means; 3.4.2.1 does the same for a "json attribute"). An
editing pass to try improve that before the RFC editor would
be good I think.

- 3.4.2 says: "This SHALL NOT be equal to the number of
elements in the resources attribute of the list response if
pagination (Section 3.4.2.4) is requested. " What if I ask
for pagination with 10 per page and there are a total of 10
matching results? That SHALL NOT seems broken.

- 3.4.2.2: Is "pr()" true when a client didn't send a value
to the server at creation time but the server included the
default value in the response to the PUT? (And what happens
to pr() and eq() when the default value changes?)

- 3.4.2.2, p21: eq() is case insensitive?  I think you badly
need a fwd ref to sections 3.8 and 5.

- 7.4, para 2 looks truncated

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 May 2015 09:37:13 -0700

Stephen,

Thanks for your comments. Replies in line.

Phil

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

> On May 13, 2015, at 9:03 AM, Stephen Farrell <[email-masked]> wrote:
> 

I am always afraid of saying never in these cases as scenarios always change.  For example, as  denial-of-service protection mechanism, an authorization server might issue a single-use token that marks a session with an anonymous client.  That might then be used by the client to perform what would otherwise be an anonymous self-registration.

The problem hear is the common confusion of authentication of users as a separate thing from session authentication.

This example might not be correct or incorrect depending on how you define authentication.  Regardless, it just felt that limiting without reason was inappropriate.

That said, I am open to changing this wording to something better.
> "operations") that has neither.

I could convert this to a table. Right now it is merely a <LIST style=“hanging”>
> editing pass to try improve that before the RFC editor would

Sounds good.
> matching results? That SHALL NOT seems broken.

I’ve got this on my list from Ben’s review/discuss.
> to pr() and eq() when the default value changes?)

Not sure if we need an additional note. 

But I would assume defaulted values are applied and fixed when a server updates its stateful representation of the entity.  Thus a subsequent search would involve testing the attribute's state which may be actual or defaulted.

From an inter-operability perspective, I wonder if this matters.  If SCIM is in front of an application (e.g. CRM), then would it be ok for the data mapping to apply its own rules in the context of the application?

> need a fwd ref to sections 3.8 and 5.

Sure.
> - 7.4, para 2 looks truncated

Looks like para 2 needs to be snipped.
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim