> On Thu, 7 Jan 2010, [email protected] wrote:
> >
> > > I agree with Cyrus. Even if the market has reached a workable compromise
> > > for the time being by using well-known host names, it has done so at the
> > > cost of flexibility which SRV records could provide. I think it would be
> > > very useful to document the naming conventions that will allow current
> > > clients to find the servers, but I don't believe that's a reason to *not*
> > > document a more robust and formal SRV record protocol as well in the hope
> > > that clients and configurations will move to that.
> >
> > Exactly right IMO.
> Thanks for all your arguments. I have been convinced. Perhaps I should be
> less negative about the likelihood of deploying improvements...
> > I also fear that an effort to do something more elaborate with XML and web
> > servers and so on carries with it a very high liklihood of failure, and
> > even if
> > we manage to agree on something (probably at some distant point in the
> > future),
> > it will then fail to deploy.
> Actually I'm less negative about this because it has clearer benefits.
My concern arises not from a lack of benefit - the benefits here are pretty
clear - but from the fact that when you go this far you're necessarily engaging
in a schema design exercise.
The past history of schema design work in the IETF has not been good. Partial
or even total failures are pretty common, and even when such efforts succeed
they have tended to take far more time than anyone expected them to.
> For
> example it allows an operator to override an MUA's built-in preferences.
> The big question is whether we can get the various MUA vendors to
> co-operate instead of continuing to do their own thing.
Yes, that's also an issue.
Ned
