On Wednesday 23 January 2008 19:39, Dave Crocker wrote: > J D Falk wrote: > > Jon Callas wrote: > >> SSP is an important, valuable, *optional* part of the email > >> infrastructure. > > > > This is a very important point. When the draft says "MUST," an > > experienced i-d reader will know that it actually means "x must do y in > > order to comply with this specification." That's not so obvious for > > other humans, especially when pretty much all of the conversation on > > this list also has the inherent assumption that SSP will be everywhere > > for everybody. > > > > There will be entirely valid use cases for which SSP will not be useful, > > and may even be damaging. Ellen's is one of these: she's probably going > > to have to change her entire business model as SSP adoption grows. In > > our discussions -- especially with people who aren't fluent in the > > ancient & dusty IETF vernacular -- we MUST remember that SSP will never > > and can never be any stronger than a SHOULD. > > > JD, > > 1. Yes, folks often forget that the premise to a standard is "IF you > embrace this standard, THEN various normative assertions apply. IF you do > not, then they do not." So all the musting and shoulding are strictly in > the context of those who have chosen to adopt the specification. > > 2. Your second point says that there should be an 'applicability statement' > for SSP, to clarify the scenarios in which it makes sense to use and the > ones it does not. >
I think he said there will be cases where it's not useful. I don't seen anything in that statement where he says we should engineer out exactly what those cases are. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
