Subject: [core] Link-format query URIs and ptoken

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Dec 2011 21:35:36 +0100

Esko's comments on the link-format document got Zach and me thinking about our usage of ptoken again.

In link-format-09, the syntax for the queries in the URIs says:

        filter-query = resource-param "=" query-pattern
        resource-param = "uri" / parmname
        query-pattern = ptoken [ "*" ]
        ptoken = <Defined in RFC5988>

Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, not in a URI.
Looking more closely:

  ptoken         = 1*ptokenchar
  ptokenchar     = "!" | "#" | "$" | "%" | "&" | "'" | "("
                 | ")" | "*" | "+" | "-" | "." | "/" | DIGIT
                 | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
                 | "[" | "]" | "^" | "_" | "`" | "{" | "|"
                 | "}" | "~"

Oops, that actually includes "*" and "&"!
There also is no mention of percent-encoding (of course not, because RFC2616 does not percent-encode headers).

So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC5988 ABNF.

First attempt:

        query-pattern = search-token [ "*" ]
        search-token = *pchar

But pchar (RFC3986) includes subdelims:

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   query         = *( pchar / "/" / "?" )

   pct-encoded   = "%" HEXDIG HEXDIG
   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

… which includes "*" and "&".

So, to do this right, let's mix this properly:

        query-pattern = search-token [ "*" ]
        search-token = *search-char
        search-char = unreserved / pct-encoded
                    / ":" / "@"   ; from pchar
                    / "/" / "?"   ; from query
                    / "!" / "$" / "'" / "(" / ")"
                    / "+" / "," / ";" / "="  ; from sub-delims

:@/?!$'()+,;= indeed.

This makes it possible to say something like:

GET /.well-known/core?rt=outdoor%20temperature

After the percent-decoding defined in core-coap's URI parsing (section 6.4), the server will see:

Uri-Path  .well-known
Uri-Path  core
Uri-Query rt=outdoor temperature

which sounds about right.

The parser in the server will now just have to
1) search for the first "=" and use that to delimit the parameter name from the search-token
2) check for a trailing "*" and remove that, if present, indicating a prefix match.

Would I use spaces for rt values?  Probably not, but there are still good reasons for staying general here.
As the percent-decoding is already done when the server sees it, there is no cost to this generality, either.

Esko: Does this change resolve that part of your comment?

Syntax is hard, let's go christmas shopping.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 16 Dec 2011 09:19:36 +0000

Yes, that resolves it, thanks.

Another point for the updated definition is the use of 'parmname'. This seems not defined in the text, in the ABNF sense,  nor explicitly imported from RFC 5988 or 5987 where it is defined. As the definition of parmname there allows # and & in the name, that seems a bit risky for URL parsing ;)
        GET /.well-known/core?my&attribute=value

So it seems that although a lot of freedom is given in defining attribute names, we may have to limit this in the queries?

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Thursday 15 December 2011 21:36
To: [email-masked] WG
Subject: [core] Link-format query URIs and ptoken

  ptoken         = 1*ptokenchar

First attempt:

... which includes "*" and "&".

:@/?!$'()+,;= indeed.

Uri-Path  .well-known
Uri-Path  core

Grüße, Carsten

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