chat log from 4/5 morning session

["Mr. Tom Rutt" <trutt@us.fujitsu.com>]

Scribe (Tom): Scribe- Tom Rutt

Scribe (Tom): Topic: New Issues

Scribe (Tom): Issue 58 - Justification for the common "created attribute is unclear

Scribe (Tom): Anish: why is created date more important than last modified date?

Scribe (Tom): Adrian: It created more problems to have it than to remove it as common attribute.  Actually Last Modified is more important in many cases.

Scribe (Tom): Jacques:  a facility for logging would cover the case for created date.  There is no use case for having a created date attribuge.

Scribe (Tom): Adrian moves to open Issue 58, Anish seconded.

Scribe (Tom): Panagiotis:  I think that last modified is more important.

Scribe (Tom): Adrian moves to ammend that this issue should be opened as P3 Issue.  Anish seconded ammendment.  No objection to ammendment.

Gil: Last-Modified is an HTTP header - not clear we need to put redundant info in our model

Scribe (Tom): No objections to ammended motion.  Issue 58 opened as P3 issue.

Scribe (Tom): Adrian: content negotiation in HTTP, is enabled by a last modified header in HTTP.  We could require the last modified header as a way to resolve this issue.

Scribe (Tom): Anish: we should be careful to overspecify the use of http in this spec.

Scribe (Tom): Adrian: since most REST protocols are underspecified, we should consider adding more guidance.

Scribe (Tom): Issue 59:  Inconsistent definition of link attributes to point at templates used to instantiate resource types.

Scribe (Tom): Anish:  There are differences, assembly always has a template, but components do not always need to have a template.

Scribe (Tom): Anish moves to open Issue 58 with priority P3, and assign to Tom, seconded by Tom

Scribe (Tom): Anish: The instantiated from template attribute could be optional for components, but it is always there for Assembly.

Scribe (Tom): No objection to open Issue 59 as P3.

Scribe (Tom): Issue 60: ApplicationComponentCapability is not linked by any resource type.

Ashok Malhotra (Oracle): Why not pointed to from Application Component?

Scribe (Tom): Anish: perhaps we could just remove this resource.

Scribe (Tom): Tom moved to open Issue 60 as P2, Adrian Seconded.

Scribe (Tom): No objection, Issue 60 opened as P2, with Gil as owner.

Scribe (Tom): Camp 61: Camp is vague about which HTTP methods each resource supports.

Scribe (Tom): Gil moves to open Issue 61 as P2 with Gil as owner, Adrian seconded.

Scribe (Tom): Adrian: we could ship without this, but it would be better to include this in the spec.  That is why P2 is appropriate.

Scribe (Tom): Anish: we could have a section with a small table.

Scribe (Tom): No objection, Issue 61 opened as P2, with Gil as owner.

Scribe (Tom): Gil: we should clearly deliniate what http methods a resource must support, but have no additional method support restrictions for resources.

Scribe (Tom): Gil: However, we might want to have some resource types that have a GET only restriction.

Scribe (Tom): Panagiotis:  What happens if you do a put on a get only resource?

Scribe (Tom): Anish:  A concise table would make this more readable.

Scribe (Tom): Tom: we should try to avoid negative testing assertions that the resource should reject non mandatory methods.

Scribe (Tom): Topic: Planning and milestones

Scribe (Tom): End March - Deadline for new P1 issues

Scribe (Tom): End May - Start 1st PR

Scribe (Tom): End July - All issues closed, 2nd PR

Scribe (Tom): End August - Start CS ballot

Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48314/CAMP%20sched.pdf

Scribe (Tom): Anish: rather than a deadline for P1 issues, after this F2F we need to raise the bar for accepting a new P1 issue.

Scribe (Tom): Anish: I support raising the bar to require support of more than 2/3 of TC to accept a new P1 issue.

Scribe (Tom): Duncan:  Any issues discovered during interop need to be dealt with.  However we should be careful to avoid scope creep thru accepting new issues.

Scribe (Tom): Martin: we could have a last call date after which no new issues will be accepted without a large super majority.

Scribe (Tom): Adrian: we need at least one more meeting before we have the last call for P1 issues.

Scribe (Tom): Adrian: all P1 and P2 issues need to be closed out before shipping spec, some P3 issues can be deferred.

Scribe (Tom): Anish: Criteria for start 1st PR is closing all P1 issues.  Criteria for 2nd PR is all V1.1 issues closed.

Scribe (Tom): Anish: we should have an interop event in this schedule.

Scribe (Tom): Adrian: test assertions may bring up bugs, resolving such bug improvement issues would be critical.

Scribe (Tom): Martin: some persons but might be another person's improvement.  We should treat all issues with the same criteria.

Scribe (Tom): Anish: for PRs we should decouple the TA spec and the base spec.  However we need the TA spec ready before a target date for interop.

Scribe (Tom): Jacques: We should have the TA doc ready for review during the 1st PR for the main spec.

Scribe (Tom): Martin: does main spec reference the TA spec?

Scribe (Tom): Anish: we could put either in non-normative refs section, or on the cover page as "related spec" url

Scribe (Tom): Anish: we need to put in dates for the TA doc in the timeline

