Re: [scim] Proposal to create a design team

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I don't understand.  How would such drafts relate to the existing
> wg drafts?

Ok bad choice of words.

What I meant to say was that the output of a design team doesn't
automatically get adopted by a WG.

_If_ they choose to write an I-D (say an I-D summarizing some
proposed changes) as input to the WG then that I-D doesn't
automatically get adopted.

I'm sorry if that was confusing.


> 
>> 
>> The purpose of this exercise is to get a focused technical
>> discussion started, not to end or preempt one.
>> 
>>> 
>>> Could somebody just catch us up and start a new thread with a
>>> brief
> summary of what exact non-trivial work has been identified as
> necessary prior to a 2.0 release?
>> 
>> There is some good starting points in the presentations that Phil
>> and Kelly made in Vancouver.
> 
> Again (and again), could you kindly be more specific?  I looked at
> those presentations and the minutes and saw nothing in Kelly's
> presentation that seemed like a question.  Phil has identified
> issues, but they seem incremental.  I don't see Phil's presentation
> posted, and what I see from the minutes is this:

Fair points but they should be answered by Kelly and Phil and others
who raised issues at the mic in Vancouver.

> 
>> . should directories evolve to support scim? Also, directory
>> vendors getting requests for rest interfaces.  Will scim be the
>> next *directory* interface?
>> 
>> . things impacting path uris: tenancy, targeting, "users" is too 
>> general, object types ay expand, ability to query for any object 
>> under /
>> 
>> . the current search is under 'get' only - security concerns.
>> ability to query using post?
>> 
>> . rest "minimum" profile
>> 
>> . add and replace - why not combine in put?  minor difference is 
>> resource identifier
>> 
>> . why not rework post to accommodate query and bulk?  What's
>> classic REST?
> 
> And then a few items from others:
>> Jon Bradley: PUT and POST are not the same.  we should probably
>> try to fix the semantics rather than bend them.  keep the rest
>> semantics clear.
>> 
>> Kent Watson: idempotence.
>> 
>> Tony Nadalin:  agree on resource type.  shouldn't be in the uri. 
>> Looking at spec, don't see how to do multitenancy correctly with
>> the urn path that's in there.  Okay place to start but shouldn't
>> rush to put out 1.1 lest people adhere to that
> 

This issue is an example of something that actually _may_ require a bit
of redesign.

> 
> And then the biggie raised by multiple people, but most notably
> Hannes and Paul:
>> axe xml[...]

as is this...

This list is a pretty good summary of what has been raised so far.

> 
> So... are these issues the scope for the design team?  And it would
> seem to me that their output should be a bunch of proposals to
> change the existing drafts, right?

I hope so.

	Cheers Leif

	

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCD1QgACgkQ8Jx8FtbMZnf0mQCfbGGB7VjEZtzCGTeCYtDuvtsB
sCIAoI/l8mdjyo402Ij2XJG0aHLtIJnr
=MDM2
-----END PGP SIGNATURE-----