Subject: Re: [core] Review of draft-ietf-core-link-format-03.txt

From: Zach Shelby <[email-masked]>
Date: Tue, 3 May 2011 12:28:27 +0300

Thanks for your review Alexey. I have made these changes, a few answers to your questions below as well.

On Apr 13, 2011, at 11:45 AM, Alexey Melnikov wrote:
> 
> In Section 2:
> 
>  The CoRE link format uses the ABNF description and associated rules
>  in Section 5 of [RFC5988].  In addition, the pchar rule is taken from
>  [RFC3986].  The "Link:" text is omitted as that is part of the HTTP
>  Link Header.  As in [RFC5988], multiple link descriptions are
>  separated by commas.  Note that commas can also occur in quoted
>  strings and URIs but do not end a description.
> 
> Does this mean that some comma escaping mechanism is needed?

Not as far as I know, at least RFC5988 doesn't use comma escaping and we haven't changed the format.

> 3.  CoRE link extensions
> 
>  The following CoRE specific target attributes are defined.  These
>  attributes describe information useful in accessing the target link
>  of the relation, and in some cases may be URIs.  These URIs MUST be
>  treated as indicators, and are not meant to be actually retrieved
>  like a URL.
> 
> Are you trying to say that they are not resolvable?

Right, I updated the language.

> 
>     link-extension    = ( "ct" "=" integer )
>     link-extension    = ( "sz" "=" integer )
>     integer           = 1*DIGIT
> 
> Are there any limits on allowed values? I generally think there should be one.

I added a range limit for ct as an ABNF comment and in the text. Let's see what text we can agree on for sz. 

> 
> 3.1.  Resource type 'rt' attribute
> 
>  The resource type "rt" attribute is used to assign a semantically
>  important type to a resource.  One can think of this as a noun
>  describing the resource.  In the case of a temperature resource this
>  could be an application-specific semantic type like
>  "OutdoorTemperature", a Universal Resource Name (URN) like
>  "urn:temperature:outdoor" or a URI referencing a specific concept in
>  an ontology like
>  "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature".
> 
> Is specific syntax important here, or are these values opaque?

Opaque, I added text to make that clearer.

> 
>  The interface description could be for example the URI of a Web
>  Application Description Language (WADL) definition of the target
> 
> I think an Informative reference is needed here.

Done.

> In Section 4.1:
> 
>  If the decoded query-pattern does not end with "*", a link value
>  matches the query only if the value of the attribute or URI-reference
>  denoted by the resource-param is bytewise identical to the query-
>  pattern.  If the decoded query-pattern ends with "*", it is
>  sufficient that the remainder of the query-pattern be a prefix of the
>  value denoted by the resource-param.
> 
> Does * match an empty string?

Yes, I would assume so if that attribute present with an empty string. 

> 6.  Security Considerations
> 
>  Multicast requests using CoAP for the well-known link-format
>  resources could be used to perform denial of service on a constrained
>  network.  A multicast request SHOULD only be accepted if the request
>  is sufficiently authenticated and secured.
> 
> Is there a mechanism to satisfy the SHOULD?

I added a mention of IPsec and object security, which would be the only options. 

> 7.1.  Attribute Registry
> 
>  This document defines a registry for the link extension attributes
>  defined for use with the CoRE Link Format.  The name of the registry
>  is "CoRE Link Format Attributes".
> 
> Is it wise to limit this registry to CORE only? For example, if another application using link relations is extended, how can conflicts with this registry be avoided?

We already had a ticket to remove this registry as Mark will work on a general one, so agreed and done. 

> 
> 7.4.  New link-format Internet media type
> 
>  This memo registers the a new Internet media type for the CoRE link
>  format, application/link-format.
> 
>  Type name: application
> 
>  Subtype name: link-format
> 
>  Required parameters: None
> 
>  Optional parameters: The query string may contain uri= to match the
>  URI, or any other attribute defined for the link format to match that
>  attribute as defined in this document.
> 
> This is a wrong type of information here, as this is not talking about MIME type parameters. So I think None should be specified in this field

Fixed.

> 
>  Encoding considerations: UTF-8 (NFC)
> 
> According to MIME type registration template this field should have the value "8bit". The rest can be a comment in ().

Fixed.

> 
>  Security considerations: None
> 
> Are you sure :-). See RFC 4288.

Oops, I added the same security considerations as in the security section here as well, as they are valid. 

> 
>  File extension(s):
> 
> Any reason not to define an extension here?

