On Sat, 2006-07-22 at 13:43 -0400, Tony Hansen wrote: > Barry Leiba wrote: > > All of these in Doug's latest note seem like reasonable changes. Only > > one thing: > > > >> The RFC2822 FWS ABNF definition carries some cruft. > >> > >> obs-FWS = 1*WSP *(CRLF 1*WSP) ; obsolete RFC822 text > >> FWS = ([*WSP CRLF] 1*WSP) / obs-FWS > >> > >> Is there a reason to permit multiple CRLFs? To obsolete support, the > >> definition should be removed after 5 years of being declared obsolete. > >> > >> FWS should be redefined as Revised FWS such as: > >> > >> R-FWS = ([*WSP CRLF] 1*WSP) ; revised > > > > I'd rather leave the FWS definition in RFC2822, rather than putting in > > our own. Is there a way to say something that means "FWS from RFC2822, > > but NOT obs-FWS"? > > No, you either get all or none. > > I personally have no problem with pulling in the full definition of FWS > from 2822. As long as there are 822 producers out there, we should be > able to accept their headers.
This definition will not affect the handling of other headers. This definition is limited to the creation and parsing of headers associated with DKIM. Oddly, FWS also affects the parsing of the key as well, as the general template was used to define the key. Simpler seems like the better choice. There does not seem to be a valid reason to permit the use of the obs-FWS definition. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
