The working group has just decided the flawn is not in the specs but
in the advanced API then either:
- or we found a good way to encode positions (I have no idea of how)
- or we arbitrary restrict the advanced API expressiveness to
some common cases (as it is done today but we already need to
add a new position for destination option headers).
As I don't know if the first goal is possible to archieve I suggest
to go to the second if no progress is done before a reasonnable delay.
Regards
[EMAIL PROTECTED]
PS: I believe my proposal will be still useful for the names
(not of headers but for positions). Of course other points are
still valid (and according to Steve Deering, it is legitimate
for a new application to use an existing header in a new position,
so mobile IPv6 doesn't violate RFC 2460).
PPS: current advanced API uses IPV6_[RECV]DSTOPTS/IPV6_[RECV]RTHDRDSTOPTS.
According to Steve this is wrong but he has not yet proposed something else.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
