> 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. 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). -------------------------------------------------------------------- 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] --------------------------------------------------------------------
