Subject: [core] Fwd: New Version Notification for draft-shelby-core-link-format-00

From: Zach Shelby <[email-masked]>
Date: Tue, 28 Sep 2010 12:06:19 +0300

http://www.ietf.org/id/draft-shelby-core-link-format-00.txt

This new draft specifies the link format and well-known URI interface for use in CoRE resource discovery separately from the base CoAP draft as per ticket #21. In the process of spinning this into a separate draft, several improvements were made (thanks Mark and Carsten!).  

o The link format ABNF from draft-nottingham-http-link-header was completely re-used, avoiding the need to redefine it.
o Quoted strings were added for string attributes
o Explanation of the target/context URI was added along with use of the relation attribute in-line with draft-nottingham-http-link-header
o References to DNS-SD and mDNS were completely removed as this was found to be misleading in Maastricht
o Well-known URI changed to /.well-known/core to make registration possible (/r was too short)
o Filtering was changed to a MAY
o Proper IANA section was created

I plan on making one slide capturing these changes for tomorrow's interim WG meeting, a 10 minute slot should be enough.

Zach 

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: September 28, 2010 11:56:43 AM GMT+03:00
> To: [email-masked]
> Subject: New Version Notification for draft-shelby-core-link-format-00 
> 
> 
> A new version of I-D, draft-shelby-core-link-format-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-core-link-format
> Revision:	 00
> Title:		 CoRE Link Format
> Creation_date:	 2010-09-28
> WG ID:		 Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This document defines a link format for use by constrained CoAP web
> servers to describe URIs of resources offered along with other
> attributes.  Based on the HTTP Link Header format, the CoRE link
> format is carried as a payload and is assigned an Internet media
> type.  A well-known URI is defined as a default entry-point for
> requesting the list of links to resources hosted by a server.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 28 Sep 2010 22:27:56 -0400

Hi Zach,

I am wondering if this is the way to discover which port the
service is bound to?  (I'm thinking here of the dynamic hc
ports.)

Also, let's FIX the DNS-SD text in -03 rather than deleting
it.  I hope we are not planning to punt on REQ8, which
comes to us from the charter.  We clearly need a scalable
service discovery mechanism for building automation.

Regards, -K-

On Tue, Sep 28, 2010 at 5:06 AM, Zach Shelby <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Peter Bigot <[email-masked]>
Date: Wed, 29 Sep 2010 11:18:04 -0500

The link extensions just prior to section 2.1 need to add required
quotations around URI and URI-Reference, as are present with the
anchor link param in draft-nottingham-http-link-header.  Otherwise
they're not conformant to that document's syntax for link-extensions.

      link-extension    = ( "d" "=" <"> URI <"> )
      link-extension    = ( "sh" "=" <"> URI-Reference <"> )
      link-extension    = ( "n" "=" quoted-string )
      link-extension    = ( "ct" "=" integer )
      link-extension    = ( "id" "=" quoted-string )

Also need to add:

      integer = 1*DIGIT

Unfortunately this makes it impossible to syntactically distinguish
URIs from strings in the "n" and "id" extensions.  Dunno if that will
be a problem for anybody.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Wed, 29 Sep 2010 21:22:31 +0300

Peter,

>      link-extension    = ( "id" "=" quoted-string )

Thanks, I will fix that. 

> be a problem for anybody.

I wouldn't find that to be a problem, except this text in Section 2.7 obviously needs to be fixed as id is only a quoted-string.

"This attribute (id) may be in quoted-string format (e.g. in the case of a UUID or XRI) or in URI format (e.g. in the case of a URN)."

Zach