Andy Johnson

So per the Oct 8, 2014 Working Group Meeting, we would like to make the following changes to the spec come version 2.0 all surrounding UTC. UTC is the slightly...

Per the 3/18/15 call, like both approaches, but no decision made on which one. Requirement would be a SHOULD\*

I'm fine with this change as compound requirements are nothing but trouble. Would be a patch change as the meaning of the requirement doesn't change, just that the example follows...

Same as issue #829 , this can wait until after the editor as needed.

I think it is good to have the discussion about reasonable lifecycle expectations of Statements, but agreed that it is a 2.0 or even potentially a separate spec altogether. On...

Per the 1/4/17 call, not a "real requirement". Will eventually be dropped. The justification is that HEAD requests were handled in as few as requirements as possible to reduce bloat....

Per the 2/1/17 call, @ahoran3 is correct and the example MUST be updated.

I see keeping the MUST requirement as extremely problematic. cmi5 for example, would break (https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md) because it uses extensions that essentially have controlled vocabulary. Not being able to reject those...

@aaronesilvers - Totally agree we need a process for 2016 regarding profiles and extensions. For 1.0.3, (which I hope is done before 2016) the good news is that even though...

@garemoko - Agreed- permissions is where most of the latitude in LRS gets in rejecting Statements. In the cmi5 example, wouldn't you have to adjust one's permissions on the fly...