Hi Chris,
On 14/04/2016 17:54, Chris Newman wrote:
Right now we have 3 STS proposals: HSTS, SMTP relay STS and MUA STS
(DEEP).
HSTS described its extensibility model, but punted on actually
creating a registry. A registry covering HSTS would be useful because
there’s at least one limited-use directive in the wild in addition to
those in the HSTS base spec. MUA STS currently describes an
extensibility model and creates a registry just for itself. SMTP relay
STS is missing both an extensibility model and registry, although
Viktor has made a compelling case that we we want to be minimal on
SMTP relay STS directives (at least initially).
There are two ways to move forward:
1. Each protocol is responsible for it’s own extension model and
registry. This has the advantage of getting MUA STS done sooner, but
we’ll probably end up with 2 or 3 separate registries with some
redundancy and potential for semantic conflicts in STS directives with
the same name between protocols.
2. We create a combined STS registry that includes a
protocol-applicability field for each directive. Some directives would
be multi-protocol (e.g., max-age may be shared between HSTS and SMTP
relay STS), most would be single-protocol initially (that could change
later). One advantage to this approach is it gives us a place to
include some prose about why STS proposals are different and why
different applicability is important. But this would take a bit longer
and mean the WG would have another draft. This would make life
slightly simpler for SMTP relay STS as it would just have to describe
its extensibility model and point to the shared registry. If we do
this, I am willing to co-author the shared-registry spec and Jeff
Hodges (co-author of HSTS spec) is also willing to co-author the spec.
I lean slightly towards option 2, but we need a WG rough consensus to
pursue that option as it’s a fairly significant change to MUA STS.
Comments?
I think I prefer option 2 or at least I would like to see us try. I am
happy to help with this.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta