Subject: Re: comments on address selection API

From: Sebastien Roy <[email-masked]>
Date: Fri, 01 Aug 2003 19:59:41 -0400

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

[email-masked] wrote:
> There's no way to avoid that.   The user (individual running the
> application) can only ever express as much control as the application
> allows

That's true, but that doesn't necessarily mean that all applications
need to be made aware of the specific rules used in destination
address ordering.

> - 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).

That's true, applications can always be written to spite the user's
preferences.  Like you say down below, I'd choose not to use such
broken applications.  I'm not trying to suggest that we somehow devise
a way to prevent applications from making preferences.  I'm suggesting
that there needs to be a way to let users make their preferences, and
that I don't really see why applications would want to make
preferences in these two cases.  I don't strongly disagree with your
point of view, I just don't really see the need for this part of the
API as it's written.

> 
> You seem to want to legislate in favour of intelligently written
> applications that do things in wise and meaningful fashions

What do you mean by that?  I can't deny that I don't want idiotically
written applications that do things in stupid and meaningless
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.

I can't disagree with that.

> 
> 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 I would hope that if this API is implemented as currently written,
then there would be some way of overriding the application's default.

> 
> And yes, usually you do want the application to pick what is the best
> default for it

I can understand that in the context of temporary addresses, as those
were devised with specific applications in mind.  I don't see why one
application would want to default to using a tunnel interface while
another would default to using a native interface (for example).
Similarly, I don't see why one application would default to using a
global address while another would default to using a site-local for
the same destination.  I guess I don't see what problems those
applications would be trying to solve by using those conflicting
defaults.

> - "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.

Perhaps, but I'm having a hard time thinking of a real-world scenario
(or dreaming up a non real-world scenario) where that would be the
case with these two destination address ordering rules.

> 
> 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.

I would do the same if I were in that situation.  I would also find it
awkward that every application would each need their own separate user
interfaces to toggle these preferences.

-Seb

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------