Subject: [spfbis] On deprecated things

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 12:13:49 -0700

We have Section 1.3.5 that defines what it means for an SPF feature to
be deprecated in the context of this document.  I think it would be a
good idea in terms of setting reader expectations to list the things
that are deprecated in a bullet list in this section.  That way, when
readers run into them, they understand the material is something
that's likely to go away soon/later/whenever/something and can plan
accordingly.  It also provides a good early summary for those already
familiar with RFC4408.

Given that we're not able to get rid of macros outright despite their
very low usage until a later version of the spec, I submit that macros
should also be on that list.  My understanding of the technical
discussion is not that removing them would be a bad idea overall, but
that removing them now is simply not permitted.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 22 Aug 2012 12:55:56 -0700

>that removing them now is simply not permitted.

I would have to discuss the matter with Andrew to provide a formal 
answer.  Informally, I don't want to go down that rabbit hole.  I 
will push back on any attempt to push me down a rabbit hole.

Regards,
S. Moonesamy
SPFBIS WG Chair

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 18:31:40 -0400

> accordingly.  It also provides a good early summary for those already

I think this makes sense.  Once it seems like we have a final list of what will 
be marked deprecated I'll be glad to add it.  Feel free to remind me if I 
forget.

> that removing them now is simply not permitted.

I'm not aware of any technical specific technical issues with macros that would 
cause us to do this.  OTOH, if we do, we are not just deprecating specific 
functions within the protocol, but deprecating functional capabilities such as 
per-user policies, logging specifics of remote SPF checks to support deployment 
verification and others.

I know a number of people want macros removed (and if not removed deprecated) 
because it would simplify the protocol.  Given that there are protocol 
features that cannot be accomplished without macros, I don't think this is a 
sufficient argument.

Scott K

P.S.  In our last go-round on macros there was one mention by someone of a 
macro related implementation defect.  I had an off list dialog with the vendor 
in question and the issue wasn't related to macro processing.  It was related 
to the way they implemented processing limits.  It was just coincidence that 
an error occurred during macro processing.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 17:02:18 -0700

> per-user policies, logging specifics of remote SPF checks to support deployment

I think given the usage statistics, that's making some presumptions of
what the users of macros are getting out of it.  Since I have those
data, I'll ask them and hopefully that will provide some insight.
Could be that they'd be fine without.

> features that cannot be accomplished without macros, I don't think this is a

It's true that the functionality can't be replaced, and it's a clever
idea, but that doesn't mean it's actually needed.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 Aug 2012 19:22:47 +0200

> be marked deprecated I'll be glad to add it.  Feel free to remind me if I 

+1, IMHO it should be a subsection of Appendix C (Change History),
when we'll clean it up and rename it Changes since RFC 4408...  Is it
worth adding a ticket for this in the datatracker, as a reminder?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Aug 2012 11:06:17 -0700

> worth adding a ticket for this in the datatracker, as a reminder?

That would defeat the stated purpose of putting a summary early in the document.

-MSK