>>>>> On Wed, 21 Aug 2002 10:32:12 -0400,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
>> I agree. How about this (which is a total rewrite of abstract):
(snip)
> Works for me!
Okay, I'll replace abstract with the proposed one.
>> Are you suggesting to add the POSIX standard in References explicitly?
>> Or are you suggesting to check the latest version of the standard and
>> to rewrite the text accordingly (if necessary)?
> Definitely suggesting the first.
Okay. I'll do that like in the basic API draft.
> I'm asking about the second. I wonder, for example, whether someone
> familiar with the POSIX/Austin Group work has reviewed the document.
> My concern is that there may be some fairly trivial inconsistencies
> with this document and the basic API. It would be nice to try and fix
> those (if they exist). Can anyone speak to this point?
Hmm, I think there are no more "trivial" inconsistencies, but I'll
hear from others for a while.
> Generally looks good, but I might reword it a bit as:
> This document updates and replaces RFC 2292. This revision is
> based on implementation experience of the RFC 2292, as well as
> some additional extensions that have been found to be useful
> through the IPv6 deployment. Note, however, that further work on
> this document may still be needed. Once the API specification
> becomes mature and is deployed among implementations, it may be
> formally standardized by a more appropriate body, such as has been
> done with the Basic API [RFC XXX]
Okay. I'll put it to the draft.
>> >> 5. Extensions to Socket Ancillary Data
>> >>
>> >> This specification uses ancillary data as defined in Posix.1g with
>> >> the following compatible extensions:
>> > should this ID also include text relative to the austin group work?
>> I'm not sure what this comment exactly means...does the proposed
>> change in Introduction answer to this comment?
> I'm asking whether at this point in time we should be referencing the
> posix.1g work as what we want to align with, or whether its the newer
> revision that has been formally adopted by the Austin
> Group. Presumably, they are not the same.
Okay, perhaps we need comments from experts on this area. Or is it
possible to get the latest work of the Austin Group on the web?
>> >> ENXIO The interface specified by ipi6_ifindex does not exist
>> >>
>> >> ENETDOWN The interface specified by ipi6_ifindex is not enabled for
>> >> IPv6 use.
>> >>
>> > Indention not right. (too far to left)
> This is minor formatting issue. In the ID, the terms "ENXIO" and
> "ENETDOWN" are all the way at the left margin. But all the other
> text in the document is indented 3 spaces. This seems to be an
> exception here.
Ah, I see. I'll fix them. (actually, this is not the only exception.
The document also has the same indentation violation in sections 1, 4,
5, 12, 17, and 18. I'll fix them too.
>> >> int inet6_opt_init(void *extbuf, size_t extlen);
>> >>
>> >> This function returns the number of bytes needed for the empty
>> >> extension header i.e. without any options.
>> > I don't understand this sentence. Does this then always return the
>> > same value? And doesn't an "empty" header require 0 bytes? Or is this
>> > actually "length remaining"?
>> > Actully, the "length" field is weird in subsequent usages to. Is it
>> > really a length, or an offset into the options? Calling it length is
>> > confusing. Is it too late to change this?
>> Yes, it always returns the same value (except -1 for errors). In our
>> implementation, the value is 2 (the length of the "next header" and
>> the "length" fields of an IPv6 option header), but I think the actual
>> value can be hidden from the caller.
> Right. If the function always returns the same value by definition,
> why return a value at all?
Because the actual value may be different among implementations, and
the value is transparently used in the succeeding calls to
inet6_opt_append(), etc. I believe even an implementation that does
not return a constant value without breaking the specification.
>> As shown in the usage examples in Section 23, the "length" value is
>> actually used as a kind of "offset." I don't think the current text
>> is confusing, but we can rewrite the description using the term
>> "offset". (It would not be too late, because the change will not
>> break compatibility to existing implementations). Do you think we
>> need the change?
> Personally, I think the term "offset" would be clearer since that is
> indeed what the variable seems to be holding..
So, perhaps we can improve the wording by saying
- the return value of inet6_opt_xxx is expected to be used
transparently, and the application should not care about the exact
value.
- in a sequence of calling inet6_opt_xxx, the 'prevlen' arguments are
used as a kind of offset. but, again, the application should not
care about the exact value.
- (additionally) the return value of inet6_opt_init() may or may not
be constant. in any case, the application should not make any
assumption on the actual return value.
Also, if necessary, I don't mind to change the parameter name
'prevlen' to (e.g.) 'offset'.
Does this make sense?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[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]
--------------------------------------------------------------------
