Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Nov 2011 12:12:30 +0800

On January 16 this year, core-link-format-02 finished working group last call.
On March 15, the -03 draft incorporated the changes from the comments received on this WGLC.

Since that update, the draft has experienced some Brownian motion.
Changes were made e.g. to adapt the examples to some coap-core changes, to clarify the use of UTF-8, to address AD comments, and to properly distribute the normative content between the different CoRE specs.
With -09, we now have a version that passes all ID-Nits.
While I personally think it could be justified to send this on to the IESG as is, I also think that might be considered bad form.

So I'm announcing today a

   second working-group last call
   for draft-ietf-core-link-format-09.txt

This is a one-week WGLC, but time does not pass during an IETF.
So please send in any comments to the CoRE list now, or latest until

   2011-11-28, 1200 UTC.

A short note of the form "I've re-read -09 and it's OK" would also be very welcome.

Gruesse, Carsten

PS.: You can use
http://tools.ietf.org/rfcdiff?url2=draft-ietf-core-link-format-09&url1=draft-ietf-core-link-format-03
to review the changes since -03.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 28 Nov 2011 11:02:35 +0000

Dear Carsten,

I reviewed the changes (diff v3/v9) and text surrounding the changes; see comments below. The first three points should be clarified or fixed in my view. In general, the document looks in good shape.

** Relation type: RFC5988 supports multiple relations in one string/entry. Should we support this or explicitly (e.g. "SHOULD NOT") exclude this in CoRE Link Format context? For example:
        rel="http://example.com/myRelationType1 http://example.com/myRelationType2 describedby"

This may be an issue if a constrained client is looking for a "describedby" relation using the byte-wise string comparison suggested by core-link-format: it would not match to above string unfortunately. Also, it causes problems if the "rel" value is stored on a CoRE server as one key/value pair and if I would do a query with resource-param = "rel" to look for a specific relation type such as "describedby", or "copyright" or "http://example.com/myRelationType2". Again, this would not match as it is not bytewise identical as defined in core-link-format as the matching criterion. One solution would be to state in core-link-format something like "the value of a "rel" parameter SHOULD NOT contain more than one relation type" i.e. optimize the use of RFC5988 a bit for constrained environments by constraining its flexibility. Another solution approach is to provide more guidance in how to do the matching in case of the "rel" attribute. Yet another solution approach is to allow multiple relations in one "rel" value, but add some mandatory implementation guidance that multiple, say N, relations should be stored as N separate relations so these can be individually found using filtering/querying.

** use of "quoted-string" in ABNF definitions - should be a regular string, not "quoted-string" here?
link-extension =/ ( "rt=" quoted-string )
link-extension =/ ( "if=" quoted-string )

** Unclear sentence (for me) "A query-pattern of "*" will match that resource-param with an empty string value."
 Was it intended that "*" matches to an empty string value as well as to any other non-empty string ?
 Or does this sentence intend to clarify that if the query is "*" then the string prefix matching process will use an empty string as the string to match all values against? (In which case, also all value strings will match).
 Or both?

** Multicast and filtering:
  "A multicast request with a query string MUST NOT be responded
  to if filtering is not supported or if the filter does not match (to
  avoid a needless response storm)."
I'm thinking if this could also be a "SHOULD NOT" requirement, but perhaps there's a good reason why "MUST NOT" is used here. If anyone on the list has further opinions on this, I would be interested.

** Minor issues and typos
- Just a thought: In the intro e.g. section 1.1 or 1.2 we could add explicitly that CoRE Link Format can be applied in for example HTTP servers or CoAP servers. Some people may unconsciously and wrongly associate "CoRE Link Format" to "CoAP link format" e.g. due to its previous linkage to CoAP Content Types and "ct" attribute.

- "Removed the assumption of a default content-type assumption"

- "To express other relations a links can make use of"

- "To express other relations a links can make use of any registered
relation parameter or target attributes by including the relation parameter."
  So, a link can make use of a relation parameter by including the relation parameter - does not seem to add much, it's obvious? If I include something I use it. Or was it meant "...use of any registered relation or target attributes..." ?

- In below text, the first and second example looks exactly the same, contradicting the text:
"""
  </sensors/temp>;rt="TemperatureC";if="sensor",
  </sensors/light>;rt="LightLux";if="sensor"
  Without the linefeeds included for readability, the format actually
  looks as follows.
  </sensors/temp>;rt="TemperatureC";if="sensor",
  </sensors/light>;rt="LightLux";if="sensor"
"""

- "When using a transfer protocol like the Constrained Application
Protocol (CoAP) that supports multicast requests, special care is taken."
Perhaps "is taken" -> "needs to be taken" ?

- "interface description" vs "Interface Description" - are they the same thing? If so use same capitalization.

- "Resource registration can be archived by having each server POST" -> ..."can be achieved"

best regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Thursday 17 November 2011 5:13
To: core WG
Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt

   2011-11-28, 1200 UTC.

Gruesse, Carsten

PS.: You can use

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Nov 2011 12:36:00 +0100

Hi Esko,

these are very useful comments.

I don't understand this one, though:

> link-extension =/ ( "if=" quoted-string )

From RFC 2616 we import via RFC 5988:

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    = "\" CHAR

Is this not exactly what we want to have?
As in:

An alternative would be ptoken, as in:

   </sensors/temp>;rt=TemperatureC;if=sensor,
   </sensors/light>;rt=LightLux;if=sensor

Entirely switching to ptoken appears somewhat restrictive to me, but could be argued for.  Certainly the following looks a bit strange, but would indeed be easy to parse.

   </sensors/temp>;rt=http://tzi.org/isq/temp&unit=centikelvin;if=sensor,
   </sensors/light>;rt=LightLux;if=http://tzi.org/w/lightsensor.wadl

Allowing both ptoken and quoted-string appears to be unneeded complexity.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 28 Nov 2011 12:34:08 +0000

Thanks Carsten,

My mistake; "quoted-string" does indeed occur in all the application/link-format examples given. I wrote this after seeing unquoted values in example queries (as in GET /.well-known/core?rt=LightLux) in which the query pattern is a ptoken.

Thinking of this, I can in theory name a resource type like
        rt="outdoor temperature"
but querying it would not be possible like this (ptoken does not allow space, char 0x20):
        GET /.well-known/core?rt=outdoor temperature
with current web server query conventions it could be phrased as:
        GET /.well-known/core?rt=outdoor+temperature

Maybe a preferred solution for such cases could be indicated in the I-D? (One pragmatic solution is stating that values with whitespace characters are to be avoided. Or maybe define a quoted-ptoken type?)

regards,
Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday 28 November 2011 12:36
To: Dijk, Esko
Cc: core WG; Zach Shelby
Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt

Hi Esko,

       quoted-pair    = "\" CHAR

Grüße, Carsten

---

From: Likepeng <[email-masked]>
Date: Tue, 29 Nov 2011 00:55:55 +0000

Hi Zach, Carsten and all,

It seems that my comments come late. Now it is after the WGLC deadline. Maybe it can be something for your future consideration.

Is it possible that we use defined binary code to replace the defined attributes. For example, use 0000 to represent "rt", 0001 represents "if", 0010 represents "ct", 0011 represents "sz", etc. We can adopt similar approach as we design options in CoAP spec.

In this way, we can avoid to use text/plain in the message payload. It will be easier for the requester to parse the link-format payload, and this can also save some bytes.

Any thoughts on this?

Thanks,
Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Thursday 17 November 2011 5:13
To: core WG
Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt

   2011-11-28, 1200 UTC.

Gruesse, Carsten

PS.: You can use