In your previous mail you wrote:
Making to these deadlines seems like a bad idea if the consequence will
be that we split off content that will then be completely and unnecessarily
redesigned thus rendering piles of existing code obsolete.
=> unfortunately the redesign is *not* unnecessary: the header order
specified in RFC 2460 was misinterpreted as mandatory and the advanced API
has not the needed flexibility. I believed the flaw was in RFC 2460 but
Steve Deering proved it is in the advanced API:
(from proceedings of San Diego 49th IETF meeting)
> Deering asked why speaker said the destination option was a "nightmare".
> Dupont: because that the destination header can occur at different places.
> Deering answered that this is the way that IPv6 was designed. Dupont
> doesn't think that this freedom is useful.
>
> Zill: We should design the API around the protocol, not the protocol around
> the API.
>
> Deering: Important to keep flexibility to allow new uses as new applications
> are conceived/developed. Deering does not understand the need for this
> approach. Dupont want there to be more structure in destination header
> placement.
>
> Bound: Also doesn't think we should change the protocol to match the API.
>
> [Editor: ran out of time, stopped presentation/discussion, but there didn't
> see to be much support for this proposal]
The draft has languished for two plus years I think.
=> this is a real problem we'd like to fix ASAP.
Rather than continuing with this meta discussion, why don't we move on to
the meat of getting the issues addressed.
=> I agree we have to put more into the real thing than into the way to do it.
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]
--------------------------------------------------------------------
