-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was asked to supply a list of "open issues" that it would be useful to
discuss at the Vienna meeting
Removal of null recipes for headers
ie: you always have to document what you changed
this considerably simplifies DSN handling, and it seems fanciful
that systems in the middle of the network are altering headers at
all, let alone in ways they are do not wish recipients to be able
to undo
Should we explicitly forbid Message-Instance headers that only differ by
ordinal value
The spec has some MUST NOT's here but all they do is heat up the
planet, they don't actually cause interworking issues
PQ Algorithm
The chairs are going to ask for advice and we have had a discussion
on how that question should be phrased. Stephen Farrell suggested
just insisting that all signatures MUST pass (but long ago the WG
disliked that so we have a SHOULD at present)
Case issues in JSON
should we insist that header field names in the recipe JSON always
be in lower (or indeed UPPER) case ?
DSN flagging
Should we provide an explicit way of labelling DSNs (prescribing a
Subject header field, or adding a flag?) rather than having MTAs
work it out from the context (and what email address is being sent
to).
Feedback
the specification has a framework for asking for feedback but stays
away from saying what that means. Does the WG think there are
things to standardise here ?
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBalAeLmHfC/FfW545EQJGXACaA6tT8FFhm3mruIDjhuabskzUkA8An0iK
loI838x8XKPGyZYzRW0GSWlJ
=p63v
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
