Barry Leiba wrote: >> So I'll ask it this way, starting a new thread for it: >> I determine from discussion that there's enough support for >> deprecating "l=" to qualify as rough consensus *if* there's not much >> objection to it. �It's the objection we need to gauge. �Please post to >> this thread if you object to deprecating "l=" in 4871bis. �You may say >> why you object, but please keep it brief, and let's not have a lot of >> discussion of it here. �If there's enough objection to derail >> deprecation, we will leave it alone. > > That was quick. I believe we already have enough objections to say > that we do NOT have rough consensus for deprecating l= at this time. > I'll close the issue in the tracker (issue #26), and we will leave it > as it is. > > Of course, folks may, if it makes them feel good, continue to register > objections here. > > :-D
But that still shouldn't mean the functional and technical informations should not be clarified. Maybe the "two weeks or so" can be used to do that? To me, the basic issue is that "l=" consideration is not isolated to itself - other factors such has what headers to sign, reducing message content complexity, removing items that could be stripped for security purposes (i.e. HTML), etc, all ideas that basically mean "Know Your Target!" If we can describe it better, then maybe we can give the readers the benefit of the doubt they may decide themselves its not needed for their purpose and implementators a better idea how to expose the option to operators. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