Scribe (Tom): Anish: June F2F, if during Public review, could focus on implementation/interop activities.

Scribe (Tom): Martin: I do not think we should hold up the 1st PR because the TA doc is not complete.  We can fill out the TA doc during the 1st PR for the base spce.

Scribe (Tom): Gil: I have a concern that end of MAY for 1st PR is, under assumption that the spec is complete, is unrealistic.  End of June is more realistic goal.

Scribe (Tom): Anish: the 1st PR should be there to get feedback from the general community on the spec.

Scribe (Tom): Martin: I think the end Aug CS ballot is the most unrealistic.

Scribe (Tom): Anish moves we have a 1st PR at end of June, with a 1st PR for TAs one month later

Anish Karmarkar: For the TA document 1st PR is end of June and all issues closed 2nd PR is end of Aug

Scribe (Tom): Seconded by Gil

Scribe (Tom): Jacques: need to consider maximizing the PR feedback.  I am concerned about how much attention people will give to TA spec if the main spec has already been reviewed.  I would strive to have the TA spec reviewed at the same time as the base spec.

Scribe (Tom): For interop could be done with the TAs evaluated using human eyes, rather than test tools.

MartinC  lowered your hand

Scribe (Tom): Jacques: I would like to ammend this motion to more closely synchronize the TA 1st PR with the base spec 1st PR.

Scribe (Tom): Duncan: pushing the 1st PR back to end of June will have a knock on effect to push everything else out.  However this would give a June F2F a greater importance as a focal point.

Scribe (Tom): Martin: moving everything out by one month is disastrous.

Scribe (Tom): Clarification: motion on table is to have TA spec 1st PR end of june, and all issues closed second PR at end of august.

Jacques (Fujitsu): ammend Anish motion: 1st TA PR to be initiated sometime between 1st PR of main specification (end May) and end of June.

Alex Heneveld (Cloudsoft): please confirm:  1st PR for spec _remains_ at end of May

Duncan Johnston-Watt (Cloudsoft): @Alex - That is _now_ my understanding

Scribe (Tom): Alex seconds Jacques motion.

Alex Heneveld (Cloudsoft): confirming:  the motion I second is that "1st TA PR initiated sometime between 1st PR of main spec and end of June"

Duncan Johnston-Watt (Cloudsoft): What we are discussing is an amendment to the current timeline to add a deadline for 1st TA PR that is end of June

MarkCarlson: Keep in mind this a goal setting exercise. We can change our minds at anytime in the future based on circumstances.

Duncan Johnston-Watt (Cloudsoft): And a second amendment to the timeline to add a second deadline for all TA issues to be closed by end of August

Anish Karmarkar: @alex 1st PR for spec does remain end of may regardless of the main motion or amendment

Duncan Johnston-Watt (Cloudsoft): ... so that a second TA PR can be initiated

Scribe (Tom): Clarification the ammendment is "1st PR for TA issued by the end of June"

Scribe (Tom): No objections.

Duncan Johnston-Watt (Cloudsoft): +1

Scribe (Tom): Amended motion" 1st PR for TA issued by end of June.

Scribe (Tom): No objection, motion passed.

Gil: have we stop wasting time?

MartinC : maybe

Scribe (Tom): Martin: is it feasable to have an implementation interop by the end of June?

Scribe (Tom): Anish: we should tailor the next interop to focus on implementation

Scribe (Tom): Alex: since interop will bring up new issues, be should have it between June and end of July.

Scribe (Tom): Adrian: suggest Interop sessions July 8 and 9 with regular TC conf call on July 10 to discuss results from inerop.

Scribe (Tom): Adrian: suggest Interop sessions July 8 and 9 with regular TC conf call on July 10 to discuss results from inerop.

Adrian Otto (Rackspace): yes

Gil: "CAMP Hack"

Scribe (Tom): test

Scribe (Tom): Action item: Oracle to investigate hosting interop in Broomfield CO July 8 and 9.

Scribe (Tom): Action item: Oracle to investigate hosting interop in Broomfield CO July 8 and 9.

Scribe (Tom): July 8, 9 , 10 with con call on 10th.

Scribe (Tom): Action item: Rackspace to investigate hosting interop July 8, 9, 10 around Colorado/Texas area.

Scribe (Tom): Action Item: all members to investigate hosting July 8, 9, 10 in colorado area.

Scribe (Tom): Topic: Issue list review

Scribe (Tom): Martin: 8 P1 issues

Scribe (Tom): Martin: issues 45 and 56 should have proposals from the editors with high priority

Alex Heneveld (Cloudsoft): discussion -- Issues 4, 45, and 9 are the high-effort ones.  (PDP, normative statement overhaul, and sensors+effectors)

Scribe (Tom): As group we need to resolve Camp 4

Gil: Can the Chair give me control of WebEx ?

Scribe (Tom): Camp 4 Adrian

Scribe (Tom): Camp 3 Anish

Scribe (Tom): Camp 9 Alex

Scribe (Tom): Adrian: owners  of P1 issues focus with priority, 4, 9, 56, 45, 55, 30, 3, 17

Scribe (Tom): Break for Lunch