In your previous mail you wrote:
I've just read the previous discussion. It seems to me that we've
basically reached a consensus for the receiving side; obsolete the
IPV6_RECVRTHDRDSTOPTS option, and let the kernel send all headers (if
requested) to applications in the receiving order.
=> we still need a format to do that (easy but this is missing).
For the sending side, which would be the difficult part, I think we
have two possible approaches.
1. try to realize the full flexibility about the header chain; the API
allows applications to specify any combination of headers (in any
order).
=> this is the only reasonnable option in the long term.
2. only loosen the restriction about destination options headers;
(e.g.) add another ancillary data type/socket option to specify the
relationship between a destination options header and a fragment
header.
=> I believe the issue has to be solved, a quick & dirty hack shan't be
enough next time.
If we're aiming at the 1st goal, I'm quite sure that we'll need much
time to discuss it and reach a consensus. So, in this case, I'd like
to separate this part from the "basic" part of the advanced API (as a
separate draft).
=> I agree. And of course we'll need time to implement and experiment
proposals.
If we take the second approach, it might be possible to get a
consensus in a relatively short period. So, it would be worth trying
to keep the whole spec in a single document.
=> the discussion about header order showed clearly that we need
some freedom. Only a major change in the API can give this.
As for no.1 vs no.2, I'm inclined to support no.2. Due to less
flexibility, of course, we may see another ordering issue in the
future.
=> I think this will happen so I don't believe in the no.2.
However, at least at this moment, I don't see a possibility
to use an extension header (except destination options headers) in a
different way than the recommended way specified in RFC 2460.
=> security headers...
And, with this approach, we might be able to avoid rewriting existing
applications that already use rfc2292bis for some extension headers
=> I know only telnet (routing header) and some specialized applications
(MLD, traceroute6, ...). This doesn't seem to be a real problem (less than
to keep the current advanced API).
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
