[ietf-dkim] Srsly.

[Dave Crocker]

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.

d/


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.
> 
> --
> J.D. Falk
> Receiver Products
> Return Path 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net