Subject: [calsify] Errata for 6868 (parameter encoding)

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Jul 2015 14:13:57 -0400

Hi folks,
An error report was recently filed against RFC6868 
(<https://www.rfc-editor.org/errata_search.php?rfc=6868&eid=4374>). The 
error relates to how to decode something like:

FOO=^^n

The report suggests there is ambiguity in the spec about how that should be 
processed and I agree with that. The question is how best to address this 
problem. The two possibilities are:

1) A 3-pass approach where each pattern from the decode list in Section 3, 
is decoded. i.e., one pass to decode all the ^n patterns, another to decode 
all ^^, another to decode ^'.

2) A single-pass (left-to-right) approach where the first occurrence of a ^ 
character triggers a check of the next character for decoding.

I prefer #2 (as that is how I coded my own implementation, and from a 
parsing performance standpoint, I think is better than the 3-pass approach).

I'd like to hear from others who have implemented this spec and see which 
of the above approaches were used.

If we can agree on #2 then I will ask for the current errata to be rejected 
in favor of a new one that I will file with appropriate text to cover 
single-pass/left-to-right processing.

-- 
Cyrus Daboo

---

From: Marten Gajda <[email-masked]>
Date: Mon, 27 Jul 2015 20:26:53 +0200

I agree that #2 is the best choice. That goes in line with how '\' 
escaping is handled in general (BASH, SQL, C, Java, <you name it>, ...). 
Everything else would be very confusing and non-intuitive.

cheers

Marten

Am 27.07.2015 um 20:13 schrieb Cyrus Daboo:
> (<https://www.rfc-editor.org/errata_search.php?rfc=6868&eid=4374>). 
> The error relates to how to decode something like:
>
> FOO=^^n
>
> The report suggests there is ambiguity in the spec about how that 
> should be processed and I agree with that. The question is how best to 
> address this problem. The two possibilities are:
>
> 1) A 3-pass approach where each pattern from the decode list in 
> Section 3, is decoded. i.e., one pass to decode all the ^n patterns, 
> another to decode all ^^, another to decode ^'.
>
> 2) A single-pass (left-to-right) approach where the first occurrence 
> of a ^ character triggers a check of the next character for decoding.
>
> I'd like to hear from others who have implemented this spec and see 
> which of the above approaches were used.
>
> If we can agree on #2 then I will ask for the current errata to be 
> rejected in favor of a new one that I will file with appropriate text 
> to cover single-pass/left-to-right processing.
>

-- 

*Marten Gajda*
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: [email-masked]
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391