[For folks who aren't aware, we just had an intense three day hackathon in
Oslo during which about a dozen of us tried to hash out new TAP extensions and
write some sort of well formed spec. We got a lot done, but didn't have quite
the clean resolution I was hoping for. Afterwards I had a
* Michael G Schwern [EMAIL PROTECTED] [2008-04-11T07:01:19]
Here's the descriptive way to specify how the diagnostic keys work.
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
I thought this had been the
On Apr 11, 2008, at 03:59, Michael G Schwern wrote:
Quite rapidly everyone shifted over to thinking that we should only
allow
X-foo for user keys because it's unambiguous. Then we don't have
to worry
about characters that don't have an up/down-case concept. And we
can eyeball
a user vs
On Apr 11, 2008, at 06:13, Ricardo SIGNES wrote:
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
I thought this had been the resolution. I hope it *is* the formalized
resolution. It is simple and easy and leaves
Michael G Schwern [EMAIL PROTECTED] writes:
Here's the descriptive way to specify how the diagnostic keys work.
1) We reserve every key which begins with a lower case letter
2) We say nothing about anything else
3) All keys are optional
How about reserving a prefix for TAP related keys
Steffen Schwigon wrote:
How about reserving a prefix for TAP related keys and allow/ignore
everything else?
Explained in another way:
a prefix lowercased tap- for TAP
Thumbs down from me. You don't see HTTP headers having to prefix all of their
labels with 'HTTP-' or email headers
Michael Peters [EMAIL PROTECTED] writes:
Steffen Schwigon wrote:
How about reserving a prefix for TAP related keys and allow/ignore
everything else?
Explained in another way:
a prefix lowercased tap- for TAP
Thumbs down from me. You don't see HTTP headers having to prefix all
of
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
A see. But TAP isn't SMTP or HTTP and an explicit prefix matches the
be descriptive of Schwern, doesn't it?
And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we
