Subject: [core] Fwd: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-00.txt

From: Bill Silverajan <[email-masked]>
Date: Tue, 10 Mar 2015 14:27:52 +0200

Hi all,

A new draft entitled "CoAP Protocol Negotiation" has been submitted. The 
draft aims to provide a new approach with which clients and servers can 
overcome the challenge of interacting with a single resource over 
multiple transports.

Regards,
Bill

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-silverajan-core-coap-protocol-negotiation-00.txt
Date: 	Mon, 09 Mar 2015 13:21:32 -0700
From: 	[email-masked]
To: 	Bilhanan Silverajan <[email-masked]>, Bill Silverajan 
<[email-masked]>

A new version of I-D, draft-silverajan-core-coap-protocol-negotiation-00.txt
has been successfully submitted by Bilhanan Silverajan and posted to the
IETF repository.

Name:		draft-silverajan-core-coap-protocol-negotiation
Revision:	00
Title:		CoAP Protocol Negotiation
Document date:	2015-03-09
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/
Htmlized:       http://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-00

Abstract:
    CoAP has been standardised as an application level REST-based
    protocol.  This document introduces a way for CoAP clients and
    servers to interact with resources by agreeing upon alternate
    locations as well as transport and protocol configurations.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Markus Becker <[email-masked]>
Date: Wed, 11 Mar 2015 19:38:03 +0100

Hi Bill,

cool work! Gotta help a lot with CoAP over SMS. Some minor comments from my side:

* Example 2: Explicitly state that a GET to /.well-known/core?tt=* gives back tt and altloc. Or should it be
/.well-known/core?tt=*&altloc=* ?

* Should tt really be only the part after 'coap+’ or should it be the complete scheme? How would you handle ‘coaps+X’?

Nits:

    This draft proposes a new link format attribute as well as a new link
    relation type that together enable an origin server to serve a
-   resource from other protocol configuratons or endpoints.  CoAP
+   resource from other protocol configurations or endpoints.  CoAP
    clients then interact with an origin server's CoRE resource discovery
    interface to obtain a set of links describing alternate locations of
    resources.

    Both "tt" and "altloc" are optional CoAP features.  If supported,
-   they occur at the granularity level of an origin server, ie. they
+   they occur at the granularity level of an origin server, i.e. they
    cannot be applied selectively on some resources only.  Therefore
    "altloc" is always anchored at the root resource ("/").
    Additionally, the "tt" link attribute and "altloc" relation type can

Markus

> On 10 Mar 2015, at 13:27, Bill Silverajan <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> A new draft entitled "CoAP Protocol Negotiation" has been submitted. The draft aims to provide a new approach with which clients and servers can overcome the challenge of interacting with a single resource over multiple transports.
> 
> Regards,
> Bill
> 
> Subject: 	New Version Notification for draft-silverajan-core-coap-protocol-negotiation-00.txt
> To: 	Bilhanan Silverajan <[email-masked]>, Bill Silverajan <[email-masked]>
> 
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Bill Silverajan <[email-masked]>
Date: Fri, 13 Mar 2015 11:23:22 +0200

Hi Markus,

> /.well-known/core?tt=*&altloc=* ?

Thanks! Regarding the query filtering, RFC 6690 states that the "search" 
variable in the query string /.well-known/core{?search*} is a 1-element 
list that has a single name/value pair. I chose to return both transport 
types and locations for the single query.

I suppose a more accurate depiction would be:

   REQ: GET /.well-known/core?tt=*

   RES: 2.05 Content
   </sensors>;tt="tcp sms ws"

And then:

   REQ: GET /.well-known/core?rel=altloc

   RES: 2.05 Content
   <coap+tcp://server.example.com/>;rel="altloc",
   <coap+tcp://server.example.net/>;rel="altloc",
   <coap+ws://server.example.com/ws-endpoint/>;rel="altloc",
   <coap+sms://001234567/>;rel="altloc"

