Re: [core] New Version Notification for draft-groves-core-bas-00.txt

[Michael Koster <[e-mail]>]

Yes, the text below should be changed. The description here seems to be a little inconsistent with the definition of observe, in that it suggest you may only need to send the representations for resources that have changed. 

I think my description in the email is more what we want to say, that the collection representation specified in the original request is returned.

We should mention conditional observe on collections in a way that leaves it open for bas

Best regards,

Michael

> On Mar 9, 2017, at 4:33 AM, Christian Groves <[e-mail]> wrote:
> 
> Hello Michael,
> 
> The text on collections was a left over from before I took over the editorship. The text in [I-D.ietf-core-interfaces] is:
> 
> 
>     3.6
>     <https://tools.ietf.org/html/draft-ietf-core-interfaces-08#section-3.6>.
>     Observing Collections
> 
> 
> 
>   Resource Observation via [I-D.ietf-core-dynlink <https://tools.ietf.org/html/draft-ietf-core-interfaces-08#ref-I-D.ietf-core-dynlink>] using CoAP [RFC7252 <https://tools.ietf.org/html/rfc7252>]
>   MAY be supported on items in a collection.  A subset of the
>   conditional observe parameters MAY be specified to apply.  In most
>   cases pmin and pmax are useful.  Resource observation on a
>   collection's items resource MAY report any changes of resource state
>   in any item in the collection.  Observation Responses, or
>   notifications, SHOULD provide representations of the resources that
>   have changed in SenML Content-Format.  Notifications MAY include
>   multiple observations of a particular resource, with SenML time
>   stamps indicating the observation times.
> 
> 
> The text in 2.1 of the BAS draft is just trying a paraphrase that. Did you want to clarify that text?
> 
> Regards, Christian
> 
> 
> On 9/03/2017 3:10 AM, Michael Koster wrote:
>> In section 2.1
>>    The current text of [I-D.ietf-core-interfaces] indicates that observe
>>    may be supported on an item in a collection not on the collection
>>    itself.
>> I don't think we should say that observe isn't supported on collections.
>> 
>> Observe should be supported for any resource, and by definition "caches" the entire method call (for example GET with all its options) for subsequent responses.
>> 
>> Observe doesn't say what triggers the subsequent responses, which dynlink and bas do specify.
>> 
>> Do I understand it correctly?
>> 
>> Best regards,
>> 
>> Michael
>