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

[Mark Nottingham <[e-mail]>]

Hi Roman,

Thanks for the review. Responses below.

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

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

As Matthew points out, tchar contains "*".

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

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

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

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

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

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

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

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,
> return output./

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

Cheers,

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