Hi Damian! I'm trying to make this work under your suggestions, but I'm not entirely clear how. Can you help me get this in shape to pass your muster?

Hi Virgil, I'd be glad to! Adding tor-dev@ back in case others have thoughts on the details. I like your idea, what I was trying to hint by asking about the motivation was that the proposal should clearly explain why we're doing this (with example use cases).

As for detail, I mean the proposal should have text we can copy and paste into the dir-spec. Maybe something like...

============================================================

The following would be added to section 2.1.2 of the dir-spec (Extra-info document format):

"X-" CustomKey SP CustomValue NL

CustomKeyChar = ALPHA / DIGIT / "_" / "-" CustomKey = 1*20 CustomKeyChar

CustomValueChar = atext / SP CustomValue = 1*200 CustomValueChar

Custom field that can appear multiple times, for example...

X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar

A CustomKey cannot appear more than once, and there cannot be more than ten of these entries.

============================================================

As a controller library author what I want from proposals is enough detail so I know *exactly* how to parse new additions. There's lot of potential edge cases. Can values be an empty string? How about keys? What should we do if a key appears multiple times? Is that valid? You mentioned a 5 KB limit, is that per option or for all custom fields?

Rather than a size threshold, in the above I'm proposing a limit of ten entries each of which can be at most 220 characters. That would only be 2 KB so feel free to tweak these limitations.

I'm not entirely sure 'atext' is what we want here. This would exclude tabs, but maybe that's not such a bad thing. You can look it up on...

http://www.ietf.org/rfc/rfc2822.txt

Cheers! -Damian