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

On Thu, May 21, 2020 at 6:36 AM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

>
> (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.
>
>
tchar contains "*" <https://tools.ietf.org/html/rfc7230#section-3.2.6> so
step 3.1 passes.


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



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


> ** 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?
>
>
UCS-2 is a sequence of 16-bit integer values.


> ** 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./
>
>
Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/