hspow: Clarifications to scheme and descriptor Item

1. Fix inconsistent terminology
2. Clarify handling of unknown schemes
3. Declare that a future pow-params can have an object

IDK whether C Tor currently permits an Object in an unknown pow-params. IMO if it doesn't, that is wrong; it seems logically sensible to permit an Object here.

Noticed these ambiguities reviewing arti!2026 (closed), which answers Q3 the other way. I will make a review comment there.

CC @beth @dgoulet

assigned to @Diziet

requested review from @ahf

added 2 commits

• 47d26df1 - Use "scheme" terminology in INTRODUCE1 pow
• 7d9b8f56 - Cross reference from INTRODUCE1 to pow-params

Compare with previous version

See also #256 (closed)

Beth's the expert here -- putting her as reviewer.

requested review from @beth and removed review request for @ahf

added 8 commits

• 7d9b8f56...81942fbb - 2 commits from branch tpo/core:main
• 9fedec9a - hspow: Use consistent terminology for hspow schemes
• 8e2b91f1 - Specify client behaviour for unknown hspow schemes.
• b002913a - Explain precisely how a pow-params might vary by scheme
• 4cedc475 - Use "scheme" terminology in INTRODUCE1 pow
• 4ef958b0 - Scheme: clarify where scheme variation occurs
• a2b18281 - Cross reference from INTRODUCE1 to pow-params

Compare with previous version

Rebased over !253 (merged) to fix conflicts

Looks good to me, thanks! I like the "scheme" naming, it makes more sense than the version/type number/string ambiguity before.

Re the object as a parameter: I think that should definitely be allowed in the spec. Right now c-tor's parser is fully inadequate for the general pow-params format, it's only prepared for a single instance with 4 args and no object.

approved this merge request

mentioned in commit bb4c1416

merged

mentioned in issue tor#40920

mentioned in merge request arti!2026 (closed)