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

From: Zach Shelby <[email-masked]>
Date: Mon, 5 Dec 2011 17:10:48 +0200

Hi Esko,

Thanks again for the useful review, I see Carsten and others have discussed most of these. Now I will be making what I can into tickets. The editorial fixes I will make directly in the update. See some comments in-line.

On Nov 28, 2011, at 1:02 PM, Dijk, Esko wrote:

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

I really don't expect arbitrary relations types to be used much in CoRE, and don't see the need for multiple at all. I agree that this can be defined as a SHOULD NOT. Will make a ticket on this.

> ** 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 )

I will reply to the thread on this one.

> 
> ** 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 ?

Correct. I will clarify this as an editorial issue.

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

We discussed this a bit with Carsten, and there is a case where SHOULD NOT makes sense. Not all POSIX interfaces are able to tell that the source address was multicast. I suggest a ticket to change this to SHOULD NOT, with an explanation of this exception. Will make this a ticket.

Thanks for the editorial comments below.

Zach

> ** 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
> 
> 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.
> 
> _______________________________________________
> 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.
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: Zach Shelby <[email-masked]>
Date: Mon, 5 Dec 2011 17:19:04 +0200

On Nov 28, 2011, at 2:34 PM, Dijk, Esko wrote:

> 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?)

Does this really affect us between CoAP end-points? Yes, obviously those examples are a bit misleading as that would not be allowed in a browser's URL line or in HTTP. But as we are normalizing this to UTF-8 in the Uri-Query option the space (or other binary data) would just be included there as UTF-8. An HTTP proxy would have to normalize this to UTF-8 as well. 

Zach

> regards,
> 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,
> 
> these are very useful comments.
> 
> I don't understand this one, though:
> 
> On Nov 28, 2011, at 12:02, Dijk, Esko wrote:
> 
> 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, 5 Dec 2011 15:33:09 +0000

To clarify ; the problem I still see is that section 4.1 defines the query pattern to be a 'ptoken' type, which does not allow spaces nor arbitrary UTF-8. So I assume a CoAP server implementer may decide to let his/her server reply with error on any query pattern containing a space?

Esko

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

Zach