[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 27th February 2013
Meeting Minutes 27th February 2013
Attendees:
Rackspace Hosting, Inc. Roshan Agrawal Voting Member
Software AG, Inc. Bhaskar Reddy Byreddy Voting Member
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Cloudsoft Corporation Limited Duncan Johnston-Watt Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
JumpSoft Charles Tupitza Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Scribe: Adrian assumes scribe duties.
Roll Call: Attendees listed above, 14/16 87% = Quorate
Agenda: updated to add link to wd06 draft under editor's report. proposed.
No objections to accepting the agenda. Agenda adopted as posted above.
Minutes:
20th February 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201302/msg00105.html
Motion: m: Adrian Otto, s: Gil: moves to approve minutes 20th Feb 2013.
Approved by UC.
Minutes Adopted.
Action Items: None
Administrivia:
Jacques gives update on Fujitsu hosting next F2F.
RSVP by March 15 for in-person attendance.
Suggestion to use Kavi to track
Action-20130227-0 Martin to set up Kavi to track attendance at April F2F
Mark Carlson indicates Hyatt in Santa Clara has a special rate offered on the Cloud COnnect conference web site.
Jacques (Fujitsu): Convention center / Hyatt is about 5mn drive to Fujitsu
Duncan Johnston-Watt suggests we have DeployCon VIP tickets available.
Duncan Johnston-Watt (Cloudsoft): http://deploycon.com/
Duncan Johnston-Watt (Cloudsoft): We are sponsoring Deploycon so happy to offer VIP tickets on first come first served basis (can set aside 5-10)
MarkCarlson: @duncan - any chance to get Krishnan to "invite" a CAMP talk or panelist?
Duncan Johnston-Watt (Cloudsoft): @mark - let me follow up on this w/ Krish
Editing Team Update:
WD06: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201302/msg00129.html
Note that WD06 v1 has an orphan section 2.1.3. Adrian will post a revision to correct that error.
Discussion of producing our next CSD
Support for voting on the next CSD next meeting.Potential motion next week for CSD02
Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48314/CAMP%20sched.pdf
Discussion of our target timeline. Gil indicates we appear to be tracking to our goals.
New Issue:
https://tools.oasis-open.org/issues/browse/CAMP-55 Lifecycle Diagram is conflating two levels of states, leading to inconsistencies
Jacques Durand presents CAMP-55
MOTION: m:Jacques, s: Gilbert Plz moves to open camp-55
Discussion suggests this should be a P1
No Objections. Motion passed by UC and will be a P1 issue
https://tools.oasis-open.org/issues/browse/CAMP-56 Add Conformance Section
Presented by Adrian.
Martin: this has to be done as part of the TC process and should be a P1
MOTION: m: Adrian Otto, s: Jacques Durand moves to open CAMP-56 as a P1
No Objection. Motion carried by UC.
Issue Discussion
http://tools.oasis-open.org/issues/browse/CAMP-30 Parameter Scheme
Adrian introduces his proposal
Discussion on need for better explaination of the diff between a param and an attribute.
Adrian will bring a proposal back for next week.
http://tools.oasis-open.org/issues/browse/CAMP-34 Immutable and read-only attributes in the REST world
Gil presents proposal
Adrian: I asked if it makes sense to perhaps just ignore requests from clients that change immutable attributes.
Jacques added support for a use model that might be less restrictive, perhaps including an indication of what changes were not replied somehow in the response body.
Anish adds explanation that if a client changes an immutable attribute value that it really should be treated as an error condition.
Adrian: I now agree with the proposed text.
MartinC: the reason i mention patch is not just because of consitency, but would people expect a patch of a mutable-false attribute to generate http 403
Gil explains that it's not likely that someone will change a mutable attribute unless they actually wanted to. They perform a Get, change the attribute they want to, and then perform
a PUT.
anish: martinC, i think so. i'm checking if the spec says anything
Discussion indicates that the proposal should apply the restriction on mutable attributes equally for both PUT and PATCH operations.
Review this text:
Consumers MUST NOT send a request that changes the value of a resource attribute that is declared with a constraint of 'Mutable=false' or 'Consumer-mutable=false'. On
receiving such a request the Provider MUST generate an HTTP response with 403 HTTP status code.
HTTP PUT requests are requests for complete replacement of the resource identified by the request URL. If a resource attribute is present on a resource and if an HTTP PUT
request omits that attribute, it should be treated by the provider as a request to delete the attribute.
anish: +1 to adrian's proposal about making it apply to all http verbs
Gil indicates that the above text is consistent for any HTTP verb acting on a resource.
Adrian: I have no remaining objections. The text is ok with me.
anish: "Consumers MUST NOT send a request that changes the value of a resource attribute that is
declared with a constraint of 'Mutable=false' or 'Consumer-mutable=false'. On receiving such a request
the Provider MUST generate an HTTP response with 403 HTTP status code." -- doesn't that apply to all verbs?
yes, it does. Thanks.
Tom indicates that REST API
Discussion of: If a resource attribute is present on a resource and if an HTTP PUT request omits that attribute, it should be treated by the provider as a request to delete the attribute.
Jacques (Fujitsu): Well, Fujitsu vote here is split, so that averages to an abstain
anish: section 6.8: s/should/MUST/
MOTION: m: Gil, s: Adrian moves to resolve CAMP-34 using the proposal, with the modification of "section 6.8: s/should/MUST/"
Gil: https://www.oasis-open.org/committees/document.php?document_id=48375&wg_abbrev=camp
No discussion, No objections. CAMP-34 resolved by UC.
http://tools.oasis-open.org/issues/browse/CAMP-52 Use of Cardinality for JSON array attributes
Tom Rutt presents the proposal.
Gil: we trust our editors in this group
anish: 5.2.1 Required
If the Required boolean constraint for an attribute of a resource type has a value of "true", then an instance of that resource type MUST have the attribute present. If the value
is "false" then the instance is valid with or without the attribute present.
Adrian Otto asked if Cardinality 0..* was used anywhere, and did we need a new way to express that. Tom Answered that no, the only instances of that were errors.
Gil confirmed they were his errors.
anish: link to that last comment: https://tools.oasis-open.org/issues/browse/CAMP-52?focusedCommentId=32614&page=com.atlassian.jira.plugin.system.issuetabpanels
%3Acomment-tabpanel#action_32614
MOTION: m: Tom Rutt, s: Anish: moves to resolve CAMP-52 with the referenced proposal (last proposal comment in jira.)
No Discussion. No Objections. Motion carries by UC. CAMP-52 resolved.
http://tools.oasis-open.org/issues/browse/CAMP-50 spec needs to clarify behavior in the case of duplicate JSON keys
Discussion of CAMP-50.
Adrian: I will produce a revision of the proposal for consideration at our next meeting.
AOB:
Stragglers: Anish, Ashok, Krishna
Meeting Adjourned.
--------------
Summary of new and outstanding action items:
Action-20130227-0 Martin to set up Kavi to track attendance at April F2F
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]