Hello Fisher, Thank you for your suggestions!
>From a purely structural point of view, representing transport security via the URI scheme could work, and that a single connect protocol combined with a URI template is a viable design. However, the current document intentionally keeps a distinction between http-connect and https-connect for several reasons: 1. Avoiding ambiguity in protocol interpretation. Allowing arbitrary schemes alongside a generic connect protocol introduces additional ambiguity (e.g., non-"http"/"https" scheme paired with "connect" protocol). By encoding the transport expectations directly in the protocol identifier, the configuration is more self-describing and easier to validate. 2. Operational and migration considerations. We expect many existing environments to migrate from PAC-based configurations, where cleartext CONNECT and TLS-wrapped CONNECT are treated as distinct proxy protocols. Keeping separate protocol identifiers makes this transition more direct and reduces the risk of misconfiguration during migration. 3. Deployment reality and client support. TLS-wrapped CONNECT is not as widely supported as cleartext CONNECT. Differentiating them at the protocol definition level allows clients to make an explicit capability decision without erroneously ignoring a scheme they don't support, attempting a connection and failing. When it comes to order of proxies, the current design is intentional and aims to separate proxy identity from proxy preference. When multiple proxy dictionaries share the same identifier, the intent is that they represent equivalent instances of the same logical proxy service. In that case, allowing (and expecting) clients to choose among them (using local policy, randomness, or other heuristics) enables natural load distribution without requiring the PvD to be dynamically generated or re-ordered per client. If a deployment requires strict, deterministic ordering (for example, primary/backup behaviour), the expectation is that those proxies be represented with distinct identifiers and that ordering be expressed explicitly in the rules that reference them. This also enables flexibility to provide a different proxy order for different proxy-match rules. Mandating that clients always select the first matching proxy with a given identifier would reduce flexibility for clients, constrain implementation choices, and make it harder to support simple load-balancing use cases without additional server-side complexity (such as dynamically shuffling proxy lists or issuing client-specific PvDs). Hope this helps. Best Regards, Yaroslav On Wed, Jan 7, 2026 at 4:43 PM Fisher Darling <fisher= [email protected]> wrote: > Hi all! > > Apologies for such a late email, but I wanted to chime in with some > thoughts on the draft. For some context, my team runs various privacy > preserving proxies, including a second-hop proxy in iCloud Private Relay (a > "Proxy B"), various single hop CONNECT proxies and finally some Oblivious > HTTP relays (and gateways). > > Overall the draft is great! It nicely defines and condenses some similar > structures we have in our own control-plane. I can see this being very > useful for our own tooling and for automatic configuration for our > customers. > > I have two minor suggestions: > > 1. First, consider removing the distinction between `http-connect` and > `https-connect` and combine the two into one protocol, `connect`. For > `http-connect` and `https-connect`, transport security is encoded in the > protocol identifier, whereas for the `connect-*` family of protocols, it's > encoded in the URI scheme. To me, the capability to provide TLS is a > question of the transport and not proxying protocol and adding a scheme is > sufficient to signal that. I suggest using a single protocol `connect` with > a `URI template` Proxy Location Format. Then with a note specifying that > only the scheme and host should be present. > > For example: > > A TLS enabled connect proxy uses `https://`: > ``` > { "protocol": "connect", "proxy": "https://proxy.example.org"; } > ``` > And one without TLS would use `http://`: > ``` > { "protocol": "connect", "proxy": "http://proxy.example.org"; } > ``` > > 2. Second, when multiple proxy dictionaries are present, I believe the > client SHOULD use the first proxy presented to it which satisfies the > client's requirements and then only move to the next satisfying proxy in > the event of failure. It is very useful to have a deterministic, > server-controlled method of determining what actions a client takes. If > clients always choose the first satisfactory proxy, it's much easier to > safely deploy breaking changes. > > More concretely, I suggest these edits: > - `should -> SHOULD` in: "If a matching rule contains more than one > identifier the client SHOULD treat the list as an ordered list." > - "Multiple proxy dictionaries can contain the same identifier value. In > this case, the client SHOULD choose the first proxy." > > Take for example a blue-green deployment of a proxy. ` > proxy-blue.example.org` and `proxy-green.example.org` run two different > versions of proxying code. Both proxies share the same identifier > `privacy-proxy`. > > The PvD would look something like this: > ``` > { > // other PvD fields omitted > "proxies": [ > { > "identifier": "privacy-proxy", > "protocol": "https-connect", > "proxy": "proxy-blue.example.org:443" > }, > { > "identifier": "privacy-proxy", > "protocol": "https-connect", > "proxy": "proxy-green.example.org:443" > }, > ] > } > ``` > > With deterministic client selection, we (the proxy provider) can know > based on this config that all clients should be using `proxy-blue` as their > primary proxy and only use `proxy-green` as a backup. To deploy, we can > drop the expiration time and begin sending PvDs with the `proxy-green` > proxy as the first one in the list. Then we slowly increase the percentage > of responses which have `proxy-green` be the first in the list while > watching health metrics. This way once 100% of PvD configs have > `proxy-green` as the first in the list, we can be fairly confident all of > our clients prefer `proxy-green` over `proxy-blue`. > > This is definitely a contrived example. Moving the traffic using > DNS/anycast/etc. is usually easier. However, the point is that breaking > changes in version-less configuration can be difficult to rollout across > all clients. Knowing that clients will use a certain configuration in a > specific order makes any breaking or risky changes easier to rollout, > especially around changes in proprietary keys. > > I'm happy to write some GitHub issues or PR if the language changes if > that's helpful for further review :) > > In any case, thanks for reading my email and thank you all for the efforts > on this draft! > > All the best and happy New Year's, > - Fisher > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
