Subject: [core] Fwd: Fwd: Coap discovery related questions...

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 May 2014 20:01:55 +0200

[One more mail I'm manually forwarding to work around yahoo’s DMARC disaster.]

> From: Sudhir Pendse <[email-masked]>
> Subject: Re: [core] Fwd: Coap discovery related questions...
> Date: 9 May 2014 19:19:38 +0200
> To: Carsten Bormann <[email-masked]>, "[email-masked] WG" <[email-masked]>
> Reply-To: Sudhir Pendse <[email-masked]>
> 
> 
> Thanks for your prompt response...
> 
> Yes, rt/if, being opaque strings, will work only if everyone uses a well 
> defined set of values in actual practice.
> 
> I reread the "if" attribute description in RFC 6690 and it talks about 
> "describing the verbs usable on a resource/..REST interface to interact.." 
> and this could be viewed to describe the methods applicable on a resource 
> like GET/POST/DELETE/PUT.. So that might certainly be a good spot, 
> although the examples given in that section do not talk about it.  
> 
> So a related question would be "what is a good place to specify this 
> well defined set of values that MAY/SHOULD be used in actual practice ?
> 
> ==(use case)
> 
> If we think of the uri's as being manageable objects, then what you can
> do to them like read/write/destroy/create (similar to the ACCESS clause 
> in a SNMP MIB) is useful information when building off-the-shelf tools 
> like a coap-browser or a generic coap management application.  
> 
> Adding support for 'ct' attribute (like the SYNTAX clause) in the draft
> helps in this effort and extends the great benefits of "dynamic discovery", 
> as it lessens the apriori knowledge needed to interact.. Similarly
> information about the methods applicable on a resource will also help.
> 
> So while discovering the methods applicable on a resource might not be 
> sufficient by itself to act on, it is a start, and in conjunction with 
> other attributes like 'ct', it helps make the goal of standards based, 
> off-the-shelf applications more realizable. Otherwise we might be left
> with vendor specific applications with pre-known knowledge using
> just a standard transport mechanism for management actions other then 
> viewing. 
> 
> One other thing to consider is only providing method information when
> requests come over a secure transport (dtls).
> 
> -Sudhir
> 
> 
> From: Carsten Bormann <[email-masked]>
> To: "[email-masked] WG" <[email-masked]> 
> Cc: Sudhir Pendse <[email-masked]> 
> Sent: Friday, May 9, 2014 12:41 AM
> Subject: Re: [core] Fwd: Coap discovery related questions...
> 
> Sudhir Pendse <[email-masked]> wrote:
> 
> 
> > a way to find out if a particular uri supports GET/POST/DELETE/PUT
> 
> 
> There have been a number of proposals to define attributes for discovering the set of methods applicable to a resource.
> 
> So far, the sentiment of the WG has been that while this is useful information to discover, it may not really be sufficient to act on it.
> Instead, attributes such as “rt=" and “if=" could be used to provide more specific information that is then directly actionable.
> 
> Obviously, whether this is the right assessment depends on specific use cases.
> (It also depends on a set of resource type/interface description names to be accepted practice.)
> 
> Sudhir: Maybe you could describe your use case in more detail so we can discuss this in more specific terms?
> 
> Grüße, Carsten
> 
> 
>