Markku
>
> > From: JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]>
> >
> > 1. try to realize the full flexibility about the header chain; the API
> > allows applications to specify any combination of headers (in any
> > order).
> > 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 like 1. It's simpler, easier to implement and document. Nice generic
> and dumb API.
>
Easier only if one doesn't have existing software which implements and uses
the current API along with documentation that documents the current API.
If one does have existing code and documentation then 1. just looks like
double the work and headaches for one's customers.
Note that the current Advanced API is not less than the second major
revision of this API. For those of us that had the pleasure of implementing
the last major revision four or so years ago and then throwing it out,
1. seems like complete insanity.
> To me it seems to be more work, if you have to define, implement and
> document every possible extension header separately in the API (as 2
> will require).
>
This would be true if it were possible to add a new extension header type
without modifying the kernel. It isn't really possible in the implementations
I have seen so there really isn't any flexibility gained by throwing out
the existing extension header API. New extension headers will require
kernel modifications. Once kernel modifications are required, adding API
hooks to deal with the new extension header is straight forward.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
