SF example parameter is confusing

[martinthomson]

The document currently uses the following example:

     Datagram-Flow-Id = 42; alternate=44

Motivating this with an example of how to express multiple flow identifiers.

I think that this example is potentially harmful. It implies a lot about a potential extension mechanism as part of an example, but does not commit to properly defining an extension. For examples like this I would much prefer to see something that is very clearly bogus. Otherwise, people might implement that to the point that they even achieve interoperability of a sort.

For instance, the following requires a lot more guessing about how to interpret it, to the point that I would guess that pseudo-interoperability would be hard to arrive at by accident:

     Datagram-Flow-Id = 42; camels-per-orthodoxy=17.4

See also #9.

[DavidSchinazi]

The goal of this example was to show a way to build an extension. A full example of this being used is the ECN extension to CONNECT-UDP. I'm not really sure how to improve this, because making it clearly bogus defeats the purpose. Could you provide a PR?

[martinthomson]

Maybe we should talk more about the spelling of the ECN extension, which I haven't reviewed.

I don't think that you should hide flow identifiers in this fashion. It prevents an intermediary from understanding which requests are actively using flow identifiers. A gateway might need to know that in order to ensure that DATAGRAM frames are consistently forwarded to the right origin server.

An alternative spelling that doesn't have that property would be:

Datagram-Flow-Id: 42; no-ecn, 43; ect0, 44; ecn-ce, 45; ect1

[DavidSchinazi]

To make sure I'm understand you correctly, are you suggesting a structured field list here? That would work, and actually in that case I'd suggest dropping the parameter on the first element to make this simpler.

Datagram-Flow-Id: 42, 44; ect0, 46; ecn-ce, 48; ect1

[martinthomson]

Yep, that's it. And I considered the same. No parameter works fine.