I propose adding the extension *.clf (Core Link Format). An alternative would be *.wlk (Web LinKing). Both seem to be free.

Zach

> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
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: Alexey Melnikov <[email-masked]>
Date: Tue, 03 May 2011 12:07:49 +0100

>Thanks for your review Alexey. I have made these changes, a few answers to your questions below as well.
Hi Zach,
I am mostly happy with your replies, so I deleted your relies where we 

>Not as far as I know, at least RFC5988 doesn't use comma escaping and we haven't changed the format.
Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are Ok. 
But I am still not clear what the last quoted sentence is trying to say?
It doesn't look like you allow for multiple URIs to be listed on a 
single line, so what has comma to do with anything?

Which brings me to a related issue: there is no ABNF of the format 
defined in the document. There are only ABNFs for pieces of the Link format.
 [...]

>Yes, I would assume so if that attribute present with an empty string. 
I suggest stating that explicitly.

>I propose adding the extension *.clf (Core Link Format). An alternative would be *.wlk (Web LinKing). Both seem to be free.
I think .wlk is a bit better, because .clf is already in use (according 
to Google search).

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 May 2011 12:10:12 +0100

Alexey Melnikov wrote:

>> I propose adding the extension *.clf (Core Link Format). An 
>> alternative would be *.wlk (Web LinKing). Both seem to be free.
>
> I think .wlk is a bit better, because .clf is already in use 
> (according to Google search).

Sorry, both are used according to <http://filext.com/>. But I don't 
think reuse is a big deal.

---

From: Zach Shelby <[email-masked]>
Date: Tue, 3 May 2011 14:25:03 +0300

On May 3, 2011, at 2:07 PM, Alexey Melnikov wrote:

> I am mostly happy with your replies, so I deleted your relies where we are in agreement. A few remaining issues below:
> 
> Ok, commas inside <> (i.e. inside URIs) or inside quoted strings are Ok. But I am still not clear what the last quoted sentence is trying to say?
> It doesn't look like you allow for multiple URIs to be listed on a single line, so what has comma to do with anything?

Don't be fooled by the example. In the RFC5988 format linefeed is not used for delimiting multiple entries, but instead a comma. 

"5.  Examples

   A few examples of typical link descriptions in this format follows.
   Multiple resource descriptions in a representation are separated by
   commas.  Linefeeds never occur in the actual format, but are shown in
   the example for readability."

> 
> Which brings me to a related issue: there is no ABNF of the format defined in the document. There are only ABNFs for pieces of the Link format.

RFC5988 describes the ABNF for the format. We are simply reusing that. Originally we did repeat that ABNF in the CoRE Link Format, but were encouraged by Martin and Mark to take that out. I agree with them that repeating it is not worthwhile. 

Done.

> I think .wlk is a bit better, because .clf is already in use (according to Google search).
> 

.wlnk is free, will go for that. 

Zach

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 May 2011 12:31:20 +0100

>   the example for readability."
Ok, I must have forgotten about this.

It would be nice to see an example with no line folding though.

>RFC5988 describes the ABNF for the format. We are simply reusing that. Originally we did repeat that ABNF in the CoRE Link Format, but were encouraged by Martin and Mark to take that out. I agree wi…
I suggest you actually point to the specific ABNF production in RFC 
5988. That way you wouldn't have to repeat ABNF from it.

>.wlnk is free, will go for that. 
Ok.

---

From: Zach Shelby <[email-masked]>
Date: Tue, 3 May 2011 14:43:13 +0300

> It would be nice to see an example with no line folding though.

Sure, good idea.

> I suggest you actually point to the specific ABNF production in RFC 5988. That way you wouldn't have to repeat ABNF from it.

The draft currently states

"The CoRE link format uses the ABNF description and associated rules
   in Section 5 of [RFC5988].  In addition, the pchar rule is taken from
   [RFC3986]. "

Is there a way to also indicate this in the ABNF of the new attributes. Some kind of "Import everything from Section 5 of RFC5988"? I can mention that in the first sentence of Section 3, but it would be nice to have that explicit in the ABNF.

Zach

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 May 2011 20:47:53 +0100

[...]

>Is there a way to also indicate this in the ABNF of the new attributes. Some kind of "Import everything from Section 5 of RFC5988"?
>
One way of doing this is by defining rules like:

link-param = <Defined in RFC 5988>

and then:

link-param =/ ...your new value goes there...

>I can mention that in the first sentence of Section 3, but it would be nice to have that explicit in the ABNF.
>