On Oct 14, 2010, at 4:27 PM, Cullen Jennings wrote:
3) The backwards comparability issue seems huge. Some people have said an
endpoint using this draft will not talk with one that only does 4975. Yet if
this draft if published as an RFC would basically depreciate the 4975 and
replace it with a the result of applying this diff to 4795. So if one person
implements the pre update version, and another person the post - it's not
clear to me how we migrate from old to new on the existing deployments. A
flag day is obviously not going to work. The more I look at this, the more I
think this draft needs to be recast as a backwards compatible extension to
4975 and not a draft that update 4975. When I look at how this changes 4975
it seems to mostly relax the existing security but not disallow things that
used to work so I think it should be possible to do this. On a side note, I
phoned a few people who I know that have MSRP implementation and none of them
had any plans to implement this and were surprised to hear there was a draft
th
at would update in 4975 with a change like this. To me this combined with the
no backwards compatibility issue argues strongly for figuring out how to make
this an extension instead of a change to MSRP.
Who were those people?
Everyone I've talked to not only knows about it, but has implementations.
(though in most cases implementations of the original acm proposal... they're
waiting on an RFC before changing again) Though I will concede my list of
vendors to ask this of is by nature going to be prone to doing this, since I
talk to folks to interop with and my systems implement acm as well.
As for the flag-day issue, in theory yes, I think it would require a flag-day
if there were a large population of legacy 4975 trying to talk to a population
of this extension. In practice, that hasn't been necessary afaict. The
domains that use full app server MSRP relays, a la 4975, have the ability to
interwork to an acm-style model in that app server; the domains that don't have
such app servers don't have a problem to begin with, since they had to use an
acm approach to not need to have app servers.
4) When I search the email lists, I find more more people who see significant
problems with this than I find people that seem to think it is OK. I don't
think it has consensus -I think it just has people who stopped care. The
changes that needed to happen in IETF LC to fix this draft so it had any
chance of working at all more or less convinced me the WG did not read this
draft. The ietf(_at_)ietf(_dot_)org list is not an ideal location for
discussion that rewrites pretty much all of the normative text of this draft
(which is what is happening here).
I personally stopped caring when implementations of draft-acm showed up and the
problem was "solved". In some ways this fits in quite nicely with the recent
discussion on ietf(_at_)ietf about taking too long with RFCs and making their
bar very high, and people deploying drafts instead.
-hadriel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf