In <428C4460(_dot_)5E7F(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Minor stuff from my POV:
[23:38]
<grumpy> 2338:u no
<Julian> 2337u: yes
<csm> 2337u: no
<MarkK> 2338u: yes
<csm> muahahahahahaha
TILT. MarkK tilted the Council flipper. In theory you're
supposed to reflect the Community will, not to play flipper.
First off, thanks Frank for this review. I think it is very important
for people to give us (the SPF council) a reality check.
That said, I disagree with you on this particular issue. Yeah, in
general, especially on political stuff, the SPF council members are
supposed to reflect the SPF community. However, in the case of the
I-D, we are trying to resolve technical issues. So far, all of the
I-D issues sent to the council for rulings are ones that I think
reasonable people can disagree on and often there is *no* good choice.
The council was created to try and give a final ruling and cut off
endless debates.
In this particular case of I-D rulings, I think that council members
basing their votes on their technical understanding is more important
than basing votes on their understanding of the SPF community.
[23:44]
<grumpy> "sign", however, is a bad name
Still the best idea after "prefix" was sent to lala-land.
And what was that idea?
[23:46]
<Julian> Anything that's semantically descriptive is fine
with me. That includes "result" and "match-result",
although the latter is not very elegant.
While "result" is elegant, it's a term in the Receive-SPF ABNF
with values like "Pass", "Fail", etc., but not "+", "-", etc.
Overloading terms in a spec. is an odd idea, stick to "sign",
or try "result-prefix" <shudder />
I don't like "sign" because ~ and ? are not signs. Maybe "indicator"?
Personally, I don't see this as a huge issue and I don't think we
should hold up the I-D because of it.
-wayne