> > The psychological benefit of the two flags is that we don't have to choose
> > the default; we can say that any application which has an explicit preference
> > should always invoke the API to state that preference.
>
> I don't follow. This is true regardless of whether there is one bit or
> t
On Tue, 2003-03-25 at 14:17, Erik Nordmark wrote:
> > And if the application specifies both "X" and "not X"?
>
> That would be an error.
Exactly. The kernel needs to test this and return an error ==> bloat.
> So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC?
PUBLIC is the obvious
> And if the application specifies both "X" and "not X"?
That would be an error.
> > An alternate API would be to have one flag per property and always require
> a > get before a set.
>
> I think I would prefer this approach. This is clean, no special cases,
> and allows simple checking of syst
On Mon, 2003-03-24 at 12:42, Erik Nordmark wrote:
> Thus not specifying either of "X" and "not X" leaves the "X" property of
> the address selection at the system default.
And if the application specifies both "X" and "not X"?
In a classic adventure game by Douglas Adams the ability to do this
w
> This is not really true. We can also specify the source address by
> the IPV6_PKTINFO socket option or ancillary data item defined the
> advanced API. This does not matter much, though, because we still
> need to specify a particular source address.
Good point. The issue is that the existing A
> 1. Introduction
>
>Currently IPv6 socket API extensions does not provide a
>mechanism to choose a particular source address other than simple
>bind() operation.
>
> This is not really true. We can also specify the source address by
> the IPV6_PKTINFO socket option or ancillary d
I have some comments on draft-chakrabarti-ipv6-addrselect-api-00.txt,
in addition to those already raised in this list (I'd apologize in
advance if there's any duplication).
1. Introduction
Currently IPv6 socket API extensions does not provide a
mechanism to choose a particular source addr