Hello Watson, Thank you very much for reading the draft and your feedback!
1. We have added more specific references to RFC 8801 in https://github.com/tfpauly/privacy-proxy/commit/086eb1bea98fb23e37aa3c91512014e8d8e55edf Does this address your first point about linking directly to Section 4.3? 2. Regarding the use of underscores for vendor-specific keys: our choice was motivated by ease of processing and consistency when converting JSON keys into common scripting and configuration formats. While RFC 8801 defines the "vendor-" prefix, it also requires clients to ignore the entire sub-dictionary if an unknown key is encountered. For proxy configuration, that restriction is too limiting, as described in the draft. Hence we opted for an alternative that balances extensibility with deployability. 3. Would https://github.com/tfpauly/privacy-proxy/pull/299 address your concern? In addition, based on this work and past operational experience with PAC files, I have also put together a separate proposal (draft-rosomakho-httpbis-outdated-proxy-config) to address the problem of outdated proxy configurations in a more robust way than fixed expiry times. Best Regards, Yaroslav On Thu, Aug 28, 2025 at 5:41 PM Watson Ladd <watsonbl...@gmail.com> wrote: > Dear all, > > While I have not been following this draft very closely (perhaps a > benefit) I've decided to give it a read, and I've come up with some > comments, some minor, some major about various bits of confusion I > faced in trying to understand it. First, there's the reference to PVD > Additional Data: perhaps we want to link directly to section 4.3 of > RFC 8801, and not just the whole thing. I don't actually know if RFC > XMLv3 can do this, but worst case we can edit the text to include > (section 4.3) or even (section 4) after the reference. > > My second question is about the way keys are reserved for > vendor-specific extensions. The rule in RFC 8801 for marking these is > to start them with "vendor-". This draft uses the underscore > character. I think that's unfortunate. First because it's different > from how the keys in the same JSON structure need to be analyzed up > one level, and secondly because it means we have to introduce a > hierarchical structure through some other character for any new keys > we might introduce. These are minor quirks, but I'm not sure why we > need to step into them. > > Lastly it might be worth reinforcing that the PVD data applies to all > the proxies listed, and doesn't need to be refetched (except as expiry > comes up) when connecting. This is true if you read through the > references to the PVD RFC and the PVD Additional Data RFC, but I think > it would help the reader to pull that out here. > > Sincerely, > Watson > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org > -- 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 -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
