An additional suggestion is to provide the registry entry for SMTP
Authentication. This serves two purposes: registers the value, and gives
an example of what a registry entry would look like.
In addition to the ptype and property values for a headerspec, it would
be appropriate to indicate the type of identity that can be expected:
hostname, username, etc.
Also, additional information for an authentication method would be
whether policies are part of the method, and which of the set of pass,
fail, softfail, neutral, temperror and permerror are to be expected.
Tony Hansen
tony(_at_)att(_dot_)com
Tony Hansen wrote:
In section 7, it says:
7. IANA Considerations
Following the policies outlined in [IANA-CONSIDERATIONS], names of
sender authentication methods supported by this specification must be
registered with IANA under the IETF Consensus method, with the excep-
tion of experimental names as defined above.
This needs to be beefed up more. What's the registry look like? There
should be specific recommendations on the information that a document
associated with an authentication method needs to provide. Obviously
there's the name of the authentication method. How about the ptype
values appropriate for this method? Or the property values that are
appropriate for this method?
I suggest adding a form that an RFC for an authentication method can
fill in as part of its text.
In addition, this document specifies the Authentication-Results header,
which needs to be registered in the mail header registry.
If section 5.1 is kept intact, then this document also specifies an
incompatible use of the Priority header that needs to be added as part
of the Priority definition in the mail header registry.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html