Use Cases draft: K. Lee (name approximate)
-new drafts up.  Definitely need reviewers.  "Non author reviewers specifically".  Mike Jones and Bill Mills raised hands.
-no significant discussion in the room.

VCard mapping:  Bert G.
-Draft seems to be stabilizing.  Updated to match latest related rafts.
-new mandatory foelds for this.
-new plurals syntax needed.
-he's generally following the slides here.
-Significant question for SCIM itself, is the character set restricted to numbers?

-Morteza asking explicity for additional reviewers, silence in the room.
-suggestion that the VCard mailing list (WG not active any more) might get some interest.

"Now we'll spend the rest of the meeting on open issues...."

Phil Hunt at the mike:
-A review of recent history.  Following the slides he has.
-discussion of 307 & 308 HTTP response codes.
-SCIM Patch
-Why not JSON patch?  Discussion

-because SCIM is not array indexed.
-Possible concurrency or object sync issues.
-Proposal:  use 6902 but a subset (perhaps subset of 6901)
-JSON Merge Patch is interesting
-but it doesn't have an add capability...
-this is interesting though.
-Still problems with complex attriutes
... running through his slide/examples pretty much verbatim
-Question from Justin Richer:  on atomicity...
-clarified by Phil and Morteza
-Nat Samimura: This is an important architectural change
-Phil: we do this now though, so it's not quite as different as you think.
-Phil:  our own developers have been confused as well.
-Justin Richer: Are these verbs only in PATCH?  Yes.  Agrees with Nat that this is NOT RESTful.
-Phil: hasn't seen consistency regarding patch.

(more general conversation and I don't type fast enough)

-Julian feels this *is* RESTful.

(more general conversation and I don't type fast enough)

-Generally not a lot of love in the room for JSON merge/patch

Running through the issues list now in the IETF issue tracker.  Phil asking for specific support of issues in the list.  It's a long wish list and we need to know if there is real support for the things that are enhancements.

Many of these may carry over from the SCIM 1 days on the Google tracker.

Room Hum: generally a YES on taking all extensions and closing them WONTFIX with the invitation to folks that feel strongly to propose a new draft to extend/define them.

Tentative consensus for closing #6.

On #30
-Morteza thinks the IANA registry considerations must be addressed.
-retarget it at the Schema doc
-HUM:  should a registry be a separate draft with just stub language in the draft?  Apathy in the room.... we'll take it to the list.

On #43:
-Erik prefers this to simplify things.
-from the chair, if we do #43 then #36 is easy/done
-HUM says yes.

On #36:
-based on the above will close.

On #45:
-several comments that this probably needs to go.
-a partial mapping might work, but not a full mapping...
-Morteza: if there's no action on this in 4 months he will ask to drop it from the charter.

On #37:
-

Barry at the mic:

-Think about the JOSE WG output and perhaps review it.  You're JSON based so it might me useful.
-Take a look at Mark Nottingham's "Get off my lawn" doc.  This draft is reserving root URLs which is probably a bad practice.
-Morteza+chair: this wasn't intended to be absolute URLs.  This confusion is improtant, so we shoudl correct the language to make this clearer.

Julian R.:  The header field in 4.1.3 implies IANA considerations.  It also kills the RESTfulness,

(more conversation and I don't type fast enough)


On #65: Phil "Do we need overrides?"
-Julian: several reasons we might need this.
-If tis is the first IETF draft that uses the override header we really need to make sure we're right.
-Erik W.: on Jabber "I think the fact that it's used by existing APIs show that X-HTTP-Method-Override is needed in some cases."
-We'll take this to the list.