fix(session.ProxyConfiguration): make it a group to allow group choices

[christian-bromann]

As we have established in similar PRs, group choices can only be done with groups, not maps.

This is similar to other places in the spec, e.g.:

• BrowserCommand
• BrowsingContextCommand
• BrowsingContextEvent
• etc.

---

Preview | Diff

[tidoust]

group choices can only be done with groups, not maps.

I don't understand what makes it impossible to turn the resulting group into a map directly. Where does RFC8610 suggest that this cannot be done?

Looking at existing RFCs that use CDDL, I don't see the exact same pattern but some constructs use group choices within the definition of types:

• in RFC8727, for example the definition of STRUCTUREDINFO
• in RFC9581, the definition of Period (group choice within a map within a tag).

[christian-bromann]

Where does RFC8610 suggest that this cannot be done?

I've observed the following areas that indicate that maps can't contain group choices:

📘 RFC 8610, Section 3.5 — Groups in Maps and Arrays

When a group is used as a member of a map, the entries in the group are included at that location in the map.

This means: maps accept groups, and groups contain entries. A group choice like A // B is a kind of group — but you must wrap it into a group context and then inject it.

📘 RFC 8610, Section 3.9 — Group-to-Group Composition

This section introduces the // operator:

The operator // is used to express a choice between groups.
The right-hand side of the operator must be a group.
It is used only in the context of a group expression.

🔗 RFC 8610 §3.9

Implication: // is only allowed inside a group, not at the map-entry level.

📘 Formal Grammar (Appendix A)

In the ABNF grammar:

group-entry = [occur] [memberkey [type]] /
              [groupname [genericparm]]
group-choice = group-entry *(S "//" S group-entry)

And for maps, the structure is:

map = "{" [group] "}"

This confirms:

• A map contains a group.
• A group contains entries.
• A group choice can appear only as a top-level group expression, not within an entry.

---

• in RFC8727, for example the definition of STRUCTUREDINFO

I would argue this is incorrect as well.

• in RFC9581, the definition of Period (group choice within a map within a tag).

This is correct use of group choice as Period is a group (( ... )).

---

I agree that this limitation is not explicitly mentioned in the CDDL spec, though the ABNF grammar supports this. Regardless I suggest we keep the same "style" how we define group choices within the WebDriver Bidi spec and so far we don't use it within maps at all.

[OrKoN]

I think with this change we will be loosing the type information for the proxy field in session.CapabilityRequest. Instead, I think we can wrap the group choice into an extra () to make sure it is a group.

[whimboo]

I think that looks fine. @OrKoN do you have any other feedback?

[OrKoN]

@christian-bromann in the RFC 8610 I see that group = grpchoice *(S "//" S grpchoice) which indicates to me that a group can consist of a group choice and does not need to be wrapped into ().

[tidoust]

@christian-bromann in the RFC 8610 I see that group = grpchoice *(S "//" S grpchoice) which indicates to me that a group can consist of a group choice and does not need to be wrapped into ().

That's my reading as well. A group choice like A // B is not "a kind of" group, it is a group and can be used wherever a group can be used. On top of the grammar, the CDDL spec notes that equivalence between a group and a list of group choices in section 2.1.2 which defines the syntax of groups:

A group definition can also contain choices between groups

That same section clarifies that parentheses are optional:

The start and end of a group can be marked by "(" and ")"

Also see section 2.1.1 that clarifies that inline definitions of groups are doable:

It is a matter of style in defining those structures whether to define groups (anonymously) right in their contexts or whether to define them in a separate rule and to reference them with their respective name (possibly more than once)".

[tidoust]

Side note: @christian-bromann, your RFC8610 quotes don't seem to match the contents of the published RFC. For example, section 3.9 is not group to group composition, I don't see the text you mention in the RFC, and the grammar terms and definitions are different. Could the text you quoted come from a previous draft, perhaps? And could that explain why we read things differently?