Subject: [CDNi] AD review of draft-ietf-cdni-redirection-16

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Feb 2016 19:46:12 -0500

I've reviewed the publication request for
draft-ietf-cdni-redirection-16, and I have two comments, both of which
we'll have to resolve before the document goes to last call.

(1) References:
2818 is the subject of a MUST (Section 5.1)
6707 has required terminology (Section 2)

I think those all need to be normative.  2818 is already in the
downref registry, and we can call out 6707 during last call.
Discussion?

(2) Section 4.2:

   The following additional rules apply to all keys in RI requests and
   responses (whether in the top level object or in sub-objects):

   o  Keys MUST always be encoded in lowercase.  Requests or responses
      containing keys that are not all lowercase MUST be considered
      syntactically invalid.

   o  Unknown keys MUST be ignored but the request or response MUST NOT
      be considered invalid unless the syntax of the request or response
      is invalid (i.e., an RI request or response MUST NOT be considered
      invalid on the basis that it contains unknown keys).

I understand what you're trying to do here, but I don't think it works
sensibly.  Consider that a client and server both understand the keys
"apple" and "orange", and then the client is updated to support the
new "banana" key (but the server isn't).

That server is expected to process "apple" and to reject "Apple" or
"APPLE" as syntatically invalid.  But, according to the second bullet,
the server is expected to ignore "banana" (because it's an unknown
key), but to reject "Banana" as syntatically invalid.  Is that really
reasonable?

What you might think you're saying is that the server should be
checking that the key doesn't contain any of the characters in
"ABCDEFGHIJKLMNOPQRSTUVWXYZ", but realise that's not sufficient: JSON
keys can contain any Unicode characters, and there are many uppercase
Unicode characters.  Should it also be syntax-checking for "ФЯЧДЩ" and
"ΛΠΩΨΔ", and similarly for uppercase Hebrew characters, and so on?

What is the value is requiring the syntax check in first bullet?  Is
it not sufficient just to require that valid keys be in the specified
case, and that keys that are invalid be ignored?  Is there really
extra value in rejecting a request or response that contains a key
that has an uppercase character?

--
Barry, ART AD

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 15 Feb 2016 09:33:44 +0000

Hi Barry,

I just published a new version (-17) that should address your comments.

I moved RFC2818 & RFC6707 to normative references and replaced the rules on JSON keys in section 4.2 with the following text:

   Senders MUST encode all (top level object and sub-object) keys
   specified in this document in lowercase.  Receivers MUST ignore any
   keys that are unknown or invalid.

Ben

> On 3 Feb 2016, at 00:46, Barry Leiba <[email-masked]> wrote:
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni