Subject: [core] Web Link Attribute parsing problems

From: Jim Schaad <[email-masked]>
Date: Fri, 7 Jul 2017 19:08:21 -0700

I have been going through my code base looking to get
draft-ietf-core-links-json implemented as well as making sure that my
implementation of RFC 6690 (CoRE Link Format).  At this point in time, I
cannot see anyway to future proof my implementation of this code because of
how RFC 6690 decided to address a compression optimization.

My code currently does not do a good job of deciding which attributes are to
be split when they are space separated (i.e. 'rt') and which should be kept
as a single string (i.e. 'title').  I can easily get a list of the things
that should be treated in which direction right now, however going forward
into the future that will not be the case.  When the code sees a new link,
it will not know what the correct processing is in the event that a space
occurs in the value field.  

As an example of what I am looking at.  I get a new WebLink with the
attribute of 

<googoo>ct=0;bletch="foo bar"

I then get a discovery query

get  /.well-known/core?bletch="foo" 

is "googoo" supposed to be a match or not?  If it is a single string, ala
'title', then it is not a match.  If it is space separated attibutes, ala
'rt', then it is a match.

Is there a recommended way to proceed?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Jul 2017 06:00:26 +0200

Hi Jim,

It is indeed a weakness of RFC 6690 that it does not define a way to find out which future attributes are going to be space-separated lists and which ones aren’t.  (It is hinting at using this for "relation-type attributes”, but there is no way to guess whether that is the case for an attribute unknown to the parser.)

> Is there a recommended way to proceed?

Implementation-wise, I would give the application a way to provide a list of attribute names for “relation-type attributes”.  Beyond that, I also don’t know how to implement functions such as discovery queries without that semantic knowledge.

Maybe we should at least press forward with having a registry for attributes; the space-separatedness can then be a column in the registration template.

Grüße, Carsten