Would this approach be better? (Note: query filter to obtain a specific 
location, eg for sms, might be slightly tricky using only the rel parameter)

> * Should tt really be only the part after 'coap+’ or should it be the complete scheme? How would you handle ‘coaps+X’?

Yes, the "tt" link attribute describes just the transport for conveying 
coap (and coaps) messages. The specific protocol configuration is 
obtained from the URI scheme describing the alternate location. In other 
words, an origin server having the "tt" link attribute "sms" can have 
the following link relations:

  <coap+sms://001234567/>;rel="altloc",
  <coaps+sms://001234568/>;rel="altloc"

where the "coap+sms" URI scheme component specifies vanilla coap over 
sms, and "coaps+sms" specifies dtls-encoded coap over sms.

This way, we can keep the responses for the link attribute brief 
(instead of returning all the URI schemes which contain far more bytes 
and imho unnecessary information in a CoAP response, to a client just 
interested in seeing transport types).

>      Additionally, the "tt" link attribute and "altloc" relation type can

Both fixed now, thanks :)

Regards,
Bill

-- 
| Bilhanan Silverajan                       Tel: +358 (0)40 849 0757  |
| Tampere University of Technology, Finland                           |

---

From: Markus Becker <[email-masked]>
Date: Mon, 16 Mar 2015 07:35:19 +0100

Hi Bill.

Please see inline.

> On 13 Mar 2015, at 10:23, Bill Silverajan <[email-masked]> wrote:
> 
> 
> Hi Markus,
> 
> Thanks! Regarding the query filtering, RFC 6690 states that the "search" variable in the query string /.well-known/core{?search*} is a 1-element list that has a single name/value pair. I chose to return both transport types and locations for the single query.

Alright. So possibly, just state in the text that you are returning tt and altloc.

> Would this approach be better? (Note: query filter to obtain a specific location, eg for sms, might be slightly tricky using only the rel parameter)

I think I like the first approach more. You are getting everything you need with just one query. Just explicitly state that in the draft, or?

> Yes, the "tt" link attribute describes just the transport for conveying coap (and coaps) messages. The specific protocol configuration is obtained from the URI scheme describing the alternate location. In other words, an origin server having the "tt" link attribute "sms" can have the following link relations:
> 
> <coaps+sms://001234568/>;rel=“altloc"

Most likely it should be the same number, or?

> where the "coap+sms" URI scheme component specifies vanilla coap over sms, and "coaps+sms" specifies dtls-encoded coap over sms.
> 
> This way, we can keep the responses for the link attribute brief (instead of returning all the URI schemes which contain far more bytes and imho unnecessary information in a CoAP response, to a client just interested in seeing transport types).

Sounds good to me.

One more thing. Should plain CoAP be included as well? Assume one connects to the device by SMS first and then wants to figure out where to connect to by plain CoAP? One way to keep the answer brief could be to return only the other transports, which are not in use by the current message exchange?

Best regards,
Markus

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 16 Mar 2015 16:07:18 +0200

Hi Markus,

>>[.....]

Ok, the text now reflects this:

"Example 2 shows a CoAP client actively soliciting a CoAP server for all 
supported transport types. Note that both the supported transport types 
as well as alternate locations are returned"

> Most likely it should be the same number, or?

Sure, both could be the same number or destination host as well. (One 
question: Does it make better sense to use MSISDN format and simply 
dropping the international call prefix for coap+sms URIs?)

> One more thing. Should plain CoAP be included as well? Assume one connects to the device by SMS first and then wants to figure out where to connect to by plain CoAP?

I think that's fair, so yes, UDP should not be excluded at all as one of 
the transports returned.

>One way to keep the answer brief could be to return only the other transports, which are not in use by the current message exchange?
>

My concern is that some scenarios might arise which complicate the 
message exchange (and implementation) if we take this route. For 
example, an origin server wishing to expose the resource in alternate 
locations for the same transport might be unable to convey this 
information if a client uses the same transport already.

Regards,
Bill