Date:        Wed, 30 Jul 2003 13:27:26 -0400
    From:        Sebastien Roy <[EMAIL PROTECTED]>
    Message-ID:  <[EMAIL PROTECTED]>

  | My initial though when I
  | saw these preferences was that we should be giving individuals running
  | applications the control, not individuals writing applications.

There's no way to avoid that.   The user (individual running the application)
can only ever express as much control as the application allows - burying
things in libraries only makes it more difficult for the application to
override, it doesn't prevent it (even to the extent of the application
ignoring the standard library routines, and doing things its own way if
the libraries insist on doing things the application doesn't like).

You seem to want to legislate in favour of intelligently written
applications that do things in wise and meaningful fashions - that
doesn't work at this level, all that can ever be done is to attempt
to get the users to prefer to use applications that work in ways
that make sense to them.

Allowing applications to set flags to control the address choices from
the library routines seems sensible to me - this doesn't mean that this
needs to be the only input to the address selection choice that an
implementation provides.

And yes, usually you do want the application to pick what is the best
default for it - "environmental controls" are usually much too crude
a control for this purpose - that is, it isn't the case that every
application should behave the same, for connections from host A to host B
for some applications one address choice is better than another, for
other applications the answer comes out exactly the other way around.

When I, the user, know better, I'm going to want a way to override the
application's preference - and if the application doesn't provide that,
I'll either fix it, if I can, or perhaps work around  it (add new names
in the DNS that only provide a subset of addresses...) or if none of
those is possible, just avoid using the application concerned.

kre

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to