Subject: Roman Danyliw's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 20 May 2020 13:29:44 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(I appreciate that this is pseudo-code which has inherent ambiguity sometimes,
so please let me know if I've interpreted it in an unintended way)

** Section 4.2.6.  There appears to be an inconsistency here in my reading of
the algorithm given the ABNF in Section 3.3.4

-- Let’s assume of token of input_string =“*foo”

-- Step 1: pass since input_string[0] = “*”

-- Step 2: Set output_string = “”

-- Step 3: pass since input_string[0] = “*”,

-- Step 3.1: input_string[0] is still “*” and not a tchar, “:” or “/” causing a
output_string=”” to be returned

This doesn’t seem correct.

** Section 4.2.7.  The parsing guidance doesn’t follow for me given the ABNF in
Section 3.3.5.

-- Let’s assume input_string =
“:cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:”, the example in Section 3.3.5

-- Step 1: pass since input_string[0] = “:”

-- Step 2: Set input_string = “cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:”

-- Step 3: pass since the last character of input_string is “:”

-- Step 4: Set b64_content = “cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==”

-- Step 5 says “consume the “:” character at the beginning of the input_string,
but there is no such character.  It was discarded in Step 2.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 4.1. Reading steps 1 – 6 like pseudo-code, if Step 1 is true,
output_string will be undefined in Step 6.    There needs to be a step 0 which
reads “Let output_string be an empty string” or Step 1 needs to explicitly
initialize output_string.

** Section 4.1.8.  Per Step 1, “If input_bytes is not a sequence of bytes, fail
serialization”, what input wouldn’t be considered as sequence of bytes?

** Section 4.2.  An algorithmic style nit.  In Section 4.1, the text used an
“IF x ELSE IF y ELSE IF z ELSE fail” convention.  Here the text is a series of
simple “IF x; IF y; IF z; …” statements.

** Section 4.2.  Editorial.  In step 8, s/Otherwise, return output./Else,
return output./

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 21 May 2020 09:21:50 +1000

> This doesn’t seem correct.
tchar contains "*" <https://tools.ietf.org/html/rfc7230#section-3.2.6> so
step 3.1 passes.

> -- Step 2: Set input_string =
> “cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:”
>
By the time we're at step 5 we've discarded the first ":" and consumed the
b64 data, so the first character of input_string should be the final ":".

Either "do not serialize the field at all" means abort the algorithm at
this step, or emit an undefined value at the end. Your choice.

> serialization”, what input wouldn’t be considered as sequence of bytes?
UCS-2 is a sequence of 16-bit integer values.

> ** Section 4.2.  Editorial.  In step 8, s/Otherwise, return output./Else,
Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 May 2020 13:05:14 +1000

Hi Roman,

Thanks for the review. Responses below.

> On 21 May 2020, at 6:29 am, Roman Danyliw via Datatracker <[email-masked]> wrote:

As Matthew points out, tchar contains "*".

> but there is no such character.  It was discarded in Step 2.

As Matthew points out, we're now at the end of the data type, this is the final ":".

Step one being true effectively triggers an exception -- "do not serialise the field at all." 

> serialization”, what input wouldn’t be considered as sequence of bytes?

Besides Matthew's comment, it depends on the type system in use by the implementation; many have a dedicated way to indicate binary content.

> simple “IF x; IF y; IF z; …” statements.

The 'else's are necessary in 4.1 to group step 5 with steps 2-4 as  a set of alternatives. It's not necessary in 4.2 (or in many other places), so we don't use it.

> ** Section 4.2.  Editorial.  In step 8, s/Otherwise, return output./Else,

We use "otherwise..." in many places.

Cheers,

--
Mark Nottingham   https://www.mnot.net/