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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Apr 2011 09:45:42 +0100

Hi,
Here is my detailed review of the draft. It is mostly fine, but has lots 
of missing references.
I also found lack of ABNF for the format to be inconvenient, but the 
prose description might be Ok, as long as it is accurate.

1.  Introduction

   The main function of such a discovery mechanism is to provide
   Universal Resource Indicators (URIs, called links) for the resources

I think "I" stands to Identifier.

1.2.1.  Discovery

   Resource Discovery can be performed either unicast or multicast.
   When a server's IP address is already known, either a priori or
   resolved via the Domain Name System (DNS), unicast disovery is

typo: discovery

This is missing an informational reference for DNS.

   performed in order to locate the entry point to the resource of
   interest.  This is performed using a GET to /.well-known/core on the
   server, which returns a payload in the CoRE Link Format.  A client
   would then match the appropriate Resource Type, Interface Description
   and possible Content-Type for its application.  These attributes may

Please add an Informative reference to RFC 2045 after Content-Type.

1.3.  Terminology

   Link
      Also called "typed links" in RFC5988.  A link is a typed
      connection between two resources identified by URIs.  Made up of a
      context URI, a link relation type, a tarfet URI, and optional

typo: target

      target attributes.

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?

   The CoRE link format
   MUST use UTF-8 encoding

A missing Normative reference to RFC 3629. 
<http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=3629&type=http&file_format=txt>

    , which SHOULD be in NFC (Unicode Normalization Form C).

This also needs a Normative reference.

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?

      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.

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?

   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.

3.3.  Content-type code 'ct' attribute

   The Content-type code "ct" attribute provides a hint about the
   Internet media type this resource returns.  Note that this is only a
   hint, and does not override the Content-type Option of a CoAP
   response obtained by actually following the link.  The value is in
   the CoAP identifier code format as a decimal ASCII integer
   [I-D.ietf-core-coap].

This sentence is making the reference Normative, while it is listed as 
Informative.

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?

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?

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?

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

   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 ().

   Security considerations: None

Are you sure :-). See RFC 4288.

   File extension(s):

Any reason not to define an extension here?