> | My initial though when I > | saw these preferences was that we should be giving individuals running > | applications the control, not individuals writing applications.
[EMAIL PROTECTED] 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 PROTECTED] --------------------------------------------------------------------
